GitOps : Argo Rollouts 1.1 offre l’intégration des services de notification

L’équipe de développement d’Argo a publié la version 1.1 d’Argo Rollouts. L’outil, conçu comme un opérateur de livraison pour Kubernetes, sert de complément à l’outil de déploiement continu Argo CD pour la mise en œuvre de stratégies de déploiement telles que les versions canari, les tests A/B et les déploiements bleu/vert. Bien qu’il ne s’agisse officiellement que d’une version mineure, Argo Rollouts 1.1 offre toute une série de nouvelles fonctions et d’améliorations – notamment une intégration complète avec les services de notification.

Le moteur et la bibliothèque de notification, qui sont détachés d’Argo CD et disponibles en tant qu’opérateur séparé, ouvrent désormais la connexion directe à de nombreux services de notification pour les déploiements Argo. Outre Slack, GitHub, Grafana ou Microsoft Teams, le courrier électronique ou les webhooks peuvent être utilisés pour la communication des messages. Pour chaque événement Kubernetes qui est envoyé via un rollout – par exemple RolloutDegraded, RolloutStepCompleted, RolloutPaused ou AnalysisRunFailed – Argo Rollout peut être configuré pour envoyer une notification basée sur des modèles prédéfinis ou des métadonnées personnalisées.

Dans la nouvelle version, l’outil peut désormais être configuré pour annuler automatiquement un déploiement si aucun progrès n’est réalisé au cours d’une période donnée. Dans les versions précédentes, cela n’était possible qu’au cours d’un contrôle par AnalysisRun était possible. En outre, l’équipe d’Argo a éliminé un problème qui, jusqu’à présent, gênait de nombreux utilisateurs : lors de l’interruption d’un déploiement, il n’était pas possible de contrôler quand ou si une pile canari ou une pile de prévisualisation devait être réduite. En outre, des différences involontaires sont apparues dans le comportement des différentes stratégies de mise à jour. À partir de la version 1.1, ces incohérences peuvent être résolues via le nouveau champ abortScaleDownDelaySeconds et définir exactement combien de temps un canari ou une pile de prévisualisation doit rester actif après l’arrêt.

Avec l’introduction du nouveau drapeau dynamicStableScale l’équipe Argo a créé un moyen de faire évoluer le ReplicaSet stable en fonction du trafic. Il s’agit de remédier à un facteur limitant pour certains utilisateurs qui peut être retracé dans l’approche des versions de Canary intégrées à Ingress ou Mesh. Au cours d’un déploiement Canary, le nombre de répliques en cours d’exécution peut doubler, comme pour les mises à jour Blue/Green.

Plus d’informations sur le sujet

Parmi les autres nouveautés de la version, il y a la possibilité de supprimer le tableau de bord introduit dans la version 1.0 de l’application kubectl-argo-rollouts-Le module d’extension introduit dans la version 1.0 peut désormais être utilisé comme un service autonome dans Kubernetes. Cependant, l’équipe Argo déconseille explicitement de faire cela dans les environnements de production, car aucune authentification n’est possible. Une vue d’ensemble de toutes les améliorations apportées dans Argo Rollouts 1.1 est fournie dans le billet de blog. Les notes de mise à jour des outils Argo Events et Argo Workflows sont disponibles dans les dépôts GitHub respectifs.

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici