finallycoffee/matrix-docker-ansible-deploy
finallycoffee/matrix-docker-ansible-deploy
5
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
e645b0e372
matrix-docker-ansible-deploy/roles/matrix-nginx-proxy/defaults/main.yml

119 lines
7.0 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
# those as more frequently out of date.
Update some Docker images
2019-03-03 10:27:43 +00:00
matrix_nginx_proxy_docker_image: "nginx:1.15.9-alpine"
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: []
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
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"
matrix_nginx_proxy_proxy_matrix_federation_api_client_max_body_size_mb: "{{ matrix_nginx_proxy_proxy_matrix_client_api_client_max_body_size_mb * 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.
Initial work on Synapse 0.99/1.0 preparation
2019-02-05 09:07:08 +00:00
matrix_nginx_proxy_tmp_directory_size_mb: "{{ matrix_nginx_proxy_proxy_matrix_federation_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 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
# 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 some Docker images
2019-03-03 10:27:43 +00:00
matrix_ssl_lets_encrypt_certbot_docker_image: "certbot/certbot:v0.31.0"
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"
Reference in New Issue Copy Permalink