overmind
/
matrix-docker-ansible-deploy
mirror da https://github.com/spantaleev/matrix-docker-ansible-deploy
1
0
Forka 0
Codice Problemi 0 Rilasci 0 Wiki Attività
Matrix Docker Ansible eploy
Non puoi selezionare più di 25 argomenti Gli argomenti devono iniziare con una lettera o un numero, possono includere trattini ('-') e possono essere lunghi fino a 35 caratteri.
5141 Commit
13 Rami (Branch)
36 MiB
 
 
Albero (Tree): 37d4bf0d1c
Rami (Branch) Tag
${ item.name }
Crea branch ${ searchTerm }
da '37d4bf0d1c'
${ noResults }
matrix-docker-ansible-deploy/roles/custom/matrix-synapse/vars/workers.yml

457 righe
18 KiB
Originale Blame Cronologia 

  1. ---

  2. 

  3. matrix_synapse_workers_generic_worker_endpoints:

  4.   # This worker can handle API requests matching the following regular expressions.

  5.   # These endpoints can be routed to any worker. If a worker is set up to handle a

  6.   # stream then, for maximum efficiency, additional endpoints should be routed to that

  7.   # worker: refer to the [stream writers](#stream-writers) section below for further

  8.   # information.

  9. 

  10.   # Sync requests

  11.   - ^/_matrix/client/(r0|v3)/sync$

  12.   - ^/_matrix/client/(api/v1|r0|v3)/events$

  13.   - ^/_matrix/client/(api/v1|r0|v3)/initialSync$

  14.   - ^/_matrix/client/(api/v1|r0|v3)/rooms/[^/]+/initialSync$

  15. 

  16.   # Federation requests

  17.   - ^/_matrix/federation/v1/event/

  18.   - ^/_matrix/federation/v1/state/

  19.   - ^/_matrix/federation/v1/state_ids/

  20.   - ^/_matrix/federation/v1/backfill/

  21.   - ^/_matrix/federation/v1/get_missing_events/

  22.   - ^/_matrix/federation/v1/publicRooms

  23.   - ^/_matrix/federation/v1/query/

  24.   - ^/_matrix/federation/v1/make_join/

  25.   - ^/_matrix/federation/v1/make_leave/

  26.   - ^/_matrix/federation/(v1|v2)/send_join/

  27.   - ^/_matrix/federation/(v1|v2)/send_leave/

  28.   - ^/_matrix/federation/(v1|v2)/invite/

  29.   - ^/_matrix/federation/v1/event_auth/

  30.   - ^/_matrix/federation/v1/exchange_third_party_invite/

  31.   - ^/_matrix/federation/v1/user/devices/

  32.   - ^/_matrix/key/v2/query

  33.   - ^/_matrix/federation/v1/hierarchy/

  34. 

  35.   # Inbound federation transaction request

  36.   - ^/_matrix/federation/v1/send/

  37. 

  38.   # Client API requests

  39.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/createRoom$

  40.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/publicRooms$

  41.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/joined_members$

  42.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/context/.*$

  43.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/members$

  44.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/state$

  45.   - ^/_matrix/client/v1/rooms/.*/hierarchy$

  46.   - ^/_matrix/client/(v1|unstable)/rooms/.*/relations/

  47.   - ^/_matrix/client/v1/rooms/.*/threads$

  48.   - ^/_matrix/client/unstable/org.matrix.msc2716/rooms/.*/batch_send$

  49.   - ^/_matrix/client/unstable/im.nheko.summary/rooms/.*/summary$

  50.   - ^/_matrix/client/(r0|v3|unstable)/account/3pid$

  51.   - ^/_matrix/client/(r0|v3|unstable)/account/whoami$

  52.   - ^/_matrix/client/(r0|v3|unstable)/devices$

  53.   - ^/_matrix/client/versions$

  54.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/voip/turnServer$

  55.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/event/

  56.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/joined_rooms$

  57.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/search$

  58. 

  59.   # Encryption requests

  60.   # Note that ^/_matrix/client/(r0|v3|unstable)/keys/upload/ requires `worker_main_http_uri`

  61.   - ^/_matrix/client/(r0|v3|unstable)/keys/query$

  62.   - ^/_matrix/client/(r0|v3|unstable)/keys/changes$

  63.   - ^/_matrix/client/(r0|v3|unstable)/keys/claim$

  64.   - ^/_matrix/client/(r0|v3|unstable)/room_keys/

  65.   - ^/_matrix/client/(r0|v3|unstable)/keys/upload/

  66. 

  67.   # Registration/login requests

  68.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/login$

  69.   - ^/_matrix/client/(r0|v3|unstable)/register$

  70.   - ^/_matrix/client/v1/register/m.login.registration_token/validity$

  71. 

  72.   # Event sending requests

  73.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/redact

  74.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/send

  75.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/state/

  76.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/(join|invite|leave|ban|unban|kick)$

  77.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/join/

  78.   - ^/_matrix/client/(api/v1|r0|v3|unstable)/profile/

  79. 

  80. # These appear to be conditional and should not be enabled by default.

  81. # We need to fix up our workers-doc-to-yaml.awk parsing script to exclude them.

  82. # For now, they've been commented out manually.

  83. #  # Account data requests

  84. #  - ^/_matrix/client/(r0|v3|unstable)/.*/tags

  85. #  - ^/_matrix/client/(r0|v3|unstable)/.*/account_data

  86. #

  87. #  # Receipts requests

  88. #  - ^/_matrix/client/(r0|v3|unstable)/rooms/.*/receipt

  89. #  - ^/_matrix/client/(r0|v3|unstable)/rooms/.*/read_markers

  90. #

  91. #  # Presence requests

  92. #  - ^/_matrix/client/(api/v1|r0|v3|unstable)/presence/

  93. 

  94.   # User directory search requests

  95.   # Any worker can handle these, but we have a dedicated user_dir worker for this,

  96.   # so we'd like for other generic workers to not try and capture these requests.

  97.   # - ^/_matrix/client/(r0|v3|unstable)/user_directory/search$

  98. 

  99.   # Additionally, the following REST endpoints can be handled for GET requests:

  100. 

  101.   # FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

  102.   # ^/_matrix/client/(api/v1|r0|v3|unstable)/pushrules/

  103. 

  104.   # Pagination requests can also be handled, but all requests for a given

  105.   # room must be routed to the same instance. Additionally, care must be taken to

  106.   # ensure that the purge history admin API is not used while pagination requests

  107.   # for the room are in flight:

  108. 

  109.   # FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

  110.   # ^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/messages$

  111. 

  112.   # Additionally, the following endpoints should be included if Synapse is configured

  113.   # to use SSO (you only need to include the ones for whichever SSO provider you're

  114.   # using):

  115. 

  116.   # for all SSO providers

  117.   # FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

  118.   # ^/_matrix/client/(api/v1|r0|v3|unstable)/login/sso/redirect

  119.   # ^/_synapse/client/pick_idp$

  120.   # ^/_synapse/client/pick_username

  121.   # ^/_synapse/client/new_user_consent$

  122.   # ^/_synapse/client/sso_register$

  123. 

  124.   # OpenID Connect requests.

  125.   # FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

  126.   # ^/_synapse/client/oidc/callback$

  127. 

  128.   # SAML requests.

  129.   # FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

  130.   # ^/_synapse/client/saml2/authn_response$

  131. 

  132.   # CAS requests.

  133.   # FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

  134.   # ^/_matrix/client/(api/v1|r0|v3|unstable)/login/cas/ticket$

  135. 

  136.   # Ensure that all SSO logins go to a single process.

  137.   # For multiple workers not handling the SSO endpoints properly, see

  138.   # [#7530](https://github.com/matrix-org/synapse/issues/7530) and

  139.   # [#9427](https://github.com/matrix-org/synapse/issues/9427).

  140. 

  141.   # Note that a [HTTP listener](usage/configuration/config_documentation.md#listeners)

  142.   # with `client` and `federation` `resources` must be configured in the `worker_listeners`

  143.   # option in the worker config.

  144. 

  145.   # #### Load balancing

  146. 

  147.   # It is possible to run multiple instances of this worker app, with incoming requests

  148.   # being load-balanced between them by the reverse-proxy. However, different endpoints

  149.   # have different characteristics and so admins

  150.   # may wish to run multiple groups of workers handling different endpoints so that

  151.   # load balancing can be done in different ways.

  152. 

  153.   # For `/sync` and `/initialSync` requests it will be more efficient if all

  154.   # requests from a particular user are routed to a single instance. Extracting a

  155.   # user ID from the access token or `Authorization` header is currently left as an

  156.   # exercise for the reader. Admins may additionally wish to separate out `/sync`

  157.   # requests that have a `since` query parameter from those that don't (and

  158.   # `/initialSync`), as requests that don't are known as "initial sync" that happens

  159.   # when a user logs in on a new device and can be *very* resource intensive, so

  160.   # isolating these requests will stop them from interfering with other users ongoing

  161.   # syncs.

  162. 

  163.   # Federation and client requests can be balanced via simple round robin.

  164. 

  165.   # The inbound federation transaction request `^/_matrix/federation/v1/send/`

  166.   # should be balanced by source IP so that transactions from the same remote server

  167.   # go to the same process.

  168. 

  169.   # Registration/login requests can be handled separately purely to help ensure that

  170.   # unexpected load doesn't affect new logins and sign ups.

  171. 

  172.   # Finally, event sending requests can be balanced by the room ID in the URI (or

  173.   # the full URI, or even just round robin), the room ID is the path component after

  174.   # `/rooms/`. If there is a large bridge connected that is sending or may send lots

  175.   # of events, then a dedicated set of workers can be provisioned to limit the

  176.   # effects of bursts of events from that bridge on events sent by normal users.

  177. 

  178.   # #### Stream writers

  179. 

  180.   # Additionally, the writing of specific streams (such as events) can be moved off

  181.   # of the main process to a particular worker.

  182. 

  183.   # To enable this, the worker must have a

  184.   # [HTTP `replication` listener](usage/configuration/config_documentation.md#listeners) configured,

  185.   # have a `worker_name` and be listed in the `instance_map` config. The same worker

  186.   # can handle multiple streams, but unless otherwise documented, each stream can only

  187.   # have a single writer.

  188. 

  189.   # For example, to move event persistence off to a dedicated worker, the shared

  190.   # configuration would include:

  191. 

  192.   # ```yaml

  193.   # instance_map:

  194.   #     event_persister1:

  195.   #         host: localhost

  196.   #         port: 8034

  197. 

  198.   # stream_writers:

  199.   #     events: event_persister1

  200.   # ```

  201. 

  202.   # An example for a stream writer instance:

  203. 

  204.   # ```yaml

  205.   # {{#include systemd-with-workers/workers/event_persister.yaml}}

  206.   # ```

  207. 

  208.   # Some of the streams have associated endpoints which, for maximum efficiency, should

  209.   # be routed to the workers handling that stream. See below for the currently supported

  210.   # streams and the endpoints associated with them:

  211. 

  212.   # ##### The `events` stream

  213. 

  214.   # The `events` stream experimentally supports having multiple writers, where work

  215.   # is sharded between them by room ID. Note that you *must* restart all worker

  216.   # instances when adding or removing event persisters. An example `stream_writers`

  217.   # configuration with multiple writers:

  218. 

  219.   # ```yaml

  220.   # stream_writers:

  221.   #     events:

  222.   #         - event_persister1

  223.   #         - event_persister2

  224.   # ```

  225. 

  226.   # ##### The `typing` stream

  227. 

  228.   # The following endpoints should be routed directly to the worker configured as

  229.   # the stream writer for the `typing` stream:

  230. 

  231.   # FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

  232.   # ^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/typing

  233. 

  234.   # ##### The `to_device` stream

  235. 

  236.   # The following endpoints should be routed directly to the worker configured as

  237.   # the stream writer for the `to_device` stream:

  238. 

  239.   # FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

  240.   # ^/_matrix/client/(r0|v3|unstable)/sendToDevice/

  241. 

  242.   # ##### The `account_data` stream

  243. 

  244.   # The following endpoints should be routed directly to the worker configured as

  245.   # the stream writer for the `account_data` stream:

  246. 

  247.   # FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

  248.   # ^/_matrix/client/(r0|v3|unstable)/.*/tags

  249.   # ^/_matrix/client/(r0|v3|unstable)/.*/account_data

  250. 

  251.   # ##### The `receipts` stream

  252. 

  253.   # The following endpoints should be routed directly to the worker configured as

  254.   # the stream writer for the `receipts` stream:

  255. 

  256.   # FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

  257.   # ^/_matrix/client/(r0|v3|unstable)/rooms/.*/receipt

  258.   # ^/_matrix/client/(r0|v3|unstable)/rooms/.*/read_markers

  259. 

  260.   # ##### The `presence` stream

  261. 

  262.   # The following endpoints should be routed directly to the worker configured as

  263.   # the stream writer for the `presence` stream:

  264. 

  265.   # FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

  266.   # ^/_matrix/client/(api/v1|r0|v3|unstable)/presence/

  267. 

  268.   # #### Background tasks

  269. 

  270.   # There is also support for moving background tasks to a separate

  271.   # worker. Background tasks are run periodically or started via replication. Exactly

  272.   # which tasks are configured to run depends on your Synapse configuration (e.g. if

  273.   # stats is enabled). This worker doesn't handle any REST endpoints itself.

  274. 

  275.   # To enable this, the worker must have a `worker_name` and can be configured to run

  276.   # background tasks. For example, to move background tasks to a dedicated worker,

  277.   # the shared configuration would include:

  278. 

  279.   # ```yaml

  280.   # run_background_tasks_on: background_worker

  281.   # ```

  282. 

  283.   # You might also wish to investigate the `update_user_directory_from_worker` and

  284.   # `media_instance_running_background_jobs` settings.

  285. 

  286.   # An example for a dedicated background worker instance:

  287. 

  288.   # ```yaml

  289.   # {{#include systemd-with-workers/workers/background_worker.yaml}}

  290.   # ```

  291. 

  292.   # #### Updating the User Directory

  293. 

  294.   # You can designate one generic worker to update the user directory.

  295. 

  296.   # Specify its name in the shared configuration as follows:

  297. 

  298.   # ```yaml

  299.   # update_user_directory_from_worker: worker_name

  300.   # ```

  301. 

  302.   # This work cannot be load-balanced; please ensure the main process is restarted

  303.   # after setting this option in the shared configuration!

  304. 

  305.   # User directory updates allow REST endpoints matching the following regular

  306.   # expressions to work:

  307. 

  308.   # FIXME: ADDITIONAL CONDITIONS REQUIRED: to be enabled manually

  309.   # ^/_matrix/client/(r0|v3|unstable)/user_directory/search$

  310. 

  311.   # The above endpoints can be routed to any worker, though you may choose to route

  312.   # it to the chosen user directory worker.

  313. 

  314.   # This style of configuration supersedes the legacy `synapse.app.user_dir`

  315.   # worker application type.

  316. 

  317. 

  318.   # #### Notifying Application Services

  319. 

  320.   # You can designate one generic worker to send output traffic to Application Services.

  321.   # Doesn't handle any REST endpoints itself, but you should specify its name in the

  322.   # shared configuration as follows:

  323. 

  324.   # ```yaml

  325.   # notify_appservices_from_worker: worker_name

  326.   # ```

  327. 

  328.   # This work cannot be load-balanced; please ensure the main process is restarted

  329.   # after setting this option in the shared configuration!

  330. 

  331.   # This style of configuration supersedes the legacy `synapse.app.appservice`

  332.   # worker application type.

  333. 

  334. 

  335. # pusher worker (no API endpoints) [

  336.   # Handles sending push notifications to sygnal and email. Doesn't handle any

  337.   # REST endpoints itself, but you should set `start_pushers: False` in the

  338.   # shared configuration file to stop the main synapse sending push notifications.

  339. 

  340.   # To run multiple instances at once the `pusher_instances` option should list all

  341.   # pusher instances by their worker name, e.g.:

  342. 

  343.   # ```yaml

  344.   # pusher_instances:

  345.   #     - pusher_worker1

  346.   #     - pusher_worker2

  347.   # ```

  348. 

  349.   # An example for a pusher instance:

  350. 

  351.   # ```yaml

  352.   # {{#include systemd-with-workers/workers/pusher_worker.yaml}}

  353.   # ```

  354. 

  355. # ]

  356. 

  357. # appservice worker (no API endpoints) [

  358.   # **Deprecated as of Synapse v1.59.** [Use `synapse.app.generic_worker` with the

  359.   # `notify_appservices_from_worker` option instead.](#notifying-application-services)

  360. 

  361.   # Handles sending output traffic to Application Services. Doesn't handle any

  362.   # REST endpoints itself, but you should set `notify_appservices: False` in the

  363.   # shared configuration file to stop the main synapse sending appservice notifications.

  364. 

  365.   # Note this worker cannot be load-balanced: only one instance should be active.

  366. 

  367. # ]

  368. 

  369. # federation_sender worker (no API endpoints) [

  370.   # Handles sending federation traffic to other servers. Doesn't handle any

  371.   # REST endpoints itself, but you should set `send_federation: False` in the

  372.   # shared configuration file to stop the main synapse sending this traffic.

  373. 

  374.   # If running multiple federation senders then you must list each

  375.   # instance in the `federation_sender_instances` option by their `worker_name`.

  376.   # All instances must be stopped and started when adding or removing instances.

  377.   # For example:

  378. 

  379.   # ```yaml

  380.   # federation_sender_instances:

  381.   #     - federation_sender1

  382.   #     - federation_sender2

  383.   # ```

  384. 

  385.   # An example for a federation sender instance:

  386. 

  387.   # ```yaml

  388.   # {{#include systemd-with-workers/workers/federation_sender.yaml}}

  389.   # ```

  390. # ]

  391. 

  392. matrix_synapse_workers_media_repository_endpoints:

  393.   # Handles the media repository. It can handle all endpoints starting with:

  394. 

  395.   - ^/_matrix/media/

  396. 

  397.   # ... and the following regular expressions matching media-specific administration APIs:

  398. 

  399.   - ^/_synapse/admin/v1/purge_media_cache$

  400.   - ^/_synapse/admin/v1/room/.*/media.*$

  401.   - ^/_synapse/admin/v1/user/.*/media.*$

  402.   - ^/_synapse/admin/v1/media/.*$

  403.   - ^/_synapse/admin/v1/quarantine_media/.*$

  404.   - ^/_synapse/admin/v1/users/.*/media$

  405. 

  406.   # You should also set `enable_media_repo: False` in the shared configuration

  407.   # file to stop the main synapse running background jobs related to managing the

  408.   # media repository. Note that doing so will prevent the main process from being

  409.   # able to handle the above endpoints.

  410. 

  411.   # In the `media_repository` worker configuration file, configure the

  412.   # [HTTP listener](usage/configuration/config_documentation.md#listeners) to

  413.   # expose the `media` resource. For example:

  414. 

  415.   # ```yaml

  416.   # {{#include systemd-with-workers/workers/media_worker.yaml}}

  417.   # ```

  418. 

  419.   # Note that if running multiple media repositories they must be on the same server

  420.   # and you must configure a single instance to run the background tasks, e.g.:

  421. 

  422.   # ```yaml

  423.   # media_instance_running_background_jobs: "media-repository-1"

  424.   # ```

  425. 

  426.   # Note that if a reverse proxy is used , then `/_matrix/media/` must be routed for both inbound client and federation requests (if they are handled separately).

  427. 

  428. matrix_synapse_workers_user_dir_endpoints:

  429.   # **Deprecated as of Synapse v1.59.** [Use `synapse.app.generic_worker` with the

  430.   # `update_user_directory_from_worker` option instead.](#updating-the-user-directory)

  431. 

  432.   # Handles searches in the user directory. It can handle REST endpoints matching

  433.   # the following regular expressions:

  434. 

  435.   - ^/_matrix/client/(r0|v3|unstable)/user_directory/search$

  436. 

  437.   # When using this worker you must also set `update_user_directory: false` in the

  438.   # shared configuration file to stop the main synapse running background

  439.   # jobs related to updating the user directory.

  440. 

  441.   # Above endpoint is not *required* to be routed to this worker. By default,

  442.   # `update_user_directory` is set to `true`, which means the main process

  443.   # will handle updates. All workers configured with `client` can handle the above

  444.   # endpoint as long as either this worker or the main process are configured to

  445.   # handle it, and are online.

  446. 

  447.   # If `update_user_directory` is set to `false`, and this worker is not running,

  448.   # the above endpoint may give outdated results.

  449. 

  450. matrix_synapse_workers_avail_list:

  451.   - appservice

  452.   - federation_sender

  453.   - generic_worker

  454.   - media_repository

  455.   - pusher

  456.   - user_dir