Un moyen simple et sûr d'automatiser les déploiements canaris avec Helm

Le déploiement Canary est un moyen très efficace de tester un nouveau code sur un sous-ensemble d'utilisateurs. Il réduit considérablement la charge de trafic, ce qui peut provoquer des problèmes pendant le processus de déploiement, car il se produit uniquement au sein d'un certain sous-groupe. Cet article est consacré à l'organisation d'un déploiement similaire à l'aide de Kubernetes et de l'automatisation du déploiement. On suppose que vous savez quelque chose sur les ressources de Helm et Kubernetes .



Le déploiement simple de Kubernetes canary comprend deux ressources clés: le service lui-même et l'outil de déploiement. Le déploiement canary fonctionne via un service, qui interagit avec deux ressources différentes qui servent le trafic de mise à jour. Une de ces ressources fonctionnera avec la version "canari" et la seconde avec la version stable. Dans cette situation, nous pouvons ajuster le nombre de versions canaris afin de réduire la quantité de trafic nécessaire à la maintenance. Si, par exemple, vous préférez utiliser Yaml, il ressemblera à ceci dans Kubernetes:

kind: Deployment metadata: name: app-canary labels: app: app spec: replicas: 1 ... image: myapp:canary --- kind: Deployment metadata: name: app labels: app: app spec: replicas: 5 ... image: myapp:stable --- kind: Service selector: app: app # Selector will route traffic to both deployments. 

Il est encore plus facile d'imaginer une telle option sur kubectl, et la documentation de Kubernetes propose même un didacticiel complet sur ce scénario. Mais la principale question de ce post est de savoir comment nous allons automatiser ce processus en utilisant Helm.

Automatisation d'un déploiement canari

Tout d'abord, nous avons besoin de la carte Helm Chart, qui a déjà inclus les ressources dont nous avons discuté ci-dessus. Cela devrait ressembler à ceci:

 ~/charts/app ├── Chart.yaml ├── README.md ├── templates │ ├── NOTES.txt │ ├── _helpers.tpl │ ├── deployment.yaml │ └── service.yaml └── values.yaml 

La base du concept Helm est la gestion des versions multi-versions. La version stable est notre principale branche stable du code du projet. Mais avec Helm, nous pouvons déployer une version canari avec notre code expérimental. L'essentiel est de garder l'échange de trafic entre la version stable et la version canari. Nous gérerons tout cela à l'aide d'un sélecteur spécial:

 selector: app.kubernetes.io/name: myapp 

Nos ressources de déploiement «canaries» et stables indiqueront cette étiquette sur les modules. Si tout est correctement configuré, lors du déploiement de la version canari de notre carte Helm, nous verrons que le trafic sera envoyé vers des modules fraîchement déployés. Une version stable de cette commande ressemblera à ceci:

 helm upgrade --install myapp \ --namespace default \ --set app.name=myapp \ # Goes into app.kubernetes.io/name --set app.version=v1 \ # Goes into app.kubernetes.io/version --set image.tag=stable \ --set replicaCount=5 

Voyons maintenant notre version canari. Pour déployer la version canari, nous devons nous rappeler deux choses. Le nom de la version doit être différent afin que nous ne reportions pas la mise à jour sur la version stable actuelle. La version et la balise doivent également être différentes afin que nous puissions déployer un code différent et identifier les différences par les étiquettes de ressources.

 helm upgrade --install myapp-canary \ --namespace default \ --set app.name=myapp \ # Goes into app.kubernetes.io/name --set app.version=v2 \ # Goes into app.kubernetes.io/version --set image.tag=canary \ --set replicaCount=1 

C'est tout, en fait! Si vous envoyez une requête ping au service, vous pouvez voir que la mise à jour canari achemine le trafic uniquement une partie du temps.

---

Si vous recherchez des outils d'automatisation de déploiement qui incluent la logique décrite, consultez Deliverybot et les outils d'automatisation Helm sur GitHub . Les graphiques Helm utilisés pour implémenter la méthode décrite ci-dessus sont sur Github, ici . En général, il s'agissait d'un aperçu théorique de la façon de mettre en œuvre le déploiement de versions canaris dans la pratique, avec des concepts et des exemples spécifiques.