TP : GitOps avec Argo CD

Ce que vous allez apprendre dans ce TP

• Installer Argo CD
• Déclarer une Application synchronisée
• Déployer et revenir en arrière par Git

Introduction #

Ce que vous allez apprendre dans cette section

• Installer Argo CD
• Déclarer une Application synchronisée
• Déployer et revenir en arrière par Git

Contexte. Les déploiements Kubernetes se font par des kubectl apply depuis les postes et personne ne sait ce qui tourne vraiment. Vous faites de Git la source de vérité.

Prérequis : Docker, kubectl, kind et un compte GitHub (fork public du dépôt d'exemples)  ·  Durée estimée : 50 min

Une application dont chaque changement passe par Git.

Mise en place #

Étapes guidées, avec leur correction.

1. 1. Installer Argo CD

   Pourquoi ? Argo CD tourne dans le cluster et tire l'état depuis Git : la CI n'a plus besoin d'accès au cluster.

   Créez un cluster kind, installez Argo CD, attendez qu'il soit prêt et récupérez le mot de passe initial.

2. 2. Préparer le dépôt de déploiement

   Pourquoi ? Le dépôt de déploiement contient les manifestes : c'est lui que l'on modifie pour déployer.

   Forkez argoproj/argocd-example-apps sur GitHub et clonez votre fork. Le dossier guestbook contient un Deployment et un Service.

3. 3. Déclarer l'Application

   Pourquoi ? L'objet Application relie un chemin d'un dépôt Git à un namespace ; selfHeal et prune rendent la synchronisation continue.

   Créez l'Application guestbook en synchronisation automatique et vérifiez que les pods sont créés.

4. 4. Constater l'auto-réparation

   Pourquoi ? Toute modification manuelle est une dérive : Argo CD la corrige pour revenir à l'état décrit dans Git.

   Modifiez le nombre de réplicas avec kubectl scale et observez Argo CD le remettre à la valeur de Git.

5. 5. Déployer par un commit

   Pourquoi ? Déployer, c'est modifier Git : la revue, l'historique et les droits de Git s'appliquent aux mises en production.

   Passez à 3 réplicas dans le manifeste, poussez, puis observez la synchronisation (forcez un rafraîchissement si besoin).

6. 6. Revenir en arrière par Git

   Pourquoi ? Le retour arrière est un git revert : il est tracé, relu et reproductible.

   Annulez le commit, poussez, vérifiez le retour à 1 réplica et consultez l'historique de l'Application. Supprimez ensuite le cluster.

Niveau de difficulté : ●●●○○ (3/5)