Wie ist DevOps wirklich – Ädu Tschirren erzählt aus dem Alltag
Seit vielen Jahren arbeitet Adrian Tschirren bei Nexplore in verschiedenen Rollen – vorwiegend als Entwickler, aber auch anderen Rollen wie Projektleiter und Requirements Engineer.
Zuletzt hat er häufig die Rolle als DevOps Engineer übernommen – neben der klassischen Software-Entwicklung ist er dafür zuständig, dass die Container erstellt, die benötigte Infrastruktur im Cluster deployed wird und die Pods und Container laufen.
Zusammen mit den System Engineers aus dem Cloud Engineering-Kreis schaut er, dass unsere Kubernetes-Cluster richtig erstellt, konfiguriert und betrieben werden.
Was machst du alles in den Projekten?
Ich erstelle die Helmcharts Konfigurationsdateien, damit die Infrastruktur unserer containerbasierten Applikationen richtig erstellt wird.
Auf unserem Azure DevOps und Build-Server bin ich dafür zuständig, dass die Container in unseren Build Pipelines richtig erstellt und beim automatisierten Deployment auf unseren Kubernetes Cluster aufgespielt werden.
Wir setzen Linux «Build Agents» für unsere Projekte ein – diese habe ich mit eingerichtet und konfiguriert. Wenn wir neue Funktionen benötigen, passe ich diese an.
Was hast du fürs DevOps alles neu gelernt?
Das Wichtigste ist es, die Konzepte von Kubernetes zu verstehen. Ohne das geht es nicht.
Das Konzept der Helmcharts ist auch sehr wichtig. Die Syntax und das Zusammenspiel der vielen verschiedenen Dateien und Module ist sehr wichtig. Anpassungen und Fehlersuche können sonst sehr aufwändig werden.
Da wir Linux auf unseren «Build-Agents» und auch für den Betrieb der Container einsetzen, wird ein Grundwissen vorausgesetzt. Wir haben bisher Windows als Betriebssystem verwendet, weil Microsoft .NET- Applikationen initial dafür entwickelt wurden. Linux bietet viele Vorteile, hat aber einige Besonderheiten. Diese sind wichtig zu kennen. Zumal wir auf Windows-PCs entwickeln und die Container lokal im Docker und Windows Subsystem für Linux (WSL) laufen lassen.
Welche Programme nutzt du für deine tägliche Arbeit?
Fürs Entwickeln von C# Applikationen verwende ich Rider. Mit Visual Studio Code arbeite ich am Frontend-Code, aber auch an Helmcharts und Docker Skripten. Docker Desktop nutze ich, um die Container auf meinem PC zu erstellen und zu starten.
Ohne das Build-Framework Nx würde vieles aufwändiger – damit erstellen wir unsere Frontend- und Backendapplikationen, paketieren diese in Container, starten die Container lokal – mit den zugehörigen Abhängigkeiten – und deployen diese auch in die Container Registry.
Ganz wichtig ist für mich auch Lens. Damit habe ich schnell einen Überblick über unsere Kubernetes Cluster – welche Pods laufen, sind die Ressourcen korrekt verteilt. Auch bei der Fehlersuche kann ich damit schnell auf die Pods verbinden und die Analyse starten.
Wie ist die Arbeit mit den Helmcharts?
Mit Helmcharts werden die Pods, Netzwerke und andere Infrastruktur im Kubernetes Cluster beschrieben.
Die Helmcharts werden im YAML-Format erstellt. Da ist es wichtig, dass sie immer korrekt formatiert werden. Ist ein Leerzeichen an der falschen Stelle, gibt es einen Fehler – der nicht immer einfach zu finden ist.
Mit vielen Komponenten und Helmcharts kann es schnell unübersichtlich werden – deswegen sollten die Dateien sauber strukturiert und abgelegt werden. Dann können sie auch gut für andere Projekte verwendet werden.
Wichtig ist es auch, früh mit dem zukünftigen Betreiber der Applikation Kontakt aufzunehmen. Beim Übergeben und Aufspielen unserer Applikation und Container auf die Umgebung beim Betreiber müssen unsere Helmcharts mit den Konfigurationsdateien vom Betreiber kombiniert werden.
Das können beispielsweise Informationen zum Netzwerk beim Betreiber, aber auch zu den verfügbaren Ressourcen im Cluster für RAM und CPUs sein.
Die Helmcharts beschreiben dabei die Konfigurationsdateien mit Platzhaltern. In den values-Dateien werden dann die eigentlichen Werte konfiguriert. Beim Deployment in den Cluster werden diese Dateien dann kombiniert.
Was ist bei der Übergabe an den Betreiber zu beachten?
Hier sollte sehr früh der Kontakt gesucht werden und die Fragen rund ums Deployment und die Konfiguration der Umgebung geklärt werden wie beispielsweise:
Welche Vorgaben zur Infrastruktur und den Helmcharts gibt es?
Welche Software und Tools, und in welchen Versionen wird eingesetzt?
Wie ist das Netzwerk aufgebaut? Besonders der Umgang mit SSL-Zertifikaten und dem Ingres ist manchmal aufwändiger.
Gibt es andere Umsysteme, die angebunden werden sollen? Wenn beispielsweise über eine Schnittstelle eine andere Software integriert werden soll, bauen wir bei Nexplore einen «Mock» oder Simulator, damit wir es testen können. Auch muss in den Helmcharts dann die Konfiguration dafür entsprechend vorgesehen sein.
Wir suchen Verstärkung!
Wenn du auf dein letztes container-basiertes Projekt zurückschaust – würdest du es noch einmal machen?
Das letzte Projekt war eine Verwaltungsapplikation für eine Behörde. Dort haben wir zwei Module gebaut, zukünftig werden weitere dazu kommen.
Die Containerisierung bringt hier viele Vorteile und passt sehr gut zu den heutigen Anforderungen.
Was würdest du unseren (zukünftigen) Kunden mitgeben?
Mit Kubernetes und Cloud Native haben wir als Softwareentwickler mehr Möglichkeiten. So können wir andere Szenarien und Architekturen umsetzen, um die Applikation besser zu skalieren. Auch können wir Änderungen besser aufteilen und nur das anpassen, was nötig ist.
So können wir (Nexplore) auch mehr Betriebsverantwortung übernehmen und die Applikation bis auf die Test- und, wenn gewünscht, Produktivumgebung beim Kunden aufspielen.
Die erhöhte Komplexität und längere Phase bis zum ersten erfolgreichen Deployment darf nicht unterschätzt werden. Auch die Fehlersuche kann länger dauern.
Alles in allem bietet die Containerisierung aber mehr Vorteile und eine gute Basis für die zukünftige Weiterentwicklung der Applikation.
Containerbasierte Softwareentwicklung bei Nexplore
Bildnachweis: Gabriel Heinzer / unsplash