¶ Déploiement automatique Blue/Green Deployment avec Argo Rollouts
¶ Argo Rollouts
Argo Rollouts est un contrôleur Kubernetes et un ensemble de définitions de ressources personnalisées (CRD) qui fournissent des fonctionnalités avancées pour le déploiement d’applications sur Kubernetes par rapport à l’objet de déploiement natif de Kubernetes.
Argo Rollouts fournit des capacités de déploiement telles que l’analyse blue-green, canari l’expérimentation et les fonctionnalités de livraison progressive à Kubernetes.
¶ Schéma
¶ Installation
Comme les Argo Rollouts sont un ensemble de CRD, nous devons les installer dans le cluster Kubernetes. Exécutez les commandes suivantes pour installer Argo Rollouts.
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
Si l’installation s’est bien déroulée, nous avons :
kubectl get pod -n argo-rolloutsNAME READY STATUS RESTARTS AGE
argo-rollouts-76fcfc8d7f-k6mth 1/1 Running 0 58s
¶ Stratégie de déploiement d’Argo Rollouts
Pour utiliser les Argo Rollouts, nous déclarons une ressource avec l’attribut apiVersion comme argoproj.io/v1alpha1 et le type comme Rollout :
apiVersion: argoproj.io/v1alpha1
kind: Rollout
La configuration des Argo Rollouts a une propriété de stratégie pour nous permettre de choisir la stratégie de déploiement que nous voulons, avec deux valeurs de blueGreen et canary.
Voir le détail ici Spécification de Rollout. N’essayez pas de comprendre toutes les propriétés pour le moment.
Dans cet article, nous allons apprendre la valeur blue/green.
¶ Pratique
J’utilise Minikube pour exécuter Kubernetes Cluster pour la démonstration. Créez un fichier nommé bluegreen-rollout.yaml.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: bluegreen-demo
labels:
app: bluegreen-demo
spec:
replicas: 2
revisionHistoryLimit: 1
selector:
matchLabels:
app: bluegreen-demo
template:
metadata:
labels:
app: bluegreen-demo
spec:
containers:
- name: bluegreen-demo
image: argoproj/rollouts-demo:green
imagePullPolicy: Always
ports:
- name: http
containerPort: 8080
protocol: TCP
strategy:
blueGreen:
autoPromotionEnabled: false
activeService: bluegreen-demo
previewService: bluegreen-demo-preview
Toutes les propriétés de Rollout sont les mêmes qu’un Deployment Object natif, seul l’attribut strategy est différent. Dans le fichier ci-dessus, nous déclarons 3 propriétés :
- autoPromotionEnabled: false — Indique si le rollout doit promouvoir immédiatement le nouveau ReplicaSet auprès du service actif ou entrer dans un état ‹ pause ›, la valeur par défaut est true.
- activeService: bluegreen-demo — Référence au service à contacter.
- previewService: bluegreen-demo-preview — Nom du service démo.
Créons les services associés :
apiVersion: v1
kind: Service
metadata:
name: bluegreen-demo
labels:
app: bluegreen-demo
spec:
type: NodePort
selector:
app: bluegreen-demo
ports:
- port: 80
targetPort: http
protocol: TCP
name: http
---
apiVersion: v1
kind: Service
metadata:
name: bluegreen-demo-preview
labels:
app: bluegreen-demo
spec:
type: NodePort
selector:
app: bluegreen-demo
ports:
- port: 80
targetPort: http
protocol: TCP
name: http
Les deux services sont identiques à leur nom près.
kubectl apply -f bluegreen-rollout.yaml
rollout.argoproj.io/bluegreen-demo createdkubectl get rollout
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
bluegreen-demo 2 2 2 2 30s
Lorsqu’on crée un Rollout, Argo Rollout crée implicitement un ReplicaSet.
kubectl get rs
NAME DESIRED CURRENT READY AGE
bluegreen-demo-fbc7b7f55 2 2 2 4m37skubectl get pod
NAME READY STATUS RESTARTS AGE
bluegreen-demo-fbc7b7f55-g6fst 1/1 Running 0 37s
bluegreen-demo-fbc7b7f55-vvdth 1/1 Running 0 37s
Ensure that Replica Set and Pod are running, next, we create a Service.
kubectl apply -f service.yaml
service/bluegreen-demo created
service/bluegreen-demo-preview created
A ce moment, bluegreen-demo et bluegreen-demo-preview pointent sur le même ReplicaSet.
minikube service bluegreen-demo --url
172.26.123.245:30000
minikube service bluegreen-demo-preview --url
172.26.123.245:30001
Dans le navigateur nous avons l’UI suivante :
Changeons l’image de l’objet Rollout :
...
spec:
containers:
- name: bluegreen-demo
image: argoproj/rollouts-demo:blue
...
Appliquons la mise à jour
kubectl apply -f bluegreen-rollout.yamlrollout.argoproj.io/bluegreen-demo configured
...
kubectl get rsbluegreen-demo-7d6459646d 2 2 2 2m11s
bluegreen-demo-fbc7b7f55 2 2 2 41m
Maintenant le service bluegreen-demo-preview est modofié et pointe sur le nouveau ReplicaSet.
Si on accède sur ce service :
Tandis que le service bluegreen-demo n’est pas modifié
Après avoir vérifié le nouveau ReplicaSet et vu que tout va bien, nous promouvons la nouvelle révision du ReplicaSet en mettant à jour le service bluegreen-demo pour qu’il pointe vers lui, nous exécutons la commande suivante (juste pour démo, nous verrons une autre méthode).
kubectl argo rollouts promote bluegreen-demorollout 'bluegreen-demo' promoted
Maintenant, les Argo Rollouts mettent à jour le service bluegreen-demo pour pointer vers le nouveau ReplicaSet, après une attente (par défaut 30 secondes), l’ancien ReplicaSet disparait.
¶ UI Dashboard
Les ingénieurs DevOps ne doivent pas faire le travail de « promotion » du nouveau ReplicaSet, notre tâche est juste de construire le CI/CD pour que le Rollout puisse être mis à jour quand une nouvelle version de l’application est disponible.
Mais un développeur ne peut pas exécuter le CLI, nous avons donc besoin d’un tableau de bord. Heureusement, Argo Rollout nous fournit un tableau de bord, que nous pouvons activer en utilisant kubectl ou en utilisant l’image conteneur de quay.io/argoproj/kubectl-argo-rollouts.
kubectl argo rollouts dashboard
Argo Rollouts Dashboard is now available at localhost 3100
Choose to bluegreen-demo.
You will see the Promote button, the person who clicks this button will be the QC, if anything is wrong, the QC will be responsible =)))), let’s click on the promote button.
Click Sure.
Now you access both the bluegreen-demo and the bluegreen-demo-preview service we will see the same UI.
Ingress
Ingress configuration for public access if you need.
Done 😁.
Conclusion
So we have learned how to automate Blue/Green Deployment with Argo Rollouts, as you can see, it’s also simple 😁. If you have any questions or need further clarification, you can ask in the comment section below.
If you like my article you can support me by buying me a coffee ☕️, thank you.