Mes WordPress ont quitté Bitnami. Leur base de données, pas encore

Le 21 octobre, la faille PHP2Shell m’a obligé à couper mes deux WordPress hébergés sur mon cluster Kubernetes. Ils tournaient sur des images Bitnami qui ne recevraient jamais le correctif de PHP. Le lendemain soir, ils étaient de nouveau en ligne, sur l’image officielle wordpress. J’ai raconté cette soirée dans l’article précédent.

Il restait pourtant une ligne dans mon inventaire : la base de données. Les deux sites s’appuient toujours sur bitnami/mariadb:latest. Cet article est écrit avant la migration. Il explique pourquoi cette base doit partir elle aussi, et comment je compte m’y prendre. Le retour d’expérience viendra une fois le travail fait.

Pourquoi ce n’était pas l’urgence du 21 octobre

PHP2Shell touche PHP, pas MariaDB. Et la base n’est pas exposée : aucun ingress ne mène à elle, elle ne répond qu’aux pods de son propre namespace. Le soir de la faille, la priorité allait donc au code exposé sur Internet. Couper la base n’aurait rien protégé de plus.

Ne pas être exposée ne veut pas dire ne pas avoir besoin d’être maintenue. C’est la même leçon que pour WordPress, un cran plus bas dans la pile.

Pourquoi elle doit quand même partir

Depuis la fin de l’été 2025, Bitnami a réduit son catalogue gratuit. Les images versionnées sont parties dans un dépôt « legacy » qui ne reçoit plus de mises à jour, et ce qui reste en accès libre est un petit ensemble d’images, en tag latest seulement, que Bitnami destine au développement. Le reste passe par un abonnement payant.

Pour ma base, cela pose trois problèmes concrets.

• Aucune garantie de correctif. Le jour où une faille touchera MariaDB, rien ne dit que cette image sera reconstruite. Je me retrouverais dans la situation du 21 octobre, sans solution le soir même.
• Un tag latest dont je ne maîtrise pas le contenu. Au prochain redémarrage du pod sur un autre nœud, l’image sera de nouveau téléchargée. Je ne sais pas ce qu’elle contiendra, ni même si elle sera encore publiée. Une base qui ne redémarre pas, ce sont deux sites coupés.
• Une release Helm que je ne peux plus toucher. La base appartient encore à l’ancienne release Bitnami des WordPress. Un helm upgrade réactiverait des éléments que j’ai volontairement arrêtés, et un helm uninstall emporterait la base et son volume. Je garde donc une dépendance figée au cœur de l’installation.

Le plan : la même méthode que pour WordPress

La migration de WordPress reposait sur un principe simple : monter la nouvelle installation à côté de l’ancienne, la vérifier sans l’exposer, basculer, et garder l’ancienne à l’arrêt comme retour arrière. Je reprends exactement la même logique pour la base.

1. Sauvegarder. Un mariadb-dump --single-transaction de chaque base, en vérifiant que le fichier se termine bien par la ligne « Dump completed ».
2. Monter la nouvelle base à côté. Un StatefulSet sur l’image officielle mariadb, avec un volume neuf et une version fixée, au moins égale à celle en place. Plus de latest.
3. Restaurer et vérifier. Recharger le dump, contrôler les tables et l’utilisateur de WordPress, sans qu’aucun site ne pointe encore dessus.
4. Basculer. Pointer WordPress vers la nouvelle base, puis contrôler le site, un article, une image et l’administration.
5. Garder l’ancienne base à zéro réplica une semaine, avec son volume intact. C’est le retour arrière : repointer WordPress suffit.

Comme pour WordPress, je commence par mon propre blog, en banc d’essai, puis j’applique la même procédure au second site en notant les écarts.

Pourquoi un dump, et pas une copie des fichiers

Réutiliser le volume existant serait plus rapide sur le papier. Mais les deux images ne rangent pas leurs données au même endroit et ne tournent pas sous le même utilisateur système. Monter les fichiers de l’une dans l’autre, c’est parier sur des détails internes que je ne maîtrise pas.

Un dump est indépendant de la façon dont l’image organise ses fichiers. Il se relit, il se teste, et il reste disponible si quelque chose se passe mal. Pour des bases de blog, il prend quelques secondes : le gain de temps d’une copie brute ne justifie pas le risque.

Les points de vigilance identifiés

• Les mots de passe. Ils vivent dans des Secrets Kubernetes créés par le chart Bitnami, et les deux sites ne les lisent pas de la même façon. La migration de WordPress l’a déjà montré. Je réutilise ces Secrets tels quels : seule l’image change.
• Les écritures pendant la bascule. Un commentaire publié entre le dump et la bascule serait perdu. Sur des sites peu écrits, une coupure courte et annoncée reste la solution la plus simple.
• Le nettoyage. Une fois tout validé, supprimer l’ancienne base et son volume à la main, sans helm uninstall, puis effacer les dumps du poste : ils contiennent les comptes des sites.

Ce que j’en retiens, avant même de commencer

Une faille de sécurité oblige à faire l’inventaire de ce qui tourne réellement. Le mien m’a montré que « remis en ligne » ne voulait pas dire « sorti de la dépendance ». La partie visible était corrigée, la partie invisible attendait son tour.

Si vous utilisez encore des images ou des charts Bitnami, la question à vous poser n’est pas « est-ce que ça marche ? », mais « qui me livrera le prochain correctif ? ». Je reviendrai ici raconter comment s’est passée la migration, écarts compris.