titanz
/
matrix-docker-ansible-deploy
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '765c046beb'
${ noResults }
matrix-docker-ansible-deploy/roles/matrix-nginx-proxy/templates/nginx/conf.d/matrix-synapse.conf.j2

415 lines
16 KiB
Raw Normal View History Unescape

Fix indentation in templates Use Jinja2 lstrip_blocks option in templates to ensure consistent indentation in generated files.
6 years ago
#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/)
5 years ago
{% 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
7 years ago
Add support to matrix-nginx-proxy to work in HTTP-only mode
5 years ago
{% macro render_vhost_directives() %}
Improve compression support
6 years ago
gzip on;
Fix nginx warning: adding already-default text/html to gzip_types
6 years ago
gzip_types text/plain application/json;
Improve compression support
6 years ago
Initial work on Synapse 0.99/1.0 preparation
6 years ago
location /.well-known/matrix {
Add Service Discovery (/.well-known/matrix/client) support
6 years ago
root {{ matrix_static_files_base_path }};
Cache /.well-known/matrix files for longer
6 years ago
{#
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
6 years ago
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.
6 years ago
add_header Access-Control-Allow-Origin *;
Add Service Discovery (/.well-known/matrix/client) support
6 years ago
}
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/)
5 years ago
{% 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`.
6 years ago
{% if matrix_nginx_proxy_proxy_matrix_corporal_api_enabled %}
Add support for matrix-corporal
6 years ago
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`.
6 years ago
set $backend "{{ matrix_nginx_proxy_proxy_matrix_corporal_api_addr_with_container }}";
Add support for matrix-corporal
6 years ago
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`.
6 years ago
proxy_pass http://{{ matrix_nginx_proxy_proxy_matrix_corporal_api_addr_sans_container }};
Add support for matrix-corporal
6 years ago
{% 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.
6 years ago
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
Add support for matrix-corporal
6 years ago
}
{% 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`.
6 years ago
{% if matrix_nginx_proxy_proxy_matrix_identity_api_enabled %}
Add mxisd Identity Server support
6 years ago
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`.
6 years ago
set $backend "{{ matrix_nginx_proxy_proxy_matrix_identity_api_addr_with_container }}";
Add mxisd Identity Server support
6 years ago
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`.
6 years ago
proxy_pass http://{{ matrix_nginx_proxy_proxy_matrix_identity_api_addr_sans_container }};
Add mxisd Identity Server support
6 years ago
{% endif %}
Send Host/X-Forwarded-For to mxisd It worked without it too, but doing this is more consistent with the mxisd recommendations.
6 years ago
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
Add mxisd Identity Server support
6 years ago
}
{% endif %}
Use mxisd for user directory searches Implements #77 (Github issue).
6 years ago
{% 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.
6 years ago
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
Use mxisd for user directory searches Implements #77 (Github issue).
6 years ago
}
{% endif %}
Add option to proxy 3pid registration endpoints
6 years ago
{% 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
5 years ago
{% 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
5 years ago
{# 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
5 years ago
set $backend "matrix-synapse:{{ client_reader_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
5 years ago
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
5 years ago
{% 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
5 years ago
{# 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
5 years ago
set $backend "matrix-synapse:{{ media_repository_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
5 years ago
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
5 years ago
set $backend "matrix-synapse:{{ media_repository_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
5 years ago
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
5 years ago
{% 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
5 years ago
{# 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
5 years ago
set $backend "matrix-synapse:{{ event_creator_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
5 years ago
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
5 years ago
{% 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
5 years ago
{# 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
5 years ago
set $backend "matrix-synapse:{{ frontend_proxy_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
5 years ago
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
5 years ago
set $backend "matrix-synapse:{{ frontend_proxy_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
5 years ago
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
5 years ago
{% 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
5 years ago
{# 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
5 years ago
set $backend "matrix-synapse:{{ user_dir_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
5 years ago
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
5 years ago
{% 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`.
6 years ago
{% 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
6 years ago
Initial work on Synapse 0.99/1.0 preparation
6 years ago
{#
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.
7 years ago
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.
6 years ago
{% 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`.
6 years ago
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.
6 years ago
proxy_pass http://$backend;
{% else %}
Minor wording improvements
6 years ago
{# 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`.
6 years ago
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.
6 years ago
{% 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.
6 years ago
proxy_set_header Host $host;
Increase max body size for the nginx proxy Otherwise, we can't support large media file uploads.
7 years ago
proxy_set_header X-Forwarded-For $remote_addr;
client_body_buffer_size 25M;
Make (most) containers run with a read-only filesystem
6 years ago
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.
7 years ago
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.
6 years ago
Enable exposure of Prometheus metrics.
6 years ago
{% 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.
6 years ago
auth_basic_user_file /nginx-data/matrix-synapse-metrics-htpasswd;
Enable exposure of Prometheus metrics.
6 years ago
{% endif %}
}
{% endif %}
Add support for proxying /_synapse/admin APIs Fixes #191 (Github Issue).
6 years ago
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.
6 years ago
location / {
Server non-scary page at matrix domain (take 2) Fix for 12b65d8ccc11217644.
6 years ago
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.
6 years ago
}
Add support to matrix-nginx-proxy to work in HTTP-only mode
5 years ago
{% 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
5 years ago
{% 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
5 years ago
{% for synchrotron_worker in synchrotron_workers %}
{# 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
5 years ago
set $backend "matrix-synapse:{{ synchrotron_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
5 years ago
server $backend:{{ 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
5 years ago
{% endfor %}
}
{% endif %}
Add support to matrix-nginx-proxy to work in HTTP-only mode
5 years ago
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.
7 years ago
}
Initial work on Synapse 0.99/1.0 preparation
6 years ago
Add support to matrix-nginx-proxy to work in HTTP-only mode
5 years ago
{% if matrix_nginx_proxy_https_enabled %}
Initial work on Synapse 0.99/1.0 preparation
6 years ago
server {
Add support to matrix-nginx-proxy to work in HTTP-only mode
5 years ago
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
6 years ago
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
5 years ago
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
6 years ago
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
5 years ago
{{ 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
5 years ago
{% 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
5 years ago
set $backend "matrix-synapse:{{ federation_reader_worker.port }}";
nginx config: route traffic to workers on matrix-synapse FIXME: horrid duplication in template file
5 years ago
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
5 years ago
{% endif %}
Initial work on Synapse 0.99/1.0 preparation
6 years ago
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 %}