Ce qui rend un déploiement vraiment sans interruption
« Déploiement sans interruption » est une expression assez galvaudée pour qu’il vaille la peine d’être précis sur ce qu’elle exige mécaniquement, pas seulement sur ce qu’elle promet. Ce n’est pas une seule fonctionnalité — ce sont cinq étapes qui doivent toutes tenir, dans l’ordre, à chaque fois.
Les cinq étapes
- Build, ou pull. Avec un dépôt, la nouvelle image se construit sur un serveur de build dédié si l’équipe en a un, sinon sur le serveur de l’application elle-même ou un serveur temporaire que Railyard démarre pour la tâche. Une source
image://saute complètement la construction et se contente de tirer l’image. - Commande de release. Si l’application en a une, elle s’exécute une fois contre la nouvelle image, avant que quoi que ce soit ne prenne le trafic — c’est là que les migrations ont leur place. Si elle échoue, le déploiement s’arrête net ici et l’application continue de tourner dans son ancienne version. Rien de ce qui est en direct n’a encore changé.
- Contrôle de santé. Le nouveau conteneur démarre à côté de celui déjà en marche, pas à sa place. Si l’application a un chemin de contrôle de santé configuré, le nouveau conteneur doit vraiment y répondre dans le délai configuré avant que quoi que ce soit d’autre ne se passe.
- Basculement du trafic. C’est seulement une fois que le nouveau conteneur a passé son contrôle de santé que le trafic bascule vers lui — tout d’un coup pour un déploiement standard, ou une part à la fois pour un déploiement canary, surveillé contre le taux d’erreur du reste de l’application avant de monter davantage.
- L’ancienne version s’arrête. Le conteneur précédent continue de tourner jusqu’à ce que le nouveau soit confirmé, et c’est seulement à ce moment-là qu’il est retiré.
Cet ordonnancement est tout le mécanisme. Il n’y a jamais de point entre les étapes où l’application a zéro conteneur fonctionnel — l’ancien ne disparaît pas avant que le nouveau ait déjà fait ses preuves.
Ce qui se passe quand quelque chose échoue
C’est la partie qui compte en fait plus que le chemin heureux : si le build, la commande de release ou le contrôle de santé échoue, Railyard laisse la version précédente tourner exactement comme elle était et marque le déploiement comme échoué. Un mauvais déploiement ne met pas l’application hors ligne — il ne sort tout simplement pas. La page de déploiement nomme la cause exacte et renvoie vers la correction — voir pourquoi un déploiement échoue vraiment, raison par raison pour ce que chacune veut dire.
Revenir en arrière, c’est le même mécanisme, pas un autre
Un retour en arrière n’est pas une échappatoire traitée à part — c’est un déploiement du commit ou de l’image d’une version antérieure, ce qui veut dire qu’il passe par exactement le même build-ou-pull, la même commande de release, le même contrôle de santé et le même basculement de trafic que n’importe quel autre déploiement. C’est voulu : un retour en arrière qui sauterait le contrôle de santé serait le seul chemin de déploiement qui pourrait vraiment causer l’interruption que le reste du système est construit pour éviter.
railyard releases my-app # liste les versions vers lesquelles revenir
railyard rollback my-app <version> [--code-only]--code-only restaure le code mais garde les variables d’environnement actuelles — utile quand une version était correcte mais qu’une variable a changé depuis et que vous ne voulez pas défaire ça aussi.
Pourquoi l’ordre ne peut pas être sauté
Chacune de ces étapes existe à cause d’un mode de défaillance précis qu’elle élimine. Sautez le contrôle de santé et une nouvelle version en boucle de crash prend quand même le trafic. Sautez le maintien de l’ancien conteneur pendant le contrôle et il y a un trou où rien ne répond. Faites tourner la commande de release après le basculement plutôt qu’avant et une migration en attente frappe le trafic en direct en plein milieu. Rien de tout ça n’est de l’ingénierie exotique — c’est juste ne pas sauter d’étapes sous la pression de livrer plus vite.
Détail complet, y compris les déploiements canary et les fenêtres de déploiement : Déploiements et retours en arrière.