Stratégie de libération des Canaries vs Blue / Green
Mon compréhension d’une version canary est qu’il s’agit d’une version partielle d’un sous-ensemble de noeuds de production avec des sessions persistantes activées. De cette façon, vous pouvez contrôler et minimiser le nombre d'utilisateurs/clients impactés si vous libérez un mauvais bogue.
Mon compréhension d’une version bleue/verte est que vous avez 2 environnements de production en miroir ("bleu" et "vert") et que vous transmettez les modifications à tous les nœuds de bleu ou de vert en même temps, Utilisez ensuite la magie des réseaux pour contrôler l’environnement vers lequel les utilisateurs sont routés via DNS.
Donc, avant de commencer, si quelque chose que j'ai dit jusqu'à présent est inexact, commencez par me corriger!
En supposant que je sois plus ou moins sur la bonne voie, quelques questions sur les deux stratégies:
- Existe-t-il des scénarios où le canari est préféré au bleu/vert et inversement?
- Existe-t-il des scénarios dans lesquels un modèle de déploiement peut implémenter les deux stratégies en même temps?
La libération bleu-vert est plus simple et plus rapide.
Vous pouvez créer une version bleu-vert si vous avez testé la nouvelle version dans un environnement de test et êtes absolument certain que la nouvelle version fonctionnera correctement dans production. Toujours utiliser fonctions alternées est un bon moyen d'accroître votre confiance dans une nouvelle version, car la nouvelle version fonctionne exactement comme l'ancienne jusqu'à ce que quelqu'un bascule d'une option à l'autre. Casser votre application en petits services pouvant être définis de manière indépendante en est un autre, car il y a moins de tests à effectuer et moins de risques de rupture.
Vous devez faire une version canarienne si vous n'êtes pas absolument certain que la nouvelle version fonctionnera correctement en production. Même si vous êtes un testeur approfondi, Internet est un lieu vaste et complexe, qui présente toujours des défis inattendus. Même si vous utilisez des options, il est possible que l'une d'entre elles soit implémentée de manière incorrecte.
L'automatisation du déploiement nécessite des efforts, de sorte que la plupart des entreprises envisagent d'utiliser une stratégie ou l'autre à chaque fois.
Faites de même pour le déploiement bleu-vert si vous vous engagez à adopter des pratiques qui vous permettent de le faire en toute confiance. Sinon, envoyez le canari.
L'essence de blue-green consiste à déployer tous les éléments en même temps et le déploiement de Canary est un déploiement incrémentiel. Par conséquent, avec un seul groupe d'utilisateurs, je ne peux pas penser à un processus que je décrirais comme faisant les deux à la fois. Si vous avez plusieurs pools d'utilisateurs indépendants, par exemple En utilisant différents centres de données régionaux, vous pouvez créer des zones bleu-vert au sein de chaque centre de données et canary entre les centres de données. Bien que si vous n'aviez pas besoin de déployer Canary dans un centre de données, vous n'en auriez probablement pas besoin dans tous les centres de données.
J'ai écrit un essai détaillé sur ce sujet ici: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined
À mon avis, la différence est de savoir si la nouvelle version "verte" est exposée ou non à de vrais utilisateurs. Si c'est le cas, je l'appellerais Canary. Un moyen courant d'implémenter Canary est le standard Blue/Green avec l'ajout d'un routage intelligent d'utilisateurs spécifiques à la nouvelle version. Lire le post pour une comparaison détaillée
Bleu vert: 
Canaries: 
Les versions bleue/verte et canari répondent au même objectif de tester un logiciel sur un public cible, avant de diffuser les fonctionnalités du logiciel à un public plus large. Dans le cas d'un canari, les déploiements peuvent partager la même infrastructure en dessous, mais dans le cas du bleu/vert, toute l'infrastructure est dupliquée avec un routeur/DNS/reverseproxy en face avant pour le routage du trafic.
Dans un environnement en nuage où il est plus facile de créer un script et de recréer une infrastructure, le déploiement bleu/vert est préférable car il permet à l'infrastructure d'être synchronisée avec l'automatisation. C'est une grande capacité à avoir lorsque la capacité de recréer des environnements est souhaitée.
Vous pouvez vous référer aux articles suivants pour une comparaison plus détaillée:
Déploiement de BlueGreen: http://martinfowler.com/bliki/BlueGreenDeployment.html
Déploiement des Canaries: http://martinfowler.com/bliki/CanaryRelease.html
Bien que ces deux termes semblent assez proches l'un de l'autre, ils présentent des différences subtiles. L'un met votre confiance dans la publication de vos fonctionnalités et l'autre, dans la manière dont vous publiez.
Canaries
La publication de Canary est une technique permettant de réduire le risque d'introduction d'une nouvelle version de logiciel en production en déployant lentement la modification sur un petit sous-ensemble d'utilisateurs avant de l'intégrer à l'ensemble de l'infrastructure.
Il est sur le point de se faire une idée de la performance de la nouvelle version (intégration avec d’autres applications, processeur, utilisation de la mémoire, du disque, etc.).
Bleu/Vert:
- Il s’agit plus de la version prévisible avec un déploiement sans temps d’arrêt.
- Rollbacks faciles en cas d'échec.
- Processus de déploiement complètement automatisé
Un bon début de définitions. Je pense que cela aide également à prendre une décision pour votre stratégie si vous divisez votre définition de "release" en "deploy" et "release (fonctionnalité)".
Déployer (binaires)
L'action de déploiement binaire de votre produit sur un système (de production).
Libération (fonctionnalité)
Action de gestion de la disponibilité des fonctionnalités pour (groupes d’utilisateurs).
Pourquoi? Lors de la "libération", vous avez généralement deux (multiples) préoccupations: 1) Bugs/compatibilité ascendante/etc 2) Vérification de la validité/de la convivialité des nouvelles fonctionnalités
Demandez-vous ensuite, avant de choisir une stratégie en mode Canaries ou Bleu/Vert ou autre mode gris/mixte: Quelles préoccupations avons-nous lorsque nous publions/déployons la nouvelle version? Et alors seulement si vous connaissez vos préoccupations, choisissez votre stratégie.
De plus, il est possible de faire des stratégies de déploiement/publication plus complexes. Par exemple, dans certains clouds/infra, il est possible de disposer de plusieurs serveurs de production, de relayer la charge dans des proportions différentes vers différents serveurs et versions de votre produit, et de contrôler la validité avant de mettre à l'échelle une version/déploiement vers tous les utilisateurs.
Signalisation des fonctionnalités
L'action de "configurer" (à froid ou même à chaud) quelle fonctionnalité est (non) disponible pour quel (groupe) d'utilisateurs
Si vous faites également quelque chose comme "le signalement des fonctionnalités", vous pouvez commencer par le déployer, mesurer la validité de votre publication dans la perspective de la compatibilité ascendante/des bogues, et diffuser progressivement les nouvelles fonctionnalités à différents utilisateurs, ou inversement (fonctionnalités de réduction et/ou de fichiers binaires inverses) ). Le marquage des fonctionnalités permet de séparer la disponibilité des fonctionnalités du déploiement des fichiers binaires et donne une prise de décision beaucoup plus fine que le seul "déploiement/annulation"