One project a day – keep the chaos away!

In diesem Artikel erfährst du:  

• Wie wir mit unserem „Lego-Baukasten“ innerhalb von 2 Stunden neue Projekte und Entwicklungsumgebungen aufsetzen  
• Wie wir die Komplexität vieler experimenteller „One-week-projects“ beherrschen  
• Wie wir möglichst viel manuellen Aufwand durch einen hohen Grad an Automatisierung vermeiden  

Warning: This Text contains a lot of technical terms, in case of confusion consult the DevOps-Engineer you trust!

Einleitung  

CodeCamp:N ist ein agiles Unternehmen, in dem wir in durchaus kurzer Folge Dinge ausprobieren, Projekte starten und diese auch wieder verwerfen (Inkubation). Außerdem sind wir seit unserer Gründung im Jahr 2017 von sieben auf ca. 140 Mitarbeiter gewachsen. Alle diese Punkte bedingen, dass wir in unserer IT Infrastruktur und unseren Abläufen einige Stellen optimieren müssen, an die man in statischeren Umgebungen so vielleicht gar nicht dächte:  

• Aufsetzen kompletter Entwicklungsplattformen (Git Repos, Cloud Umgebung, CI/CD Pipelines)  
• Management und Operations einer relativ großen Anzahl teilweise sehr kurzlebiger Umgebungen  

Diese beiden Faktoren stellen für uns einen Flaschenhals direkt zu Anfang unserer Pipeline dar und müssen daher effizient gestaltet werden.  

Wir sind seit der Gründung in unserer Infrastruktur Cloud-first ausgerichtet. Wir nutzen also tatsächlich ausschließlich Cloud Services wie Microsoft365, Atlassian Cloud, GitHub und natürlich Azure und AWS. Insbesondere bei den Cloud Plattformen (Azure und AWS) ist eine gewisse Flexibilität notwendig, da wir die entwickelten Produkte auch schnell und einfach aus dem Gesamtverbund heraustrennen können müssen um diese z.B. Kunden für den Eigenbetrieb zu übergeben oder um auf eine Änderung in den Anforderungen zu reagieren.  

Diese Gründe haben dazu geführt, dass wir uns für ein Konzept entschieden haben, welches einen schnellen und weitgehend automatisierten Start von Projekten ermöglicht. Dabei werden die Abhängigkeiten von einem bestimmten Cloud Provider minimiert und eine gute horizontale Skalierbarkeit erreicht.  

Philosophie  

Um den hohen Durchsatz (“Projekte pro Woche”), schnelle Umsetzungszeiten und minimalen Aufwand zu erreichen, ist es erforderlich, dass einerseits Standards genutzt werden und andererseits, die Umsetzung weitestgehend automatisiert erfolgt.  

Um diese Ziele zu erreichen, haben wir uns für einen GitOps Ansatz entschieden. Hierbei dienen ein oder mehrere Git Repositories als Quelle für die SOLL-Konfiguration. Mittels CI/CD Pipelines wird diese SOLL-Konfiguration kontinuierlich in die IST-Konfiguration in der Cloud übertragen. Mit einer entsprechenden Implementierung der Automatisierung kann Git somit als “Single Source of Truth” betrachtet werden: Was im Git steht ist die SOLL-Konfiguration, welche durch überwachte Automatismen in die IST Konfiguration überführt wird. Dabei wird die Konfiguration, die als Textdateien vorliegen, wie Code behandelt (Configuration as Code) und analog zu Programmcode in Git verwaltet.  

Gleichzeitig dient der Git Workflow als Dokumentation der Historie und erzwingt eine Überprüfung von geplanten Änderungen durch einen Freigabe Mechanismus.  

Die Runtime Plattform  

Als Basis unserer Runtime Plattform kommt Kubernetes zum Einsatz. Hierbei greifen wir auf die Kubernetes-as-a-Service Produkte der Cloudprovider zurück, in unserem Fall also Azure Kubernetes Services und AWS Elastic Kubernetes Services. Dies vermeidet, dass wir uns selbst um die Details des Kubernetes Betriebs kümmern müssen. Ein Kubernetes Cluster bei einem anderen Cloud Provider kann leicht ausgerollt werden, falls es notwendig sein sollte (z.B.: via Rancher).  

Um die Kubernetes Cluster und die darauf laufenden Applikationen zu überwachen, ist eine umfassende Observability Lösung implementiert. Für die Erfassung von Metriken (Zeitserien) aus den Clustern kommt Prometheus zum Einsatz und Thanos kümmert sich um die Cluster übergreifende Konsolidierung dieser Daten. Logs werden mit Loki verarbeitet und für die Visualisierung wird Grafana eingesetzt. Die Alarmierung bei Anomalien übernimmt Alertmanager in Verbindung mit OpsGenie zur Benachrichtigung des Teams. Diese komplette Lösung wird zentral und automatisiert bereitgestellt und steht allen Projekten ohne zusätzliche Kosten oder Aufwände zur Verfügung.  

Um das Deployment der einzelnen Applikationen zu automatisieren, verwenden wir ArgoCD. Dieser überwacht eine Sammlung von Git Repositories, in denen die Deployment SOLL-Konfigurationen der Applikationen liegen. Bei Änderungen an diesen Repositories werden die Deployments aus den Repositories mit denen im Cluster verglichen und eventuelle Änderungen automatisch ausgerollt. Des Weiteren überwacht der ArgoCD die im Cluster ausgerollten Applikationen und setzt manuell durchgeführte Änderungen automatisch zurück auf den im Deployment Repository festgelegten SOLL-Stand um so sicherzustellen, dass der IST-Zustand (Kubernetes) immer der SOLL-Konfiguration entspricht.  

Die Entwicklerperspektive

Um ein neues Projekt zur Verfügung zu stellen, greifen wir auf Template Git Repositories zurück. Diese enthalten den notwendigen Standard-Code (eine minimale “Hallo Welt!” Applikation in der gewünschten Programmiersprache) und das Grundgerüst, um den Code zu bauen, ein Docker Image zu erzeugen und das zugehörige Deployment Repository, in welchem die Konfiguration für den Roll-Out der Applikation bereitsteht.  

Für ein neues Projekt sucht man sich aus den verfügbaren Template Repos die benötigten heraus und passt diese auf das neue Projekt an (Projektname, Config Details etc.). Zur Verfügung stehen eine Sammlung von Frontend und Backend Repositories, wie z.B. backend-java-springboot oder frontend-ts-react. Die Auswahl an Repositories ist begrenzt, wird aber nach Bedarf erweitert.  

Für eine typische “Frontend+Backend” Applikation nimmt man also jeweils ein Template für Frontend und Backend, sowie das Deployment Repo-Template.  

Die bereits vorhandenen CI-Pipelines (GitHub Actions) bauen den Code auf der Basis von Docker, so dass der gesamte Build Ablauf in einem Dockerfile hinterlegt wird. Der Vorteil dieses Mechanismus ist, dass man das Image auch problemlos auf dem eigenen Notebook bauen und auch starten kann, ohne dass es erforderlich ist, komplexe Build-Umgebungen oder Projekt-Konfigurationen reproduzieren zu müssen. Außerdem sind das lokal gebaute und das durch die Pipeline gebaute Image komplett identisch, so dass hier Unstimmigkeiten reduziert werden.  

Die CI Pipeline baut also das Docker Image, hinterlegt dieses in der Docker Registry und passt anschließend die Deployment Konfiguration an und diese wird automatisch zur neuen SOLL-Konfiguration. Der im Cluster laufende ArgoCD bemerkt diese Änderung und rollt die neue, aktuelle Applikationsversion aus.  

In den Template Repositories ist dieser komplette Workflow bereits für eine Test- und Produktivversion hinterlegt, so dass man von Tag 1 an in einem Projekt mit einem funktionierenden Staging Ansatz arbeiten kann. Es kann dann in Feature Branches entwickelt werden, die später in den Test Branch überführt und jeweils direkt als aktueller Entwicklungstand deployed und getestet werden. Nachdem der Entwicklungsstand für gut befunden wird (projektabhängiger Release- und Testprozess), wird dieser in den Main Branch überführt, was dann ebenfalls automatisiert diesen neuen Stand in der Produktivumgebung ausrollt.  

Fazit  

Der Rollout kompletter Projekte und Entwicklungsumgebungen ist bei uns zwar nicht komplett automatisiert, wird aber durch einen vorhandenen “Lego-Baukasten” erheblich vereinfacht. Die Ergebnisse dieses Baukastenprinzip enthalten direkt ein vollautomatisches Deployment der Entwicklungs- und Produktions Version einer Applikation. Die Runtime Plattform stellt automatisch umfassendes Monitoring und Observability zur Verfügung, ohne dass diese jeweils projektspezifisch nochmal angelegt und verwaltet werden müssen.  

Mit diesem Ansatz können wir Projekte mit einem manuellen Aufwand von unter zwei Stunden schnell erstellen, so dass es durchaus möglich ist, experimentelle “Ein-Wochen-Projekte” durchzuführen (z.B. zur Evaluation neuer Technologien), ohne dass der initiale Aufwand uns dabei behindert. Länger laufende Projekte profitieren von den weitergehenden Features der Plattform, wie Monitoring und Loganalyse. Kubernetes als Basis-Plattform ermöglicht es uns, Projekte leicht herauszulösen, um diese auf einer anderen (Container-)Plattform zum Laufen zu bringen oder in eine andere Cloud zu portieren.