pub-solar/matrix-docker-ansible-deploy
5
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity
matrix-docker-ansible-deploy/roles/matrix-synapse/templates/synapse/worker.yaml.j2

46 lines
1.6 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 21:44:53 +00: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 10:14:46 +00: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 21:44:53 +00:00
Clean up worker.yaml generation a bit and make it more flexible
2021-01-25 11:02:01 +00:00
{% if matrix_synapse_replication_listener_enabled %}
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 10:14:46 +00: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 21:44:53 +00:00
worker_replication_http_port: {{ matrix_synapse_replication_http_port }}
Clean up worker.yaml generation a bit and make it more flexible
2021-01-25 11:02:01 +00:00
{% endif %}
{% set has_listeners = (matrix_synapse_worker_details.type not in [ 'appservice', 'federation_sender', 'pusher' ] or matrix_synapse_metrics_enabled) %}
{% set http_resources = [] %}
{% if matrix_synapse_worker_details.type in ['generic_worker', 'frontend_proxy', 'user_dir'] %}
{% set http_resources = http_resources + ['client'] %}
{% endif %}
{% if matrix_synapse_worker_details.type in ['generic_worker'] %}
{% set http_resources = http_resources+ ['federation'] %}
{% endif %}
{% if matrix_synapse_worker_details.type in ['media_repository'] %}
{% set http_resources = http_resources + ['media'] %}
{% endif %}
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 21:44:53 +00:00
Clean up worker.yaml generation a bit and make it more flexible
2021-01-25 11:02:01 +00:00
{% if http_resources|length > 0 or matrix_synapse_metrics_enabled %}
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 21:44:53 +00:00
worker_listeners:
Clean up worker.yaml generation a bit and make it more flexible
2021-01-25 11:02:01 +00:00
{% if http_resources|length > 0 %}
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 21:44:53 +00: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 10:29:47 +00: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 10:14:46 +00: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 21:44:53 +00:00
resources:
Clean up worker.yaml generation a bit and make it more flexible
2021-01-25 11:02:01 +00:00
- names: {{ http_resources|to_json }}
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 22:49:23 +00: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 10:24:12 +00: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 21:49:15 +00:00
- type: metrics
Fix metrics listeners for Synapse workers `::` leads to errors like: > socket.gaierror: [Errno -9] Address family for hostname not supported
2021-02-15 09:19:07 +00:00
bind_addresses: ['0.0.0.0']
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 10:14:46 +00: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 10:24:12 +00:00
{% endif %}
Clean up worker.yaml generation a bit and make it more flexible
2021-01-25 11:02:01 +00: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 21:49:15 +00: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 10:14:46 +00: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 21:44:53 +00:00
{% endif %}
refactor to use new workers and routes they serve
2020-08-28 11:53:39 +00: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 21:44:53 +00:00
worker_daemonize: false
worker_log_config: /data/{{ matrix_server_fqn_matrix }}.log.config
Reference in a new issue Copy permalink