Étude de cas
MigrationMigration d’une messagerie professionnelle vers Kubernetes
Contexte
Acteur français de l’hypervirtualisation open source, qui héberge ses propres services sur ses machines, dans des datacenters français, avec des logiciels libres. Sa messagerie instantanée venait de passer de Mattermost à Matrix Element en version OSS, déployée en Docker Compose. L’étape suivante était la version enterprise, mais l’installation en place n’avait pas été pensée pour ça : ni la supervision, ni la montée en charge, ni les montées de version.
Le défi
Basculer sur la version enterprise déployée sur Kubernetes avec une chart Helm, brique par brique, en laissant la messagerie en service : plus de 150 utilisateurs à migrer avec leurs salons et leur historique, sans régression et avec le minimum de temps d’indisponibilité.
Rester chez soi
L’entreprise héberge ses services sur ses propres machines, en France, avec des logiciels open source. La version enterprise devait donc s’installer chez elle, pas chez un tiers.
Migration en service
La messagerie est un outil de travail quotidien : impossible de l’éteindre le temps de la migration. Chaque brique devait basculer avec le minimum d’interruption.
Historique et comptes
Plus de 150 utilisateurs, leurs salons et leurs conversations : la migration ne repart pas d’une page blanche, elle reprend l’existant.
Changement de modèle d’exploitation
Passer de Docker Compose à Kubernetes, ce n’est pas changer d’outil de déploiement mais de façon d’exploiter : orchestration, configuration, secrets, mises à jour.
L’approche
01 · Le cadre
Une version enterprise, hébergée sur place
La cible était la version enterprise de Matrix Element, installée sur l’infrastructure de l’entreprise, dans ses datacenters français. Le choix de l’open source et de l’auto-hébergement n’était pas négociable : la migration devait s’y conformer, pas l’inverse.
02 · Le déploiement
Une chart Helm, composant par composant
Chaque brique a été reprise une par une et posée sur Kubernetes avec une chart Helm : on migre un composant, on vérifie qu’il tient, et on passe au suivant. La chart décrit l’état cible et sert ensuite aux montées de version.
03 · La bascule
Le minimum de downtime
La messagerie est restée en service pendant toute l’opération. Le temps d’indisponibilité a été réduit à la fenêtre strictement nécessaire au basculement de chaque brique, avec la possibilité de revenir en arrière tant que la suivante n’était pas engagée.
04 · Les données
Comptes, salons et historique repris
La migration conserve les comptes, les salons et l’historique des conversations. Les utilisateurs se sont basculés par vagues, sans avoir à reconstruire leurs espaces de travail.
05 · L’équipe
Une migration menée à deux
L’opération a été menée en coopération avec un collègue de l’équipe : répartition des composants, des vérifications et des fenêtres de bascule, pour avancer sans se bloquer l’un l’autre sur le même système.
Les résultats
150 utilisateurs migrés
La messagerie est passée en version enterprise sans interruption de service pour les plus de 150 utilisateurs.
Meilleures performances
Les performances se sont améliorées pour tout le monde, sur une base qui tient la charge.
Plus fiable
Le service a gagné en fiabilité : la plateforme se remet en état au lieu de tomber.
Historique conservé
Salons et historique des conversations repris, aucune perte de données.
Déploiement reproductible
Une chart Helm décrit désormais la messagerie : la prochaine montée de version se joue dans le même cadre.
La stack
Messagerie
- Matrix
- Element
Plateforme
- Kubernetes
- Helm
Données
- PostgreSQL
Sortie
- Docker Compose