self-hosted/matrix-docker-ansible-deploy
1
0
Fork 0
mirror of https://github.com/spantaleev/matrix-docker-ansible-deploy.git synced 2024-12-12 08:43:55 +02:00
Code Issues Releases Activity
d5a0f562ba
matrix-docker-ansible-deploy/roles/matrix-nginx-proxy/defaults/main.yml

92 lines
5.1 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 17:53:00 +02: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 20:25:13 +02:00
# We use an official nginx image, which we fix-up to run unprivileged.
# An alternative would be an `nginxinc/nginx-unprivileged` image, but
# those as more frequently out of date.
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 17:53:00 +02:00
matrix_nginx_proxy_docker_image: "nginx:1.15.8-alpine"
matrix_nginx_proxy_data_path: "{{ matrix_base_data_path }}/nginx-proxy"
matrix_nginx_proxy_confd_path: "{{ matrix_nginx_proxy_data_path }}/conf.d"
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 18:05:48 +02: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: []
# Controls whether proxying the riot domain should be done.
matrix_nginx_proxy_proxy_riot_enabled: false
matrix_nginx_proxy_proxy_riot_hostname: "{{ hostname_riot }}"
# Controls whether proxying the matrix domain should be done.
matrix_nginx_proxy_proxy_matrix_enabled: false
matrix_nginx_proxy_proxy_matrix_hostname: "{{ hostname_matrix }}"
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 13:32:46 +02: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"
matrix_nginx_proxy_proxy_matrix_corporal_api_addr_sans_container: "localhost:41081"
Use mxisd for user directory searches Implements #77 (Github issue).
2019-01-17 15:55:23 +02: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"
matrix_nginx_proxy_proxy_matrix_user_directory_search_addr_sans_container: "localhost: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 13:32:46 +02: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"
matrix_nginx_proxy_proxy_matrix_identity_api_addr_sans_container: "localhost:8090"
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 17:53:00 +02: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 13:32:46 +02:00
matrix_nginx_proxy_proxy_matrix_client_api_addr_with_container: "matrix-synapse:8008"
matrix_nginx_proxy_proxy_matrix_client_api_addr_sans_container: "localhost:8008"
# 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 18:52:02 +02:00
matrix_nginx_proxy_proxy_matrix_client_api_client_max_body_size_mb: 25
# The tmpfs at /tmp needs to be large enough to handle multiple concurrent file uploads.
matrix_nginx_proxy_tmp_directory_size_mb: "{{ matrix_nginx_proxy_proxy_matrix_client_api_client_max_body_size_mb * 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 13:32:46 +02: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 17:53:00 +02: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
# Note TLSv1.3 is not yet available in dockerized nginx
# See: https://github.com/nginxinc/docker-nginx/issues/190
matrix_nginx_proxy_ssl_protocols: "TLSv1.1 TLSv1.2"
# 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)
#
# 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
# where <domain> refers to the domains that you need (usually `hostname_matrix` and `hostname_riot`).
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 18:05:48 +02: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 17:53:00 +02:00
# Controls whether to obtain production or staging certificates from Let's Encrypt.
matrix_ssl_lets_encrypt_staging: false
matrix_ssl_lets_encrypt_certbot_docker_image: "certbot/certbot:v0.30.0"
matrix_ssl_lets_encrypt_certbot_standalone_http_port: 2402
matrix_ssl_lets_encrypt_support_email: "{{ host_specific_matrix_ssl_lets_encrypt_support_email }}"
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 18:52:02 +02:00
matrix_ssl_log_dir_path: "{{ matrix_ssl_base_path }}/log"
Reference in New Issue Copy Permalink