mirror/matrix-docker-ansible-deploy
1
0
Fork 0
mirror of https://github.com/spantaleev/matrix-docker-ansible-deploy.git synced 2024-11-10 20:57:41 +01:00
Code Issues Packages Projects Releases Wiki Activity
46984a4f99
matrix-docker-ansible-deploy/roles/matrix-nginx-proxy/templates/nginx/conf.d/matrix-synapse.conf.j2

412 lines
16 KiB
Plaintext
Raw Normal View History

Fix indentation in templates Use Jinja2 lstrip_blocks option in templates to ensure consistent indentation in generated files.
2019-05-07 21:23:35 +02:00
#jinja2: lstrip_blocks: "True"
Serve nginx status page over HTTPS as well Continuation of #234 (Github Pull Request). I had unintentionally updated the documentation for the feature, saying the page is available at `https://matrix.DOMAIN/nginx_status`. Looks like it wasn't the case, going against my expectations. I'm correcting this with this patch. The status page is being made available on both HTTP and HTTPS. Serving over HTTP is likely necessary for services like Longview (https://www.linode.com/docs/platform/longview/longview-app-for-nginx/)
2019-08-07 11:53:53 +02:00
{% macro render_nginx_status_location_block(addresses) %}
{# Empty first line to make indentation prettier. #}
location /nginx_status {
stub_status on;
access_log off;
{% for address in addresses %}
allow {{ address }};
{% endfor %}
deny all;
}
{% endmacro %}
Initial commit
2017-07-31 22:07:30 +02:00
Add support to matrix-nginx-proxy to work in HTTP-only mode
2019-12-06 10:53:09 +01:00
{% macro render_vhost_directives() %}
Improve compression support
2018-08-17 07:00:38 +02:00
gzip on;
Fix nginx warning: adding already-default text/html to gzip_types
2018-08-17 09:44:34 +02:00
gzip_types text/plain application/json;
Improve compression support
2018-08-17 07:00:38 +02:00
Initial work on Synapse 0.99/1.0 preparation
2019-02-05 10:07:08 +01:00
location /.well-known/matrix {
Add Service Discovery (/.well-known/matrix/client) support
2018-09-17 09:51:46 +02:00
root {{ matrix_static_files_base_path }};
Cache /.well-known/matrix files for longer
2019-02-05 12:06:17 +01:00
{#
A somewhat long expires value is used to prevent outages
in case this is unreachable due to network failure or
due to the base domain's server completely dying.
#}
expires 4h;
Add Service Discovery (/.well-known/matrix/client) support
2018-09-17 09:51:46 +02:00
default_type application/json;
Fix /.well-known/matrix/client for CORS This is provoked by Github issue #46. No client had made use of the well-known mechanism so far, so the set up performed by this playbook was not tested and turned out to be a little deficient. Even though /.well-known/matrix/client is usually requested with a simple request (no preflight), it's still considered cross-origin and [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) applies. Thus, the file always needs to be served with the appropriate `Access-Control-Allow-Origin` header. Github issue #46 attempts to fix it at the "reverse-proxying" layer, which may work, but would need to be done for every server. It's better if it's done "upstream", so that all reverse-proxy configurations can benefit.
2018-11-29 07:35:57 +01:00
add_header Access-Control-Allow-Origin *;
Add Service Discovery (/.well-known/matrix/client) support
2018-09-17 09:51:46 +02:00
}
Serve nginx status page over HTTPS as well Continuation of #234 (Github Pull Request). I had unintentionally updated the documentation for the feature, saying the page is available at `https://matrix.DOMAIN/nginx_status`. Looks like it wasn't the case, going against my expectations. I'm correcting this with this patch. The status page is being made available on both HTTP and HTTPS. Serving over HTTP is likely necessary for services like Longview (https://www.linode.com/docs/platform/longview/longview-app-for-nginx/)
2019-08-07 11:53:53 +02:00
{% if matrix_nginx_proxy_proxy_matrix_nginx_status_enabled %}
{{ render_nginx_status_location_block(matrix_nginx_proxy_proxy_matrix_nginx_status_allowed_addresses) }}
{% endif %}
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 12:32:46 +01:00
{% if matrix_nginx_proxy_proxy_matrix_corporal_api_enabled %}
Add support for matrix-corporal
2018-08-21 12:34:34 +02:00
location /_matrix/corporal {
{% if matrix_nginx_proxy_enabled %}
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
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 12:32:46 +01:00
set $backend "{{ matrix_nginx_proxy_proxy_matrix_corporal_api_addr_with_container }}";
Add support for matrix-corporal
2018-08-21 12:34:34 +02:00
proxy_pass http://$backend;
{% else %}
{# Generic configuration for use outside of our container setup #}
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 12:32:46 +01:00
proxy_pass http://{{ matrix_nginx_proxy_proxy_matrix_corporal_api_addr_sans_container }};
Add support for matrix-corporal
2018-08-21 12:34:34 +02:00
{% endif %}
Pass Host/X-Forwarded-For everywhere It hasn't mattered much to have these so far, but it's probably a good idea to have them.
2019-01-17 15:25:08 +01:00
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
Add support for matrix-corporal
2018-08-21 12:34:34 +02:00
}
{% endif %}
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 12:32:46 +01:00
{% if matrix_nginx_proxy_proxy_matrix_identity_api_enabled %}
Add mxisd Identity Server support
2018-08-15 09:23:22 +02:00
location /_matrix/identity {
{% if matrix_nginx_proxy_enabled %}
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
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 12:32:46 +01:00
set $backend "{{ matrix_nginx_proxy_proxy_matrix_identity_api_addr_with_container }}";
Add mxisd Identity Server support
2018-08-15 09:23:22 +02:00
proxy_pass http://$backend;
{% else %}
{# Generic configuration for use outside of our container setup #}
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 12:32:46 +01:00
proxy_pass http://{{ matrix_nginx_proxy_proxy_matrix_identity_api_addr_sans_container }};
Add mxisd Identity Server support
2018-08-15 09:23:22 +02:00
{% endif %}
Send Host/X-Forwarded-For to mxisd It worked without it too, but doing this is more consistent with the mxisd recommendations.
2019-01-17 15:21:04 +01:00
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
Add mxisd Identity Server support
2018-08-15 09:23:22 +02:00
}
{% endif %}
Use mxisd for user directory searches Implements #77 (Github issue).
2019-01-17 14:55:23 +01:00
{% if matrix_nginx_proxy_proxy_matrix_user_directory_search_enabled %}
location /_matrix/client/r0/user_directory/search {
{% if matrix_nginx_proxy_enabled %}
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
set $backend "{{ matrix_nginx_proxy_proxy_matrix_user_directory_search_addr_with_container }}";
proxy_pass http://$backend;
{% else %}
{# Generic configuration for use outside of our container setup #}
proxy_pass http://{{ matrix_nginx_proxy_proxy_matrix_user_directory_search_addr_sans_container }};
{% endif %}
Send Host/X-Forwarded-For to mxisd It worked without it too, but doing this is more consistent with the mxisd recommendations.
2019-01-17 15:21:04 +01:00
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
Use mxisd for user directory searches Implements #77 (Github issue).
2019-01-17 14:55:23 +01:00
}
{% endif %}
Add option to proxy 3pid registration endpoints
2019-05-08 20:49:51 +02:00
{% if matrix_nginx_proxy_proxy_matrix_3pid_registration_enabled %}
location ~ ^/_matrix/client/r0/register/(email|msisdn)/requestToken$ {
{% if matrix_nginx_proxy_enabled %}
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
set $backend "{{ matrix_nginx_proxy_proxy_matrix_3pid_registration_addr_with_container }}";
proxy_pass http://$backend;
{% else %}
{# Generic configuration for use outside of our container setup #}
proxy_pass http://{{ matrix_nginx_proxy_proxy_matrix_3pid_registration_addr_sans_container }};
{% endif %}
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
{% endif %}
Add to synapse nginx template conditional URL rewrites for workers · 😅 How to keep this in sync with the matrix-synapse documentation? · regex location matching is expensive · nginx syntax limit: one location only per block / statement · thus, lots of duplicate statements in this file
2020-04-11 03:08:59 +02:00
{% if synchrotron_workers %}
{# c.f. https://github.com/matrix-org/synapse/blame/master/docs/workers.md#L134 #}
location /_matrix/client/r0/sync {
proxy_pass http://synchrotron$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
location /_matrix/client/r0/events {
proxy_pass http://synchrotron$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
location /_matrix/client/r0/initialSync {
proxy_pass http://synchrotron$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
location ~ ^/_matrix/client/r0/rooms/[^/]+/initialSync$ {
proxy_pass http://synchrotron$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
{% endif %}
{% set client_reader_worker = matrix_synapse_workers_enabled_list|selectattr('worker', 'equalto', 'client_reader')|first %}
{% if client_reader_worker %}
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
{# c.f. https://github.com/matrix-org/synapse/blame/master/docs/workers.md#L252 #}
location ^/_matrix/client/(versions$|(api/v1|r0|unstable)/(publicRooms$|rooms/.*/joined_me|rooms/.*/context/.|rooms/.*/members$|rooms/.*/messages$|rooms/.*/state$|login$|account/3pid$|keys/query$|keys/changes$|voip/turnServer$|joined_groups$|publicised_groups$|publicised_groups/|pushrules/.*$|groups/.*$|register$|auth/.*/fallback/web$)) {
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
add missing ; to matrix-synapse.conf.j2
2020-04-19 19:50:42 +02:00
set $backend "matrix-synapse:{{ client_reader_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
proxy_pass http://$backend$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
Add to synapse nginx template conditional URL rewrites for workers · 😅 How to keep this in sync with the matrix-synapse documentation? · regex location matching is expensive · nginx syntax limit: one location only per block / statement · thus, lots of duplicate statements in this file
2020-04-11 03:08:59 +02:00
{% endif %}
{% set media_repository_worker = matrix_synapse_workers_enabled_list|selectattr('worker', 'equalto', 'media_repository')|first %}
{% if media_repository_worker %}
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
{# c.f. https://github.com/matrix-org/synapse/blame/master/docs/workers.md#L219 #}
location /_matrix/media/ {
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
add missing ; to matrix-synapse.conf.j2
2020-04-19 19:50:42 +02:00
set $backend "matrix-synapse:{{ media_repository_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
proxy_pass http://$backend$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
{# c.f. https://github.com/matrix-org/synapse/blame/master/docs/workers.md#L223 #}
location ~ ^/_synapse/admin/v1/(purge_media_cache|room/.*/media.*|user/.*/media.*|media/.*|quarantine_media/.*)$ {
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
add missing ; to matrix-synapse.conf.j2
2020-04-19 19:50:42 +02:00
set $backend "matrix-synapse:{{ media_repository_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
proxy_pass http://$backend$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
Add to synapse nginx template conditional URL rewrites for workers · 😅 How to keep this in sync with the matrix-synapse documentation? · regex location matching is expensive · nginx syntax limit: one location only per block / statement · thus, lots of duplicate statements in this file
2020-04-11 03:08:59 +02:00
{% endif %}
{% set event_creator_worker = matrix_synapse_workers_enabled_list|selectattr('worker', 'equalto', 'event_creator')|first %}
{% if event_creator_worker %}
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
{# c.f. https://github.com/matrix-org/synapse/blame/master/docs/workers.md#L323 #}
location ~ ^/_matrix/client/(api/v1|r0|unstable)/(rooms/.*/send|rooms/.*/state/|rooms/.*/(join|invite|leave|ban|unban|kick)$|join/|profile/) {
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
add missing ; to matrix-synapse.conf.j2
2020-04-19 19:50:42 +02:00
set $backend "matrix-synapse:{{ event_creator_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
proxy_pass http://$backend$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
Add to synapse nginx template conditional URL rewrites for workers · 😅 How to keep this in sync with the matrix-synapse documentation? · regex location matching is expensive · nginx syntax limit: one location only per block / statement · thus, lots of duplicate statements in this file
2020-04-11 03:08:59 +02:00
{% endif %}
{% set frontend_proxy_worker = matrix_synapse_workers_enabled_list|selectattr('worker', 'equalto', 'frontend_proxy')|first %}
{% if frontend_proxy_worker %}
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
{# c.f. https://github.com/matrix-org/synapse/blame/master/docs/workers.md#L302 #}
location ~ ^/_matrix/client/(api/v1|r0|unstable)/keys/upload {
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
add missing ; to matrix-synapse.conf.j2
2020-04-19 19:50:42 +02:00
set $backend "matrix-synapse:{{ frontend_proxy_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
proxy_pass http://$backend$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
{% if not matrix_synapse_use_presence %}
location ~ ^/_matrix/client/(api/v1|r0|unstable)/presence/[^/]+/status {
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
add missing ; to matrix-synapse.conf.j2
2020-04-19 19:50:42 +02:00
set $backend "matrix-synapse:{{ frontend_proxy_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
proxy_pass http://$backend$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
{% endif %}
Add to synapse nginx template conditional URL rewrites for workers · 😅 How to keep this in sync with the matrix-synapse documentation? · regex location matching is expensive · nginx syntax limit: one location only per block / statement · thus, lots of duplicate statements in this file
2020-04-11 03:08:59 +02:00
{% endif %}
{% set user_dir_worker = matrix_synapse_workers_enabled_list|selectattr('worker', 'equalto', 'user_dir')|first %}
{% if user_dir_worker %}
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
{# c.f. https://github.com/matrix-org/synapse/blame/master/docs/workers.md#L290 #}
location ~ ^/_matrix/client/(api/v1|r0|unstable)/user_directory/search$ {
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
add missing ; to matrix-synapse.conf.j2
2020-04-19 19:50:42 +02:00
set $backend "matrix-synapse:{{ user_dir_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
proxy_pass http://$backend$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
Add to synapse nginx template conditional URL rewrites for workers · 😅 How to keep this in sync with the matrix-synapse documentation? · regex location matching is expensive · nginx syntax limit: one location only per block / statement · thus, lots of duplicate statements in this file
2020-04-11 03:08:59 +02:00
{% endif %}
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 12:32:46 +01:00
{% for configuration_block in matrix_nginx_proxy_proxy_matrix_additional_server_configuration_blocks %}
{{- configuration_block }}
{% endfor %}
Expose mautrix-telegram public endpoint through nginx It used to allow user to logging with their own account to the bot see: https://github.com/tulir/mautrix-telegram/wiki/Authentication#replacing-telegram-accounts-matrix-puppet-with-matrix-account for more informations
2018-10-21 23:20:37 +02:00
Initial work on Synapse 0.99/1.0 preparation
2019-02-05 10:07:08 +01:00
{#
This handles the Matrix Client API only.
The Matrix Federation API is handled by a separate vhost.
#}
Increase max body size for the nginx proxy Otherwise, we can't support large media file uploads.
2017-08-12 14:39:21 +02:00
location /_matrix {
Put all containers in their own isolated Docker network (matrix) Moving away from using the default bridge network to using our own. This isolates our services from other Docker containers running on the default network on the same host. The benefits are that: - isolation is a little better - we no longer share a default bridge network with any other containers that might be running on the host - there are no longer hard dependencies - we do service discovery by DNS name, and not via explicit `--link` usage during container start, so containers can start out of order and fail without bringing down others with them (`matrix-nginx-proxy` can continue running, even if one of the other services dies) In the future, when other services get introduced, the increased resilience and simplicity will help as well.
2018-08-08 07:23:36 +02:00
{% if matrix_nginx_proxy_enabled %}
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
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 12:32:46 +01:00
set $backend "{{ matrix_nginx_proxy_proxy_matrix_client_api_addr_with_container }}";
Put all containers in their own isolated Docker network (matrix) Moving away from using the default bridge network to using our own. This isolates our services from other Docker containers running on the default network on the same host. The benefits are that: - isolation is a little better - we no longer share a default bridge network with any other containers that might be running on the host - there are no longer hard dependencies - we do service discovery by DNS name, and not via explicit `--link` usage during container start, so containers can start out of order and fail without bringing down others with them (`matrix-nginx-proxy` can continue running, even if one of the other services dies) In the future, when other services get introduced, the increased resilience and simplicity will help as well.
2018-08-08 07:23:36 +02:00
proxy_pass http://$backend;
{% else %}
Minor wording improvements
2018-08-15 09:19:31 +02:00
{# Generic configuration for use outside of our container setup #}
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 12:32:46 +01:00
proxy_pass http://{{ matrix_nginx_proxy_proxy_matrix_client_api_addr_sans_container }};
Put all containers in their own isolated Docker network (matrix) Moving away from using the default bridge network to using our own. This isolates our services from other Docker containers running on the default network on the same host. The benefits are that: - isolation is a little better - we no longer share a default bridge network with any other containers that might be running on the host - there are no longer hard dependencies - we do service discovery by DNS name, and not via explicit `--link` usage during container start, so containers can start out of order and fail without bringing down others with them (`matrix-nginx-proxy` can continue running, even if one of the other services dies) In the future, when other services get introduced, the increased resilience and simplicity will help as well.
2018-08-08 07:23:36 +02:00
{% endif %}
Pass Host/X-Forwarded-For everywhere It hasn't mattered much to have these so far, but it's probably a good idea to have them.
2019-01-17 15:25:08 +01:00
proxy_set_header Host $host;
Increase max body size for the nginx proxy Otherwise, we can't support large media file uploads.
2017-08-12 14:39:21 +02:00
proxy_set_header X-Forwarded-For $remote_addr;
client_body_buffer_size 25M;
Make (most) containers run with a read-only filesystem
2019-01-29 17:52:02 +01:00
client_max_body_size {{ matrix_nginx_proxy_proxy_matrix_client_api_client_max_body_size_mb }}M;
Increase max body size for the nginx proxy Otherwise, we can't support large media file uploads.
2017-08-12 14:39:21 +02:00
proxy_max_temp_file_size 0;
}
Serve a non-scary page at the matrix domain Fixes #18 (Github issue). It would probably be better if we serve our own page, as the Matrix one says: "To use this server you'll need a Matrix client", which is true, but we install Riot by default and it'd be better if we mention that instead.
2018-12-23 18:45:03 +01:00
Enable exposure of Prometheus metrics.
2019-01-30 19:31:50 +01:00
{% if matrix_nginx_proxy_proxy_synapse_metrics %}
location /_synapse/metrics {
{% if matrix_nginx_proxy_enabled %}
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
set $backend "{{ matrix_nginx_proxy_proxy_synapse_metrics_addr_with_container }}";
proxy_pass http://$backend;
{% else %}
{# Generic configuration for use outside of our container setup #}
proxy_pass http://{{ matrix_nginx_proxy_proxy_synapse_metrics_addr_sans_container }};
{% endif %}
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
{% if matrix_nginx_proxy_proxy_synapse_metrics_basic_auth_enabled %}
auth_basic "protected";
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 21:15:22 +01:00
auth_basic_user_file /nginx-data/matrix-synapse-metrics-htpasswd;
Enable exposure of Prometheus metrics.
2019-01-30 19:31:50 +01:00
{% endif %}
}
{% endif %}
Add support for proxying /_synapse/admin APIs Fixes #191 (Github Issue).
2019-05-29 07:32:06 +02:00
location /_synapse/admin {
{% if matrix_nginx_proxy_enabled %}
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
set $backend "{{ matrix_nginx_proxy_proxy_matrix_client_api_addr_with_container }}";
proxy_pass http://$backend;
{% else %}
{# Generic configuration for use outside of our container setup #}
proxy_pass http://{{ matrix_nginx_proxy_proxy_matrix_client_api_addr_sans_container }};
{% endif %}
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
client_body_buffer_size 25M;
client_max_body_size {{ matrix_nginx_proxy_proxy_matrix_client_api_client_max_body_size_mb }}M;
proxy_max_temp_file_size 0;
}
Serve a non-scary page at the matrix domain Fixes #18 (Github issue). It would probably be better if we serve our own page, as the Matrix one says: "To use this server you'll need a Matrix client", which is true, but we install Riot by default and it'd be better if we mention that instead.
2018-12-23 18:45:03 +01:00
location / {
Server non-scary page at matrix domain (take 2) Fix for 12b65d8ccc11217644.
2018-12-29 19:11:37 +01:00
rewrite ^/$ /_matrix/static/ last;
Serve a non-scary page at the matrix domain Fixes #18 (Github issue). It would probably be better if we serve our own page, as the Matrix one says: "To use this server you'll need a Matrix client", which is true, but we install Riot by default and it'd be better if we mention that instead.
2018-12-23 18:45:03 +01:00
}
Add support to matrix-nginx-proxy to work in HTTP-only mode
2019-12-06 10:53:09 +01:00
{% endmacro %}
Add to synapse nginx template conditional URL rewrites for workers · 😅 How to keep this in sync with the matrix-synapse documentation? · regex location matching is expensive · nginx syntax limit: one location only per block / statement · thus, lots of duplicate statements in this file
2020-04-11 03:08:59 +02:00
{% set synchrotron_workers = matrix_synapse_workers_enabled_list|selectattr('worker', 'equalto', 'synchrotron')|list %}
{% if synchrotron_workers %}
upstream synchrotron {
# ensures that requests from the same client will always be passed
# to the same server (except when this server is unavailable)
ip_hash;
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
{% for synchrotron_worker in synchrotron_workers %}
Nginx conf: more testing less b0rk
2020-04-19 19:55:43 +02:00
server "matrix-synapse:{{ synchrotron_worker.port }}";
Add to synapse nginx template conditional URL rewrites for workers · 😅 How to keep this in sync with the matrix-synapse documentation? · regex location matching is expensive · nginx syntax limit: one location only per block / statement · thus, lots of duplicate statements in this file
2020-04-11 03:08:59 +02:00
{% endfor %}
}
{% endif %}
Add support to matrix-nginx-proxy to work in HTTP-only mode
2019-12-06 10:53:09 +01:00
server {
listen {{ 8080 if matrix_nginx_proxy_enabled else 80 }};
server_name {{ matrix_nginx_proxy_proxy_matrix_hostname }};
server_tokens off;
root /dev/null;
{% if matrix_nginx_proxy_https_enabled %}
location /.well-known/acme-challenge {
{% if matrix_nginx_proxy_enabled %}
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
set $backend "matrix-certbot:8080";
proxy_pass http://$backend;
{% else %}
{# Generic configuration for use outside of our container setup #}
proxy_pass http://127.0.0.1:{{ matrix_ssl_lets_encrypt_certbot_standalone_http_port }};
{% endif %}
}
{% if matrix_nginx_proxy_proxy_matrix_nginx_status_enabled %}
{{ render_nginx_status_location_block(matrix_nginx_proxy_proxy_matrix_nginx_status_allowed_addresses) }}
{% endif %}
location / {
return 301 https://$http_host$request_uri;
}
{% else %}
{{ render_vhost_directives() }}
{% endif %}
Increase max body size for the nginx proxy Otherwise, we can't support large media file uploads.
2017-08-12 14:39:21 +02:00
}
Initial work on Synapse 0.99/1.0 preparation
2019-02-05 10:07:08 +01:00
Add support to matrix-nginx-proxy to work in HTTP-only mode
2019-12-06 10:53:09 +01:00
{% if matrix_nginx_proxy_https_enabled %}
Initial work on Synapse 0.99/1.0 preparation
2019-02-05 10:07:08 +01:00
server {
Add support to matrix-nginx-proxy to work in HTTP-only mode
2019-12-06 10:53:09 +01:00
listen {{ 8443 if matrix_nginx_proxy_enabled else 443 }} ssl http2;
listen [::]:{{ 8443 if matrix_nginx_proxy_enabled else 443 }} ssl http2;
Initial work on Synapse 0.99/1.0 preparation
2019-02-05 10:07:08 +01:00
server_name {{ matrix_nginx_proxy_proxy_matrix_hostname }};
server_tokens off;
root /dev/null;
Add support to matrix-nginx-proxy to work in HTTP-only mode
2019-12-06 10:53:09 +01:00
ssl_certificate {{ matrix_ssl_config_dir_path }}/live/{{ matrix_nginx_proxy_proxy_matrix_hostname }}/fullchain.pem;
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 10:07:08 +01:00
ssl_protocols {{ matrix_nginx_proxy_ssl_protocols }};
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
Add support to matrix-nginx-proxy to work in HTTP-only mode
2019-12-06 10:53:09 +01:00
{{ render_vhost_directives() }}
}
{% endif %}
{% if matrix_nginx_proxy_proxy_matrix_federation_api_enabled %}
{#
This federation vhost is a little special.
It serves federation over HTTP or HTTPS, depending on `matrix_nginx_proxy_https_enabled`.
#}
server {
{% if matrix_nginx_proxy_https_enabled %}
listen 8448 ssl http2;
listen [::]:8448 ssl http2;
{% else %}
listen 8448;
{% endif %}
server_name {{ matrix_nginx_proxy_proxy_matrix_hostname }};
server_tokens off;
root /dev/null;
gzip on;
gzip_types text/plain application/json;
{% if matrix_nginx_proxy_https_enabled %}
ssl_certificate {{ matrix_nginx_proxy_proxy_matrix_federation_api_ssl_certificate }};
ssl_certificate_key {{ matrix_nginx_proxy_proxy_matrix_federation_api_ssl_certificate_key }};
ssl_protocols {{ matrix_nginx_proxy_ssl_protocols }};
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
{% endif %}
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
{% set federation_reader_worker = matrix_synapse_workers_enabled_list|selectattr('worker', 'equalto', 'federation_reader')|first %}
{% if federation_reader_worker %}
{# c.f. https://github.com/matrix-org/synapse/blame/master/docs/workers.md#L160 #}
location ~ ^(/_matrix/federation/v1/event/|/_matrix/federation/v1/state/|/_matrix/federation/v1/state_ids/|/_matrix/federation/v1/backfill/|/_matrix/federation/v1/get_missing_events/|/_matrix/federation/v1/publicRooms|/_matrix/federation/v1/query/|/_matrix/federation/v1/make_join/|/_matrix/federation/v1/make_leave/|/_matrix/federation/v1/send_join/|/_matrix/federation/v2/send_join/|/_matrix/federation/v1/send_leave/|/_matrix/federation/v2/send_leave/|/_matrix/federation/v1/invite/|/_matrix/federation/v2/invite/|/_matrix/federation/v1/query_auth/|/_matrix/federation/v1/event_auth/|/_matrix/federation/v1/exchange_third_party_invite/|/_matrix/federation/v1/user/devices/|/_matrix/federation/v1/send/|/_matrix/federation/v1/get_groups_publicised$|/_matrix/key/v2/query|/_matrix/federation/v1/groups/) {
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
add missing ; to matrix-synapse.conf.j2
2020-04-19 19:50:42 +02:00
set $backend "matrix-synapse:{{ federation_reader_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
2020-04-19 18:41:27 +02:00
proxy_pass http://$backend$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
Add to synapse nginx template conditional URL rewrites for workers · 😅 How to keep this in sync with the matrix-synapse documentation? · regex location matching is expensive · nginx syntax limit: one location only per block / statement · thus, lots of duplicate statements in this file
2020-04-11 03:08:59 +02:00
{% endif %}
Initial work on Synapse 0.99/1.0 preparation
2019-02-05 10:07:08 +01:00
location / {
{% if matrix_nginx_proxy_enabled %}
{# Use the embedded DNS resolver in Docker containers to discover the service #}
resolver 127.0.0.11 valid=5s;
set $backend "{{ matrix_nginx_proxy_proxy_matrix_federation_api_addr_with_container }}";
proxy_pass http://$backend;
{% else %}
{# Generic configuration for use outside of our container setup #}
proxy_pass http://{{ matrix_nginx_proxy_proxy_matrix_federation_api_addr_sans_container }};
{% endif %}
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
client_body_buffer_size 25M;
client_max_body_size {{ matrix_nginx_proxy_proxy_matrix_federation_api_client_max_body_size_mb }}M;
proxy_max_temp_file_size 0;
}
}
{% endif %}
Reference in New Issue Copy Permalink