ansol/matrix-docker-ansible-deploy
7
0
Fork 0
mirror of https://github.com/spantaleev/matrix-docker-ansible-deploy.git synced 2024-11-07 16:12:43 +00:00
Code Issues Projects Releases Wiki Activity
3264024055
matrix-docker-ansible-deploy/roles/matrix-nginx-proxy/defaults/main.yml

160 lines
9.2 KiB
YAML
Raw Normal View History

Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable.
2019-01-12 15:53:00 +00:00
matrix_nginx_proxy_enabled: true
Make (most) containers start as non-root This makes all containers (except mautrix-telegram and mautrix-whatsapp), start as a non-root user. We do this, because we don't trust some of the images. In any case, we'd rather not trust ALL images and avoid giving `root` access at all. We can't be sure they would drop privileges or what they might do before they do it. Because Postfix doesn't support running as non-root, it had to be replaced by an Exim mail server. The matrix-nginx-proxy nginx container image is patched up (by replacing its main configuration) so that it can work as non-root. It seems like there's no other good image that we can use and that is up-to-date (https://hub.docker.com/r/nginxinc/nginx-unprivileged is outdated). Likewise for riot-web (https://hub.docker.com/r/bubuntux/riot-web/), we patch it up ourselves when starting (replacing the main nginx configuration). Ideally, it would be fixed upstream so we can simplify.
2019-01-27 18:25:13 +00:00
# We use an official nginx image, which we fix-up to run unprivileged.
# An alternative would be an `nginxinc/nginx-unprivileged` image, but
Automatically force-pull :latest images We do use some `:latest` images by default for the following services: - matrix-dimension - Goofys (in the matrix-synapse role) - matrix-bridge-appservice-irc - matrix-bridge-appservice-discord - matrix-bridge-mautrix-facebook - matrix-bridge-mautrix-whatsapp It's terribly unfortunate that those software projects don't release anything other than `:latest`, but that's how it is for now. Updating that software requires that users manually do `docker pull` on the server. The playbook didn't force-repull images that it already had. With this patch, it starts doing so. Any image tagged `:latest` will be force re-pulled by the playbook every time it's executed. It should be noted that even though we ask the `docker_image` module to force-pull, it only reports "changed" when it actually pulls something new. This is nice, because it lets people know exactly when something gets updated, as opposed to giving the indication that it's always updating the images (even though it isn't).
2019-06-10 11:23:51 +00:00
# that is frequently out of date.
Update nginx and certbot
2019-08-17 07:21:23 +00:00
matrix_nginx_proxy_docker_image: "nginx:1.17.3-alpine"
Automatically force-pull :latest images We do use some `:latest` images by default for the following services: - matrix-dimension - Goofys (in the matrix-synapse role) - matrix-bridge-appservice-irc - matrix-bridge-appservice-discord - matrix-bridge-mautrix-facebook - matrix-bridge-mautrix-whatsapp It's terribly unfortunate that those software projects don't release anything other than `:latest`, but that's how it is for now. Updating that software requires that users manually do `docker pull` on the server. The playbook didn't force-repull images that it already had. With this patch, it starts doing so. Any image tagged `:latest` will be force re-pulled by the playbook every time it's executed. It should be noted that even though we ask the `docker_image` module to force-pull, it only reports "changed" when it actually pulls something new. This is nice, because it lets people know exactly when something gets updated, as opposed to giving the indication that it's always updating the images (even though it isn't).
2019-06-10 11:23:51 +00:00
matrix_nginx_proxy_docker_image_force_pull: "{{ matrix_nginx_proxy_docker_image.endswith(':latest') }}"
Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable.
2019-01-12 15:53:00 +00:00
Rename matrix_nginx_proxy_data_path to matrix_nginx_proxy_base_path `matrix_nginx_proxy_data_path` has always served as a base path, so we're renaming it to reflect that. Along with this, we're also introducing a new "data path" variable (`matrix_nginx_proxy_data_path`), which is really a data path this time. It's used for storing additional, non-configuration, files related to matrix-nginx-proxy.
2019-03-12 20:15:22 +00:00
matrix_nginx_proxy_base_path: "{{ matrix_base_data_path }}/nginx-proxy"
matrix_nginx_proxy_data_path: "{{ matrix_nginx_proxy_base_path }}/data"
matrix_nginx_proxy_confd_path: "{{ matrix_nginx_proxy_base_path }}/conf.d"
Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable.
2019-01-12 15:53:00 +00:00
Make roles more independent of one another With this change, the following roles are now only dependent on the minimal `matrix-base` role: - `matrix-corporal` - `matrix-coturn` - `matrix-mailer` - `matrix-mxisd` - `matrix-postgres` - `matrix-riot-web` - `matrix-synapse` The `matrix-nginx-proxy` role still does too much and remains dependent on the others. Wiring up the various (now-independent) roles happens via a glue variables file (`group_vars/matrix-servers`). It's triggered for all hosts in the `matrix-servers` group. According to Ansible's rules of priority, we have the following chain of inclusion/overriding now: - role defaults (mostly empty or good for independent usage) - playbook glue variables (`group_vars/matrix-servers`) - inventory host variables (`inventory/host_vars/matrix.<your-domain>`) All roles default to enabling their main component (e.g. `matrix_mxisd_enabled: true`, `matrix_riot_web_enabled: true`). Reasoning: if a role is included in a playbook (especially separately, in another playbook), it should "work" by default. Our playbook disables some of those if they are not generally useful (e.g. `matrix_corporal_enabled: false`).
2019-01-16 16:05:48 +00:00
# List of systemd services that matrix-nginx-proxy.service depends on
matrix_nginx_proxy_systemd_required_services_list: ['docker.service']
# List of systemd services that matrix-nginx-proxy.service wants
matrix_nginx_proxy_systemd_wanted_services_list: []
Allow additional volumes to be mounted into matrix-nginx-proxy Certain use-cases may require that people mount additional files into the matrix-nginx-proxy container. Similarly to how we do it for Synapse, we are introducing a new variable that makes this possible (`matrix_nginx_proxy_container_additional_volumes`). This makes the htpasswd file for Synapse Metrics (introduced in #86, Github Pull Request) to also perform mounting using this new mechanism. Hopefully, for such an "extension", keeping htpasswd file-creation and volume definition in the same place (the tasks file) is better. All other major volumes' mounting mechanism remains the same (explicit mounting).
2019-02-05 09:46:16 +00:00
# A list of additional "volumes" to mount in the container.
# This list gets populated dynamically at runtime. You can provide a different default value,
# if you wish to mount your own files into the container.
# Contains definition objects like this: `{"src": "/outside", "dst": "/inside", "options": "rw|ro|slave|.."}
matrix_nginx_proxy_container_additional_volumes: []
Add the possibility to pass extra flags to the docker container
2019-04-30 14:35:18 +00:00
# A list of extra arguments to pass to the container
matrix_nginx_proxy_container_extra_arguments: []
Add support for serving base domain via matrix-nginx-proxy
2019-03-12 20:27:18 +00:00
# Controls whether matrix-nginx-proxy should serve the base domain.
#
# This is useful for when you only have your Matrix server, but you need to serve
# to serve `/.well-known/matrix/*` files from the base domain for the needs of
# Server-Discovery (Federation) and for Client-Discovery.
#
# Besides serving these Matrix files, a homepage would be served with content
# as specified in the `matrix_nginx_proxy_base_domain_homepage_template` variable.
# You can also put additional files to use for this webpage
# in the `{{ matrix_nginx_proxy_data_path }}/matrix-domain` (`/matrix/nginx-proxy/data/matrix-domain`) directory.
matrix_nginx_proxy_base_domain_serving_enabled: false
matrix_nginx_proxy_base_domain_hostname: "{{ matrix_domain }}"
matrix_nginx_proxy_base_domain_homepage_template: |-
<!doctype html>
<meta charset="utf-8" />
<html>
<body>
Hello from {{ matrix_domain }}!
</body>
</html>
Make roles more independent of one another With this change, the following roles are now only dependent on the minimal `matrix-base` role: - `matrix-corporal` - `matrix-coturn` - `matrix-mailer` - `matrix-mxisd` - `matrix-postgres` - `matrix-riot-web` - `matrix-synapse` The `matrix-nginx-proxy` role still does too much and remains dependent on the others. Wiring up the various (now-independent) roles happens via a glue variables file (`group_vars/matrix-servers`). It's triggered for all hosts in the `matrix-servers` group. According to Ansible's rules of priority, we have the following chain of inclusion/overriding now: - role defaults (mostly empty or good for independent usage) - playbook glue variables (`group_vars/matrix-servers`) - inventory host variables (`inventory/host_vars/matrix.<your-domain>`) All roles default to enabling their main component (e.g. `matrix_mxisd_enabled: true`, `matrix_riot_web_enabled: true`). Reasoning: if a role is included in a playbook (especially separately, in another playbook), it should "work" by default. Our playbook disables some of those if they are not generally useful (e.g. `matrix_corporal_enabled: false`).
2019-01-16 16:05:48 +00:00
# Controls whether proxying the riot domain should be done.
matrix_nginx_proxy_proxy_riot_enabled: false
Rename some variables
2019-02-28 09:51:09 +00:00
matrix_nginx_proxy_proxy_riot_hostname: "{{ matrix_server_fqn_riot }}"
Make roles more independent of one another With this change, the following roles are now only dependent on the minimal `matrix-base` role: - `matrix-corporal` - `matrix-coturn` - `matrix-mailer` - `matrix-mxisd` - `matrix-postgres` - `matrix-riot-web` - `matrix-synapse` The `matrix-nginx-proxy` role still does too much and remains dependent on the others. Wiring up the various (now-independent) roles happens via a glue variables file (`group_vars/matrix-servers`). It's triggered for all hosts in the `matrix-servers` group. According to Ansible's rules of priority, we have the following chain of inclusion/overriding now: - role defaults (mostly empty or good for independent usage) - playbook glue variables (`group_vars/matrix-servers`) - inventory host variables (`inventory/host_vars/matrix.<your-domain>`) All roles default to enabling their main component (e.g. `matrix_mxisd_enabled: true`, `matrix_riot_web_enabled: true`). Reasoning: if a role is included in a playbook (especially separately, in another playbook), it should "work" by default. Our playbook disables some of those if they are not generally useful (e.g. `matrix_corporal_enabled: false`).
2019-01-16 16:05:48 +00:00
# Controls whether proxying the matrix domain should be done.
matrix_nginx_proxy_proxy_matrix_enabled: false
Rename some variables
2019-02-28 09:51:09 +00:00
matrix_nginx_proxy_proxy_matrix_hostname: "{{ matrix_server_fqn_matrix }}"
Make roles more independent of one another With this change, the following roles are now only dependent on the minimal `matrix-base` role: - `matrix-corporal` - `matrix-coturn` - `matrix-mailer` - `matrix-mxisd` - `matrix-postgres` - `matrix-riot-web` - `matrix-synapse` The `matrix-nginx-proxy` role still does too much and remains dependent on the others. Wiring up the various (now-independent) roles happens via a glue variables file (`group_vars/matrix-servers`). It's triggered for all hosts in the `matrix-servers` group. According to Ansible's rules of priority, we have the following chain of inclusion/overriding now: - role defaults (mostly empty or good for independent usage) - playbook glue variables (`group_vars/matrix-servers`) - inventory host variables (`inventory/host_vars/matrix.<your-domain>`) All roles default to enabling their main component (e.g. `matrix_mxisd_enabled: true`, `matrix_riot_web_enabled: true`). Reasoning: if a role is included in a playbook (especially separately, in another playbook), it should "work" by default. Our playbook disables some of those if they are not generally useful (e.g. `matrix_corporal_enabled: false`).
2019-01-16 16:05:48 +00:00
Implement self-hosted Dimension server
2019-03-07 05:22:08 +00:00
# Controls whether proxying the dimension domain should be done.
matrix_nginx_proxy_proxy_dimension_enabled: false
matrix_nginx_proxy_proxy_dimension_hostname: "{{ matrix_server_fqn_dimension }}"
Make matrix-nginx-proxy role independent of others The matrix-nginx-proxy role can now be used independently. This makes it consistent with all other roles, with the `matrix-base` role remaining as their only dependency. Separating matrix-nginx-proxy was relatively straightforward, with the exception of the Mautrix Telegram reverse-proxying configuration. Mautrix Telegram, being an extension/bridge, does not feel important enough to justify its own special handling in matrix-nginx-proxy. Thus, we've introduced the concept of "additional configuration blocks" (`matrix_nginx_proxy_proxy_matrix_additional_server_configuration_blocks`), where any module can register its own custom nginx server blocks. For such dynamic registration to work, the order of role execution becomes important. To make it possible for each module participating in dynamic registration to verify that the order of execution is correct, we've also introduced a `matrix_nginx_proxy_role_executed` variable. It should be noted that this doesn't make the matrix-synapse role dependent on matrix-nginx-proxy. It's optional runtime detection and registration, and it only happens in the matrix-synapse role when `matrix_mautrix_telegram_enabled: true`.
2019-01-17 11:32:46 +00:00
# Controls whether proxying for the matrix-corporal API (`/_matrix/corporal`) should be done (on the matrix domain)
matrix_nginx_proxy_proxy_matrix_corporal_api_enabled: false
matrix_nginx_proxy_proxy_matrix_corporal_api_addr_with_container: "matrix-corporal:41081"
Use IPv4 localhost everywhere (or almost everywhere)
2019-02-04 15:49:45 +00:00
matrix_nginx_proxy_proxy_matrix_corporal_api_addr_sans_container: "127.0.0.1:41081"
Make matrix-nginx-proxy role independent of others The matrix-nginx-proxy role can now be used independently. This makes it consistent with all other roles, with the `matrix-base` role remaining as their only dependency. Separating matrix-nginx-proxy was relatively straightforward, with the exception of the Mautrix Telegram reverse-proxying configuration. Mautrix Telegram, being an extension/bridge, does not feel important enough to justify its own special handling in matrix-nginx-proxy. Thus, we've introduced the concept of "additional configuration blocks" (`matrix_nginx_proxy_proxy_matrix_additional_server_configuration_blocks`), where any module can register its own custom nginx server blocks. For such dynamic registration to work, the order of role execution becomes important. To make it possible for each module participating in dynamic registration to verify that the order of execution is correct, we've also introduced a `matrix_nginx_proxy_role_executed` variable. It should be noted that this doesn't make the matrix-synapse role dependent on matrix-nginx-proxy. It's optional runtime detection and registration, and it only happens in the matrix-synapse role when `matrix_mautrix_telegram_enabled: true`.
2019-01-17 11:32:46 +00:00
Use mxisd for user directory searches Implements #77 (Github issue).
2019-01-17 13:55:23 +00:00
# Controls whether proxying for the User Directory Search API (`/_matrix/client/r0/user_directory/search`) should be done (on the matrix domain).
# This can be used to forward the API endpoint to another service, augmenting the functionality of Synapse's own User Directory Search.
# To learn more, see: https://github.com/kamax-matrix/mxisd/blob/master/docs/features/directory.md
matrix_nginx_proxy_proxy_matrix_user_directory_search_enabled: false
matrix_nginx_proxy_proxy_matrix_user_directory_search_addr_with_container: "matrix-mxisd:8090"
Use IPv4 localhost everywhere (or almost everywhere)
2019-02-04 15:49:45 +00:00
matrix_nginx_proxy_proxy_matrix_user_directory_search_addr_sans_container: "127.0.0.1:8090"
Use mxisd for user directory searches Implements #77 (Github issue).
2019-01-17 13:55:23 +00:00
Add option to proxy 3pid registration endpoints
2019-05-08 18:49:51 +00:00
# Controls whether proxying for 3PID-based registration (`/_matrix/client/r0/register/(email|msisdn)/requestToken`) should be done (on the matrix domain).
# This allows another service to control registrations involving 3PIDs.
# To learn more, see: https://github.com/kamax-matrix/mxisd/blob/master/docs/features/registration.md
matrix_nginx_proxy_proxy_matrix_3pid_registration_enabled: false
matrix_nginx_proxy_proxy_matrix_3pid_registration_addr_with_container: "matrix-mxisd:8090"
matrix_nginx_proxy_proxy_matrix_3pid_registration_addr_sans_container: "127.0.0.1:8090"
Make matrix-nginx-proxy role independent of others The matrix-nginx-proxy role can now be used independently. This makes it consistent with all other roles, with the `matrix-base` role remaining as their only dependency. Separating matrix-nginx-proxy was relatively straightforward, with the exception of the Mautrix Telegram reverse-proxying configuration. Mautrix Telegram, being an extension/bridge, does not feel important enough to justify its own special handling in matrix-nginx-proxy. Thus, we've introduced the concept of "additional configuration blocks" (`matrix_nginx_proxy_proxy_matrix_additional_server_configuration_blocks`), where any module can register its own custom nginx server blocks. For such dynamic registration to work, the order of role execution becomes important. To make it possible for each module participating in dynamic registration to verify that the order of execution is correct, we've also introduced a `matrix_nginx_proxy_role_executed` variable. It should be noted that this doesn't make the matrix-synapse role dependent on matrix-nginx-proxy. It's optional runtime detection and registration, and it only happens in the matrix-synapse role when `matrix_mautrix_telegram_enabled: true`.
2019-01-17 11:32:46 +00:00
# Controls whether proxying for the Identity API (`/_matrix/identity`) should be done (on the matrix domain)
matrix_nginx_proxy_proxy_matrix_identity_api_enabled: false
matrix_nginx_proxy_proxy_matrix_identity_api_addr_with_container: "matrix-mxisd:8090"
Use IPv4 localhost everywhere (or almost everywhere)
2019-02-04 15:49:45 +00:00
matrix_nginx_proxy_proxy_matrix_identity_api_addr_sans_container: "127.0.0.1:8090"
Make matrix-nginx-proxy role independent of others The matrix-nginx-proxy role can now be used independently. This makes it consistent with all other roles, with the `matrix-base` role remaining as their only dependency. Separating matrix-nginx-proxy was relatively straightforward, with the exception of the Mautrix Telegram reverse-proxying configuration. Mautrix Telegram, being an extension/bridge, does not feel important enough to justify its own special handling in matrix-nginx-proxy. Thus, we've introduced the concept of "additional configuration blocks" (`matrix_nginx_proxy_proxy_matrix_additional_server_configuration_blocks`), where any module can register its own custom nginx server blocks. For such dynamic registration to work, the order of role execution becomes important. To make it possible for each module participating in dynamic registration to verify that the order of execution is correct, we've also introduced a `matrix_nginx_proxy_role_executed` variable. It should be noted that this doesn't make the matrix-synapse role dependent on matrix-nginx-proxy. It's optional runtime detection and registration, and it only happens in the matrix-synapse role when `matrix_mautrix_telegram_enabled: true`.
2019-01-17 11:32:46 +00:00
Enable exposure of Prometheus metrics.
2019-01-30 18:31:50 +00:00
# Controls whether proxying for metrics (`/_synapse/metrics`) should be done (on the matrix domain)
matrix_nginx_proxy_proxy_synapse_metrics: false
matrix_nginx_proxy_proxy_synapse_metrics_basic_auth_enabled: false
matrix_nginx_proxy_proxy_synapse_metrics_basic_auth_key: ""
Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable.
2019-01-12 15:53:00 +00:00
# The addresses where the Matrix Client API is.
# Certain extensions (like matrix-corporal) may override this in order to capture all traffic.
Make matrix-nginx-proxy role independent of others The matrix-nginx-proxy role can now be used independently. This makes it consistent with all other roles, with the `matrix-base` role remaining as their only dependency. Separating matrix-nginx-proxy was relatively straightforward, with the exception of the Mautrix Telegram reverse-proxying configuration. Mautrix Telegram, being an extension/bridge, does not feel important enough to justify its own special handling in matrix-nginx-proxy. Thus, we've introduced the concept of "additional configuration blocks" (`matrix_nginx_proxy_proxy_matrix_additional_server_configuration_blocks`), where any module can register its own custom nginx server blocks. For such dynamic registration to work, the order of role execution becomes important. To make it possible for each module participating in dynamic registration to verify that the order of execution is correct, we've also introduced a `matrix_nginx_proxy_role_executed` variable. It should be noted that this doesn't make the matrix-synapse role dependent on matrix-nginx-proxy. It's optional runtime detection and registration, and it only happens in the matrix-synapse role when `matrix_mautrix_telegram_enabled: true`.
2019-01-17 11:32:46 +00:00
matrix_nginx_proxy_proxy_matrix_client_api_addr_with_container: "matrix-synapse:8008"
Use IPv4 localhost everywhere (or almost everywhere)
2019-02-04 15:49:45 +00:00
matrix_nginx_proxy_proxy_matrix_client_api_addr_sans_container: "127.0.0.1:8008"
Make matrix-nginx-proxy role independent of others The matrix-nginx-proxy role can now be used independently. This makes it consistent with all other roles, with the `matrix-base` role remaining as their only dependency. Separating matrix-nginx-proxy was relatively straightforward, with the exception of the Mautrix Telegram reverse-proxying configuration. Mautrix Telegram, being an extension/bridge, does not feel important enough to justify its own special handling in matrix-nginx-proxy. Thus, we've introduced the concept of "additional configuration blocks" (`matrix_nginx_proxy_proxy_matrix_additional_server_configuration_blocks`), where any module can register its own custom nginx server blocks. For such dynamic registration to work, the order of role execution becomes important. To make it possible for each module participating in dynamic registration to verify that the order of execution is correct, we've also introduced a `matrix_nginx_proxy_role_executed` variable. It should be noted that this doesn't make the matrix-synapse role dependent on matrix-nginx-proxy. It's optional runtime detection and registration, and it only happens in the matrix-synapse role when `matrix_mautrix_telegram_enabled: true`.
2019-01-17 11:32:46 +00:00
# This needs to be equal or higher than the maximum upload size accepted by Synapse.
Make (most) containers run with a read-only filesystem
2019-01-29 16:52:02 +00:00
matrix_nginx_proxy_proxy_matrix_client_api_client_max_body_size_mb: 25
Initial work on Synapse 0.99/1.0 preparation
2019-02-05 09:07:08 +00:00
# Controls whether proxying for the Matrix Federation API should be done.
matrix_nginx_proxy_proxy_matrix_federation_api_enabled: false
matrix_nginx_proxy_proxy_matrix_federation_api_addr_with_container: "matrix-synapse:8048"
matrix_nginx_proxy_proxy_matrix_federation_api_addr_sans_container: "localhost:8048"
Add explicit |int casting for more variables As discussed in #151 (Github Pull Request), it's a good idea to not selectively apply casting, but to do it in all cases involving arithmetic operations.
2019-04-30 15:25:57 +00:00
matrix_nginx_proxy_proxy_matrix_federation_api_client_max_body_size_mb: "{{ (matrix_nginx_proxy_proxy_matrix_client_api_client_max_body_size_mb | int) * 3 }}"
Allow for the federation port (tcp/8448)'s certificate to be changed If someone decides to not use `/.well-known/matrix/server` and only relies on SRV records, then they would need to serve tcp/8448 using a certificate for the base domain (not for the matrix) domain. Until now, they could do that by giving the certificate to Synapse and setting it terminate TLS. That makes swapping certificates more annoying (Synapse requires a restart to re-read certificates), so it's better if we can support it via matrix-nginx-proxy. Mounting certificates (or any other file) into the matrix-nginx-proxy container can be done with `matrix_nginx_proxy_container_additional_volumes`, introduced in 96afbbb5a.
2019-02-05 09:49:59 +00:00
matrix_nginx_proxy_proxy_matrix_federation_api_ssl_certificate: "{{ matrix_ssl_config_dir_path }}/live/{{ matrix_nginx_proxy_proxy_matrix_hostname }}/fullchain.pem"
matrix_nginx_proxy_proxy_matrix_federation_api_ssl_certificate_key: "{{ matrix_ssl_config_dir_path }}/live/{{ matrix_nginx_proxy_proxy_matrix_hostname }}/privkey.pem"
Initial work on Synapse 0.99/1.0 preparation
2019-02-05 09:07:08 +00:00
Make (most) containers run with a read-only filesystem
2019-01-29 16:52:02 +00:00
# The tmpfs at /tmp needs to be large enough to handle multiple concurrent file uploads.
Fix value of nginx-proxy tmpfs size Use an int conversion in the computation of the value of matrix_nginx_proxy_tmp_directory_size_mb, to have the integer value multiplied by 50 instead of having the string repeated 50 times.
2019-04-27 19:54:21 +00:00
matrix_nginx_proxy_tmp_directory_size_mb: "{{ (matrix_nginx_proxy_proxy_matrix_federation_api_client_max_body_size_mb | int) * 50 }}"
Make matrix-nginx-proxy role independent of others The matrix-nginx-proxy role can now be used independently. This makes it consistent with all other roles, with the `matrix-base` role remaining as their only dependency. Separating matrix-nginx-proxy was relatively straightforward, with the exception of the Mautrix Telegram reverse-proxying configuration. Mautrix Telegram, being an extension/bridge, does not feel important enough to justify its own special handling in matrix-nginx-proxy. Thus, we've introduced the concept of "additional configuration blocks" (`matrix_nginx_proxy_proxy_matrix_additional_server_configuration_blocks`), where any module can register its own custom nginx server blocks. For such dynamic registration to work, the order of role execution becomes important. To make it possible for each module participating in dynamic registration to verify that the order of execution is correct, we've also introduced a `matrix_nginx_proxy_role_executed` variable. It should be noted that this doesn't make the matrix-synapse role dependent on matrix-nginx-proxy. It's optional runtime detection and registration, and it only happens in the matrix-synapse role when `matrix_mautrix_telegram_enabled: true`.
2019-01-17 11:32:46 +00:00
# A list of strings containing additional configuration blocks to add to the matrix domain's server configuration.
matrix_nginx_proxy_proxy_matrix_additional_server_configuration_blocks: []
Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable.
2019-01-12 15:53:00 +00:00
# Specifies when to reload the matrix-nginx-proxy service so that
# a new SSL certificate could go into effect.
matrix_nginx_proxy_reload_cron_time_definition: "20 4 */5 * *"
# Specifies which SSL protocols to use when serving Riot and Synapse
Add TLS v1.3 support to matrix-nginx-proxy This was mentioned in #27 (Github Pull Request), but it's just now that the nginx Docker image actually supports TLS v1.3 and we can enable it.
2019-02-01 09:47:43 +00:00
matrix_nginx_proxy_ssl_protocols: "TLSv1.1 TLSv1.2 TLSv1.3"
Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable.
2019-01-12 15:53:00 +00:00
Make self-check not validate self-signed certificates By default, `--tags=self-check` no longer validates certificates when `matrix_ssl_retrieval_method` is set to `self-signed`. Besides this default, people can also enable/disable validation using the individual role variables manually. Fixes #124 (Github Issue)
2019-03-22 07:39:17 +00:00
# Controls whether the self-check feature should validate SSL certificates.
matrix_nginx_proxy_self_check_validate_certificates: true
Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable.
2019-01-12 15:53:00 +00:00
# By default, this playbook automatically retrieves and auto-renews
# free SSL certificates from Let's Encrypt.
#
# The following retrieval methods are supported:
# - "lets-encrypt" - the playbook obtains free SSL certificates from Let's Encrypt
# - "self-signed" - the playbook generates and self-signs certificates
# - "manually-managed" - lets you manage certificates by yourself (manually; see below)
Add 'none' SSL certificate retrieval method
2019-02-01 14:50:02 +00:00
# - "none" - like "manually-managed", but doesn't care if you don't drop certificates in the location it expects
Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable.
2019-01-12 15:53:00 +00:00
#
# If you decide to manage certificates by yourself (`matrix_ssl_retrieval_method: manually-managed`),
# you'd need to drop them into the directory specified by `matrix_ssl_config_dir_path`
# obeying the following hierarchy:
# - <matrix_ssl_config_dir_path>/live/<domain>/fullchain.pem
# - <matrix_ssl_config_dir_path>/live/<domain>/privkey.pem
Rename some variables
2019-02-28 09:51:09 +00:00
# where <domain> refers to the domains that you need (usually `matrix_server_fqn_matrix` and `matrix_server_fqn_riot`).
Add 'none' SSL certificate retrieval method
2019-02-01 14:50:02 +00:00
#
# The "none" type (`matrix_ssl_retrieval_method: none`), simply means that no certificate retrieval will happen.
# It's useful for when you've disabled the nginx proxy (`matrix_nginx_proxy_enabled: false`)
# and you'll be using another reverse-proxy server (like Apache) with your own certificates, managed by yourself.
Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable.
2019-01-12 15:53:00 +00:00
matrix_ssl_retrieval_method: "lets-encrypt"
Make roles more independent of one another With this change, the following roles are now only dependent on the minimal `matrix-base` role: - `matrix-corporal` - `matrix-coturn` - `matrix-mailer` - `matrix-mxisd` - `matrix-postgres` - `matrix-riot-web` - `matrix-synapse` The `matrix-nginx-proxy` role still does too much and remains dependent on the others. Wiring up the various (now-independent) roles happens via a glue variables file (`group_vars/matrix-servers`). It's triggered for all hosts in the `matrix-servers` group. According to Ansible's rules of priority, we have the following chain of inclusion/overriding now: - role defaults (mostly empty or good for independent usage) - playbook glue variables (`group_vars/matrix-servers`) - inventory host variables (`inventory/host_vars/matrix.<your-domain>`) All roles default to enabling their main component (e.g. `matrix_mxisd_enabled: true`, `matrix_riot_web_enabled: true`). Reasoning: if a role is included in a playbook (especially separately, in another playbook), it should "work" by default. Our playbook disables some of those if they are not generally useful (e.g. `matrix_corporal_enabled: false`).
2019-01-16 16:05:48 +00:00
# The list of domains that this role will obtain certificates for.
matrix_ssl_domains_to_obtain_certificates_for: []
Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable.
2019-01-12 15:53:00 +00:00
# Controls whether to obtain production or staging certificates from Let's Encrypt.
matrix_ssl_lets_encrypt_staging: false
Update nginx and certbot
2019-08-17 07:21:23 +00:00
matrix_ssl_lets_encrypt_certbot_docker_image: "certbot/certbot:v0.37.1"
Automatically force-pull :latest images We do use some `:latest` images by default for the following services: - matrix-dimension - Goofys (in the matrix-synapse role) - matrix-bridge-appservice-irc - matrix-bridge-appservice-discord - matrix-bridge-mautrix-facebook - matrix-bridge-mautrix-whatsapp It's terribly unfortunate that those software projects don't release anything other than `:latest`, but that's how it is for now. Updating that software requires that users manually do `docker pull` on the server. The playbook didn't force-repull images that it already had. With this patch, it starts doing so. Any image tagged `:latest` will be force re-pulled by the playbook every time it's executed. It should be noted that even though we ask the `docker_image` module to force-pull, it only reports "changed" when it actually pulls something new. This is nice, because it lets people know exactly when something gets updated, as opposed to giving the indication that it's always updating the images (even though it isn't).
2019-06-10 11:23:51 +00:00
matrix_ssl_lets_encrypt_certbot_docker_image_force_pull: "{{ matrix_ssl_lets_encrypt_certbot_docker_image.endswith(':latest') }}"
Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable.
2019-01-12 15:53:00 +00:00
matrix_ssl_lets_encrypt_certbot_standalone_http_port: 2402
Rename some variables
2019-02-28 09:51:09 +00:00
matrix_ssl_lets_encrypt_support_email: ~
Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable.
2019-01-12 15:53:00 +00:00
matrix_ssl_base_path: "{{ matrix_base_data_path }}/ssl"
matrix_ssl_config_dir_path: "{{ matrix_ssl_base_path }}/config"
Make (most) containers run with a read-only filesystem
2019-01-29 16:52:02 +00:00
matrix_ssl_log_dir_path: "{{ matrix_ssl_base_path }}/log"
add suggested change; correct indent
2019-04-23 07:44:02 +00:00
# ngnix status page configurations.
correct defaults
2019-08-07 08:56:29 +00:00
matrix_nginx_proxy_proxy_matrix_nginx_status_enabled: false
matrix_nginx_proxy_proxy_matrix_nginx_status_allowed_addresses: ['{{ ansible_default_ipv4.address }}']
Reference in New Issue Copy Permalink