De MinIO à SeaweedFS : migrer neuf outils S3

MinIO est de retour, mais il ne restera pas notre stockage objet. Après avoir reconstruit son image Docker pour remettre la plateforme en marche, j’ai migré ses neuf consommateurs vers SeaweedFS. La bascule est terminée et les neuf outils ont passé leurs contrôles. Garage, l’autre candidat, a été testé lui aussi : il a réussi huit parcours sur neuf.

Cette migration n’a pas consisté à changer une URL S3. Elle a demandé d’inventorier les usages, de vérifier les clients réels, de décider quelles données copier et de contrôler les accès après adoption par les opérateurs Kubernetes. Le premier volet de cette histoire, la remise en service temporaire de MinIO, est raconté dans l’article sur la reconstruction de son image Docker.

Neuf outils, dix-huit buckets

L’inventaire GitOps comptait dix-huit buckets déclarés : trois pour Mimir, un pour Tempo, deux pour Loki, un pour Pyroscope, sept pour GitLab, puis un chacun pour Harbor, Langfuse, Burrito et Terrakube. Certains buckets, comme ceux du ruler Loki ou de l’Alertmanager Mimir, sont peu remplis quand le composant correspondant est désactivé. Ils restent néanmoins des usages configurés, à tester.

La criticité varie fortement. Une courte interruption de télémétrie n’a pas le même effet que la perte d’un état Terraform, d’artefacts GitLab ou des couches d’images nécessaires à un redéploiement. Il fallait donc raisonner application par application, et ne pas conclure à partir d’un simple test PUT/GET.

La migration a aussi été l’occasion de remplacer les identifiants partagés par une identité distincte et des droits limités pour chaque application. L’opérateur SeaweedFS a pris en charge la création déclarative des buckets et des identités à la place des jobs ponctuels mc. La plupart des services consomment le Secret généré par l’opérateur ; GitLab et Terrakube demandent une configuration plus explicite de leurs clés dans Git.

« Compatible S3 » ne suffit pas

J’ai déployé chaque candidat à côté de MinIO et exécuté les contrôles depuis les applications elles-mêmes : démarrage, lecture et écriture, tâches de fond, puis tests fonctionnels propres à chaque produit. Les manifests et valeurs Helm pouvaient sembler corrects sans prouver que les clients Java, Go ou Ruby signaient leurs requêtes de la même façon.

Les deux serveurs ont passé les essais initiaux, mais Garage a révélé une incompatibilité reproductible avec Terrakube. Son client Java utilise la région SigV4 auto, valeur imposée par la configuration retenue. Garage attendait us-east-1 et Terrakube ne permettait pas de remplacer cette région dans ce chemin de configuration. Huit consommateurs fonctionnaient ; le neuvième ne pouvait pas écrire ses objets. Pour un stockage des états Terraform, ce n’était pas un défaut acceptable à contourner en production.

SeaweedFS a passé les neuf parcours. Ce résultat réel a pesé davantage que la liste théorique des fonctions S3 : le stockage devait fonctionner avec les versions exactes des neuf logiciels, pas seulement exposer une API présentée comme compatible.

Copier ce qui doit l’être, vérifier ce qui compte

Tous les objets n’ont pas été transférés. Mimir et Tempo ont été redémarrés sans copie : leurs données concernées étaient considérées comme périssables pour cette opération. En revanche, Loki et Pyroscope ont nécessité une copie, car leurs index ou métadonnées locaux font référence à des objets conservés dans S3. Déplacer les seuls fichiers objet sans préserver cette cohérence aurait laissé des références cassées.

Les données persistantes des autres produits ont été transférées puis vérifiées avec leurs workflows. Quelques repères mesurent l’opération : Burrito a déplacé 46 237 objets en 70 secondes ; Harbor, 5,28 Gio en 57 secondes ; Langfuse, 76 Mio en 6 secondes ; GitLab, 982 artefacts en 15 secondes. Les sommes SHA-256 attendues par GitLab ont été contrôlées. Pour Terrakube, 27 états ont été comparés avec rclone check, sans différence.

La durée de copie n’était pas le seul critère. Garage a demandé 13 minutes 39 secondes pour un volume Burrito comparable et 190 secondes pour Harbor. SeaweedFS a terminé ces transferts en 70 et 57 secondes. Garage était plus léger en mémoire au repos, mais son avantage ne compensait ni l’échec Terrakube ni ces durées dans notre campagne. Ces chiffres décrivent notre environnement et nos essais ; ils ne constituent pas un benchmark universel.

SeaweedFS choisi, avec ses propres surprises

Le choix final est donc SeaweedFS. Ce n’est pas une conclusion générale selon laquelle il serait toujours préférable à Garage : dans notre cas, la compatibilité complète des neuf outils, notamment Terrakube, était déterminante. Garage demeure une option crédible pour un parc dont les clients S3 sont compatibles et dont les volumes rendent son empreinte plus intéressante.

SeaweedFS a toutefois exposé un piège opérationnel pendant la mise en charge. La plateforme a atteint sa limite de 36 volumes alloués alors que le disque était encore peu utilisé. Augmenter le nombre maximal de volumes à 100 a débloqué la création de capacité. L’espace disque ne suffit donc pas pour juger de la marge disponible : il faut aussi surveiller les limites logiques du serveur et ajuster les alertes.

Autre détail important : une adoption par l’opérateur peut régénérer des Secrets. Une application qui garde une ancienne clé explicite peut alors sembler saine, mais échouer lors d’une réconciliation ultérieure. Ces deux consommateurs doivent être traités avec leur configuration déclarative et leurs secrets, pas seulement en vérifiant leur état juste après le changement.

Une migration terminée, pas un retrait précipité

Après les bascules individuelles, la campagne finale a validé les neuf outils simultanément sur SeaweedFS : 9 sur 9. Les usages ne se limitaient donc pas à des probes de disponibilité : les parcours fonctionnels et les contrôles de données prévus ont été exécutés. MinIO reste néanmoins disponible comme point de retour tant que la procédure de retour arrière et la réconciliation des écritures ne sont pas formalisées.

Il reste également du nettoyage opérationnel : revoir certaines permissions, faire tourner et retirer une clé GitLab encore présente dans la configuration, régler les alertes SeaweedFS et préparer la désinstallation définitive de MinIO et de ses images de dépannage. La migration des consommateurs est achevée ; cela ne signifie pas qu’il faut supprimer immédiatement l’ancien stockage et son volume.

Le principal enseignement est simple : une migration S3 se valide avec les applications et les données qu’on exploite, pas avec une étiquette de compatibilité. L’inventaire a évité d’oublier des buckets peu utilisés ; les tests réels ont éliminé un candidat pourtant prometteur ; les comparaisons et contrôles de cohérence ont rendu la bascule vérifiable. C’est ce travail qui transforme le remplacement d’un endpoint en migration maîtrisée.

Cette panne a aussi rappelé où passent les dépendances d’une plateforme. Les premiers tombés n’étaient pas des applications métier mais Tempo, Mimir et Loki, c’est-à-dire la télémétrie elle-même : quand le stockage objet s’arrête, on perd en même temps le service et les moyens de l’observer. C’est le sujet de notre formation Observabilité avec OpenTelemetry et Grafana.

Le reste du chantier tient dans deux autres compétences. La bascule a été exécutée en modifiant des manifestes versionnés plutôt qu’en se connectant au cluster, ce qui rend chaque étape relisible et réversible : c’est la méthode enseignée dans le Workshop CI/CD et GitOps avec Kubernetes. Et tout cela suppose de savoir ce qu’est un volume persistant, un Job immuable ou un DaemonSet, que couvre la formation Kubernetes.