self-hosted/matrix-docker-ansible-deploy
1
0
Fork 0
mirror of https://github.com/spantaleev/matrix-docker-ansible-deploy.git synced 2024-12-24 10:27:04 +02:00
Code Issues Releases Activity
e033520ce2
matrix-docker-ansible-deploy/roles/custom/matrix-synapse/templates/synapse/systemd/matrix-synapse-worker.service.j2

71 lines
4.0 KiB
Plaintext
Raw Normal View History

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 12:14:46 +02:00
#jinja2: lstrip_blocks: "True"
[Unit]
Description=Synapse worker ({{ matrix_synapse_worker_container_name }})
AssertPathExists={{ matrix_synapse_config_dir_path }}/{{ matrix_synapse_worker_config_file_name }}
After=matrix-synapse.service
Make Synapse worker systemd service files depend on matrix-synapse.service Many of these do depend on the Synapse master process (`matrix-synapse.service`), so it makes sense to do it. Furthermore, we're doing it so that one can stop the `matrix-synapse.service` service and have systemd cascade this into stopping all the workers as well. This is useful for easily stopping all of Synapse, so that Postgres upgrades (`--tags=upgrade-postgres`) can happen cleanly. Postgres upgrades currently stop `devture_postgres_systemd_services_to_stop_for_maintenance_list` which includes Synapse, but stopping just the master process and leaving workers running is not safe enough and sometimes leads to errors like: > ERROR: insert or update on table "event_forward_extremities" violates foreign key constraint "event_forward_extremities_event_id" With this dependency in place, stopping `matrix-synapse.service` will stop all Synapse processes.
2023-09-16 10:27:52 +02:00
Requires=matrix-synapse.service
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 12:14:46 +02:00
[Service]
Type=simple
matrix_systemd_unit_home_path -> devture_systemd_docker_base_systemd_unit_home_path (via com.devture.ansible.role.systemd_docker_base)
2022-11-04 16:37:47 +02:00
Environment="HOME={{ devture_systemd_docker_base_systemd_unit_home_path }}"
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 12:14:46 +02:00
matrix_host_command_sh -> devture_systemd_docker_base_host_command_sh (via com.devture.ansible.role.systemd_docker_base)
2022-11-04 16:40:25 +02:00
ExecStartPre=-{{ devture_systemd_docker_base_host_command_sh }} -c '{{ devture_systemd_docker_base_host_command_docker }} kill {{ matrix_synapse_worker_container_name }} 2>/dev/null || true'
ExecStartPre=-{{ devture_systemd_docker_base_host_command_sh }} -c '{{ devture_systemd_docker_base_host_command_docker }} rm {{ matrix_synapse_worker_container_name }} 2>/dev/null || 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 12:14:46 +02:00
# Intentional delay, so that the homeserver can manage to start.
ExecStartPre={{ matrix_host_command_sleep }} 5
Add matrix_synapse_container_network and matrix_synapse_container_additional_networks
2023-02-17 16:13:38 +02:00
ExecStartPre={{ devture_systemd_docker_base_host_command_docker }} create \
--rm \
--name={{ matrix_synapse_worker_container_name }} \
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 12:14:46 +02:00
--log-driver=none \
Add matrix_synapse_uid, matrix_synapse_gid and matrix_synapse_username
2023-02-17 17:16:50 +02:00
--user={{ matrix_synapse_uid }}:{{ matrix_synapse_gid }} \
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 12:14:46 +02:00
--cap-drop=ALL \
--read-only \
--tmpfs=/tmp:rw,noexec,nosuid,size={{ matrix_synapse_tmp_directory_size_mb }}m \
Make use of matrix_synapse_container_network in the matrix-synapse role It's the same as `matrix_docker_network` for now, so this practically doesn't change anything.
2023-05-02 12:22:31 +02:00
--network={{ matrix_synapse_container_network }} \
Disable healthcheck for Synapse workers which serve no web traffic This was mostly affecting the stream writer (events) worker, which was being reported as unhealthy. It wasn't causing any issues, but it just looked odd and was confusing people. As an alternative to hitting the regular `/health` healthcheck route (on the "client" API which this stream writer does not expose), we may have went for hitting some "replication" API endpoint instead. This is more complicated and likely unnecessary.
2023-05-19 17:26:05 +02:00
{% if matrix_synapse_worker_details.port != 0 and matrix_synapse_worker_details.webserving %}
Make healthchecks work for Synapse worker containers Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/456
2021-02-24 07:59:14 +02:00
--health-cmd 'curl -fSs http://localhost:{{ matrix_synapse_worker_details.port }}/health || exit 1' \
{% else %}
--no-healthcheck \
{% endif %}
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 12:14:46 +02:00
{% if matrix_synapse_workers_enabled and matrix_synapse_workers_container_host_bind_address %}
{% if matrix_synapse_worker_details.port != 0 %}
-p {{ '' if matrix_synapse_workers_container_host_bind_address == '*' else (matrix_synapse_workers_container_host_bind_address + ':') }}{{ matrix_synapse_worker_details.port }}:{{ matrix_synapse_worker_details.port }} \
{% endif %}
{% if matrix_synapse_worker_details.metrics_port != 0 %}
-p {{ '' if matrix_synapse_workers_container_host_bind_address == '*' else (matrix_synapse_workers_container_host_bind_address + ':') }}{{ matrix_synapse_worker_details.metrics_port }}:{{ matrix_synapse_worker_details.metrics_port }} \
{% endif %}
{% endif %}
--mount type=bind,src={{ matrix_synapse_config_dir_path }},dst=/data,ro \
--mount type=bind,src={{ matrix_synapse_storage_path }},dst=/matrix-media-store-parent,bind-propagation=slave \
{% for volume in matrix_synapse_container_additional_volumes %}
-v {{ volume.src }}:{{ volume.dst }}:{{ volume.options }} \
{% endfor %}
appservice: add and use homeserver_container_* vars (#2045) * appservice: add and use matrix_homeserver_* vars * appservice: use the new vars * Apply suggestions from code review Co-authored-by: Slavi Pantaleev <slavi@devture.com> Co-authored-by: Slavi Pantaleev <slavi@devture.com>
2022-08-24 07:38:12 +02:00
{% for arg in matrix_synapse_container_arguments %}
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 12:14:46 +02:00
{{ arg }} \
{% endfor %}
Add support for Synapse container image customization This allows people to augment the Synapse image with custom tools and addons without having to rebuild it from scratch. If customizations are enabled, the playbook will build a new `localhost/matrixdotorg/synapse:VERSION-customized` image on top of the default one (`FROM matrixdotorg/synapse:VERSION`) and with custom Dockerfile build steps. For servers that self-build the Synapse image, the Synapse image will be built first, before proceding to extend it the same way. In the future, we'll also have easy to enable Dockerfile build steps for modules that the playbook supports.
2022-10-14 15:33:19 +02:00
{{ matrix_synapse_docker_image_final }} \
Add support for stream writer Synapse workers As stream writer workers are also powered by the `generic_worker` Synapse app, this necessitated that we provide means for distinguishing between them and regular `generic_workers`. I've also taken the time to optimize nginx configuration generation (more Jinja2 macro usage, less duplication). Worker names have also changed. Workers are now named sequentially like this: - `matrix-synapse-worker-0-generic` - `matrix-synapse-worker-1-stream-writer-typing` - `matrix-synapse-worker-2-pusher` instead of `matrix-synapse-worker_generic_worker-18111` (indexed with a port number). People who modify `matrix_synapse_workers_enabled_list` directly will need to adjust their configuration.
2022-09-15 06:05:25 +02:00
run -m synapse.app.{{ matrix_synapse_worker_details.app }} -c /data/homeserver.yaml -c /data/{{ matrix_synapse_worker_config_file_name }}
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 12:14:46 +02:00
Add matrix_synapse_container_network and matrix_synapse_container_additional_networks
2023-02-17 16:13:38 +02:00
{% for network in matrix_synapse_container_additional_networks %}
ExecStartPre={{ devture_systemd_docker_base_host_command_docker }} network connect {{ network }} {{ matrix_synapse_worker_container_name }}
{% endfor %}
ExecStart={{ devture_systemd_docker_base_host_command_docker }} start --attach {{ matrix_synapse_worker_container_name }}
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 12:14:46 +02:00
matrix_host_command_sh -> devture_systemd_docker_base_host_command_sh (via com.devture.ansible.role.systemd_docker_base)
2022-11-04 16:40:25 +02:00
ExecStop=-{{ devture_systemd_docker_base_host_command_sh }} -c '{{ devture_systemd_docker_base_host_command_docker }} kill {{ matrix_synapse_worker_container_name }} 2>/dev/null || true'
ExecStop=-{{ devture_systemd_docker_base_host_command_sh }} -c '{{ devture_systemd_docker_base_host_command_docker }} rm {{ matrix_synapse_worker_container_name }} 2>/dev/null || 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 12:14:46 +02:00
matrix_host_command_docker -> devture_systemd_docker_base_host_command_docker (via com.devture.ansible.role.systemd_docker_base)
2022-11-04 16:39:35 +02:00
ExecReload={{ devture_systemd_docker_base_host_command_docker }} exec {{ matrix_synapse_worker_container_name }} /bin/sh -c 'kill -HUP 1'
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 12:14:46 +02:00
Restart=always
RestartSec=30
SyslogIdentifier={{ matrix_synapse_worker_container_name }}
# Intentionally not making this WantedBy=matrix-synapse.service,
# as matrix.synapse.service already has `Wants=` lines.
# Also, WantedBy will trigger the creation of some `matrix-synapse.service.wants/` directory,
# which we'd have to clean, etc. Better not.
[Install]
WantedBy=multi-user.target
Reference in New Issue Copy Permalink