This is based on the PR (https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3241)
by Tobias Diez (https://github.com/tobiasdiez).
I've refactored some parts, made it more configurable, polished it up,
and it's integrated into the playbook now.
Both the WeChat bridge and WeChat agent appear to be working.
The WeChat bridge joins rooms and responds as expected.
That said, end-to-end testing (actually bridging to a WeChat account) has not been done yet.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/701
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3092
This is sponsored https://etke.cc/ work related to https://gitlab.com/etke.cc/ansible/-/issues/2
Squashed commit of the following:
commit fdd37f0247
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 21:05:53 2024 +0300
Add documentation for WeChat bridge
commit 8426fc8b95
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:59:42 2024 +0300
Rename directory for matrix_wechat_agent_container_src_files_path
commit da200df82b
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:58:26 2024 +0300
Make WeChat listen_secret configurable and auto-configured via matrix_homeserver_generic_secret_key
commit 4022cb1355
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:54:56 2024 +0300
Refactor install.yml for WeChat a bit (using blocks, etc.)
commit d07a39b4c4
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:52:35 2024 +0300
Rename WeChat Agent configuration file
This makes it more clear that it belongs to the agent.
Otherwise, `config.yaml` and `configure.yaml` make you wonder.
commit ccca72f8d1
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:49:06 2024 +0300
Move WeChat agent configuration to a template
commit a4047d94d8
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:47:17 2024 +0300
Mount WeChat config as readonly and instruct bridge to not update it
commit bc0e89f345
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:46:33 2024 +0300
Sync WeChat config with upstream
Brings up-to-date with:
https://github.com/duo/matrix-wechat/commits/0.2.4/example-config.yaml
commit a46f5b9cbc
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 19:48:17 2024 +0300
Rename some files
commit 3877679040
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 19:47:10 2024 +0300
Update WeChat logging config
This brings it up-to-date with what mautrix-go uses.
Otherwise, on startup we see:
> Migrating legacy log config
.. and it gets migrated to what we've done here.
commit e3e95ab234
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 19:43:37 2024 +0300
Make sure matrix-wechat-agent runs as 1000:1000
It needs to write stuff to `/home/user/.vnc`.
`/home/user` is owned by `user:group` (`1000:1000`), so it cannot run
any other way.
Previously, if the `matrix` user was uid=1000 by chance, it would work,
but that's pure luck.
commit 4d5748ae9b
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 18:57:09 2024 +0300
Pin wechat and wechat-agent versions
commit 40d40009f1
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 18:53:58 2024 +0300
docker_image -> container_image for WeChat bridge
commit cc33aff592
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 18:00:25 2024 +0300
docker_src -> container_src in WeChat bridge
commit 42e6ae9a64
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 17:54:24 2024 +0300
matrix_go_wechat_ -> matrix_wechat_
The bridge is written in Go, but does not include Go anywhere in its
name. As such, it's mostly useless to use `matrix_go_wechat` as the
prefix.
commit d6662a69d1
Author: Tobias Diez <code@tobiasdiez.de>
Date: Mon Mar 25 10:55:16 2024 +0800
Add wechat bridge
Only `amd64` and `arm64` actually work.
The KeyDB role includes a validation task and will complain about
unsupported architectures (like `arm32`).
`arm32` users can stick to Redis for now (`keydb_enabled: false` + `redis_enabled: true`) until:
- the KeyDB role starts supporting self-building.. although building such large
projects on weak CPUs is probably impractical
- a prebuilt arm32 image is made available by other means
commit cf8637efac
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:14:57 2024 +0200
Make devture_systemd_docker_base_ipv6_enabled automatically reconfigure geerlingguy/ansible-role-docker
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3218
commit dc7af3bc7d
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:10:31 2024 +0200
Replace matrix_ipv6_enabled with devture_systemd_docker_base_ipv6_enabled
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3218
commit 07e900d6a2
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:01:51 2024 +0200
Improve matrix_ipv6_enabled comments
commit 3f03ca7f69
Author: Tilo Spannagel <development@tilosp.de>
Date: Sat Mar 9 19:27:50 2024 +0000
Add setting to enable ipv6
* Draupnir for all Role
* Draupnir for all Documentation
* Pin D4A to Develop until D4A patches are in a release.
* Update D4A Docs to mention pros and cons of D4A mode compared to normal
* Change Documentation to mention a fixed simpler provisioning flow.
Use of /plain allows us to bypass the bugs encountered during the development of this role with clients attempting to escape our wildcards causing the grief that led to using curl.
This reworded commit does still explain you can automatically inject stuff into the room if you wanted to.
* Emphasise the State of D4A mode
* Link to Draupnir-for-all docs and tweak the docs some
* Link to Draupnir-for-all from Draupnir documentation page
* Announce Draupnir-for-all
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
This is a break in backward-compatibility for people disabling
`index.html` creation via the playbook but are managing their static
website files in another way (AUX role, etc).
Previously, we only enabled metrics when the playbook was installing
Prometheus (as indicated by `prometheus_enabled`).
We are exposing metrics when `matrix_metrics_exposure_enabled` is
toggled to `true` though, but people need to toggle various
`_metrics_enabled` variables to make services actually serve metrics.
No more. If `matrix_metrics_exposure_enabled` is `true`, we'll
automatically enable metrics for all services.
This allows people to not include the `matrix-conduit` or
`matrix-dendrite` roles in their custom playbook (based on our roles)
and still not have the playbook choke on variables from these roles
missing.
For getting rid of the `matrix-synapse` role in a similar way,
more work is likely necessary.
After some checking, it seems like there's `/_synapse/client/oidc`,
but no such thing as `/_synapse/oidc`.
I'm not sure why we've been reverse-proxying these paths for so long
(even in as far back as the `matrix-nginx-proxy` days), but it's time we
put a stop to it.
The OIDC docs have been simplified. There's no need to ask people to
expose the useless `/_synapse/oidc` endpoint. OIDC requires
`/_synapse/client/oidc` and `/_synapse/client` is exposed by default
already.
Traefik also serves an internal entrypoint that all addon services
(bridges, bots, etc.) depend on, so it makes sense to have it be
available early on. It is injected as a systemd `required` dependency
for all services, so it would have been pulled earlier anyway (despite
the priority). Nevertheless, it's better to make the playbook-defined
priotities for services match, so that services are explicitly asked to
start in a more correct order.
With these changes in place now, all "start service" tasks executed by
Ansible cause a "change", indicating that all these services are started
in the correct order and none of them is unintentionally started as a
dependency for another.
The old variables still work. The global lets us avoid
auto-detection logic like we're currently doing for
`matrix_nginx_proxy_proxy_matrix_federation_api_enabled`.
In the future, we'd just be able to reference
`matrix_homeserver_federation_enabled` and know the up-to-date value
regardless of homeserver.
This was meant to serve as an intermediary for services needing to reach
the homeserver. It was used like that for a while in this
`bye-bye-nginx-proxy` branch, but was never actually public.
It has recently been superseded by homeserver-like services injecting
themselves into a new internal Traefik entrypoint
(see `matrix_playbook_internal_matrix_client_api_traefik_entrypoint_*`),
so `matrix-homeserver-proxy` is no longer necessary.
---
This is probably a good moment to share some benchmarks and reasons
for going with the internal Traefik entrypoint as opposed to this nginx
service.
1. (1400 rps) Directly to Synapse (`ab -n 1000 -c 100 http://matrix-synapse:8008/_matrix/client/versions`
2. (~900 rps) Via `matrix-homeserver-proxy` (nginx) proxying to Synapse (`ab -n 1000 -c 100 http://matrix-homeserver-proxy:8008/_matrix/client/versions`)
3. (~1200 rps) Via the new internal entrypoint of Traefik (`matrix-internal-matrix-client-api`) proxying to Synapse (`ab -n 1000 -c 100 http://matrix-traefik:8008/_matrix/client/versions`)
Besides Traefik being quicker for some reason, there are also other
benefits to not having this `matrix-homeserver-proxy` component:
- we can reuse what we have in terms of labels. Services can register a few extra labels on the new Traefik entrypoint
- we don't need services (like `matrix-media-repo`) to inject custom nginx configs into `matrix-homeserver-proxy`. They just need to register labels, like they do already.
- Traefik seems faster than nginx on this benchmark for some reason, which is a nice bonus
- no need to run one extra container (`matrix-homeserver-proxy`) and execute one extra Ansible role
- no need to maintain a setup where some people run the `matrix-homeserver-proxy` component (because they have route-stealing services like `matrix-media-repo` enabled) and others run an optimized setup without this component and everything needs to be rewired to talk to the homeserver directly. Now, everyone can go through Traefik and we can all run an identical setup
Downsides of the new Traefik entrypoint setup are that:
- all addon services that need to talk to the homeserver now depend on Traefik
- people running their own Traefik setup will be inconvenienced - they
need to manage one additional entrypoint
HarHarLinks
CKSit
Slavi Pantaleev
Igor Goldenberg
Aine
Aine
Catalan Lover
Catalan Lover
Pierre 'McFly' Marty
Charles Wright