Implémentation des versions Canary avec Apache APISIX

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 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.

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, 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.

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 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, et weighted_upstreams qui est un ensemble de flux en amont vers lesquels diriger le trafic.

-- 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 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

1. Définir un itinéraire fourre-tout
2. Configurez comment diviser le trafic ; ici, les poids
3. 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

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 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

1. Divisez le trafic uniquement si l'en-tête HTTP 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

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 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:

• 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