Qu'est-ce que le GitOps ?

Le GitOps est une approche où un dépôt Git décrit l'état souhaité de l'infrastructure et des déploiements, et où un agent réconcilie en continu le système réel avec ce que dit Git. Le dépôt devient la source de vérité unique : tout changement passe par un commit, et rien n'est appliqué à la main.

Argo CD pousse-t-il ou tire-t-il les changements ?

Argo CD fonctionne en mode « pull » : il tourne à l'intérieur du cluster et tire les manifestes depuis Git pour les appliquer. Aucun accès au cluster n'a besoin d'être exposé à la CI, ce qui est plus sûr qu'un « push » où un pipeline externe détiendrait les identifiants du cluster.

Comment faire un rollback avec Argo CD ?

Puisque l'état vécu du cluster suit Git, revenir en arrière se fait par un « git revert » du commit fautif : Argo CD détecte le changement et resynchronise le cluster sur l'état précédent. L'historique Git devient l'historique des déploiements.

🚀 Argo CD : le GitOps sur k3s, le dépôt Git comme source de vérité

📚 Introduction

Ta CI construit et teste l’image — GitLab CI ou GitHub Actions font ça très bien. Mais ensuite ? Qui applique les manifestes sur le cluster Kubernetes ? Si la réponse est « quelqu’un lance kubectl apply depuis son poste », tu as un problème : aucun historique, aucune trace de qui a déployé quoi, et un cluster qui dérive doucement de ce que décrivent tes fichiers.

Le GitOps répond à ça, et Argo CD est son implémentation la plus répandue pour Kubernetes. C’est un projet open source, diplômé de la CNCF. L’idée : le dépôt Git décrit l’état souhaité du cluster, et Argo CD s’assure en permanence que le cluster y ressemble. On va le poser sur un k3s local.

🔎 C’est quoi, le GitOps ?

Le GitOps repose sur une inversion simple : au lieu de pousser des changements vers le cluster, on les déclare dans Git, et un agent dans le cluster les tire et les applique. Trois principes :

Déclaratif : tout l’état (déploiements, services, config) est décrit en fichiers YAML — éventuellement générés par Helm ou Kustomize.
Versionné : ces fichiers vivent dans Git. Le dépôt est la source de vérité unique.
Réconcilié en continu : Argo CD compare sans arrêt l’état réel du cluster à ce que dit Git, et corrige les écarts.

La boucle GitOps : Git comme source de vérité, Argo CD compare et synchronise le cluster k3s

🚀 Installer Argo CD sur k3s

L’installation officielle tient en deux commandes, plus un accès à l’interface :

kubectl create namespace argocd
kubectl apply -n argocd --server-side --force-conflicts \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
 
# accéder à l'interface web (et à l'API)
kubectl port-forward svc/argocd-server -n argocd 8080:443

La version stable au moment où j’écris est Argo CD 3.4.5. Une fois les pods démarrés, l’interface est disponible sur https://localhost:8080.

🧱 Une Application, c’est un pointeur vers Git

Le cœur d’Argo CD est un objet Kubernetes : la ressource Application. Elle dit « voici un dépôt, un chemin, et un cluster de destination — garde-les synchronisés » :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: mon-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/moi/mon-repo-gitops
    targetRevision: main
    path: apps/mon-app
  destination:
    server: https://kubernetes.default.svc
    namespace: mon-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Les deux options de automated sont les plus parlantes : selfHeal ramène le cluster vers Git s’il dérive (un kubectl edit sauvage est annulé), et prune supprime ce qui a disparu du dépôt. À partir de là, déployer = commiter.

🎯 Pourquoi c’est puissant

Historique et audit gratuits. L’historique Git est l’historique des déploiements : qui a changé quoi, quand, et pourquoi. Un rollback, c’est un git revert.
Séparation propre CI / CD. La CI construit l’image et met à jour le tag dans le dépôt GitOps ; Argo CD s’occupe du déploiement. Chacun son rôle.
Sécurité du modèle « pull ». Argo CD tire depuis Git, à l’intérieur du cluster. Nul besoin de confier les identifiants du cluster à un pipeline externe.

⚠️ Quelques précautions

Git devient critique. Le dépôt est la source de vérité : on le protège (branches, revues) comme le code applicatif.
Ne commite pas de secrets en clair. Les manifestes sont versionnés : mots de passe et clés passent par des outils dédiés (Sealed Secrets, SOPS, External Secrets), jamais en dur dans le YAML.
Automatise la mise à jour des tags d’image. Sans mécanisme (bump du manifeste par la CI, ou Argo CD Image Updater), le tag reste figé dans Git et rien ne se redéploie.

🎉 Conclusion

Argo CD transforme le déploiement en un acte versionné et réversible : le cluster suit Git, pas l’humeur du dernier kubectl apply. Sur un k3s de homelab, c’est un excellent terrain pour apprendre le GitOps sans risque : une Application, un dépôt, et tu regardes Argo CD garder le cluster aligné tout seul. Le jour où quelqu’un bidouille la prod à la main, le self-heal remet les choses en place — et l’historique dira qui a essayé.