Argo CD Argo CD

Contrôler le comportement de synchronisation : auto-sync, prune, self-heal et rollback

Décidez quand Argo CD applique les changements, ce qu'il supprime et comment annuler un mauvais déploiement.

12 min Intermédiaire

Les valeurs par défaut d’Argo CD sont prudentes : il détecte les différences mais ne modifie pas votre cluster de lui-même. Chaque comportement qui le rend entièrement automatique est un opt-in explicite, ce qui vous permet de choisir différents niveaux d’automatisation par environnement. Ce guide passe en revue chaque réglage à l’aide de l’application webapp-dev du guide précédent.

Synchronisation manuelle ou automatisée

Une Application sans bloc syncPolicy.automated est manuelle. Argo CD compare Git et le cluster et marque l’application OutOfSync quand ils diffèrent, mais rien n’est appliqué tant que quelqu’un ne clique pas sur Sync dans l’interface ou n’exécute pas argocd app sync.

Beaucoup d’équipes utilisent la synchronisation automatisée pour les environnements de dev et de test et gardent la production en manuel, de sorte qu’une personne approuve chaque déploiement en production jusqu’à ce que l’équipe ait confiance dans le pipeline.

Activer la synchronisation automatisée

Ajoutez un bloc automated à la syncPolicy de l’application :

spec:
  syncPolicy:
    automated: {}

Avec cela, tout nouveau commit qui modifie l’état souhaité est appliqué sans clic. Deux précisions sur le timing :

  • Argo CD détecte les nouveaux commits en interrogeant le dépôt, toutes les trois minutes par défaut. C’est indépendant de la sync policy. La policy décide seulement si une différence détectée est appliquée.
  • Pour réagir immédiatement, configurez un webhook de votre hébergeur Git vers le endpoint /api/webhook d’Argo CD, ou appuyez sur Refresh dans l’interface pendant vos tests.

Ajouter le pruning

Par défaut, la synchronisation automatisée crée et met à jour des ressources mais ne supprime rien. Si vous renommez ou supprimez un manifeste dans Git, l’ancien objet reste dans le cluster et l’application apparaît OutOfSync à cause de ce reliquat. Activez la suppression par opt-in :

spec:
  syncPolicy:
    automated:
      prune: true

Pour l’essayer, renommez le Deployment dans dev/deployment.yaml de webapp en webapp-v2 et commitez. Argo CD crée le nouveau Deployment et supprime l’ancien. Pour une synchronisation manuelle, vous pouvez élaguer une fois avec argocd app sync webapp-dev --prune, ou cocher Prune dans la boîte de dialogue de synchronisation. Le pruning supprime de vrais objets : activez-le donc délibérément, et soyez prudent avec les ressources qui contiennent de l’état.

Ajouter le self-heal

La synchronisation automatisée réagit aux changements dans Git. Le self-heal réagit aussi aux changements dans le cluster :

spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Testez-le en faisant une modification manuelle que Git ne connaît pas :

kubectl scale deployment webapp-v2 -n webapp --replicas=5
kubectl get pods -n webapp -w

Des Pods supplémentaires démarrent, puis Argo CD ramène le Deployment aux deux réplicas déclarés dans Git. C’est tout l’intérêt : Git reste l’unique source de vérité. Si votre équipe n’est pas prête à ce que les modifications manuelles soient annulées automatiquement, laissez selfHeal désactivé. Argo CD affichera quand même l’application comme OutOfSync, de sorte que la dérive reste visible. Ajoutez des notifications si vous voulez en être informé.

Revenir en arrière en sécurité

Pour revenir à un état déployé antérieur, ouvrez la vue History and Rollback de l’application, choisissez une révision précédente et effectuez le rollback. Les équivalents en CLI sont :

argocd app history webapp-dev
argocd app rollback webapp-dev <ID>

Le rollback exige que la synchronisation automatisée soit désactivée. Sinon, Argo CD resynchroniserait immédiatement l’application sur le dernier commit et annulerait le rollback. Désactivez-la d’abord avec argocd app set webapp-dev --sync-policy none. Après un rollback, l’application est OutOfSync, car Git est en avance sur ce qui tourne. Considérez le rollback comme un levier d’urgence, pas comme la solution. La correction durable consiste à faire un git revert du mauvais commit, à le pousser, puis à réactiver la synchronisation automatisée pour que Git et le cluster concordent de nouveau.

Guides populaires