GitOps en pratique, déploiement d'applications Kubernetes avec ArgoCD

GitOps est un ensemble de pratiques pour déployer des applications à l’aide de Git. Les définitions, les configurations et la connectivité des applications sont stockées dans un logiciel de contrôle de version tel que Git. Git sert alors d’unique source de vérité et de confiance pour l’infrastructure déclarative et ses applications hébergées.

L’utilisation de GitOps implique que toute modification associé au déploiement doit être adressé par un commit git. Un opérateur de livraison continue (continuous delivery operator) analyse les différences entre les commits et synchronise l’état entre le référentiel et l’environnement ciblé.

Le principal avantage de GitOps est que chaque modification est versionnée et vérifiable. Le versionning permet de revenir facilement à un état précédent en cas d’erreur. La reprise après sinistre est également simplifiée. La source de vérité reste inchangée et il vous suffit de changer d’environnement ciblé.

L’article présente comment nous utilisons [ArgoCD pour synchroniser l’état de nos Kubernetes clusters. Il couvre son installation et ses utilisations à l’aide d’un exemple d’application simple hébergé sur GitHub.

Étant donné que les manifestes Kubernetes sont déclaratifs, ils correspondent parfaitement au CI/CD pattern et la plupart des outils GitOps se concentrent sur Kubernetes.

En pratique

Il est recommandé d’isoler entre 2 dépôts Git distincts le code source de votre application et vos définitions représentant l’état souhaité des déploiements. Les fichiers YAML sont utilisés pour décrire le cluster Kubernetes, y compris les Deployments, ConfigMap, Secrets, …

Le dépôts représentant l’état des déploiements est organisé selon la disposition suivante :

./myapp-ops
├── base
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   └── service.yaml
├── dev
│   ├── deployment-patch.yaml
│   └── kustomization.yaml
└── prod
    ├── deployment-patch.yaml
    └── kustomization.yaml

Ici, nous utilisons kustomize pour la personnalisation des configuration de manière déclarative. Les répertoires dev et prod définissent l’état de notre application et partagent une base commune. Dev et Prod peuvent être déployés dans des clusters Kubernetes identiques ou différents selon nos besoins.

Le workflow typique pour l’incorporation d’une nouvelle fonctionnalité dans une application utilisant le modèle GitOPs est le suivant :

1. Le code est poussé vers le référentiel de code.
2. Le code est construit et testé dans la plate-forme CI.
3. Le code est publié : une image docker est construite et poussée vers un registre.
4. Le pipeline CI valide et pousse une nouvelle version dans le dépôt de déploiement.
5. Ce push déclenche une synchronisation : le nouveau code est automatiquement déployé sur l’infrastructure cible.

Les utilisateurs sont libres de commiter eux-mêmes dans le dépôt de déploiement, par exemple ils peuvent définir le nombre de ReplicaSet d’un déploiement.

ArgoCD

ArgoCD est un opérateur GitOps qui synchronise l’état décrit dans un dépôt Git avec un déploiement dans un ou plusieurs clusters Kubernetes.

ArgoCD prend en charge plusieurs formats pour les définitions déclaratives (Kustomize, Helm, Ksonnet ou plain-YAML).

Il est implémenté en tant que contrôleur Kubernetes qui surveille le dépôt Git et le déploiement actuel. Si, pour une raison quelconque, le statut actuel s’écarte de la cible (attente d’une action utilisateur, échec du déploiement, restauration manuelle…), l’application est considérée comme OutOfSync.

ArgoCD Installation

L’installation basique d’ArgoCD est simple :

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# ArgoCD is now installed on your cluster !

# The admin password can be found here:
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d && echo

# The Web UI and CLI are exposed by the service argocd-server, let's access it:
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
# Or if no LoadBalancer provider is available
kubectl port-forward svc/argocd-server -n argocd 8080:443
# Or use an ingress controller

L’étape suivante consiste à installer la commande argocd-cli en respectant le guide d’installation officiel ArgoCD CLI installation.

Plus de documentation sur l’installation (gestion des utilisateurs, haute disponibilité, observabilité…) sont disponibles ici.

Utilisation d’ArgoCD

Créons maintenant une application ArgoCD à l’aide de la CLI. Cela peut être fait facilement via la Web UI.

argocd login $myargocd:8443
argocd app create demo-app-dev --repo https://github.com/PACordonnier/demo-cicd-ops.git --path dev --dest-server https://kubernetes.default.svc --dest-namespace dev
# Wait a few minutes
argocd app get demo-app-dev
Name:               demo-app-dev
Project:            default
Server:             https://kubernetes.default.svc
Namespace:          dev
URL:                https://192.168.39.5/applications/demo-app-dev
Repo:               https://github.com/PACordonnier/demo-cicd-ops.git
Target:             
Path:               dev
SyncWindow:         Sync Allowed
Sync Policy:        Automated
Sync Status:        Synced to  (babc0df)
Health Status:      Healthy

# Enable autosync
$ argocd app set demo-app --sync-policy auto

# Our application is now Synced and healthy! All changes to our infrastructure repository are automatically applied

En naviguant dans la Web UI, on peut voir tous les objets gérés par ArgoCD ainsi que leur état actuel :

Conclusion

Si vous utilisez Kubernetes pour votre déploiement et que vous avez du mal à savoir ce qui est déployé sur vos environnements, GitOps est fait pour vous. Sa mise en œuvre n’est pas sorcier et ne peut que profiter à votre objectif d conformité avec les bonnes pratiques DevOps.

ArgoCD est un excellent produit. Il résout un vrai problème tout en étant pratique et simple d’utilisation.