mirror/matrix-docker-ansible-deploy
1
0
Fork 0
mirror of https://github.com/spantaleev/matrix-docker-ansible-deploy.git synced 2024-11-07 03:07:33 +01:00
Code Issues Packages Projects Releases Wiki Activity
1462409b34
matrix-docker-ansible-deploy/roles/matrix-synapse/templates/synapse/worker.yaml.j2

36 lines
1.2 KiB
Plaintext
Raw Normal View History

Add initial support for synapse workers · needs documentation; no checks yet for port clashes or typos in worker name · according to https://github.com/matrix-org/synapse/wiki/Workers-setup-with-nginx#results about 90% of requests go to the synchrotron endpoint · thus, the synchrotron worker is especially suited to be load-balanced · most of the other workers are documented to support only a single instance · https://github.com/matrix-org/synapse/blob/master/docs/workers.md
2020-04-10 23:44:53 +02:00
#jinja2: lstrip_blocks: "True"
Run Synapse workers in their own containers This switches the `docker exec` method of spawning Synapse workers inside the `matrix-synapse` container with dedicated containers for each worker. We also have dedicated systemd services for each worker, so this are now: - more consistent with everything else (we don't use systemd instantiated services anywhere) - we don't need the "parse systemd instance name into worker name + port" part - we don't need to keep track of PIDs manually - we don't need jq (less depenendencies) - workers dying would be restarted by systemd correctly, like any other service - `docker ps` shows each worker separately and we can observe resource usage
2021-01-25 11:14:46 +01:00
worker_app: synapse.app.{{ matrix_synapse_worker_details.type }}
worker_name: {{ matrix_synapse_worker_details.type ~ ':' ~ matrix_synapse_worker_details.port }}
Add initial support for synapse workers · needs documentation; no checks yet for port clashes or typos in worker name · according to https://github.com/matrix-org/synapse/wiki/Workers-setup-with-nginx#results about 90% of requests go to the synchrotron endpoint · thus, the synchrotron worker is especially suited to be load-balanced · most of the other workers are documented to support only a single instance · https://github.com/matrix-org/synapse/blob/master/docs/workers.md
2020-04-10 23:44:53 +02:00
Run Synapse workers in their own containers This switches the `docker exec` method of spawning Synapse workers inside the `matrix-synapse` container with dedicated containers for each worker. We also have dedicated systemd services for each worker, so this are now: - more consistent with everything else (we don't use systemd instantiated services anywhere) - we don't need the "parse systemd instance name into worker name + port" part - we don't need to keep track of PIDs manually - we don't need jq (less depenendencies) - workers dying would be restarted by systemd correctly, like any other service - `docker ps` shows each worker separately and we can observe resource usage
2021-01-25 11:14:46 +01:00
worker_replication_host: matrix-synapse
Add initial support for synapse workers · needs documentation; no checks yet for port clashes or typos in worker name · according to https://github.com/matrix-org/synapse/wiki/Workers-setup-with-nginx#results about 90% of requests go to the synchrotron endpoint · thus, the synchrotron worker is especially suited to be load-balanced · most of the other workers are documented to support only a single instance · https://github.com/matrix-org/synapse/blob/master/docs/workers.md
2020-04-10 23:44:53 +02:00
worker_replication_http_port: {{ matrix_synapse_replication_http_port }}
worker_listeners:
Run Synapse workers in their own containers This switches the `docker exec` method of spawning Synapse workers inside the `matrix-synapse` container with dedicated containers for each worker. We also have dedicated systemd services for each worker, so this are now: - more consistent with everything else (we don't use systemd instantiated services anywhere) - we don't need the "parse systemd instance name into worker name + port" part - we don't need to keep track of PIDs manually - we don't need jq (less depenendencies) - workers dying would be restarted by systemd correctly, like any other service - `docker ps` shows each worker separately and we can observe resource usage
2021-01-25 11:14:46 +01:00
{% if matrix_synapse_worker_details.type not in [ 'appservice', 'federation_sender', 'pusher' ] %}
Add initial support for synapse workers · needs documentation; no checks yet for port clashes or typos in worker name · according to https://github.com/matrix-org/synapse/wiki/Workers-setup-with-nginx#results about 90% of requests go to the synchrotron endpoint · thus, the synchrotron worker is especially suited to be load-balanced · most of the other workers are documented to support only a single instance · https://github.com/matrix-org/synapse/blob/master/docs/workers.md
2020-04-10 23:44:53 +02:00
- type: http
Fix worker listening addresses Not specifying bind addresses for the worker resulted in this warning: > synapse.app - 47 - WARNING - None - Failed to listen on 0.0.0.0, continuing because listening on [::] Additionally, metrics listening only on 127.0.0.1 seems like a no-op. Only having it accessible from within the container is likely not what we intend. Changed that to all interfaces as well. Whether it actually gets exposed or not depends on the systemd service and `matrix_synapse_workers_container_host_bind_address`.
2021-01-25 11:29:47 +01:00
bind_addresses: ['::']
Run Synapse workers in their own containers This switches the `docker exec` method of spawning Synapse workers inside the `matrix-synapse` container with dedicated containers for each worker. We also have dedicated systemd services for each worker, so this are now: - more consistent with everything else (we don't use systemd instantiated services anywhere) - we don't need the "parse systemd instance name into worker name + port" part - we don't need to keep track of PIDs manually - we don't need jq (less depenendencies) - workers dying would be restarted by systemd correctly, like any other service - `docker ps` shows each worker separately and we can observe resource usage
2021-01-25 11:14:46 +01:00
port: {{ matrix_synapse_worker_details.port }}
Add initial support for synapse workers · needs documentation; no checks yet for port clashes or typos in worker name · according to https://github.com/matrix-org/synapse/wiki/Workers-setup-with-nginx#results about 90% of requests go to the synchrotron endpoint · thus, the synchrotron worker is especially suited to be load-balanced · most of the other workers are documented to support only a single instance · https://github.com/matrix-org/synapse/blob/master/docs/workers.md
2020-04-10 23:44:53 +02:00
resources:
- names:
Run Synapse workers in their own containers This switches the `docker exec` method of spawning Synapse workers inside the `matrix-synapse` container with dedicated containers for each worker. We also have dedicated systemd services for each worker, so this are now: - more consistent with everything else (we don't use systemd instantiated services anywhere) - we don't need the "parse systemd instance name into worker name + port" part - we don't need to keep track of PIDs manually - we don't need jq (less depenendencies) - workers dying would be restarted by systemd correctly, like any other service - `docker ps` shows each worker separately and we can observe resource usage
2021-01-25 11:14:46 +01:00
{% if matrix_synapse_worker_details.type in [ 'generic_worker', 'frontend_proxy', 'user_dir' ] %}
Add initial support for synapse workers · needs documentation; no checks yet for port clashes or typos in worker name · according to https://github.com/matrix-org/synapse/wiki/Workers-setup-with-nginx#results about 90% of requests go to the synchrotron endpoint · thus, the synchrotron worker is especially suited to be load-balanced · most of the other workers are documented to support only a single instance · https://github.com/matrix-org/synapse/blob/master/docs/workers.md
2020-04-10 23:44:53 +02:00
- client
Add worker_name to synapse worker config template & restrict federation listener; frontend_proxy / user_dir don't need it
2020-09-09 19:57:49 +02:00
{% endif %}
Run Synapse workers in their own containers This switches the `docker exec` method of spawning Synapse workers inside the `matrix-synapse` container with dedicated containers for each worker. We also have dedicated systemd services for each worker, so this are now: - more consistent with everything else (we don't use systemd instantiated services anywhere) - we don't need the "parse systemd instance name into worker name + port" part - we don't need to keep track of PIDs manually - we don't need jq (less depenendencies) - workers dying would be restarted by systemd correctly, like any other service - `docker ps` shows each worker separately and we can observe resource usage
2021-01-25 11:14:46 +01:00
{% if matrix_synapse_worker_details.type in [ 'generic_worker' ] %}
Add initial support for synapse workers · needs documentation; no checks yet for port clashes or typos in worker name · according to https://github.com/matrix-org/synapse/wiki/Workers-setup-with-nginx#results about 90% of requests go to the synchrotron endpoint · thus, the synchrotron worker is especially suited to be load-balanced · most of the other workers are documented to support only a single instance · https://github.com/matrix-org/synapse/blob/master/docs/workers.md
2020-04-10 23:44:53 +02:00
- federation
Run Synapse workers in their own containers This switches the `docker exec` method of spawning Synapse workers inside the `matrix-synapse` container with dedicated containers for each worker. We also have dedicated systemd services for each worker, so this are now: - more consistent with everything else (we don't use systemd instantiated services anywhere) - we don't need the "parse systemd instance name into worker name + port" part - we don't need to keep track of PIDs manually - we don't need jq (less depenendencies) - workers dying would be restarted by systemd correctly, like any other service - `docker ps` shows each worker separately and we can observe resource usage
2021-01-25 11:14:46 +01:00
{% elif matrix_synapse_worker_details.type in [ 'media_repository' ] %}
Add initial support for synapse workers · needs documentation; no checks yet for port clashes or typos in worker name · according to https://github.com/matrix-org/synapse/wiki/Workers-setup-with-nginx#results about 90% of requests go to the synchrotron endpoint · thus, the synchrotron worker is especially suited to be load-balanced · most of the other workers are documented to support only a single instance · https://github.com/matrix-org/synapse/blob/master/docs/workers.md
2020-04-10 23:44:53 +02:00
- media
{% endif %}
synapse workers: untangle config template and specify bind address .. to mitigate log noise - WARNING: Failed to listen on 0.0.0.0, continuing because listening on [::]
2020-12-01 23:49:23 +01:00
{% endif %}
Prevent Synapse warning about enabling metric listeners with enable_metrics: false > synapse.app.generic_worker - 606 - WARNING - None - Metrics listener configured, but enable_metrics is not True!
2021-01-25 11:24:12 +01:00
{% if matrix_synapse_metrics_enabled %}
synapse workers: define and expose METRICS port for each worker As seen on TV: https://github.com/matrix-org/synapse/blob/master/docs/metrics-howto.md#monitoring-workers
2020-12-01 22:49:15 +01:00
- type: metrics
Fix worker listening addresses Not specifying bind addresses for the worker resulted in this warning: > synapse.app - 47 - WARNING - None - Failed to listen on 0.0.0.0, continuing because listening on [::] Additionally, metrics listening only on 127.0.0.1 seems like a no-op. Only having it accessible from within the container is likely not what we intend. Changed that to all interfaces as well. Whether it actually gets exposed or not depends on the systemd service and `matrix_synapse_workers_container_host_bind_address`.
2021-01-25 11:29:47 +01:00
bind_addresses: ['::']
Run Synapse workers in their own containers This switches the `docker exec` method of spawning Synapse workers inside the `matrix-synapse` container with dedicated containers for each worker. We also have dedicated systemd services for each worker, so this are now: - more consistent with everything else (we don't use systemd instantiated services anywhere) - we don't need the "parse systemd instance name into worker name + port" part - we don't need to keep track of PIDs manually - we don't need jq (less depenendencies) - workers dying would be restarted by systemd correctly, like any other service - `docker ps` shows each worker separately and we can observe resource usage
2021-01-25 11:14:46 +01:00
port: {{ matrix_synapse_worker_details.metrics_port }}
Prevent Synapse warning about enabling metric listeners with enable_metrics: false > synapse.app.generic_worker - 606 - WARNING - None - Metrics listener configured, but enable_metrics is not True!
2021-01-25 11:24:12 +01:00
{% endif %}
synapse workers: define and expose METRICS port for each worker As seen on TV: https://github.com/matrix-org/synapse/blob/master/docs/metrics-howto.md#monitoring-workers
2020-12-01 22:49:15 +01:00
Run Synapse workers in their own containers This switches the `docker exec` method of spawning Synapse workers inside the `matrix-synapse` container with dedicated containers for each worker. We also have dedicated systemd services for each worker, so this are now: - more consistent with everything else (we don't use systemd instantiated services anywhere) - we don't need the "parse systemd instance name into worker name + port" part - we don't need to keep track of PIDs manually - we don't need jq (less depenendencies) - workers dying would be restarted by systemd correctly, like any other service - `docker ps` shows each worker separately and we can observe resource usage
2021-01-25 11:14:46 +01:00
{% if matrix_synapse_worker_details.type == 'frontend_proxy' %}
worker_main_http_uri: http://matrix-synapse:8008
Add initial support for synapse workers · needs documentation; no checks yet for port clashes or typos in worker name · according to https://github.com/matrix-org/synapse/wiki/Workers-setup-with-nginx#results about 90% of requests go to the synchrotron endpoint · thus, the synchrotron worker is especially suited to be load-balanced · most of the other workers are documented to support only a single instance · https://github.com/matrix-org/synapse/blob/master/docs/workers.md
2020-04-10 23:44:53 +02:00
{% endif %}
refactor to use new workers and routes they serve
2020-08-28 13:53:39 +02:00
Add initial support for synapse workers · needs documentation; no checks yet for port clashes or typos in worker name · according to https://github.com/matrix-org/synapse/wiki/Workers-setup-with-nginx#results about 90% of requests go to the synchrotron endpoint · thus, the synchrotron worker is especially suited to be load-balanced · most of the other workers are documented to support only a single instance · https://github.com/matrix-org/synapse/blob/master/docs/workers.md
2020-04-10 23:44:53 +02:00
worker_daemonize: false
worker_log_config: /data/{{ matrix_server_fqn_matrix }}.log.config
Reference in New Issue Copy Permalink