Le redéploiement de conteneur est l’opération qui bascule un conteneur en exécution vers une étiquette d’image différente. Le conteneur est reconstruit à partir de la nouvelle image pendant que la plateforme préserve automatiquement la configuration personnalisée, le contenu des volumes et les fichiers spécifiques au stack.
Le redéploiement est la façon d’appliquer des mises à jour au niveau image à un conteneur : une nouvelle version mineure du serveur applicatif, une image OS de base patchée, une image personnalisée avec des paquets additionnels intégrés. C’est distinct du déploiement applicatif, qui ne met à jour que le code s’exécutant au-dessus du conteneur.
Quand redéployer
- Récupérer un correctif de sécurité dans l’image de base.
- Passer d’une version de stack à une plus récente (par exemple Tomcat 9 vers Tomcat 10).
- Basculer vers une image de conteneur personnalisée que vous avez construite et poussée vers votre registre.
Pour des changements code seulement, utilisez le déploiement applicatif (archive, VCS ou Git-Push-Deploy). Le redéploiement est inutile et plus lent.
Comment fonctionne le redéploiement
Trois étapes s’exécutent sous le capot :
- La plateforme note les données qui doivent survivre — volumes, fichiers personnalisés listés dans
/etc/jelastic/redeploy.confet certains fichiers système infogérés par la plateforme (clés SSH, règles pare-feu, configuration AutoFS / NFS). - Le conteneur est reconstruit à partir de la nouvelle étiquette d’image. Le système de fichiers original du conteneur est remplacé.
- Les données préservées sont restaurées dans le nouveau système de fichiers du conteneur.
Le conteneur se retrouve à exécuter la nouvelle image avec la configuration applicative intacte.
Déclencher un redéploiement
Trois surfaces de pilotage :
- Tableau de bord — survolez un conteneur dans la vue d’environnement et cliquez sur Redeploy. Choisissez la nouvelle étiquette d’image dans la boîte de dialogue.
- CLI —
~/jelastic/environment/control/redeploycontainerbyidou~/jelastic/environment/control/redeploycontainersbygroupcouvrent les redéploiements à un conteneur et au niveau du palier. - API — les mêmes opérations sont accessibles via des appels REST API.
Les manifestes Cloud Scripting peuvent aussi déclencher le redéploiement dans le cadre d’un flux plus large.
Ce qui est préservé
La plateforme préserve trois catégories de données automatiquement :
- Volumes — volumes par défaut et personnalisés attachés au conteneur. Leur contenu survit intact.
- Configuration de conteneur personnalisée — commandes de lancement, liens entre conteneurs, variables d’environnement, mappages de ports.
- Fichiers système — accès SSH (
/root/.ssh/authorized_keyset associés), règles pare-feu, configuration AutoFS / NFS et la liste spécifique au stack maintenue dans/etc/jelastic/redeploy.conf.
Pour la liste complète des fichiers système préservés par stack — et le mécanisme pour ajouter vos propres fichiers personnalisés à la liste de préservation — voir données préservées au redéploiement.
Ce qui est réinitialisé
Tout ce qui est hors de la liste préservée est réinitialisé à l’état intégré dans la nouvelle image :
- Fichiers de configuration du serveur applicatif livrés avec le stack.
- Code applicatif dans les chemins par défaut du stack (sauf si le chemin est adossé à un volume).
- Paquets personnalisés installés dans le conteneur via apt/yum/etc. (sauf s’ils sont capturés par un hook de déploiement ou intégrés à une image personnalisée).
- Fichiers journaux écrits dans des chemins hors volume.
Si vous maintenez de la configuration personnalisée hors de la liste préservée, ajoutez les chemins de fichiers à la section custom files and folders de /etc/jelastic/redeploy.conf avant de redéployer.
Redéploiement séquentiel pour les paliers mis à l’échelle
Pour les paliers de serveur applicatif mis à l’échelle sur plusieurs instances, le redéploiement est appliqué une instance à la fois avec un délai par défaut de 30 secondes. Les instances restantes continuent de servir le trafic pendant le déroulement. C’est automatique et ne requiert aucune configuration au-delà d’avoir un palier mis à l’échelle.
Pour un délai plus petit ou aucun délai, ajustez via les drapeaux CLI sur l’appel de redéploiement.
Gestion des échecs
Si la nouvelle image échoue à démarrer, le conteneur reste en état d’erreur. La plateforme ne fait pas de retour arrière automatique. Options :
- Inspectez les journaux du conteneur pour identifier l’échec (typiquement un fichier de config absent ou un paramètre runtime incompatible).
- Redéployez à nouveau vers une étiquette connue saine.
- Pour les paliers mis à l’échelle, l’instance en échec est sortie de la rotation ; les instances saines continuent de servir le trafic jusqu’à ce que vous complétiez le retour arrière.