Skip to main content
Cette page explique comment annuler un déploiement en cours ou revenir à la version précédente, selon le type de ressource Kubernetes déployée : Rollout (avec Argo Rollouts) ou Deployment classique.

​
Interrompre un canary en cours

Lorsqu’un déploiement canary est en cours et que vous constatez des erreurs, vous pouvez arrêter immédiatement la bascule de trafic. La commande abort renvoie tout le trafic vers la version stable précédente sans attendre la fin du canary.
Abort
Le trafic reprend son état d’avant le démarrage du canary. Les pods de la nouvelle version restent en place mais ne reçoivent plus de requêtes. Vous pouvez ensuite décider de les supprimer ou de relancer un canary corrigé.

​
Revenir à la révision précédente (Rollout)

Si le canary est déjà terminé et que la nouvelle version est devenue la version stable, utilisez undo pour revenir à l’avant-dernière révision connue.
Undo Rollout
Cette commande est équivalente à un rollback natif Kubernetes, mais adaptée à la ressource Rollout gérée par Argo Rollouts. Elle restaure les paramètres de la révision précédente, y compris le tag d’image.

​
Rollback d’un Deployment (chart antid)

Pour les applications qui utilisent encore le chart antid-v2 (Deployment classique), la commande est différente :
Rollout undo Deployment
Le chart antid-v2 est un Deployment classique. Contrairement au chart rollout-v2, il ne gère pas de canary progressif. Le rollback est donc immédiat dès l’exécution de la commande.

​
Revenir à une image spécifique

Parfois, undo ne suffit pas : vous voulez cibler une version précise qui n’est pas la révision immédiatement précédente, ou l’historique des révisions a été modifié.
Le tag d’image n’est PAS stocké dans Git (voir /deploiement/image-updater). Un git revert ne ramène donc pas la version précédente de l’image en production.
Deux options s’offrent à vous :
Modifiez directement le paramètre d’image de l’application dans ArgoCD :
ArgoCD détecte le changement et resynchronise le déploiement. Cette méthode est rapide et ne nécessite pas de commit.

​
Ordre de décision

En cas de problème suite à un déploiement, suivez ce cheminement pour choisir la bonne action :
1

Constater le problème

La nouvelle version cause un problème observable : alertes Prometheus, erreurs 5xx, latence anormale, ou remontées utilisateur.
2

Vérifier l'état du canary

Si le canary est en cours, exécutez abort immédiatement pour stopper la bascule de trafic.
3

Canary terminé : undo

Si le canary est terminé et que la nouvelle version est stable, utilisez undo pour revenir à l’avant-dernière révision.
4

Undo impossible ou ciblage précis

Si undo échoue ou si vous devez viser une version spécifique, passez par argocd app set avec le tag d’image souhaité.
5

Communiquer

Annoncez le rollback dans le canal d’astreinte. Si l’impact était significatif, créez un post-mortem pour analyser la cause racine et éviter la récurrence.
Gardez toujours le numéro de tag de la dernière version connue stable. C’est votre plan B immédiat si vous devez revenir en arrière rapidement sans fouiller dans l’historique.