GitOps avec ArgoCD : déploiement continu sur Kubernetes

Le principe GitOps

GitOps positionne Git comme la seule source de vérité pour l'état désiré de votre infrastructure. Tout changement — déploiement, mise à jour de configuration, scaling — passe obligatoirement par une Pull Request dans un dépôt Git. Les opérateurs ne se connectent plus jamais directement aux clusters pour effectuer des changements manuels. ArgoCD surveille le dépôt et réconcilie en continu l'état réel du cluster avec l'état déclaré dans Git.

Ce modèle offre des avantages considérables : auditabilité complète (chaque changement est un commit avec auteur et timestamp), rollback trivial (revert Git), cohérence multi-environnements, et récupération automatique en cas de dérive de configuration.

Architecture recommandée : dépôts séparés

La pratique recommandée est de séparer le dépôt de code applicatif du dépôt de configuration Kubernetes. Cela permet des pipelines CI/CD distincts et évite de mélanger la logique de déploiement avec le code métier.

Dépôts Git :
  ├── app-source/           # Code applicatif (CI → build → push image)
  └── app-config/           # Manifests Kubernetes (GitOps → ArgoCD)
      ├── base/             # Configuration commune
      │   ├── deployment.yaml
      │   ├── service.yaml
      │   └── kustomization.yaml
      ├── overlays/
      │   ├── dev/          # Overrides dev (replicas=1, resources faibles)
      │   ├── staging/      # Overrides staging
      │   └── prod/         # Overrides prod (replicas=3, HPA, PDB)

ArgoCD Applications :
  ├── app-dev     → app-config/overlays/dev     (sync automatique)
  ├── app-staging → app-config/overlays/staging (sync automatique)
  └── app-prod    → app-config/overlays/prod    (sync MANUEL — approbation requise)

Installation et configuration d'ArgoCD

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

# Accès à l'UI (localhost:8080)
kubectl port-forward svc/argocd-server -n argocd 8080:443

# Récupérer le mot de passe admin initial
kubectl -n argocd get secret argocd-initial-admin-secret   -o jsonpath="{.data.password}" | base64 -d

Pour la production, configurez ArgoCD avec un IdP externe (Dex + GitHub OAuth ou SAML) et désactivez le compte admin local. Appliquez les RBAC ArgoCD pour restreindre qui peut sync quelle Application.

Définir une Application ArgoCD (CRD)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app-prod
  namespace: argocd
  annotations:
    notifications.argoproj.io/subscribe.on-sync-succeeded.slack: deployments
    notifications.argoproj.io/subscribe.on-sync-failed.slack: alerts
spec:
  project: production
  source:
    repoURL: https://github.com/move2cloud/app-config
    targetRevision: HEAD
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true      # Supprime les resources retirées de Git
      selfHeal: true   # Réconcilie les changements manuels non-Git
    syncOptions:
      - CreateNamespace=true
      - PrunePropagationPolicy=foreground

Pipeline CI/CD intégré avec GitHub Actions

Le workflow GitOps complet suit ce pattern :

1. Développeur pousse sur main du dépôt app-source
2. GitHub Actions build, teste, et push une nouvelle image Docker
3. GitHub Actions met à jour le tag d'image dans app-config
4. ArgoCD détecte le commit dans app-config et synchonise le cluster

# .github/workflows/ci.yml (dans app-source)
- name: Build and push image
  run: |
    docker build -t $REGISTRY/my-app:${{ github.sha }} .
    docker push $REGISTRY/my-app:${{ github.sha }}

- name: Update image tag in config repo
  run: |
    git clone https://x-access-token:${{ secrets.CONFIG_REPO_TOKEN }}@github.com/move2cloud/app-config
    cd app-config
    yq e '.image.tag = "${{ github.sha }}"' -i overlays/prod/values.yaml
    git config user.email "ci@move2cloud.fr"
    git config user.name "GitHub Actions CI"
    git commit -am "ci: update prod image to ${{ github.sha }}"
    git push

Déploiements progressifs avec Argo Rollouts

Argo Rollouts étend ArgoCD avec des stratégies de déploiement avancées :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  strategy:
    canary:
      steps:
        - setWeight: 10    # 10 % du trafic vers la nouvelle version
        - pause: {duration: 5m}
        - analysis:        # Vérifie les métriques Prometheus
            templates: [{templateName: success-rate}]
        - setWeight: 50
        - pause: {duration: 10m}
        - setWeight: 100
      # Rollback automatique si error rate > 5 %
      analysis:
        successCondition: result[0] >= 0.95

Conclusion

ArgoCD est le standard de facto pour implémenter GitOps sur Kubernetes. Sa maturité, sa communauté active et son intégration avec l'écosystème CNCF (Argo Rollouts, Argo Workflows, Argo Events) en font un choix solide pour la production. Le vrai gain n'est pas seulement technique — c'est organisationnel : une traçabilité complète de chaque déploiement, des rollbacks en une commande, et l'élimination des modifications manuelles non-auditées sur les clusters de production.