post-image

GitOps und Preview Environments


Wir bei Lion5 sind große Fans davon, Anwendungen in der Cloud zu betreiben. Mit per Klick verfügbarer Infrastruktur und automatischer Skalierung können wir uns darauf konzentrieren, Features für unsere Kunden zu implementieren, anstatt Infrastruktur manuell aufzusetzen und zu warten.

In diesem Artikel stellen wir zwei Konzepte vor um Cloud-Infrastruktur praktisch per Git zu versionieren und damit auch einfach Integrationstests ausführen zu können.

GitOps

Gerade bei schnell wachsenden Anwendungen ist es leicht, den Überblick über die nötige Infrastruktur zu verlieren. Eine gute Möglichkeit das zu verhindern ist GitOps. GitOps wurde als Begriff 2017 von Weaveworks geprägt und beschreibt das Konzept Infrastruktur per Infrastructure as Code (IaC) in Git zu definieren und einen Operator einzusetzen, um die Infrastruktur bereitzustellen.

Ein typischer GitOps Ansatz benötigt mindestens zwei git Repositories, wobei im Prinzip auch andere Versionskontrollsysteme eingesetzt werden können. Das zentrale Element ist das Environment Repository, in dem alle IaC-Definitionen verwaltet werden. Dieses Repository gilt als Single Point of Truth, sprich es definiert welche Komponenten in einer Umgebung gewünscht sind, und die Verwaltung dieser Komponenten findet ausschließlich dort statt. Der Inhalt des Environment Repositories wird automatisch durch herkömmliche CI/CD Systeme aktualisiert, wenn eine neue Version einer Anwendung released wird. Daher ergibt sich auch die Anforderungen von mindestens zwei Repositories, da auch mehrere Anwendungen oder Anwendungskomponenten ein einziges Environment Repository aktualisieren können.

Sobald sich IaC-Definitionen im Environment Repository befinden, greift der Operator diese auf. Hinter dem Begriff des Operators versteckt sich eine einfache Anwendung, welche das Environment Repository regelmäßig klont und die definierten Resourcen bereitstellt. Da IaC für gewöhnlich idempotent ist benötigt der Operator keine zusätzliche Logik, sondern kann einfach alle Definitionen neu anwenden.

Workflow *

GitOps Workflow * Quelle: https://gitops.tech

Doch welche Vorteile ergeben sich nun aus einem solchen Workflow? Allen voran ist der Zustand der Infrastruktur mit einem GitOps-Modell deutlich einfacher zu erfassen. Wenn ein Deployment fehlschlägt, gitb es automatisch neue Versuche des Operators einen konsistenten Zustand herzustellen. Sollte ein Deployment über einen definierten Zeitraum keinen konsistenten Zustand erreichen können, so können Operator wie z.B. Flux Benachrichtigungen versenden. Ein Rollback kann dann einfach per git revert ausgeführt werden.

Zusätzlich bietet GitOps auch den Vorteil der besseren Nachvollziehbarkeit, da typische Entwicklungspraktiken wie Code Reviews von Pull Requests damit auch auf Infrastruktur angewandt werden können. Das ermöglicht das Vier-Augen-Prinzip mit bekannten Mitteln umzusetzen. Ein weiterer Vorteil ensteht dadurch, dass Ressourcen nicht mehr händisch angelegt werden müssen und dadurch Zugangsdaten zu Produktivumgebungen nicht mit Entwicklern geteilt werden müssen. Mit GitOps können Entwickler einfach benötigte Resourcen im Environment Repository definieren und diese werden vom Operator bereitgestellt.

GitOps - Cloud-native Continuous Deployment Mehr zu GitOps? GitOps - Cloud-native Continuous Deployment ist als E-Book verfügbar!

Preview Environments

Eine weitere Herausforderung in Cloud-Umgebungen sind Integrationstests. Häufig werden hierfür eine Vielzahl von Cloud-Resourcen benötigt um die Tests auszuführen. Zusätzlich möchten wir häufig neue Features auch manuell testen, bevor sie in der Produktivumgebung deployed werden.

Hierfür verwenden wir ein weiteres Konzept, das perfekt mit GitOps und IaC im Allgemeinen harmoniert: Preview Environments. Unter Preview Environments versteht man automatisierte Deployments einer kompletten Umgebung für neue Features. In unseren Projekten haben wir Preview Environments mit GitHub Actions realisiert, die automatisch AWS Cloud Formation Stacks für jeden Feature Branch in unseren Repositories bereitstellen und den Entwickler darüber per Kommentar am Pull Request informieren.

Entwickler werden per Kommentar an Pull Requests über ihr Preview Environment informiert.

Dadurch können manuelle Tests einfach in einer Umgebung, die der Produktivumgebung so gut wie möglich ähnelt, ausgeführt werden, nachdem die Integrationstests automatisiert durchgeführt wurden.

Für jedes Feature Deployment werden Integrationstests angestoßen.

Wie Sie Preview Environments mit AWS Cloud Formation aufsetzen können, erfahren Sie in einem bald erscheinenden weiteren Artikel.

Ihnen gefällt, was Sie lesen?

Empfehlen Sie uns weiter!

Zurück