GitOps en pratique, déployez des applications Kubernetes avec ArgoCD

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

L’utilisation de GitOps signifie que toute modification du déploiement doit être traitée dans un commit git. Un opérateur de livraison continue différencie ensuite le commit 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 antérieur 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 Grappes Kubernetes. 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 Modèle CI/CD et la plupart des outils GitOps se concentrent sur Kubernetes.

En pratique

Il est recommandé d’isoler le code source de votre application de vos définitions d’état de déploiement entre 2 référentiels Git distincts. YAML les fichiers sont utilisés pour décrire le cluster Kubernetes, y compris les déploiements, ConfigMap, les secrets, …

Le référentiel d’état de déploiement est organisé selon la disposition :

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

Ici nous utilisons personnaliser pour notre personnalisation de configuration déclarative. dev et prod définit l’état de notre application et partage un répertoire commun base. Dev et Prod peuvent être déployés dans le même cluster Kubernetes ou dans des clusters différents selon nos besoins.

Le flux de travail typique pour une nouvelle fonctionnalité dans une application utilisant 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 expédié : une image docker est construite et poussée vers un registre.
4. Le pipeline CI valide et envoie une nouvelle version dans le référentiel 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 s’engager eux-mêmes dans le référentiel 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 référentiel Git avec un déploiement dans un ou plusieurs clusters Kubernetes.

ArgoCD prend en charge plusieurs formats pour les définitions déclaratives (Personnaliser, Barre, Ksonnet ou plaine-YAML).

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

Installation d’Argo CD

Une installation simple d’ArgoCD est simple :

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml



kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath=".data.password" | base64 -d && echo


kubectl patch svc argocd-server -n argocd -p '"spec": "type": "LoadBalancer"'

kubectl port-forward svc/argocd-server -n argocd 8080:443

L’étape suivante consiste à installer le argocd-cli commande suivant l’officiel Installation de la CLI ArgoCD.

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 l’interface utilisateur Web.

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

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


$ argocd app set demo-app --sync-policy auto

En naviguant dans l’interface utilisateur Web, nous pouvons 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 bénéficier à votre conformité DevOps.

ArgoCD est un excellent produit. Il résout un vrai problème tout en étant pratique et facile à utiliser.