Commit graph

16 commits

Author SHA1 Message Date
Slavi Pantaleev f12206676f Upgrade Synapse (v1.66.0 -> 1.67.0) and remove frontend_proxy workers
`frontend_proxy` workers have been superseded by `generic_worker` workers.
Related to https://github.com/matrix-org/synapse/pull/13645
2022-09-13 15:45:50 +03:00
David Mehren f6a73231ab
Synapse workers should respect X-Forwarded headers
Currently, Synapse workers ignore the X-Forwarded headers, which leads to internal Docker IP addresses randomly appearing in the users' device list.

This adds the `x_forwarded: true` option to the worker config, fixing the issue.
2022-06-18 16:13:08 +02:00
boris runakov 1ec67f49b0 replaced 8008 where possible 2021-11-15 22:43:05 +02:00
Slavi Pantaleev 43059bb040 Fix metrics listeners for Synapse workers
`::` leads to errors like:

> socket.gaierror: [Errno -9] Address family for hostname not supported
2021-02-15 11:19:07 +02:00
Slavi Pantaleev 66cdc7bf5a Clean up worker.yaml generation a bit and make it more flexible 2021-01-25 13:02:01 +02:00
Slavi Pantaleev 1462409b34 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`.
2021-01-25 12:29:47 +02:00
Slavi Pantaleev 01747c8cc4 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!
2021-01-25 12:24:12 +02:00
Slavi Pantaleev 70796703d3 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
Marcel Partap e892ac464f 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 [::]
2020-12-01 23:49:23 +01:00
Marcel Partap f201bca519 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
2020-12-01 22:49:15 +01:00
Marcel Partap 2d1b9f2dbf synapse workers: reworkings + get endpoints from upstream docs via awk
(yes, a bit awkward and brittle… xD)
2020-10-28 07:13:19 +01:00
Marcel Partap 501efee07e 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)
2020-10-22 20:53:41 +02:00
Marcel Partap d2e61af224 Add worker_name to synapse worker config template
& restrict federation listener; frontend_proxy / user_dir don't need it
2020-10-11 21:52:08 +02:00
Max Klenk a25a429a52
add redis support 2020-09-10 13:39:00 +02:00
Max Klenk 06bc430c7c
refactor to use new workers and routes they serve 2020-08-28 13:53:39 +02:00
Marcel Partap 353bc7c362 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-19 19:05:03 +02:00