🛠 Refonte de la stack Matrix sans-nuage

[Optogram]

J’ai posté ça : https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5338

[Optogram]

Voici mes notes d’installation :

Prérequis

Paramètres DNS

• Port HTTP : 80, en TCP
• Port HTTPS : 443, en TCP et UDP
• Port de la fédération : 8448, en TCP et UDP

Type	Hôte	Cible
A	matrix	Adresse IPv4 du serveur
AAA	matrix	Adresse IPv6 du serveur
CNAME	element	matrix.domaine.com
CNAME	ntfy	matrix.domaine.com

Applications

sudo apt update
sudo apt install pipx
pipx ensurepath
sudo apt install git
sudo apt install just
sudo apt install python3
sudo apt install pwgen
sudo pipx install --include-deps ansible

Ansible

Normalement, le playbook se fait sur un autre système puis est exécuté sur la machine distante. Moi, je ne suis pas doué, j’ai tout fait sur une seule machine.

Récupérez le playbook

Depuis le dossier de l’utilisateur (/home/utilisateur), ça créera un dossier matrix-docker-ansible-deploy depuis lequel il faudra exécuter toutes les commandes

git clone https://github.com/spantaleev/matrix-docker-ansible-deploy.git

Créer le dossier du serveur

Depuis le dossier matrix-docker-ansible-deploy. Il faut modifier le nom de domaine avec celui qui sera utilisé.

mkdir -p inventory/host_vars/matrix.domaine.com

Créer le fichier de configuration d’exemple, vars.yml

cp examples/vars.yml inventory/host_vars/matrix.domaine.com/vars.yml

Le contenu du fichier correponds à ce que j’ai proposé plus haut (https://forum.arn-fai.net/t/topic/9867/32)

Paramètres de délégation

C’est le sujet sur lequel je patauge, je vous laisse lire la documentation : https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/docs/configuring-playbook.md

Modifier le date du journal des modifications

En haut du fichier vars.yml, il faut changer la date du journal des modifications pour montrer qu’il a bien été lu (https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/CHANGELOG.md).

matrix_playbook_migration_validated_version: v2026.05.24.0

Récupérez le fichier hôte, hosts

cp examples/hosts inventory/hosts

Voici le contenu de mon fichier :

matrix.domaine.com ansible_host=ADRESSE-IP-DU-SERVEUR ansible_ssh_user=UTILISATEUR ansible_become=true ansible_become_user=root ansible_connection=local

Puisque le playbook est crée et exécuté sur la même machine, les paramètres suivants sont ajoutés. Un texte commenté précise ce sujet dans le fichier host d’exemple que vous avez copié.

ansible_become_user=root
ansible_connection=local

Lancer le playbook pour la première fois

just update
ansible-playbook -i inventory/hosts setup.yml --tags=install-all,ensure-matrix-users-created,start --ask-become-pass

Puisque je lance la commande avec un utilisateur non root, en local, j’ajoute ask-become-pass à la fin de la commande et j’entre le mot de passe de l’utilisateur pour exécuter le playbook avec sudo.

Mettre à jour les services après une modification de la configuration

S’il n’y a que des modifications de paramètres :

just update
ansible-playbook -i inventory/hosts setup.yml --tags=install-all,start --ask-become-pass

Si des nouveaux composants sont ajoutés :

just update
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,ensure-matrix-users-created,start --ask-become-pass

Administration

Créer le premier compte

ansible-playbook -i inventory/hosts setup.yml --extra-vars='username=NOM-D-UTILISATEUR password=MOT-DE-PASSE admin=yes' --tags=register-user --ask-become-pass

Si l’utilisateur n’est pas administrateur, il faut ôter le paramètre admin=yes.

Accéder à l’interface d’administration avec le premier compte

https://matrix.domaine.com/ketesa/

Maintenance

Libérer de l’espace disque

Compresser les state_groups

L’opération est réalisée automatiquement, en fonction de la configuration de vars.yml. Ces commandes déclenchent manuellement la compression.

sudo systemctl start matrix-synapse-auto-compressor
sudo journalctl -fu matrix-synapse-auto-compressor

Supprimer les conteneurs docker inutilisés

sudo docker system prune -a

[Optogram]

@sepp Est-ce que tu peux publier ici l’étendue de ton avancement s’il te plait ?

[sepp]

J’ai créé un rôle Ansible qui installe deux serveurs Matrix en fédération. Matrix-users et Matrix bridges. Les bridges sont installés sur Matrix Bridges. Les bases de donnée des 2 serveurs Matrix et des bridges (chaque bridges a sa propre base de données) sont sur une vm dédiée.

Le tout se situe derrière un proxy Caddy.Celui-ci permet de diriger les

- HTTPS / certificats TLS

• reverse proxy vers Synapse, Element, Keycloak
• headers X-Forwarded-* pour Keycloak
• .well-known Matrix pour la fédération

Voici le rôle Ansible du stack matrix: GitHub - sepp67/ansible-role-matrix-stack

Ce rôle ne fait qu’installer les programmes (matrix-element et les DB).

Le paramétrage du réseau( les IPs, les ports et les certificats SSL) est encadré par un autre rôle : GitHub – sepp67/devops_staging_prod_infra

Explication. J’ai un rôle staging-production qui se compose de deux reverse proxies Caddy. Il permet de déployer un rôle Ansible en local avec des certificats autosignés. Ensuite de déployer ce même rôle en production (accessible sur internet.) Ça permet d’avoir un environnement test pour expérimenter les grands changements dans le rôle.

Ce rôle encadre tous mes sites et mes applications, mais je ferai une version qui déploie que la stack Matrix pour ARN. C’est assez simple. Il y a une liste dans l’inventaire d’Ansible à décocher.

Pour ARN, on peut s’éviter de mettre en place un environnement staging. Pour tester les grandes actualisations, il faudra déployer le stack Matrix en local, comme je fais chez moi.

Keycloak est installé semi-manuellement avec un docker-compose. Je n’ai pas créé de rôle pour ça parce que Keycloak devrait toujours être actualisé manuellement. C’est plus sûr.

Étape suivante, le déployer et voir si mon rôle s’installe sans embrouille

[sepp]

Ce serait une bonne opportunité pour faire un ou des ateliers spécial INFRA.

Pour mettre en place ce projet, il faut plusieurs grandes actions:

Créer des VMs sur Proxmox.

Configurer le routage pour que la VM Caddy obtienne une IP fixe

Mettre en place la redirection pour que le nom de domaine pointe vers cette IP.

Ensuite, on crée les autres VMs et on déploie toute la stack.

[Optogram]

Je viens d’aller voir le Github, sacré boulot !

J’ai plein de questions :

• Tu t’es inspiré du playbook ansible dont on parlait avant ?
• Si on veut ajouter des bridges et des fonctions, il faut créer soi-même les fichiers de configuration ?
• Comment effectuer les mises à jour ?
• A quel point nous sommes dépendants de ton expertise ?
• Tu as utilisé Claude pour faire tout ça ? Si oui, dans quelle mesure ?
• Est-ce qu’il est possible d’utiliser ce rôle pour créer le serveur matrix CHATONS, qui est donc unique, sans bridges mais sans doute avec des outils de modération ou autre ?

Ce qui m’embête, c’est que ta solution custom ne règle pas le problème de base que l’on a actuellement avec les paquets Yunohost et leurs mises à jour. L’intérêt du gros playbook Ansible est qu’il est beaucoup utilisé et bien maintenu.

Je vois que tu as encore prévu de créer toutes les fonctions que l’on souhaite déployer, si tu es chaud, c’est fantastique.

[GautGaut]

• existe-t-il une notion de fork/héritage dans les rôles ansible ? Genre on clonerait le repo du playbook bien connu et on ferait des modifs comme ça on pourrait récupérer les modifs du dépôt upstream ?

• Quel est l’intérêt de ta solution vs déployer https://github.com/spantaleev/matrix-docker-ansible-deploy configuré à notre sauce sur deux serveurs ?

• A savoir qu’il n’y aurait pas d’utilisateurs finaux qui auraient besoin de s’identifier sur le serveur des bridges, donc pourquoi y connecter keycloak ?

• Pourquoi ne pas tout mettre sur une seule VM avec des docker dedans ? Le paquet yunohost étant multi-instance on doit au moins pouvoir mettre les deux synapse sur la même machine https://github.com/YunoHost-Apps/synapse_ynh/blob/master/manifest.toml#L28 Après pour des affaires de droits on peut vouloir que certains admin aient accès au serveur user et d’autres au serveur des bridges.

[sepp]

Réponses à Optogram

« Tu t’es inspiré du playbook ansible dont on parlait avant ? »

Je m’en suis inspiré dans l’esprit (séparer la stack Matrix du reste de l’infra, gérer les bridges de façon générique) mais pas dans le code. J’ai fait le choix d’écrire un rôle « from scratch », plus petit et pensé spécifiquement pour notre topologie à deux homeservers (users / bridges) et en me fondant sur mon INFRA existante (Caddy, Vault, inventaires staging/prod).

« Si on veut ajouter des bridges et des fonctions, il faut créer soi-même les fichiers de configuration ? »

Pour un bridge déjà supporté par l’image (whatsapp, telegram, signal aujourd’hui), non : il suffit d’ajouter une entrée dans la liste matrix_bridges (image, tag, ports, identifiants DB) et une entrée correspondante dans matrix_postgresql_databases. Le rôle génère tout seul config.yaml, registration.yaml et docker-compose.yml à partir d’un template générique, sans toucher au code du rôle.

Par contre, pour la configuration « métier » propre à chaque bridge (connexion QR WhatsApp, API Telegram, liaison Signal), il faut effectivement fournir des paramètres spécifiques via extra_config .

« Comment effectuer les mises à jour ? »

Aujourd’hui, une mise à jour se fait en changeant le tag d’image Github (tag: latest ou une version épinglée) dans les variables, puis en relançant le playbook — le rôle est idempotent, donc il ne touche que ce qui a changé. Il n’y a pas encore de mécanisme de veille automatique sur les nouvelles versions. Grave à mon infra staging-production on peut tester à chaque fois en local une mise à jour.

« À quel point sommes-nous dépendants de ton expertise ? »

Aujourd’hui : beaucoup, parce que le rôle est jeune, peu documenté au-delà du README, et que je suis le seul contributeur. Mon objectif est justement d’écrire une documentation suffisante (structure des variables, procédure d’ajout de bridge, procédure de mise à jour, restauration) pour qu’un autre admin puisse reprendre la main sans moi. Mais comme toute infra gérée en interne, tant que le projet a un seul mainteneur et zéro autre contributeur, il y a dépendance et donc risque de bus factor.

« Tu as utilisé Claude pour faire tout ça ? Si oui, dans quelle mesure ? »

Oui, j’ai utilisé Claude comme assistant tout au long du développement : conception de l’architecture (séparation rôle/infra, gestion générique des bridges), écriture des tâches Ansible et des templates Jinja, le debugage, et surtout la rédaction du README ! Maintenir un readme, c’est l’enfer!

Dans la pratique, il a fallu que je lui prompte block par block: serveurs matrix, puis mise en palce de la fédération, puis mise en place des bridges, etc. I part très vite dans des conceptions trop complexes qui n’amènent à rien. Donc, c’est bien moi l’architecte. Je pense, il écrit, je relis, je teste et je debug ce qu’il a produit.

« Est-ce possible d’utiliser ce rôle pour créer le serveur matrix CHATONS, unique, sans bridges, avec modération ? »

Oui, c’est prévu : matrix_component peut utiliser uniquement postgres + synapse_users, sans jamais activer synapse_bridges/bridges. Le rôle déploierait un seul homeserver. Les outils de modération (Draupnir est dans le roadmap « Planned ») ne sont pas encore implémentés, mais l’architecture générique est faite pour accueillir ce genre de composant sans réécrire le rôle.

**
La question des paquets Yunohost vs le rôle custom :**

Le rôle custom résout :

• Le problème de la fédération à deux homeservers avec bridges dédiés. Ce que Yunohost ne gère pas nativement.
• La séparation des bases de données, ce qui les rend plus résistantes à un bourrage de logs
• La facilité de tester et maintenir les bridges grâce à l’environnement staging-production

Mais il crée effectivement un nouveau repo ARN à maintenir, en plus des paquets Yunohost.

Réponses à GautGaut

« Existe-t-il une notion de fork/héritage dans les rôles Ansible ? »

Techniquement, un rôle Ansible n’a pas de mécanisme de « classe mère/fille » comme en programmation objet. Les options qui s’en rapprochent sont :

• Fork Git classique : cloner matrix-docker-ansible-deploy, faire nos modifs, et régulièrement git merge upstream/main pour récupérer les mises à jour. Ça marche mais génère des conflits de merge à chaque customisation profonde.

• include_role/import_role avec surcharge de variables : on peut consommer un rôle upstream tel quel et ne surcharger que ses variables (defaults), sans toucher son code. C’est la méthode la plus « propre » mais elle suppose que le rôle upstream expose tout ce dont on a besoin via des variables — sinon on est bloqué.

• Collection Ansible avec rôle « wrapper » : on écrit un petit rôle à nous qui appelle le rôle upstream en dependencies (meta/main.yml) et ajoute nos tâches par-dessus.

Dans tous les cas, plus on s’éloigne de la configuration standard du projet upstream, plus le fork devient coûteux à maintenir à jour.

« Quel est l’intérêt de ta solution vs matrix-docker-ansible-deploy configuré à notre sauce sur deux serveurs ? »

matrix-docker-ansible-deploy est nettement plus complet et mieux maintenu, c’est un vrai argument en sa faveur, je ne le conteste pas.

Mon rôle a deux différences de conception :

1. Il sépare volontairement la stack Matrix de la gestion de l’infra (proxy, DNS, TLS, vault), alors que le projet upstream a tendance à tout gérer lui-même (y compris Traefik/nginx). Ce qui le rend hypercomplexe. Avec mon projet on peux testet et deployer facilement des nouvelles mises à jour ou ajouts majeurs sans tout casser.

2. Il traite les bridges comme des entrées de liste totalement génériques, sans code spécifique par bridge — ce qui correspond à notre besoin d’ajouter simplement de nouveaux bridges sans toucher au rôle.

Ceci dit, ces deux points pourraient sans doute être obtenus en configurant matrix-docker-ansible-deploy correctement (désactiver ses rôles proxy/DNS, utiliser ses group_vars). Mais on se retouve à en créer un fork.

En résumé :

matrix-docker-ansible-deploy = plus robuste et mieux testé mais plus complexe à adapter à notre structure ;

solution maison = plus simple et sur-mesure cependant reposant sur moins de mainteneurs.

« Pourquoi connecter Keycloak au serveur des bridges s’il n’y a pas d’utilisateurs finaux dessus ? »

Bonne remarque ! Il n’y a pas de raison de le faire sur le homeserver bridges, seulement sur celui des utilisateurs (synapse_users). Je vais corriger ca merci de l’avoir soulevé.

« Pourquoi ne pas tout mettre sur une seule VM avec des dockers dedans ? »

Deux raisons à la séparation en VMs distinctes :

1. Cloisonnement des droits d’admin, comme tu le notes : certains admins n’ont besoin d’accéder qu’au serveur users, d’autres qu’au serveur bridges (qui manipule des identifiants tiers WhatsApp/Telegram/Signal, plus sensibles). Séparer les VMs rend ce cloisonnement simple au niveau SSH/pare-feu, sans avoir à gérer des permissions fines à l’intérieur d’une seule machine.

2. Isolation en cas d’incident : un bridge qui plante, consomme beaucoup de ressources, mais n’affectera pas le homeserver des utilisateurs finaux si il est sur uen autre VM.

Techniquement, oui, on pourrait tout regrouper : multi-instance Yunohost pour Synapse, ou plusieurs projets docker-compose sur une seule VM Debian (c’est d’ailleurs déjà ce qu’on fait entre Synapse Bridges et les bridges, qui cohabitent sur vm-matrix-bridges mais dans des projets Compose séparés pour éviter que localhost d’un conteneur ne fuite vers un autre).

Mais mutualiser users + bridges sur une seule VM romprait le cloisonnement des droits que tu évoques toi-même comme utile. Le surcoût (une VM de plus) me semble raisonnable au regard du gain en isolation, mais c’est un arbitrage capacité/sécurité qu’on peut discuter si les ressources Proxmox sont contraintes.