🛠 Refonte de la stack Matrix sans-nuage

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.