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.
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 vous devez mesurer l'impact 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.
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 :
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é.
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, par exemple 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, par exemple aux en-têtes HTTP - 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, c'est-à-dire ; 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.
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.
À 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
traffic-split
peut être utilisé pour diriger dynamiquement des parties du trafic vers divers services en amont.Cela se fait en configurant
match
, qui sont des règles personnalisées pour diviser le trafic, etweighted_upstreams
qui est un ensemble de flux en amont vers lesquels diriger le 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 traffic-split
pour transférer la majeure partie du trafic vers la v1 et une fraction vers la v2 :
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
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
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.
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 traffic-split
dans ce cas.
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
X-Canary
a la valeur configurée.
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, c'est-à -dire 95/5 :
curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080
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 traffic-split
. Ce dernier peut même être configuré davantage pour permettre des cas d'utilisation plus complexes.
Le code source complet de cet article peut être trouvé sur GitHub .
Pour aller plus loin:
Publié initialement sur A Java Geek le 3 décembre 2023