Role defaults should not reference playbook-level variables like
matrix_playbook_reverse_proxy_type or traefik_entrypoint_primary,
as this breaks standalone usage of the role.
Following the pattern established by other roles (matrix-sliding-sync,
matrix-synapse-admin, matrix-media-repo, etc.), Traefik variables now
use safe standalone defaults (true, web-secure, default) while the
actual playbook wiring remains in group_vars/matrix_servers.
Also standardized certResolver variable naming to use camelCase,
consistent with other roles in the playbook.
Instead of hardcoding 'https' in the publicUrl, introduce a scheme variable
that can be configured. This follows the pattern used by other roles
(e.g., matrix_mautrix_discord_scheme, matrix_hookshot_public_scheme).
New variables:
- matrix_appservice_irc_ircService_mediaProxy_publicUrl_scheme (defaults to https)
- matrix_appservice_irc_ircService_mediaProxy_publicUrl (combines scheme, hostname, pathPrefix)
The scheme is wired in group_vars/matrix_servers based on matrix_playbook_ssl_enabled,
consistent with how other roles handle this.
Variables that map to nested YAML config properties should follow the pattern:
matrix_<component>_<configPath>_<nestedProperty>
For ircService.mediaProxy.*, we now use:
- matrix_appservice_irc_ircService_mediaProxy_bindPort
- matrix_appservice_irc_ircService_mediaProxy_publicUrl_hostname
- matrix_appservice_irc_ircService_mediaProxy_publicUrl_pathPrefix
This follows the existing pattern used by matrix_appservice_irc_ircService_servers
and similar variables in other roles (e.g., matrix_hookshot_github_defaultOptions_*).
Also renamed the Traefik path prefix variable to include 'media_proxy' for clarity:
- matrix_appservice_irc_container_labels_media_proxy_traefik_path_prefix
This:
- brings consistency - no more mixing `_name_prefix` and `_registry_prefix`
- adds extensibility - a future patch will allow reconfiguring all registry prefixes for all roles in the playbook
We still have `_docker_` vs `_container_` inconsistencies.
These may be worked on later.
This is done for a few reasons:
- less globals and more indepdendence for each role is better. We rely
on various externally-hosted roles and they don't rely on this global
either.
- `matrix_container_global_registry_prefix` could make people think they
could just override this variable and have all their images pull from
elsewhere. This is rarely the case, unless you've taken special care
to mirror all the various components (from their respective
registries) to your own. In such a case, you probably know what you're
mirroring and can adjust individual variables.
- nowadays, various components live on different registries.
With Docker Inc tightening rate limits for Docker Hub, it's even more
likely that we'll see increased diversity in where images are hosted
* Add a global config option for Docker network MTU
* Upgrade systemd_docker_base (v1.2.0-0 -> v1.3.0-0)
The new version includes `devture_systemd_docker_base_container_networks_driver_options`
due to 3cc7d12396
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3502
* Switch from passing matrix_playbook_docker_network_mtu to respecting devture_systemd_docker_base_container_networks_driver_options
Related to:
- 3cc7d12396
- https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3502
* Update all roles to versions that respect `devture_systemd_docker_base_container_networks_driver_options`
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Related to 0241c71a4c
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3270#issuecomment-2143782962
With this change, it should be possible for people to adjust the Docker
dependency from `docker.service` to something else (e.g. `pkg-ContainerManager-dockerd.service`),
or to completely eliminate it by setting `devture_systemd_docker_base_docker_service_name` to an empty string.
This makes it easier for people to use the playbook against a Synology DSM server.
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
This is an attempt at optimizing service startup.
The effect is most pronounced when many services are restarted one by one.
The systemd service manager role sometimes does this - for example when `just install-service synapse` runs.
In such cases, a 5-second delay for each Synapse worker service
(or other bridge/bot service that waits on the homeserver) quickly adds up to a lot.
When services are all stopped fully and then started, the effect is not so pronounced, because
`matrix-synapse.service` starts first and pulls all worker services (defined as `Wants=` for it).
Later on, when the systemd service manager role "starts" these worker services, they're started already.
Even if they had a 5-second wait each, it would have happened in parallel.
Slavi Pantaleev
Thom Wiggers
Jade Ellis
Suguru Hirahara
David Mehren