August 20, 2025
Premiers retours d'experience de migration #Bitnami
Pour mes clients, j'explore plusieurs alternatives aux images #Docker et #Chart #Helm de Bitnami en raison du passage au mode d'abonnement payant (cf mes anciens posts & #Broadcom).
Option 1 : payer l'abonnement (50k+ €/an) si ces images/charts génèrent suffisamment de valeur pour vous. Bien sûr ce sera douloureux et l'avenir reste incertain, mais tout autre chemin le sera probablement plus....
Option 2 : Modifier vos pipelines CI-CD pour pointer sur le repo d'image archivées (sur https://lnkd.in/eye96tEq) qui ne recevront plus de mises à jour (fortement déconseillé), ou bien utiliser les "latest" , seules encore gratuites mais destinées au développement, directement en production (fortement déconseillé)
Option 3 : trouver ou construire des images alternatives mais iso-fonctionnelles.
Et là c'est le drame...
Comparons par exemple l'image #wordpress officielle et l'image bitnami/wordpress :
- points de montage des volumes différents
- UID/GID différents
- pas de healthcheck #kubernetes implémentés dans la version officielle
- pas d'#observabilité native (apache-metrics-exporter est intégrésà bitnami)
- pas de wp-cli
- pas de provisionning pour la wordpress officielle contrairement à bitnami qui est très riche via un init script/container (mot de passe , URL, multisite , langue, plugin WP, SMTP...)
Bref, il va falloir renoncer à des fonctionnalités, les coder ou bien trouver des images qui les implémente et les **maintienne** dans le temps.
Certains charts Bitnami sont très utilisés (je pense à sealed-secrets, external-dns, redis, pgsql, mongodb, rabbitmq, ghost...).
Et vous, comment abordez-vous cet évènement ?
2 Likes
August 20, 2025
Discussion about this post
Guillaume Tristani
9 days ago
Chief Technology Officer chez OpsVox
En même temps, dès le début, c’était un très mauvais plan d’utiliser Bitnami autrement que pour un usage expérimental et très loin d’une production, pour plusieurs raisons.
La carte jouée par VMware pour compenser un certain retard dans le domaine des conteneurs n’a vraiment pas aidé.
En somme, gérer son image n’est pas la tâche la plus complexe lorsqu’on en fait un métier.
En ce qui concerne les charts, l’offre officielle est généralement à portée de main.
Une fois que les utilisateurs se sont habitués à cette facilité, ils ferment le piège et facturent un service dont ils tirent eux‑mêmes les composants de l’open‑source, sans véritable valeur ajoutée comparée à leurs marges. Ce n’est pas ce qui dérange, c’est courant; cependant, d’un point de vue sécurité, après analyse des images en question, on est très loin du compte.
Il existe des alternatives plus sérieuses qui surfent sur cette tendance : https://www.docker.com/products/hardened-images/
💻 Adrien Roches
9 days ago
Lead Tech
Comme ça.... Non mais en vrai pour le moment vu les délais et les congés l'option "legacy" reste le mieux pour ne pas tout casser sur le court terme. Mais clairement ca va être de migrer sur les images officielles et de push plus de contrib / issues la dessus pour arriver au même niveau je pense.
Pascal Valois
9 days ago
j'administre du linux, j'automatise avec ansible, bash et python, je pousse dans kubernetes, et je bois du thé comme du café ! Je propose des formations sur ces sujets sur Superprof.fr
je dirais que bitmami est une commodité (excellente commodité), mais en terme de sécurité, ce n'est pas forcement un choix. je preconiserait de refaire si possible ses propres images docker, a partir d'une alpine ou python basique avec des ajouts controlés pour faire son image custom
dans sa registry custom mais bien sur il faudrait la maintenir ... il n'y a pas vraiment de solution magique
