F: Hi Martin, was ist deine Position bei in2code und was hast du bei h-ka.de gemacht?
Als CTO bei in2code und kümmere mich hauptsächlich um die Technik im Hintergrund und um unsere eigene technische Weiterentwicklung. Hierbei ist es eine meiner Hauptaufgaben, das DevOps-Prinzip in den Köpfen aller Kollegen zu fördern und zu verfestigen.
Die h-ka.de ist ein Projekt, bei dem wir komplett neue Wege gehen wollten. Vor allem im Bereich der Server im Rechenzentrum der Hochschule, die von uns installiert, konfiguriert und gewartet werden. Unser Ziel war und ist ein ganzheitlicher DevOps-Ansatz. Dazu gehörten die Bereiche Infrastructure-as-Code (IaC) und vor allem eine vollständige Automatisierung mit Gitlab CI (Continous Integration) und die Containerisierung des kompletten Software-Stacks auf Basis von Docker. Mein Job ist, das gemeinsam mit den Kollegen zu konzipieren und natürlich auch umzusetzen.
F: Wer hat alles an dem Infrastruktur-Projekt mitgearbeitet?
Sehr viele! Durch den DevOps-Ansatz ist es zwingend notwendig, das sich Entwickler und Systemadministratoren eng abstimmen. Somit war initial das komplette Administratorenteam und ein Entwickler von Anfang an mit der Konzeption und Umsetzung beschäftigt. Nachdem die Grundzüge der Infrastruktur definiert und zum Teil auch umgesetzt waren, kamen der Reihe nach immer mehr Entwickler hinzu.
F: Was hat dieses Projekt so besonders gemacht?
Ziel war ein ganzheitlicher Ansatz, der alle Beteiligten, auch über die verschiedenen Zuständigkeitsbereiche wie Serverbetriebssysteme und Anwendungsentwicklung hinaus, gemeinsam am selben Code arbeiten lässt. Das haben wir letztlich dann auch geschafft.
F: Welche Vorteile ergeben sich aus dem Konstrukt?
Der größte Vorteil ist die Gesamtheit des Projekts an einer Stelle. Damit sind wir in der Lage, Änderungen, welche etwa übergreifend zwischen Serverkonfiguration und Anwendung sind, zeitgleich auf die Server auszurollen und auszuführen. Ein Beispiel wäre etwa die Anpassung einer PHP-Version, die wir nun zentral an einem einzigen Punkt einstellen können. Wenn wir das Projekt nun bauen, testen und deployen lassen, wird vollautomatisiert der Server vorbereitet und die Anwendung mit dieser geänderten PHP-Version ausgerollt. Da wir natürlich mit verschiedenen Instanzen arbeiten, wie etwa einer Develop-. Release- und Liveinstanz, können wir solche Anpassungen auch nur über eine einzige Instanz ausrollen und testen. Konkret heißt das auch, dass Entwickler lokal, Product Owner auf einem Release-System und die Redakteure auf dem Live-System alle mit der exakt gleichen Serverkonfiguration arbeiten. Spezifische Fehler können so nun auch schon früh erkannt und beseitigt werden.
Ein weiterer Vorteil durch den Infrastructure-as-Code ist die immer aktuelle Dokumentation. Da keine Einstellungen etwa auf dem Server über einen Befehl auf der Kommandozeile von einer Person angepasst werden, sondern immer über die automatische Provisionierung erfolgt, sind diese immer von allen Beteiligten nachvollziehbar. Auch der sogenannte Schneeflocken-Effekt wird dadurch vermieden. Dieser beschreibt, dass sich die Konfigurationen von ähnlichen Servern nach längerer Laufzeit immer weiter voneinander unterscheiden.
Zusätzlich ist es durch die Verwendung von Docker als Container-Engine möglich, einzelne Instanzen auf unterschiedlichen Software-Versionen laufen zu lassen. Die Instanzen sind somit nicht davon abhängig, welche Version einer Software direkt auf dem Server installiert ist, sondern bringt die jeweils benötigte Version abgekapselt in einem eigenen Container mit.
F: Du klingst ja richtig begeistert. Welche Hürden gab es denn bei der Umsetzung?
Es gab zwar keine größeren Schwierigkeiten, dafür aber eine Menge kleinerer Probleme (lacht). Aber das bringt ein Projekt in dieser Größenordnung einfach mit sich. Rückblickend ist es noch wichtiger, dass die Kommunikation zwischen den verschiedenen Teams und den unterschiedlichen Verantwortungsgebieten gut funktioniert.
Übrigens: Ich bekomme immer wieder die Frage gestellt, warum wir uns für diesen Weg entschieden haben. Da lautet meine Antwort dann einfach: "Es ist auch komplex, wenn wir es anders machen. Aber jetzt machen wir die Komplexität sichtbar."
F: Hast du noch einen Tipp für ähnliche Projekte?
Ich würde genau so einen Weg wieder gehen: Infrastructure-as-Code und die damit verbundene Containerisierung und Vollautomatisierung. Je nach Frequentierung würde ich bei großen Seiten aber zu einem Kubernetes-Cluster raten, um Lasten besser verteilen zu können und um mögliche Ausfallzeiten zu verringern.