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/tasks/synapse/workers/setup_install.yml

43 lines
1.5 KiB
YAML
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
---
Stop/disable unnecessary worker services before deleting them
2021-01-25 13:20:37 +00:00
- name: Determine current worker configs
synapse role workers setup: make configs clean action remote compatible Many people probably didn't even know this - that ansible can be quite a bit picky about what it will be willing to work with remotely. Thanks @maxklenk !
2020-12-01 21:20:27 +00:00
find:
path: "{{ matrix_synapse_config_dir_path }}"
patterns: "worker.*.yaml"
use_regex: 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
register: matrix_synapse_workers_current_config_files
synapse role workers setup: make configs clean action remote compatible Many people probably didn't even know this - that ansible can be quite a bit picky about what it will be willing to work with remotely. Thanks @maxklenk !
2020-12-01 21:20:27 +00:00
Stop/disable unnecessary worker services before deleting them
2021-01-25 13:20:37 +00:00
# This also deletes some things which we need. They will be recreated below.
synapse workers: polishing, cleansing and installation of jq dependency
2020-10-23 18:49:53 +00:00
- name: Ensure previous worker configs are cleaned
file:
synapse role workers setup: make configs clean action remote compatible Many people probably didn't even know this - that ansible can be quite a bit picky about what it will be willing to work with remotely. Thanks @maxklenk !
2020-12-01 21:20:27 +00:00
path: "{{ item.path }}"
synapse workers: polishing, cleansing and installation of jq dependency
2020-10-23 18:49:53 +00:00
state: absent
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
with_items: "{{ matrix_synapse_workers_current_config_files.files }}"
synapse workers: polishing, cleansing and installation of jq dependency
2020-10-23 18:49:53 +00:00
Stop/disable unnecessary worker services before deleting them
2021-01-25 13:20:37 +00:00
- name: Determine current worker systemd services
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
find:
path: "{{ matrix_systemd_path }}"
patterns: "matrix-synapse-worker.*.service"
use_regex: true
register: matrix_synapse_workers_current_systemd_services
synapse workers: polishing, cleansing and installation of jq dependency
2020-10-23 18:49:53 +00:00
Stop/disable unnecessary worker services before deleting them
2021-01-25 13:20:37 +00:00
- name: Ensure unnecessary worker systemd services are stopped and disabled
service:
name: "{{ item.path|basename }}"
state: stopped
enabled: false
with_items: "{{ matrix_synapse_workers_current_systemd_services.files }}"
when: "not ansible_check_mode and item.path|basename not in matrix_systemd_services_list"
- name: Ensure unnecessary worker systemd services are cleaned
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
file:
path: "{{ item.path }}"
state: absent
with_items: "{{ matrix_synapse_workers_current_systemd_services.files }}"
synapse workers: polishing, cleansing and installation of jq dependency
2020-10-23 18:49:53 +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
- name: Ensure creation of worker systemd service files and configuration files
Relocate tasks related to Synapse workers
2021-02-15 08:42:20 +00:00
include_tasks: "{{ role_path }}/tasks/synapse/workers/util/setup_files_for_worker.yml"
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
with_items: "{{ matrix_synapse_workers_enabled_list }}"
loop_control:
loop_var: matrix_synapse_worker_details
Reference in a new issue Copy permalink