Wie kann Argo CD bei GitOps helfen?

Nick Nov 18, 2019
Wie kann Argo CD bei GitOps helfen?

Vor kurzem haben wir Argo CD als neues Feature in unser Nine Managed GKE aufgenommen. In diesem Beitrag erklären wir, warum wir uns dafür entschieden haben, was die Vorteile sind und wie man es benutzt.

Unsere Motivation

Als wir Anfang des Jahres den Workflow für die Entwicklung unseres "Nine Managed GKE"-Produkts planten, waren einige der Ziele, die wir uns vorgenommen hatten:

  • Guter Wissensaustausch im Team
  • Automatisiertes Testen von Features
  • Automatisierte Releases neuer Features
  • Eine History, anhand der gemachte Änderungen nachvollzogen werden können

Wir schauten uns um und fanden heraus, dass andere Unternehmen erfolgreich mit etwas arbeiteten, dass sich GitOps nennt. Bei GitOps wird git verwendet (wie der Name schon sagt) und dient als Source of Truth für die deklarative Infrastruktur und den Anwendungs-Code. Egal, welche Infrastruktur oder welche Anwendung bereitgestellt oder konfiguriert werden soll, der Quellcode dafür ist auf git gespeichert.

Um den aktuellen Status auf reale Objekte ausserhalb von git zu übertragen (wie beispielsweise Kubernetes Cluster, VMs, etc.), werden sogenannte Pipelines hinzugefügt. Mit Pipelines können bestimmte Aufgaben über spezifische git-Vorgänge ausgeführt werden (wie z.B. neue Commits in einem Branch, das Erstellen von Tags oder das Zusammenführen mit einem bereits vorhandenen Branch). In Kombination mit anderen Funktionen wie etwa Merge Requests (oder Pull Requests, wie sie bei GitHub heißen) wird git zur Kommandozentrale für alle Aufgaben.

Wir begannen, unsere Workflows anzupassen, integrierten neue Tools und bauten Pipelines, um alles Nötige zu automatisieren.

Heute können wir sagen, dass wir unsere Ziele erreicht haben. 💪

 

Die Auswirkungen von GitOPs & Wie Sie Ihren Argo CD Cluster erhalten

Goal GitOps-Auswirkung
Wissensaustausch jede Veränderung muss von einem anderen Team-Mitglied genehmigt werden, was dazu führt, dass Know-How ausgetauscht wird
Automatisiertes Testen von Features| Code wird in gitlab-Pipelines getestet, wenn er dort bestätigt wurde
Automatisierte Releases neuer Features Pipelines führen automatisch neue Software-Versionen oder -Konfigurationen ein
Änderungs-History git-Versionierung weiss genau, was sich verändert hat

 

Da wir sehr zufrieden mit unseren Workflows und der daraus resultierenden Produktivität sind, möchten wir auch unsere Kunden dazu anhalten, GitOps zu nutzen, wenn sie Code auf ihrem Kubernetes Cluster bereitstellen. Ein Tool, das sich gut dazu eignet, ist das von Intuit angebotene Argo CD, das wir grundsätzlich bei allen "nine managed GKE"-Clustern verwenden. Die URL zu ihrer Argo CD Cluster-Installation finden sie auf runway.

 

Nie mehr ein Update verpassen!

Jetzt Updates vom Engineering Logbook abonnieren

 

Argo CD - Ein starkes Tool

Wie wir festgestellt haben, sind die meisten unserer Kunden an die üblichen Entwicklungs-, Staging- und Produktions-Umgebungen für Applikationen gewöhnt. Diese können ganz einfach in Kubernetes erstellt werden. Dazu muss nur ein Namespace mit den notwendigen Deployment-Ressourcen eingerichtet werden und dann muss alles hinzugefügt werden, was nötig ist, um die Applikation für die jeweilige Umgebung zu konfigurieren (Config Maps, Secrets, Ingress, etc.) Der große Nachteil bei diesem Ansatz ist, dass es mit der Zeit Abweichungen in der Konfiguration geben wird. Ihr Namespace für die Entwicklung hat dann vielleicht alle neuen und coolen Features der neuesten Entwicklungs-Version Ihrer Applikation, aber Sie werden alle Änderungen manuell in die anderen Umgebungen übernehmen müssen. Eine Möglichkeit, um diese Situation zu verbessern, ist die Nutzung eines Konfigurations-/Template-Systems (wie etwa Helm Charts, Kustomize, Jsonnet, etc.), um die Kubernetes-Ressourcen Ihrer Applikation zu definieren. Wenn Sie Helm Charts benutzen, können Sie die Versionierung nutzen und verschiedene Versionen in den unterschiedlichen Umgebungen bereitstellen. Es ist dann allerdings immer noch schwierig, im Auge zu behalten, welche Version in welcher Umgebung bereitgestellt wurde.

Wir denken, dass es am besten ist, alle Konfigurationen der Umgebungen in git zu speichern. Dann können Sie Merge Requests für Umgebungs-Veränderungen erstellen, wodurch die Konfigurationen laufend synchronisiert werden. Um automatisch alle Konfigurationen aus dem git-Repository auf den Kubernetes-Cluster zu übertragen, können Sie Argo CD nutzen. 

Argo CD ist ein Tool, das Ihre Umgebungs-Konfiguration – die entweder als Helm Chart, Kustomize-Dateien, Jsonnet- oder einfach als YAML-Dateien erstellt wurde – aus Ihrem git-Repository ausliest und sie dann auf Ihre Kubernetes-Namespaces überträgt.

Einige der Features von Argo CD sind:

  • Deklarative Applikations-Deployments mit Versions-Kontrolle
  • Automatisierung und Nachvollziehbarkeit durch den GitOps-Workflow
  • Unterstützt Applikations-Deklarationen mit Helm, Kustomize und Jsonnet
  • eine Web UI stellt Kubernetes-Ressourcen dar
  • Kommandozeilen-Schnittstellen-Applikation
  • Grafana Metrics-Dashboard
  • Parameterüberschreibung von Helm/Ksonnet-Deklarationen (vereinfacht Entwicklungs-Deployments)
  • Auditprotokolle für Vorgänge in der Applikation und API-Aufrufe

Trennung von Konfiguration und Code

Argo CD bietet eine Applikations-CRD, die den Konfigurations-Code eines bestimmten git-Repository auf einem Kubernetes-Namespace abbildet. Bitte bedenken Sie, dass Argo CD dabei nicht direkt auf das Code-Repository Ihrer Anwendung zugreift. Argo CD empfiehlt explizit diese Best Practices zur Trennung von Anwendungs-Code und Repositories mit Konfigurations-Code. Beim Erstellen einer neuen Version des Anwendungs-Codes, für die ein Deployment in eine bestimmte Umgebung vorgesehen ist, können Sie entweder: 

  • Einen Merge-Request im Konfigurations-Repository machen, um die neue Applikations-Version in der Umgebung zu benutzen 
  • Das Update über eine Pipeline im Code-Repository der Anwendung automatisieren

So können auch die Zuständigkeiten leichter aufgeteilt werden zwischen denjenigen, die für den Anwendungscode verantwortlich sind, und denjenigen, die laufende Anwendungs-Versionen managen. Die Trennung von Code und Konfiguration ist darüber hinaus einer der Bausteine von Twelve-Factor Apps.

Wählen Sie Ihren Konfigurations-Typ

Nachdem sie das Konfigurations-Repository in git erstellt haben, muss nun die Sprache, in der die Konfiguration programmiert werden soll/der Systemtyp gewählt werden. Wie zuvor erwähnt, unterstützt Argo CD Helm Charts, Kustomize-Dateien, Jsonnet-Deklarationen oder einfache YAML-Dateien. Da wir bei nine verstärkt Helm Charts benutzen, empfehlen wir Ihnen, Ihre Konfiguration ebenfalls als Helm Chart darzustellen. Helm Charts ermöglichen es Ihnen auch, später Parameter Overrides oder Sub-Charts zu verwenden. Machen Sie sich aber keine Sorgen: Argo CD benötigt keine laufende Tiller-Instanz. Es kann die Chart mit Helm generieren und die Ressourcen direkt auf Kubernetes anwenden.

Das “App of Apps”-Modell

Um verschiedene Umgebungen für Ihre Applikation abzubilden, muss pro Umgebung eine Argo-CD-Applikation erstellt werden. Die jeweiligen Argo-CD-Applikationen können auch mit verschiedenen Zweigen Ihres Konfigurations-Repositories verknüpft sein (Entwicklung, Staging, etc.) Zur erstmaligen Erstellung dieser Ressourcen bietet Ihnen Argo CD eine Web UI und CLI-Applikation an. Doch es gibt noch einen besseren Weg: das sogenannte App of Apps Pattern. Da Argo-CD-Applikationen deklarativ programmiert werden können, ist es möglich, sie alle in einer Helm Chart unterzubringen, die dann mithilfe einer “Root” Argo-CD-Applikation bereitgestellt wird. So können Sie leicht Applikationen über GitOps hinzufügen oder entfernen.

 

Automatisierung über Pipelines

Wie auch immer Ihr Workflow bei der Entwicklung aussieht, wird es doch immer wieder Zeiten geben, zu denen sie eine neue Applikations-Version bereitstellen müssen. Mit Argo CD gestaltet sich ein Update der laufenden Version ganz einfach. Dazu müssen Sie nur die Version des Container-Image im Konfigurations-Repository ändern. Argo CD erkennt die Änderung von selbst und stellt die neue Version bereit. Ein Commit auf das Konfigurations-Repository kann einfach über eine laufenden Pipeline des Applikationscode-Repositories gemacht werden. Man sollte nicht vergessen, dass sowohl diese Pipeline als auch alle Vorgänge, die nötig sind, um sie in Betrieb zu nehmen, sehr individuell angepasst werden können. Einige Beispiele dafür sind:

  • Deployment in die Produktionsumgebung wird gemacht, wenn ein neuer Versions-Tag im Applikations-Repository erstellt wurde
  • Deployment in die Staging-Umgebung wird gemacht, wenn neuer Code in den Staging-Branch des Applikations-Repository eingefügt wird
  • Pro Feature-Branch erstellt man eine neue Umgebung im Anwendungs-Repository
  • wenn ein neues Container-Image für die Produktion bereitsteht, wird ein Merge-/Pull-Request im Konfigurations-Repository in git erstellt

Egal, welchen Workflow Sie bevorzugen, sie benötigen dafür nur die Pipeline, welche die Vorgänge aus dem Code-Repository Ihrer Anwendung mit Maßnahmen verbindet, die zu einer entsprechenden Veränderung im Konfigurations-Repository führen.

 

Fazit

Argo CD hilft dabei, GitOps-Techniken für schnellere und sicherere Deployments anzuwenden. Es bietet eine schöne UI, mit der die momentan aktiven Kubernetes-Ressourcen und -Vorgänge nachvollzogen werden können. Wenn sie das Tool mit unserem nine managed GKE benutzen wollen, finden Sie alle Links dazu auf runway.

 

Interessiert an unserem Managed Google Kubernetes (GKE)?

Ich möchte mehr über gke erfahren