Wie weit kann man es treiben?

Die Zeiten der langen Build- und Deployment Pipeline sind gezählt. Neue Ideen wie GitOps oder ChatOps entstehen und das Tooling, sowie die Workflows, ändern sich. Ich werde euch in diesem Artikel ein GitOps Tool näher bringen, die Vor- und Nachteile aufzeigen und wie einfach der Einstieg in die GitOps Welt sein kann.

 

Was ist GitOps?

GitOps versucht, Deployments versioniert und somit auch dokumentiert per Git-Tooling zu erreichen. Des Weiteren können einzelne CI/CD Schritte entkoppelt werden, indem man vom Push- zum Pull-Prinzip der Deployments wechselt. Dabei ist die Idee, ein Git als “Single source of truth” zu besitzen und der Versuch, die Infrastruktur und Deployments mit denselben Prozessen und Tools zu managen. Die Techniken der Softwareentwicklung werden somit auf den gesamten Deployment Lifecycle übertragen.

Der Begriff wurde von der Firma Weaveworks geprägt, die auch das Tool Flux bereitstellt. Mittlerweile gibt es neben Flux auch Alternativen wie ArgoCD. Die Idee ist dieselbe: „Development Lifecycle” as Code.

Der Anwendungsbereich ist sehr groß, jede Komponente, die sich deklarativ beschreiben lässt, kann mit GitOps bzw. in einem GitOps Workflow bereitgestellt werden. Wie z.B. Kubernetes Deployments oder sogar die Automatisierung eines Cloud Anbieters Google, über deren Kubernetes Schnittstelle “Config Connector”.

 

GitOps Workflow

Der große Unterschied liegt im Ereignis, das den Workflow anstößt. Bei einer normalen CI/CD Pipeline wird durch einen Push, von z.B. neuen Software Code, die Pipeline angestoßen. GitOps basiert auf dem Pull-Prinzip, das Tooling überwacht das ihm zugeordnete Git und der Workflow wird über die Zustandsänderung im Git angestoßen.

Dafür wird ein Operator benötigt, der diese Gits überwacht, Änderungen erkennt und im Cluster einspielt. In unserem Beispiel Flux. Der große Vorteil besteht also darin, bewährte Prozesse der Softwareentwicklung im operativen Bereich anwenden zu können, wie Pull Request, Code Reviews, Quality Gates, u.v.m.

 

FluxCD – das GitOps Toolkit

FluxCD ist ein GitOps-Tool, um Kubernetes Manifeste jeglicher Arten im ihm zugeteilten Cluster zu installieren. Dabei ist Flux in der Microservice Architektur aufgebaut und ein Event getriebenes System. Somit bietet Flux mehrere Controller und Operatoren die es sehr einfach machen den GitOps Ansatz in bestehende Infrastrukturen einbetten. Dabei automatisiert sich Flux selbst über das eigene Tooling.

 

Flux Workflow

Der Source Controller überwacht alle Änderungen in versionierbaren File Systemen, in diesem Beispiel Git. Diese können dann über das normale “Git Toolkit” wie Pull Requests und Reviews verwaltet und aktualisiert werden. Sind die Änderungen genehmigt und eingespielt, erkennt dies der Source Controller und leitet das Deployment an den jeweiligen Deployment-Controller weiter. Für Helm-Charts an den Helm Controller, für Kustomize Manifeste an den Kustomize Controller. Es ist möglich, auch noch weitere Deployment Deskriptoren zu nutzen. Diese Deployments werden dann von den Controllern überwacht und in regelmäßigen Abständen „reconciled“. Kubernetes versucht den in den Manifesten beschriebenen Zustand zu erreichen, z.B. beschreibt man in einem Deployment, dass ein Pod dreimal auf dem System zur Verfügung stehen soll. Kubernetes wird diese Definition in regelmäßigen Abständen überprüfen und versuchen, den beschriebenen Zustand zu erreichen. Sind nur zwei Pods im Cluster, wird Kubernetes einen weiteren anlegen. Diese Reconciliations werden über einen Notification Controller weitergeleitet und können somit im Monitoring erfasst oder z.B. in Slack dargestellt werden.

Die Installation von Flux ist sehr simpel und erfolgt über eine Kustomize Datei. Dadurch werden alle nötigen Controller im Namespace “flux-system” installiert und somit ist Flux auch schon einsatzbereit.

Damit ist es nun möglich, jede Deployment-Information im Git festzuhalten, jede Änderung wird asynchron im Cluster eingespielt. Mit der FluxCLI oder der Oberfläche von Weave ist dann der Status jedes Deployments einsehbar.

 

Flux um Google Cloud zu automatisieren

Wird dieses Konzept kombiniert mit dem Tool Config Connector von Google, erhält man die Möglichkeit einer kompletten Cloud Automatisierung über ein Kubernetes Cluster im GitOps Approach. Durch die CustomResourceDefinitions, die der Config Connector dem Cluster hinzugefügt, ist es möglich, fast alles in Google Cloud zu verwalten und zu automatisieren. Jede Ressource in Google ist somit über eine CRD automatisierbar. Somit wird das gesamte System deklarativ im Kubernetes Cluster verwaltet.

Der große Vorteil, der dadurch entsteht, ist, dass jede Ressource über den Reconciliation-Loop von Kubernetes verwaltet wird. Das Dependency Management ist damit in vielen Bereichen obsolet.

Code Block

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  annotations:
    cnrm.cloud.google.com/force-destroy: "false"
  labels:
    label-one: "value-one"
  # StorageBucket names must be globally unique. Replace ${PROJECT_ID?} with your project ID.
  name: ${PROJECT_ID?}-sample
spec:
  lifecycleRule:
    - action:
        type: Delete
      condition:
        age: 7
  versioning:
    enabled: true
  cors:
    - origin: ["http://example.appspot.com"]
      responseHeader: ["Content-Type"]
      method: ["GET", "HEAD", "DELETE"]
      maxAgeSeconds: 3600
  uniformBucketLevelAccess: true

Diese dargestellte Ressourcendefinition reicht, um ein Storage Bucket in der Google Cloud anzulegen. Somit ist es nicht nur möglich, das gesamte Deployment einer Komponente in Kubernetes abzubilden, sondern auch noch über den GitOps Workflow nutzbar.

 

Fazit

Die Idee ist hervorragend, doch in der Realität zeigt der “Config Connector” leider viele Lücken. Darüber hinaus sind keinerlei Mechanismen automatisiert. Ein vollwertiges Deployment mit Anlegen der GCP, IAM, Kubernetes, Ingress und Netzwerkressourcen ist sehr aufwändig und führt zu einer großen, unübersichtlichen Deployment Definition und viel wiederkehrenden Code Blöcken. Jede Ressource benötigt ein dementsprechendes, darüber hinaus noch ein korrektes Berechtigungsmodell. Trotzdem ist es so möglich, den gesamten Deployment Zyklus in Git abzulegen und zu managen. Dabei wird nicht nur ein Container im Cluster angelegt, sondern ein in sich abgeschlossenes Deployment, das komplett verwaltet werden kann, ohne dabei eine neue Automatisierungssprache neben dem bekannten Git und Kubernetes Deskriptoren lernen zu müssen. Auch Weave ist im Punkte Infrastrukturautomatisierung einen Schritt weiter gegangen und bietet für Flux nun den Terraform Controller an, der es ermöglicht seine Infrastrukturautomatisierung über den GitOps Approach und der Kubernetes “Reconcile Mechanismen” abzubilden. 

Wenn man das ganze aus architektureller Sicht betrachtet, ist diese Art der Automatisierung mit der Microservice- oder Macroservice Architektur vergleichbar, welche dem Entwickler den Zugang zur Infrastrukturautomatisierung näher bringt, Fehlermanagement und Wartung auf kleinere “Blöcke” reduziert und eine bessere Anpassungsfähigkeit gewährleistet. Die Wiederverwendbarkeit einzelner Code Snippets ist auch gegeben, doch man verliert schnell den Überblick. Somit stellt Weaveworks mit FluxCD ein hervorragendes Werkzeug für DevOps zur Verfügung. Automatisierung der Cloud aus Kubernetes heraus.