Revenir à l’image précédente ne restaure pas les écritures faites après le déploiement. Elles vivent dans le conteneur ou le volume, jamais dans l’image.
Un déploiement casse la production. On rollback vers l’image précédente, le service repart, et les données saisies entre les deux déploiements ont disparu. Le rollback a fait son travail. Le problème était ailleurs.
Une image est figée, les écritures ne le sont pas
Une image conteneur est immuable. Elle contient le code et la config au moment du build, rien d’autre. Tout ce qui est écrit après le démarrage, fichiers uploadés, base locale, cache, vit dans la couche d’écriture du conteneur, pas dans l’image.
Rollback vers l’image N-1 instancie un conteneur neuf depuis un état figé. Les écritures du conteneur N ne sont nulle part dans cette image. Elles ne reviennent pas.
Récupérer, puis corriger la cause
Si l’ancien conteneur n’a pas été supprimé, ses données sont encore dans sa couche d’écriture, sur le conteneur orphelin. On peut l’inspecter et copier les fichiers. Si un volume était monté, les données y sont restées et survivent au rollback.
La cause de fond est le stockage filesystem-only : écrire des données durables dans le conteneur. La donnée durable va dans un volume monté ou un service externe, base ou object-storage. L’image et le conteneur redeviennent jetables.
Le principe : un rollback restaure du code, jamais des données. Si une donnée doit survivre à un déploiement, elle ne doit pas vivre dans le conteneur.