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 '983bf819ef'
${ noResults }
matrix-docker-ansible-deploy/roles/matrix-synapse/tasks/synapse/workers/setup_uninstall.yml

38 lines
1.3 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
---
Fix corner-cases found through testing (aka ansible is nuts)
5 years ago
- name: Populate service facts
More ansible-lint fixes
2 years ago
ansible.builtin.service_facts:
Fix corner-cases found through testing (aka ansible is nuts)
5 years ago
- name: Ensure any worker services are stopped
Use fully-qualified module names for builtin Ansible modules Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1939
2 years ago
ansible.builtin.service:
Fix corner-cases found through testing (aka ansible is nuts)
5 years ago
name: "{{ item.key }}"
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
state: stopped
More ansible-lint fixes
2 years ago
with_dict: "{{ ansible_facts.services | default({})|dict2items|selectattr('key', 'match', 'matrix-synapse-worker-.+\\.service')|list|items2dict }}"
fix: all praise the allmighty yamllinter
3 years ago
when: "item.value['status'] != 'not-found'" # see https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1461
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
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 !
4 years ago
- name: Find worker configs to be cleaned
More ansible-lint fixes
2 years ago
ansible.builtin.find:
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 !
4 years ago
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
4 years ago
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 !
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
- name: Ensure previous worker configs are cleaned
Use fully-qualified module names for builtin Ansible modules Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1939
2 years ago
ansible.builtin.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 !
4 years ago
path: "{{ item.path }}"
synapse workers: polishing, cleansing and installation of jq dependency
4 years ago
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
4 years ago
with_items: "{{ matrix_synapse_workers_current_config_files.files }}"
synapse workers: polishing, cleansing and installation of jq dependency
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
- name: Find worker systemd services to be cleaned
More ansible-lint fixes
2 years ago
ansible.builtin.find:
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
path: "{{ matrix_systemd_path }}"
patterns: "matrix-synapse-worker.*.service"
use_regex: true
register: matrix_synapse_workers_current_systemd_services
synapse workers: supply systemd with actual worker PIDs (requires jq) also, worker.yaml.j2: - hone worker_name - remove worker_pid_file entry (would only be used if worker_daemonize set to true; also, synapse only knows about the container namespace and thus can not provide the required host-view PID)
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
- name: Ensure previous worker systemd services are cleaned
Use fully-qualified module names for builtin Ansible modules Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1939
2 years ago
ansible.builtin.file:
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
path: "{{ item.path }}"
synapse workers: supply systemd with actual worker PIDs (requires jq) also, worker.yaml.j2: - hone worker_name - remove worker_pid_file entry (would only be used if worker_daemonize set to true; also, synapse only knows about the container namespace and thus can not provide the required host-view PID)
4 years ago
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
4 years ago
with_items: "{{ matrix_synapse_workers_current_systemd_services.files }}"