GitOps für IT-Architekt:innen – Kubernetes transparent und sicher

Agile Software-Entwicklung und ihre Prinzipien haben in den letzten Jahren immer mehr Aufmerksamkeit gewonnen. Sie tragen dazu bei, dass Produktteams flexibler und produktiver werden. Um das Potenzial der Agilität in Software-Entwicklungsprojekten voll auszuschöpfen, bedarf es auch eines agilen Betriebsmodells samt DevOps-Prinzipien für eine schnelle und einfache Bereitstellung bzw. Auslieferung der Ergebnisse – sogenannte Deployments. 
GitOps folgt hierfür modernen DevOps-Prinzipien und ermöglicht sichere, schnelle und zuverlässige Deployments, die auch Absicherungsprozessen und Audits gerecht werden.

Der Mythos vom Kontrollverlust durch DevOps

Aus unserer Praxiserfahrung wissen wir, dass viele IT-Architekt:innen und -Manager:innen fälschlicherweise davon ausgehen, dass moderne DevOps-Prinzipien einen Kontrollverlust, insbesondere in Bezug auf die Einhaltung von IT-Governance-Prozessen, mit sich bringen. Oft hören wir, dass die Betriebs- und Entwicklungsteams, zugunsten einer Qualitätskontrolle und aufgrund ihrer unterschiedlichen Aufgabenschwerpunkte, strikt getrennt sein müssten. Eine Automatisierung über diese Grenzen hinweg scheint undenkbar, da sie Sicherheitsfunktionen wie Audit- und Freigabeprozesse außer Kraft setzen würde.

In diesem Blogpost erklären wir, was sich hinter dem GitOps-Ansatz verbirgt und wie dieser eingesetzt werden kann, um Deployments zu automatisieren und gleichzeitig Freigabe- und Audit-Prozesse sicherzustellen. Hierdurch lassen sich die oft geforderten Absicherungen ermöglichen.

Continuous Integration und Deployments zur Implementierung von DevOps-Prinzipien

Bevor wir genauer auf das GitOps-Konzept eingehen, ist es wichtig zu verstehen, was sich hinter dem zugrundeliegenden DevOps-Paradigma verbirgt. Der Begriff DevOps ist eine Kombination aus den Begriffen Development und Operations (auf Deutsch: Bereitstellung und Betrieb). Der Begriff steht für ein enges Zusammenspiel dieser beiden Aufgabengebiete beziehungsweise Perspektiven und ist eine Voraussetzung für einen flexiblen und agilen Software-Entwicklungszyklus.

Die Kernidee von DevOps ist es, einen schnellen und leistungsfähigen Prozess für die Software-Entwicklung, -Integration und -Bereitstellung zu ermöglichen. Um einen solchen Prozess zu erreichen, ist eine starke Automatisierung von entscheidender Bedeutung. Kontinuierliche Integration (Continuous Integration, CI) und kontinuierliche Bereitstellung bzw. Auslieferung (Continuous Deployment & Delivery, CD) sind zwei Prinzipien, um diese Art der Automatisierung zu erreichen.

Continuous Integration (CI) legt nahe, dass Code automatisch zu einem Build zusammengebaut und getestet wird, sobald eine Änderung in das (Code-)Versionierungssystem übertragen wird. So ermöglicht CI dem Softwareentwicklungsteam, Fehler frühzeitig zu finden, indem Tests oder Builds in der CI-Pipeline fehlschlagen. CI ist ein inzwischen gut verbreiteter Ansatz, der von einer Fülle von Werkzeugen unterstützt wird.

Continuous Delivery & Deployment (CD) bezieht sich auf die Automatisierung entlang des Auslieferungs- und Bereitstellungsprozesses im Software-Entwicklungszyklus. Obwohl sie oft synonym verwendet werden, gibt es einen kleinen, aber wichtigen Unterschied zwischen Continuous Delivery und Continuous Deployment: Continuous Delivery beschreibt die Fähigkeit, eine Version einer Anwendung jederzeit mit einem einzigen Klick oder gar komplett automatisiert erzeugen (Build) und liefern (Deployment) zu können. Im Gegensatz dazu, beschreibt Continuous Deployment den Prozess der automatischen Bereitstellung jeder erfolgreich getesteten Änderung, in einer bestimmten Umgebung (z. B. Entwicklungs-, Qualitätssicherungs- oder Produktionsumgebung).

Verwenden Sie bereits CD-Pipelines?

Inzwischen lässt sich eine gute Verbreitung von CI-Mechanismen feststellen. Dagegen stellen wir fest, dass CD-Mechanismen in vielen Unternehmen noch nicht genutzt werden. Gründe hierfür sind nicht zuletzt die oben beschriebenen Anforderungen zur Freigabe und Auditierbarkeit. Große Unternehmen nutzen oft zu einem hohen Maße Continous Integration und greifen dennoch auf einen manuellen Prozess für die Bereitstellung von Software in QS- und Produktionsumgebungen zurück. Dies erhöht nicht nur das Risiko menschlicher Fehler, sondern verlangsamt auch den Prozess insgesamt. Um solche unerwünschten Effekte zu vermeiden, ermöglicht GitOps die Kontrolle über automatische Bereitstellungen in jeder Umgebung zu behalten und gleichzeitig einen benutzerdefinierten Freigabeprozess und eine nahtlose Überprüfbarkeit sicherzustellen.

GitOps zur Verbesserung der Transparenz

GitOps ermöglicht automatisierte Deployments, beispielsweise in Kubernetes-Clustern, einzig und allein durch Änderungen (Commits) in einem Git-Repository. Das Git-Repository (auch als State Repository bezeichnet) fungiert als einzige Quelle für den Status der Anwendungslandschaft. Wenn eine Anwendungslandschaft geändert werden soll, erfolgt dies über einen oder mehrere Änderungen in dem State Repository. Durch die Verwendung von Merge- bzw. Pull-Request-Funktionen, die mit den am häufigsten verwendeten Versionierungssystemen mitgeliefert werden, ist es möglich, jeden Freigabeprozess zu implementieren, der in einem Unternehmen erforderlich ist. Sobald die Freigabe für eine Änderung erteilt wurde, ermöglicht GitOps eine automatische Bereitstellungen in der gewünschten Umgebung.

Durch die Verwendung von Git als Quelle für die Konfiguration der Anwendungslandschaft wird jede Änderung automatisch in der Git-Historie aufgezeichnet. Dies ist ermöglicht eine nahtlose Auditierbarkeit in Bezug darauf, wer was zu welchem Zeitpunkt an der Anwendungslandschaft geändert hat. Darüber hinaus ermöglicht die Versionierung der Anwendungslandschaft schnelle Rollbacks auf frühere Versionen. Die Rollbacks sind so einfach wie das Zurücksetzen zu einem vorherigen Git-Commit und das Pushen dieser Änderung in das State Repository Ihrer Anwendung.

CNCF empfiehlt Flux

Wenn eine Anwendungslandschaft über Kubernetes orchestriert wird, ist Flux-CD ein hilfreiches Werkzeug, das im Kubernetes-Cluster ausgeführt wird und die Synchronisierung eines GitOps State Repositorys mit dem Cluster übernimmt. Jedes Mal wenn Flux-CD eine Diskrepanz zwischen dem aktuellen Status des Kubernetes-Clusters und der im State Repository definierten Konfiguration erkennt, wird das Cluster aktualisiert. Die folgende Abbildung zeigt das GitOps-Betriebsmodell mit Flux-CD.

GitOps Betriebsmodell mit Flux CD (https://github.com/fluxcd/flux)

Mit GitOps übertragen Entwickler:innen die Konfiguration eines Kubernetes-Clusters (Kubernetes.yaml-Dateien) an das State Repository, anstatt sie direkt auf das Kubernetes-Cluster anzuwenden. Dies ermöglicht Freigabeprozesse über Merge- / Pull-Requests und versioniert jede Konfiguration des Kubernetes-Clusters, um eine nahtlose Auditierbarkeit zu ermöglichen. Im nächsten Schritt erkennt Flux-CD die Änderungen im State Repository und wendet diese auf das Cluster an.

Ein wichtiger Unterschied zu anderen Betriebsmodellen besteht darin, dass Flux-CD, das im Kubernetes-Cluster ausgeführt wird, die Änderungen aktiv aus dem State Repository abzieht, anstatt dass das State Repository oder ein anderes externes Werkzeug Änderungen an das Cluster überträgt. Dies ermöglicht eine zusätzliche Absicherung, da wir dem State Repository oder einer anderen Anwendung außerhalb des Clusters keine Administrationsrechte erteilen müssen. Tatsächlich ist es so möglich, jegliche Schreibvorgänge auf das Kubernetes-Cluster von außen zu unterbinden. Es wäre sogar möglich, die Sicherheit noch weiter zu erhöhen, indem der Kubernetes-API-Endpunkt gänzlich deaktiviert wird.

Ein weiterer Vorteil von Flux-CD ist, dass Sie damit ein State Repository mit einer beliebigen Anzahl von Kubernetes-Clustern synchronisieren können. Somit ermöglicht das GitOps-Modell die Bereitstellung und Verwaltung einer Anwendungslandschaft, in ein oder mehrere Kubernetes-Cluster durch ein State Repository. Da die gesamte Konfiguration einer Anwendungslandschaft in git definiert ist, ist es außerdem einfach, die Landschaft in einem neuen Kubernetes-Cluster wieder bereitzustellen, falls es Probleme mit dem aktuellen Cluster gibt.

Fazit

Alles in allem ist GitOps ein modernes CD-Prinzip, das auch hohe Anforderungen an Auditierbarkeit, Genehmigungsprozesse und Absicherung erfüllt. Wenn Sie mehr über GitOps und Flux-CD erfahren möchten, schauen Sie sich unsere aufgezeichnete Websession an, in der wir unter anderem auf die Konzepte von DevOps, CI / CD, GitOps und Flux-CD detaillierter eingehen– inklusive einer Live-Demonstration, die einen typischen GitOps-Workflow zeigt.

Wenn Sie GitOps in Ihrer Organisation verwenden möchten, würden wir uns freuen, von Ihren Plänen zu erfahren: