En quelques mots, l'idée derrière les versions Canary est de fournir une nouvelle version du logiciel à seulement une fraction des utilisateurs, d'analyser les résultats et de décider d'aller plus loin ou non. Si les résultats ne correspondent pas aux attentes, revenez en arrière ; si tel est le cas, augmentez le nombre d’utilisateurs exposés jusqu’à ce que tous les utilisateurs bénéficient de la nouvelle version.  Dans cet article, j'aimerais détailler brièvement cette introduction, expliquer les différentes manières de définir la fraction et montrer comment l'exécuter avec  Apache APISIX.  Introduction aux versions Canary  Le terme « canari » provient de l’industrie minière du charbon. Lors d'une exploitation minière, il n'est pas rare de libérer des gaz toxiques : dans un petit espace clos, cela peut signifier une mort rapide. Pire encore, le gaz peut être inodore, de sorte que les mineurs le respirent jusqu'à ce qu'il soit trop tard pour partir. Le monoxyde de carbone est assez courant dans les mines de charbon et n'est pas détectable par les sens humains.  Pour cette raison, les mineurs ont amené des canaris avec eux sous terre. Si le canari tombait soudainement mort, il y avait de fortes chances qu'une telle poche de gaz ait été percée, et il était grand temps de quitter les lieux.  Il y a des années, nous avons adopté cette approche pour publier une nouvelle version du logiciel. L'analogie est la suivante : les mineurs sont l'équipe Ops qui déploie la version, le canari comprend tous les outils permettant de mesurer l'impact de la version et le gaz est un bug (critique).  La partie la plus cruciale est que   de la version, y compris les taux d'échec, les codes d'état HTTP, etc., et les comparer avec ceux de la version précédente. Cela sort du cadre de cet article, mais encore une fois, c'est essentiel si vous souhaitez bénéficier des versions Canary. La deuxième partie la plus importante est la possibilité de revenir en arrière rapidement si la nouvelle version est boguée. vous devez mesurer l'impact  Versions Canary et indicateurs de fonctionnalités  Notez que les versions Canary ne sont pas le seul moyen de gérer le risque lié à la publication d'un nouveau code. Par exemple, les indicateurs de fonctionnalités sont un autre moyen populaire :  L'approche Canary fournit l'ensemble complet des fonctionnalités dans la nouvelle version du composant  Les indicateurs de fonctionnalité déploient également le composant, mais des paramètres de configuration dédiés permettent d'activer et de désactiver chaque fonctionnalité individuellement.  Les indicateurs de fonctionnalités représentent une approche plus agile (dans le vrai sens du terme) vers les restaurations. Si une fonctionnalité sur 10 est boguée, vous n'avez pas besoin d'annuler le déploiement de la nouvelle version ; vous désactivez uniquement la fonction buggy. Cependant, ce super pouvoir se fait au prix d’une complexité supplémentaire de la base de code, que vous utilisiez des produits tiers ou que vous l’implémentiez vous-même.  D'un autre côté, Canary nécessite un pipeline de déploiement mature pour pouvoir déployer et annuler le déploiement à volonté.  Approches des versions Canary  L'idée derrière les versions Canary est de permettre à seulement une fraction des utilisateurs d'accéder à la nouvelle version. La plupart des définitions Canary définissent uniquement la « fraction » en pourcentage d’utilisateurs. Cependant, il y a plus à cela.  La première étape peut consister à autoriser uniquement les utilisateurs approuvés à vérifier que le déploiement dans l'environnement de production fonctionne comme prévu. Dans ce cas, vous pouvez transférer uniquement un ensemble spécifique d'utilisateurs internes,   des testeurs, vers la nouvelle version. Si vous connaissez les personnes à l'avance et que le système authentifie les utilisateurs, vous pouvez le configurer par identité ; sinon, vous devez recourir à une méthode générique,   aux en-têtes HTTP -   . par exemple par exemple X-Canary: Let-Me-Go-To-v2  N'oubliez pas que nous devons surveiller l'ancien et le nouveau système pour déceler les écarts. Si rien n’apparaît, c’est le moment idéal pour augmenter le nombre d’utilisateurs redirigés vers la nouvelle version. Je suppose que vous mangez votre propre nourriture pour chien,   ; les membres de l'équipe utilisent le logiciel qu'ils développent. Si vous n'avez pas, par exemple, de site de commerce électronique de voitures de luxe, vous pouvez ignorer cette section. c'est-à-dire  Pour élargir la fraction d'utilisateurs tout en limitant les risques, nous pouvons désormais proposer sans discernement la nouvelle version aux utilisateurs internes. Nous pouvons configurer le système pour qu'il redirige vers la nouvelle version en fonction de l'adresse IP du client pour ce faire. À une époque où les gens travaillaient sur site, c'était facile car leurs adresses IP se situaient dans une plage spécifique. Remote ne change pas grand chose puisque les utilisateurs accèdent probablement au réseau de l'entreprise via un VPN.  Encore une fois, surveillez et comparez à ce stade.  Les neuf mètres entiers  À ce stade, tout devrait fonctionner comme prévu pour les utilisateurs internes, quelques-uns ou tous. Mais tout comme aucun plan ne résiste au contact de l’ennemi, aucun usage ne peut reproduire toute la diversité d’une charge de travail de production. En bref, nous devons permettre aux utilisateurs réguliers d'accéder à la nouvelle version, mais de manière contrôlée, tout comme nous avons progressivement augmenté le nombre d'utilisateurs jusqu'à présent : commencer avec une petite fraction, la surveiller, et si tout va bien, augmenter la fraction .  Voici comment procéder avec Apache APISIX. Apache APISIX propose une architecture basée sur des plugins et fournit un plugin qui répond à nos besoins, à savoir le plugin   . traffic-split  Le plugin   peut être utilisé pour diriger dynamiquement des parties du trafic vers divers services en amont. traffic-split  Cela se fait en configurant   , qui sont des règles personnalisées pour diviser le trafic, et   qui est un ensemble de flux en amont vers lesquels diriger le trafic. match weighted_upstreams  --  répartition du trafic  Commençons par quelques amonts de base, un pour chaque version :   upstreams: - id: v1 nodes: "v1:8080": 1 - id: v2 nodes: "v2:8080": 1  Nous pouvons utiliser le plugin   pour transférer la majeure partie du trafic vers la v1 et une fraction vers la v2 : traffic-split   routes: - id: 1 uri: "*" #1 upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: #2 - upstream_id: v2 #3 weight: 1 #3 - weight: 99 #3  Définir un itinéraire fourre-tout  Configurez comment diviser le trafic ; ici, les poids  Transférez 99 % du trafic vers la v1 et 1 % vers la v1. Notez que les poids sont relatifs les uns aux autres. Pour atteindre 50/50, vous pouvez définir les poids 1 et 1, 3 et 3, 50 et 50, etc.  Encore une fois, nous surveillons tout et veillons à ce que les résultats soient ceux attendus. Ensuite, on peut augmenter la fraction du trafic transmis vers la v2,   : par exemple   routes: - id: 1 uri: "*" upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: - upstream_id: v2 weight: 5 #1 - weight: 95 #1  Augmenter le trafic vers la v2 à 5%  Notez qu'Apache APISIX recharge les modifications apportées au fichier toutes les secondes. Par conséquent, vous répartissez le trafic en temps quasi réel. Alternativement, vous pouvez utiliser l'API Admin pour obtenir la même chose.  Des rejets plus contrôlés  Dans ce qui précède, je suis passé des utilisateurs internes à une fraction d'utilisateurs externes. Peut-être que la diffusion à tous les utilisateurs internes représente un risque trop important pour votre organisation et que vous avez besoin d'encore plus de contrôle. Notez que vous pouvez configurer davantage le plugin   dans ce cas. traffic-split   routes: - id: 1 uri: /* upstream_id: v1 plugins: traffic-split: rules: - match: - vars: [["http_X-Canary","~=","Let-Me-Go-To-v2"]] #1 - weighted_upstreams: - upstream_id: v2 weight: 5 - weight: 95  Divisez le trafic uniquement si l'en-tête HTTP   a la valeur configurée. X-Canary  La commande suivante transmet toujours à la v1 :   curl http://localhost:9080  La commande suivante transmet également toujours à la v1 :   curl -H 'X-Canary: Let-Me-Go-To-v1' http://localhost:9080  La commande suivante répartit le trafic en fonction des pondérations configurées,   -dire 95/5 : c'est-à   curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080  Conclusion  Cet article explique les versions Canary et comment vous pouvez en configurer une via Apache APISIX. Vous pouvez commencer avec plusieurs itinéraires avec des priorités différentes et passer au plugin   . Ce dernier peut même être configuré davantage pour permettre des cas d'utilisation plus complexes. traffic-split  Le code source complet de cet article peut être trouvé sur   . GitHub   Pour aller plus loin:   Implémentation d'une solution Canary Release basée sur Apache APISIX   Version Canary dans Kubernetes avec Apache APISIX Ingress   Version fluide de Canary à l'aide du contrôleur d'entrée APISIX avec Flagger  Publié initialement sur   le 3 décembre 2023 A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Cet audio est produit dans la langue originale de l'histoire !

Implémentation des versions Canary avec Apache APISIX

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Télégramme : le pont de Crypto Island vers le continent

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

Télégramme : le pont de Crypto Island vers le continent

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Croissance des crypto-monnaies : créer des profils d'utilisateurs efficaces

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps