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 'e41fcf2746'
${ noResults }
matrix-docker-ansible-deploy/roles/matrix-synapse/templates/synapse/worker.yaml.j2

46 lines
1.7 KiB
Raw Normal View History Unescape

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
5 years ago
#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
4 years ago
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
5 years ago
Clean up worker.yaml generation a bit and make it more flexible
4 years ago
{% 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
4 years ago
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
5 years ago
worker_replication_http_port: {{ matrix_synapse_replication_http_port }}
Clean up worker.yaml generation a bit and make it more flexible
4 years ago
{% 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
5 years ago
Clean up worker.yaml generation a bit and make it more flexible
4 years ago
{% 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
5 years ago
worker_listeners:
Clean up worker.yaml generation a bit and make it more flexible
4 years ago
{% 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
5 years ago
- 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`.
4 years ago
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
4 years ago
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
5 years ago
resources:
Clean up worker.yaml generation a bit and make it more flexible
4 years ago
- 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 [::]
4 years ago
{% 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!
4 years ago
{% 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
4 years ago
- type: metrics
Fix metrics listeners for Synapse workers `::` leads to errors like: > socket.gaierror: [Errno -9] Address family for hostname not supported
4 years ago
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
4 years ago
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!
4 years ago
{% endif %}
Clean up worker.yaml generation a bit and make it more flexible
4 years ago
{% 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
4 years ago
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
4 years ago
{% if matrix_synapse_worker_details.type == 'frontend_proxy' %}
replaced 8008 where possible
3 years ago
worker_main_http_uri: http://matrix-synapse:{{ matrix_synapse_container_client_api_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
5 years ago
{% endif %}
refactor to use new workers and routes they serve
4 years ago
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
5 years ago
worker_daemonize: false
worker_log_config: /data/{{ matrix_server_fqn_matrix }}.log.config