Une méthode simple et sécurisée pour automatiser les déploiements canaris avec Helm

Le déploiement canari est un moyen très efficace de tester un nouveau code sur un sous-ensemble d'utilisateurs. Il réduit considérablement le trafic, ce qui peut poser des problèmes lors du déploiement, car il ne se déroule que dans un groupe cible défini. Cette note est consacrée à la manière d'organiser un tel déploiement à l'aide de Kubernetes et de l'automatisation des déploiements. On suppose que vous savez déjà quelque chose sur Helm et les ressources Kubernetes.



Un déploiement canari simple dans Kubernetes comprend deux ressources clés : le service lui-même et l'outil de déploiement. Le déploiement canari fonctionne à travers un service qui interagit avec deux ressources différentes, gérant le trafic de mise à jour. L'une de ces ressources travaillera avec la version « canari », tandis que l'autre utilisera la version stable. Dans cette situation, nous pouvons réguler le nombre de versions canaris afin de réduire le volume de trafic à gérer. Par exemple, si vous préférez utiliser Yaml, 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 # Le sélecteur fera router le trafic vers les deux déploiements.

Il est encore plus facile d'envisager cette option sur kubectl, et dans la documentation sur Kubernetes il existe même un tutoriel 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 du déploiement canari

Tout d'abord, nous aurons besoin d'une carte des charts Helm, qui comprend déjà les ressources dont nous avons parlé ci-dessus. Elle devrait ressembler à ceci :

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

Le principe de base de Helm est la gestion des versions multiples des releases. La version stable est notre branche principale stable du code de projet. Mais avec Helm, nous pouvons déployer une version canari avec notre code expérimental. L'essentiel est de maintenir l'échange de trafic entre la version stable et la version canari. 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, qu'elles soient «canary» ou stables, indiqueront cette balise sur les modules. Si tout est configuré correctement, lors du déploiement de la version canary de notre carte des charts Helm, nous verrons que le trafic sera dirigé vers les modules récemment déployés. La version stable de cette commande sera comme suit :

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

Maintenant, vérifions notre déploiement canary. Pour déployer la version canary, nous devons nous rappeler deux choses. Le nom du déploiement doit être différent, afin que nous ne mettions pas à jour la version stable actuelle. La version et le tag doivent également être différents pour que nous puissions déployer un code différent et identifier les différences par les balises des ressources.

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

Voilà, c'est tout ! Si vous pinguez le service, vous pouvez voir que la mise à jour canary ne dirige le trafic qu'une partie du temps.

Si vous recherchez des outils d'automatisation de déploiement qui intègrent la logique décrite, veuillez consulter Deliverybot et en les outils d'automatisation Helm sur GitHub. Les charts Helm utilisés pour mettre en œuvre la méthode décrite ci-dessus sont disponibles sur Github, ici. En fait, il s'agissait d'une vue d'ensemble théorique sur la façon de mettre en œuvre l'automatisation des déploiements canary en pratique, avec des concepts et des exemples concrets.

Source : habr.com