Un moyen simple et sécurisé d'automatiser les déploiements Canary avec Helm

Le déploiement Canary est un moyen très efficace de tester un nouveau code sur un sous-ensemble d'utilisateurs. Cela réduit considérablement la charge de trafic qui peut poser problème lors du processus de déploiement, car elle ne se produit que dans un sous-ensemble spécifique. Cette note est consacrée à la manière d'organiser un tel déploiement à l'aide de Kubernetes et de l'automatisation du déploiement. Nous supposons que vous savez quelque chose sur les ressources Helm et Kubernetes.



Un simple déploiement Canary sur Kubernetes comprend deux ressources clés : le service lui-même et l'outil de déploiement. Le déploiement Canary fonctionne via un service unique qui interagit avec deux ressources différentes servant le trafic de mise à jour. L'une de ces ressources fonctionnera avec la version « Canary », et la seconde fonctionnera avec la version stable. Dans cette situation, nous pouvons réguler le nombre de versions Canary afin de réduire la quantité de trafic nécessaire à la desserte. Si, par exemple, vous préférez utiliser Yaml, alors cela 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 cette option en utilisant kubectl, et dans Documentation Kubernetes Il existe même un tutoriel complet sur ce scénario. Mais la question principale de cet article est de savoir comment nous allons automatiser ce processus à l'aide de Helm.

Automatisation du déploiement Canary

Tout d’abord, nous avons besoin d’une carte graphique Helm, qui inclut déjà les ressources dont nous avons parlé ci-dessus. Ça devrait ressembler a quelque chose comme ca:

~/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 Canary avec notre code expérimental. L'essentiel est de maintenir l'échange de trafic entre la version stable et la version Canary. Nous allons gérer tout cela à l'aide d'un sélecteur spécial :

selector:
  app.kubernetes.io/name: myapp

Nos ressources de déploiement « canari » et stables indiqueront ce label sur les modules. Si tout est configuré correctement, alors lors du déploiement de la version Canary de notre carte graphique Helm, nous verrons que le trafic sera dirigé vers les modules nouvellement déployés. La 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

Vérifions maintenant notre version Canary. Pour déployer la version Canary, nous devons nous rappeler deux choses. Le nom de la version doit être différent afin que nous ne déployions pas de mise à jour vers la version stable actuelle. La version et la balise doivent également être différentes afin que nous puissions déployer d'autres codes et identifier les différences par balises 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! Si vous effectuez une requête ping sur le service, vous pouvez constater que la mise à jour Canary n'achemine le trafic qu'une partie du temps.

Si vous recherchez des outils d'automatisation de déploiement incluant la logique décrite, faites attention à Bot de livraison et Outils d'automatisation Helm sur GitHub. Les chartes Helm utilisées 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 manière de mettre en œuvre l'automatisation du déploiement des versions Canary dans la pratique, avec des concepts et des exemples spécifiques.

Source: habr.com