GitOps: Argo Rollouts 1.1 bietet Integration von Benachrichtigungsdiensten
Das auf Deployment-Strategien spezialisierte Tool aus dem Argo-Projekt hört nun auf Nachrichten von Slack, GitHub, Grafana oder Microsoft Teams.
- Matthias Parbel
Das Argo-Entwicklungsteam hat Version 1.1 von Argo Rollouts veröffentlicht. Das als Delivery Operator für Kubernetes ausgelegte Tool dient als Ergänzung zum Continuous-Deployment-Werkzeug Argo CD zur Umsetzung von Deployment-Strategien wie Canary Releases, A/B-Tests und Blue/Green Deployments. Obwohl formal lediglich als Minor Release ausgewiesen, bietet Argo Rollouts 1.1 eine ganze Reihe neuer Funktionen und Verbesserungen – darunter die umfassende Integration mit Benachrichtigungsdiensten.
Anbindung an Slack, GitHub, Teams & Co.
Die von Argo CD losgelöste und als separater Operator zur Verfügung stehende Notification Engine samt Library eröffnet Argo Rollouts nun die direkte Anbindung an zahlreiche Benachrichtigungsdienste. Neben Slack, GitHub, Grafana oder Microsoft Teams lassen sich E-Mail oder Webhooks für die Nachrichtenkommunikation nutzen. Für jeden Kubernetes-Event, der über einen Rollout ausgesendet wird – beispielsweise RolloutDegraded, RolloutStepCompleted, RolloutPaused oder AnalysisRunFailed – lässt sich Argo Rollout so konfigurieren, dass eine Benachrichtigung dazu auf Basis vorgefertigter Vorlagen oder mit individuell angepassten Metadaten versendet wird.
In der neuen Version lässt sich das Tool nun so konfigurieren, dass ein Rollout, bei dem innerhalb eines festgelegten Zeitraums kein Fortschritt zu verzeichnen ist, automatisch abbricht. In den bisherigen Versionen war dies nur im Zuge einer Prüfung durch AnalysisRun möglich. Darüber hinaus hat das Argo-Team ein Problem beseitigt, das offenbar vielen Anwenderinnen und Anwendern bisher ein Ärgernis war: Beim Abbruch eines Rollouts ließ sich nicht steuern, wann oder ob ein Canary oder Preview Stack verkleinert werden sollte. Außerdem traten unbeabsichtigte Unterschiede im Verhalten der verschiedenen Aktualisierungsstrategien auf. Diese Inkonsistenzen lassen sich ab Version 1.1 über das neue Feld abortScaleDownDelaySeconds steuern und genau festlegen, wie lange ein Canary oder Preview Stack nach dem Abbruch noch aktiv bleiben soll.
Mehr Kontrolle
Mit Einführung des neuen Flags dynamicStableScale hat das Argo-Team eine Möglichkeit geschaffen, das stabile ReplicaSet Traffic-abhängig zu skalieren. Das soll einen für manche Nutzer offenbar limitierenden Faktor beheben, der auf den Ansatz der Ingress- beziehungsweise Mesh-integrierten Canary Releases zurückzuführen ist. Im Verlauf eines Canary Rollout konnte es dazu kommen, dass sich die Zahl der laufenden Replicas verdoppelt hat – ähnlich wie bei Blue/Green-Updates.
Unter den weiteren Neuerungen im Release findet sich die Option, das in Version 1.0 eingeführte Dashboard aus dem kubectl-argo-rollouts-Plug-in nun auch als eigenständigen Service in Kubernetes zu nutzen. Das Argo-Team rät jedoch ausdrücklich davon ab, dies auch in Produktionsumgebungen zu tun, da dabei keine Authentifizierung möglich ist. Einen Überblick sämtlicher Verbesserungen in Argo Rollouts 1.1 liefert der Blogbeitrag. Release Notes zu den ebenfalls aktualisierten Tools Argo Events und Argo Workflows finden sich in den jeweiligen GitHub Repos.
(map)