Deployments blue/green

Un Deployment détient une identité applicative stable et deux slots d’exécution. Opfield prépare une nouvelle version dans le slot inactif, évalue sa santé et ne bascule le trafic que lorsque la version est prête. Le slot précédemment actif reste disponible comme candidat au retour arrière jusqu’à sa mise hors service par le cycle de vie du Deployment.

Gérez les slots via le Deployment plutôt que comme des Containers individuels. Le Deployment détient la bascule du trafic, l’historique des versions, l’éligibilité au retour arrière et la relation entre les deux enfants d’exécution. Modifier directement un enfant actif crée une dérive d’état et affaiblit les garanties qui rendent le retour arrière sûr.

Ce que change le choix d’un Deployment

Choisissez un Deployment lorsque le risque d’une publication tient surtout au démarrage et à la santé de l’application, et lorsque deux slots de publication peuvent coexister sans danger sur le même nœud Docker pendant la bascule. Le résultat est une identité de service stable avec une promotion contrôlée et un candidat explicite au retour arrière. C’est particulièrement utile pour les services publics ou partagés pour lesquels remplacer directement un Container créerait une interruption évitable.

L’équipe applicative est responsable de la préparation de la version, de la sémantique de santé, de la compatibilité des migrations de données et de la décision de promouvoir ou de revenir en arrière. L’équipe plateforme est responsable de la capacité des nœuds, de la confiance dans les images, des Routes, de la fourniture des secrets et de la disponibilité du chemin de retour arrière. Opfield coordonne les slots et enregistre l’opération ; il ne peut pas rendre réversible une modification de schéma incompatible.

N’utilisez pas le blue/green à la place d’une stratégie de données. Les deux slots peuvent accéder temporairement à la même dépendance externe ou aux mêmes données persistantes. Les migrations de bases de données doivent être rétrocompatibles pendant la fenêtre de retour arrière, ou le plan de publication doit accepter explicitement que le retour arrière de l’exécution ne suffit pas à lui seul.

Prérequis

Utilisez une empreinte d’image immuable ou un artefact de build approuvé. Avant de lancer une publication, vérifiez que le nœud cible est en ligne, que l’image peut être récupérée, que les secrets et volumes sont corrects, que les limites de ressources tiennent sur le nœud et que la route de santé vérifie le chemin applicatif qui compte pour les utilisateurs. Examinez les Routes et liaisons de bases de données dépendantes dans le cadre du même changement.

Publier une nouvelle version

1. Ouvrez le Deployment et préparez la nouvelle image et la nouvelle configuration.
2. Examinez les entrées de la publication, y compris l’environnement, les secrets, les volumes, le choix de l’environnement d’exécution et la vérification de santé.
3. Lancez la publication et suivez la tâche pendant qu’Opfield prépare le slot inactif.
4. Attendez que la vérification de santé réussisse.
5. Laissez la bascule du trafic se terminer, puis vérifiez une vraie requête, les journaux de l’application et les métriques.
6. Gardez le slot précédent intact jusqu’à la fin de la fenêtre de retour arrière convenue.

Enregistrer un nouveau tag d’image, une commande, des montages, des labels ou un environnement d’exécution dans les paramètres du Deployment le déploie de cette façon ; le bouton s’intitule Save & Deploy. Enregistrer les variables d’environnement d’un Deployment en cours d’exécution les déploie sur le slot de secours. Les limites de ressources sont enregistrées avec la configuration. Déployer ou mettre à jour un Deployment avec une nouvelle image ou une nouvelle commande nécessite docker:containers:environment et docker:containers:secrets sur celui-ci, car le nouveau slot reçoit l’environnement et les secrets du Deployment ; un nouvel environnement seul ne nécessite que docker:containers:environment. Les commandes de déploiement attendent la récupération de l’image, la période de grâce au démarrage et le délai de déploiement avant de renvoyer un résultat.

Via l’API, POST /api/docker/nodes/{nodeId}/deployments/{deploymentId}/deploy avec env remplace tout l’environnement du Deployment et l’enregistre comme sa configuration ; envoyez donc chaque variable que le Deployment doit conserver. L’outil MCP deploy_docker_deployment et l’assistant, eux, appliquent env par-dessus l’environnement enregistré et suppriment les clés listées dans removeEnv ; toutes les autres variables enregistrées sont conservées. Les deux nécessitent docker:containers:environment.

Les publications déclenchées par webhook utilisent le même chemin d’autorisation et de conditionnement par la santé. Une requête de webhook ne contourne pas la propriété du Deployment et ne transforme pas un build en échec en version publique.

Échec et retour arrière

Si la préparation ou la validation de santé échoue avant la bascule du trafic, le slot actif existant reste la version servie. Examinez l’opération à la recherche d’erreurs de récupération d’image, de démarrage, de santé, de secrets, de volumes ou de capacité ; corrigez la cause et lancez une nouvelle publication plutôt que de modifier sur place le slot en échec. Un slot candidat qui échoue à sa vérification de santé est arrêté et conservé pour ses journaux, afin qu’il ne puisse pas redémarrer en boucle et prendre des connexions de base de données au slot actif ; une bascule ultérieure vers ce slot le recrée à partir de sa version enregistrée.

Si une régression visible par les clients apparaît après la bascule, utilisez l’action explicite de retour arrière. Elle rétablit le trafic vers le slot conservé réputé sain et enregistre l’événement dans l’historique du Deployment. Vérifiez la Route, la santé de l’application et les journaux après le retour arrière. Une bascule de slot conserve la version du slot de secours, et le retour arrière revient à la version précédente. Ne supprimez pas le slot le plus récent tant que l’enregistrement de l’incident et la suite à donner ne sont pas clairs.

Opérations pendant les redémarrages, les mises à jour et les builds

Les opérations de Deployment survivent aux redémarrages d’Opfield. Un balayage durable termine le vidage du slot précédent, et une publication interrompue est reconstituée à partir du slot que sert réellement le routeur du nœud. Si le nœud ne peut pas être examiné dans les 5 minutes, la publication est marquée en échec avec une raison telle qu’un routeur arrêté ou un démon incapable de signaler son slot actif ; dans ce dernier cas, mettez à jour le démon Docker.

Pendant une publication, les paramètres du Deployment sont verrouillés : l’enregistrement renvoie DEPLOYMENT_BUSY et la Console désactive Save jusqu’à la fin de la publication. Pendant le déploiement d’un build Git sur le Deployment, les changements de cycle de vie et de configuration renvoient BUILD_ROLLOUT_IN_PROGRESS ; attendez la fin du déploiement. Un Deployment revient sur son slot actif après Stop puis Start, ou après un redémarrage du nœud, et un redémarrage d’Opfield au milieu d’un déploiement ne fait pas perdre la publication. Pendant une mise à jour d’Opfield, les nouvelles opérations de Deployment sont refusées avec OPFIELD_UPDATING jusqu’à la fin de la mise à jour ; voir Prérequis de mise à jour en 2.11.

Routeur du Deployment

Chaque Deployment dispose d’un petit conteneur routeur nginx sur son nœud. Le routeur reçoit le trafic du Deployment et le transmet au slot actif ; une bascule ou un retour arrière ne modifie que la cible du routeur.

• Il revient après un redémarrage. Les routeurs s’exécutent avec la politique de redémarrage unless-stopped. Au démarrage du démon Docker, celui-ci répare le routeur de chaque Deployment actif : un routeur créé par une version plus ancienne, ou resté avec la politique de redémarrage no, reçoit la politique actuelle ou est recréé à partir de la configuration qu’il sert, avec ses routes et ses ports publiés, et est dirigé vers le slot applicatif qui s’exécute réellement. Le démon répète la réparation chaque minute jusqu’à ce qu’elle réussisse ; tant qu’une opération de Deployment détient le Deployment, la réparation l’attend et s’exécute une fois celle-ci terminée. Un Deployment délibérément arrêté ou tué garde son routeur arrêté.
• Les opérations démarrent un routeur arrêté. Un déploiement, une bascule de slot, une mise à jour du routeur ou un démarrage relance un routeur arrêté par un kill ou un stop au lieu d’échouer, et un Deployment dont le slot actif ne peut pas démarrer ne reste plus bloqué.
• Il ne dépend pas du DNS de Docker. La configuration du routeur indique l’adresse du conteneur du slot actif et lui transmet directement le trafic sur toutes les versions de nginx, sans résolveur ; le démon vérifie l’adresse toutes les 5 secondes et réécrit la configuration lorsqu’elle change. Seule une configuration écrite avant que l’adresse du slot ne soit connue résout le nom du slot via le DNS de Docker. Les routeurs existants sont mis à jour sur place, sans être recréés.
• Il n’écrit aucun journal d’accès. Le nœud Ingress journalise déjà chaque requête. Un routeur ne se bloque donc jamais sur la sortie de son conteneur, que dockerd vide ; un Docker Engine (dockerd) bloqué n’arrête donc pas le trafic vers un Deployment en cours d’exécution.
• Applications qui journalisent chaque requête. La sortie des conteneurs passe par la chaîne de journaux de Docker, qui cesse de se vider tant que dockerd est figé. Une application qui écrit une ligne sur stdout ou stderr pour chaque requête peut donc se bloquer une fois ce tube plein, même si le routeur et les Secure Links continuent de fonctionner. Gardez la journalisation par requête hors de la sortie du conteneur, ou acceptez qu’une telle application puisse se bloquer pendant un gel de dockerd.
• Les corps de requête ne sont pas limités. Le routeur transmet des corps de requête de toute taille (c’est la Route qui fixe la limite) et les envoie en flux au slot au lieu de les mettre en mémoire tampon sur disque. Les routeurs créés avant ce changement l’adoptent lors de leur prochain déploiement, de leur prochaine bascule de slot ou de leur prochain redémarrage.
• Ses propres erreurs sont signalées. Lorsque le routeur ne parvient pas à joindre le slot actif, il répond 502 ou 504 avec l’en-tête X-Opfield-Deployment-Router: upstream-unavailable (X-Gateway-Deployment-Router pour un routeur déployé avant 2.12.1, jusqu’au prochain déploiement du Deployment), ce qui permet de distinguer une erreur du routeur d’une erreur de l’application. Workload Availability s’en sert pour décider si un placement de Deployment est prêt.

Conséquences de la mise hors service

Supprimer un Deployment supprime ses slots gérés et peut supprimer des relations d’accès qui n’appartiennent qu’à cette ressource. Un Deployment peut être supprimé alors que son slot de secours exécute encore une image plus ancienne. Détachez ou migrez d’abord les Routes, les liaisons de bases de données et les données persistantes qui doivent survivre. Un retour arrière de Deployment protège un slot d’exécution antérieur ; il ne remplace pas la sauvegarde des données modifiables des volumes.

Critères de réussite et politique de déploiement

Définissez une vérification de santé qui représente une dépendance pertinente pour l’utilisateur, et pas seulement le fait que le processus accepte une connexion TCP. Avant la promotion, vérifiez les journaux de démarrage, la stabilité de la santé pendant la période d’observation convenue, l’utilisation des ressources et les éventuelles dépendances privées. Après la promotion, vérifiez une vraie requête via la Route et surveillez le taux d’erreur et la latence avant de mettre hors service le slot précédent.

Définissez une fenêtre de retour arrière explicite. Pendant cette fenêtre, gardez disponibles l’artefact et la configuration précédents et évitez les changements qui rendraient impossible leur service. Si un problème ultérieur est sans rapport avec la nouvelle version, consignez-en les éléments avant de revenir en arrière ; des bascules de slot inutiles peuvent compliquer le diagnostic.

Détails pour l’opérateur : capacité et publications en échec

Le slot inactif a besoin de suffisamment de CPU, de mémoire, de stockage, de ports et d’accès à la récupération d’images pour démarrer à côté du slot actif. Pendant le chevauchement, les deux slots partagent aussi chaque lien du Deployment vers une base de données, qui transporte autant de connexions que la base en accepte ; dimensionnez les pools de connexions de sorte que le nouveau slot puisse ouvrir ses pools pendant que le slot actif conserve les siens. Voir Capacité des liens et pools de connexions. La planification de la capacité doit inclure ce chevauchement temporaire. Une publication qui ne peut pas allouer son slot inactif doit échouer avant toute modification du trafic, en laissant le service actif intact.

Lorsque la santé ne devient jamais prête, examinez les journaux du slot inactif et la réponse exacte de la vérification de santé. Corrigez l’image ou la configuration de la publication et lancez une nouvelle tentative ; ne modifiez pas le Container enfant géré. Si la promotion s’est terminée mais que la vérification échoue, utilisez l’action de retour arrière enregistrée, puis vérifiez à la fois le chemin du service et l’identité finale du slot actif.