matrix-docker-ansible-deploy/roles/matrix-synapse/tasks/workers/setup_install.yml

---

- name: Find worker configs to be cleaned
  find:
    path: "{{ matrix_synapse_config_dir_path }}"
    patterns: "worker.*.yaml"
    use_regex: true
  register: matrix_synapse_workers_current_config_files

- name: Ensure previous worker configs are cleaned
  file:
    path: "{{ item.path }}"
    state: absent
  with_items: "{{ matrix_synapse_workers_current_config_files.files }}"

- name: Find worker systemd services to be cleaned
  find:
    path: "{{ matrix_systemd_path }}"
    patterns: "matrix-synapse-worker.*.service"
    use_regex: true
  register: matrix_synapse_workers_current_systemd_services

- name: Ensure previous worker systemd services are cleaned
  file:
    path: "{{ item.path }}"
    state: absent
  with_items: "{{ matrix_synapse_workers_current_systemd_services.files }}"

- name: Ensure creation of worker systemd service files and configuration files
  include_tasks: "{{ role_path }}/tasks/workers/util/setup_files_for_worker.yml"
  with_items: "{{ matrix_synapse_workers_enabled_list }}"
  loop_control:
    loop_var: matrix_synapse_worker_details
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			`---`

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 22:20:27 +01:00			`- name: Find worker configs to be cleaned`
			`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 11:14:46 +01: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 22:20:27 +01:00
synapse workers: polishing, cleansing and installation of jq dependency 2020-10-23 20:49:53 +02: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 22:20:27 +01:00			`path: "{{ item.path }}"`
synapse workers: polishing, cleansing and installation of jq dependency 2020-10-23 20:49:53 +02: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 11:14:46 +01:00			`with_items: "{{ matrix_synapse_workers_current_config_files.files }}"`
synapse workers: polishing, cleansing and installation of jq dependency 2020-10-23 20:49: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			`- name: Find worker systemd services to be cleaned`
			`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 20:49: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			`- name: Ensure previous worker systemd services are cleaned`
			`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 20:49: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			`- name: Ensure creation of worker systemd service files and configuration files`
			`include_tasks: "{{ role_path }}/tasks/workers/util/setup_files_for_worker.yml"`
			`with_items: "{{ matrix_synapse_workers_enabled_list }}"`
			`loop_control:`
			`loop_var: matrix_synapse_worker_details`