Wissenssilos steigern nicht die Produktivität. IT-Profis wissen das, und seitdem sie die DevOps-Bewegung ins Leben gerufen haben, hat in ihrer Branche ein Umdenken stattgefunden: Heute weiß jeder Manager und jeder C-Level-Akteur, dass Teamarbeit das A und O in Sachen Softwareentwicklung ist. Schade, dass es so lange gedauert hat – doch besser spät als nie. Die Folge ist, dass Unternehmen die Bildung von Wissenssilos mittlerweile durch die Implementierung verschiedener Taktiken, Strategien und Arbeitsmodelle unterbinden können. Eine dieser Taktiken – und das namensgebende Modell von DevOps – ist die enge Zusammenarbeit von
- Entwicklern (Devs) und
- IT-Administratoren (Ops).
Sie teilen sich bei diesem Ansatz die Verantwortung für den Erfolg des gesamten Softwareentwicklungsprozesses und eine strikte Trennung der Zuständigkeiten findet effektiv nicht mehr statt.
Abb. 1: In klassischen Szenarien des Software-Deployments herrscht eine strikte Trennung zwischen Entwicklung und IT-Betrieb
Dieser Paradigmenwechsel führt natürlich zu ungewohnten Veränderungen für beide Seiten und erfordert ein großes Maß an Vertrauen. Viele Entwickler und Administratoren erinnern sich zum Beispiel noch sehr gut an Zeiten, in denen die Betriebsumgebung für Entwickler absolut tabu war, quasi eine verbotene Zone. Diese hermetische Abriegelung ist für den DevOps-Ansatz nicht aufrechtzuerhalten: Auch die Devs müssen sich in der Produktionsumgebung, auf der die von ihnen geschriebene Anwendung laufen soll, bestens auskennen, sonst entstehen wieder Wissenssilos, die es zu vermeiden gilt.
Trotz aller möglichen Ressentiments haben Entwickler daher mittlerweile oft – wenn auch mit notwendigen Einschränkungen – Zugriff auf die Betriebsumgebung. Dieser Modus Operandi ist allerdings keine Formalität, denn das Ops-Team hat durchaus auch etwas davon. Treten Probleme auf, können Entwickler ihre Teamkollegen leichter und gezielter bei deren Behebung unterstützen. Die Last, eine Lösung zu finden, liegt somit nicht mehr allein beim IT-Betrieb.
Konsequenterweise führt die neue Offenheit zu einer reibungsloseren Softwareverteilung. Der enge Austausch und kontinuierliche Feedbackschleifen sorgen überdies für nachhaltige Prozess- und Testoptimierungen. All diese Verfahren profitieren vom Einsatz von Containern, die das Teamwork auf technologischer Ebene erleichtern.
Grundlagen zum Ablauf von Softwareprojekten
Um zu verstehen, warum Container und DevOps diese Probleme im Zusammenspiel lösen können, ist es wichtig, sich die Prozesse der Softwareentwicklung noch einmal vor Augen zu führen: Traditionell laufen Softwareprojekte nach ein und demselben Schema ab: Nach der Entwicklung und einem lokalen Testing durchlaufen die Anwendungsteile – heute sind Microservices-Architekturen gang und gäbe, daher „Teile“ – einen weitestgehend automatisieren Prozess, dessen Output das Software-Artefakt ist.
Nach dem Continuous-Integration-(CI-) oder auch Continuous-Delivery-(CD-)Prozess folgt ein Integrationstest, der aufdeckt, ob alle Teile der Anwendung einwandfrei miteinander kooperieren. Treten dabei Fehler auf, können Entwickler sie im Zuge der Tests beheben. Im Anschluss an den erfolgreichen Integrationstest endet die Arbeit der Devs im Normalfall und die Übergabe an das Ops-Team, das die Software dann auf der Produktionsumgebung ausrollt, markiert auch das Ende ihrer Verantwortlichkeit.
Allerdings kommt es nicht selten vor, dass Anwendungen auf den Rechnern der Entwickler und möglicherweise auch beim Integrationstest einwandfrei funktionieren und in der Produktionsumgebung dann ein Fehler nach dem anderen auftritt. Der Spruch „Es läuft auf meiner Maschine“ ist den meisten Tech-Experten wohl schon einmal untergekommen. Er rührt daher, dass sich die Workstations von Entwicklern teils fundamental von den Umgebungen für Integrationstests und der Produktion unterscheiden. Und da die Zuständigkeiten klar abgegrenzt sind, ist es im traditionellen Prozess nicht die Aufgabe der Entwickler, die Software in Produktion zum Laufen zu bringen.
Container + DevOps = Gamechanger
Genau an dieser Stelle hilft DevOps. Die enge Zusammenarbeit zwischen Entwicklern und IT-Betrieb ermöglicht dem Team, Probleme teilweise schon vor ihrem Auftreten zu erkennen und zu beheben. Das ist zwar nicht immer der Fall, aber definitiv häufiger als nach der traditionellen Methode. Zudem nimmt sie Reibung aus dem Prozess und schafft so eine produktivere Unternehmenskultur. Setzt das Team allerdings Container ein, wird DevOps zum wahren Gamechanger. Wer sich mit der Materie befasst hat, wird den Leitspruch von Docker kennen: „Build, Ship, Run“.
Abb. 2: Der Einsatz von Containern stärkt die Zusammenarbeit zwischen Dev- und Ops-Team. Außerdem kann das Zusammenspiel von Hardware und Software keine Fehlerquelle im Betrieb mehr sein
Das Motto des beliebten Tools gibt einen Hinweis darauf, was Container zu leisten vermögen, nämlich Software einfach zu erstellen und überall auszuführen. Container egalisieren die Unterschiede der verschiedenen Test- und Produktionsumgebungen, da sie die Software sauber von der Hardware entkoppeln. Somit sind Entwickler nicht mehr genötigt, ihre Anwendungen an eine bestimmte Hardware-Umgebung für den Betrieb anzupassen. Die Funktionalität der Anwendung ist somit gewährleistet – vorausgesetzt die Zielumgebung verfügt grundsätzlich über ausreichend Ressourcen für die Ausführung der Software. Prozess-Isolierung, Portabilität und unveränderliche („immutable“) Infrastrukturen sind die drei technologischen Konzepte, die der Container-Technologie zugrunde liegen.
Prozess-Isolierung
So unterschiedlich Softwareprozesse grundsätzlich auch sein mögen, sie alle haben einiges gemein, etwa individuelle Abhängigkeiten. Zudem benötigen sie je nach Anwendungsfall spezielle Dateien oder Librarys in einer bestimmten Version und konkurrieren um die System-Ressourcen. Mehrere Softwareprozesse auf einem einzigen Rechner abzubilden, ist daher schwierig. Die Lösung war lange Zeit, für jeden Prozess einen eigenen physikalischen Rechner bereitzustellen. Der Verwaltungsaufwand und die Kosten dafür wären für heutige Anwendungsfälle allerdings exorbitant und damit nicht praktikabel, weshalb Container eine willkommene Alternative sind.
Sie stellen quasi eine Sandbox für Prozesse dar und isolieren sie voneinander. Für die Software ist der Container quasi die Umgebung, in der sie läuft: Er enthält das nötige Dateisystem, alle relevanten Konfigurationen und Betriebssystem-Module, die für die Ausführung des Softwareprozesses nötig sind – das Container-Image ersetzt somit das Artefakt, das Entwickler sonst am Ende der CI/CD-Pipeline erhalten. Auf den Zielsystemen muss lediglich die passende Container-Runtime laufen, damit auch die Software läuft. Diese Entkopplung von Hard- und Software führt logischerweise nicht dazu, dass auf magische Weise neue physische CPU- oder RAM-Ressourcen bereitstehen. Allerdings blockieren sich die einzelnen Prozesse auf diese Weise zumindest nicht mehr gegenseitig, indem sie auf die gleichen Ressourcen zugreifen – der Konkurrenzkampf findet somit nicht mehr statt.
Natürlich bestehen dennoch Unterschiede zwischen den verschiedenen IT-Umgebungen, doch sie sind eher marginal. So erhalten auch im containerisierten Entwicklungsmodus Testsysteme keinen Zugriff auf die gleichen Datenbanken wie das Produktionssystem. Die Prozess-Isolierung ebnet darüber hinaus den Weg für die Portabilität, des zweiten Konzepts der Container-Technologie.
Portabilität
Da die Software-Prozesse in ihren Containern isoliert an keine Software-Umgebung mehr gebunden sind, benötigen sie für eine volle Portabilität nur noch die Unabhängigkeit von der nötigen Hardware. Normalerweise bestehen hardwarebezogene Dependencys insbesondere zu persistentem Plattenspeicher oder dem Netzwerk-Routing. Container bieten für ihre Entkopplung aber ebenfalls genug Mechanismen, sodass deren Images grundsätzlich auf jeglicher Hard- und Software laufen, die nötige Runtime auf den Systemen immer vorausgesetzt.
Die Portabilität, die Container garantieren, macht den IT-Betrieb hochkomfortabel und bietet viele Möglichkeiten für die Automatisierung und Ausfallsicherheit. Fällt eine Hardware-Instanz beispielsweise aus, startet das System bei entsprechender Voreinstellung die darauf laufenden Container vollautomatisch auf einer anderen Maschine neu. Das ginge nicht, wenn die Software mit Abhängigkeiten zu bestimmten Komponenten eines Systems behaftet wäre. Früher mussten Administratoren für eine solche Ausfallsicherheit die exakt gleiche Software mehrfach auf verschiedenen Maschinen vorinstallieren, also Ausfälle quasi jederzeit antizipieren. Gleichermaßen einfach gestaltet sich das Ersetzen veralteter Hardware: Anstatt umfangreiche Neuinstallationen und eine Anpassung der Software für das neue System durchzuführen, müssen Administratoren lediglich die Container-Runtime auf dem neuen System installieren und die Container-Images von der alten auf die neue Maschine übertragen. Dieses Verfahren spart sehr viel Zeit und Geld.
Unveränderliche Infrastruktur
Das dritte und letzte Konzept, auf dem die Container-Technologie basiert, hängt mit dem Erstellen der Container zusammen. In klassischen IT-Szenarien legen Administratoren manuell auf dem Rechner die Umgebung für die Softwareprozesse an. Bei der Nutzung der Container-Technologie konfiguriert ein Skript das Container-Image – und damit die virtuelle Maschine, auf der die Software schließlich laufen wird. Die Container selbst sind immer unveränderlich oder „immutable“. Müssen Entwickler und Administratoren Veränderungen am Container vornehmen oder die in ihm laufende Software aktualisieren, verändern sie einfach das Skript, nicht die Software oder den Container. Sind die Änderungen vorgenommen, starten sie das Skript, welches dann einen neuen Container baut, der den alten ersetzt.
Was geradezu verschwenderisch klingt, hat einen praktischen Sinn. Jahrzehntelang beobachtete der IT-Betrieb, dass manuell verwaltete Server irgendwann schlicht nicht mehr rekonstruierbar waren – nach einer Zeit wussten selbst diejenigen, die die Server einst erschaffen hatten, nicht mehr wie – oder manchmal gar „warum“ – sie funktionieren. Sind Container im Einsatz, sind alle Änderungen leicht nachzuvollziehen, da das Ops-Team ja nicht mehr die Maschinen, sondern nur die Skripte verändert. So können sie im Zweifel Server genauso einfach ersetzen wie die Container, die auf ihnen laufen. Die Skripte verwalten die Experten in der Regel via Versionskontrolle. Git ist heutzutage der De-facto-Standard, um die Änderungen am Skript jederzeit und lückenlos reproduzierbar zu machen.
Container in der Praxis
Container sorgen dafür, dass der Unterschied zwischen Entwicklungs-, Test- und Produktionsumgebung keinesfalls der Grund für Probleme beim Betrieb einer Software sein können. Die drei Konzepte Unabhängigkeit, Unveränderlichkeit und Portabilität sind dafür die Garanten. Ein weiterer Vorteil ist, dass Entwickler das Container-Image aus der Produktion ebenso in- und auswendig kennen wie das von ihnen im Test eingesetzte: Es ist nämlich das exakt Gleiche. Das erleichtert nicht nur die Fehleranalyse, sondern eröffnet Devs auch die Möglichkeit, Tools für das Finden von Bugs direkt in die Container zu implementieren.
Darüber hinaus sind Container recht kurzlebig und enthalten in der Regel lediglich einen einzigen Softwareprozess. Ops-Experten sehen es daher – anders als früher – nicht so eng, wenn Entwickler auch mal in Containern, die sich bereits in Produktion befinden, nach Fehlern suchen und dabei eventuell eine Konfiguration verändern. Führen diese Veränderungen zu weiteren Fehlern, ist ein Neustart des Containers mit der funktionierenden Einstellung kein größeres Problem. Durch diese Kapazitäten fördert die Container-Technologie die Zusammenarbeit und das Vertrauen zwischen Devs und Ops – und erleichtert die Umsetzung von DevOps-Initiativen.
Nächster Halt: Kubernetes
Sind Container ein Gamechanger, ist der Einsatz von Container-Orchestrierungs-Plattformen wie Kubernetes eine Revolution. Neben dem Container-Betrieb bieten die Plattformen noch einen interessanten Vorteil: feste Zuständigkeitsbereiche für Entwickler und Administratoren. Was zunächst wie ein Rückschritt klingt, ist auf den zweiten Blick doch sinnvoll, denn in diesem Fall sind die Bereiche den Anforderungen der Abteilungen angepasst. Dank einer Abstraktionsebene ist die Verwaltung der Betriebsressourcen durch die Entwickler möglich. Sie stellt alle notwendigen High-Level-Funktionalitäten dafür zur Verfügung, sodass das Dev-Team sich praktisch ohne Administratoren um den Betrieb ihres Softwareprojekts kümmern kann – frei nach dem beliebten Motto: „You build it, you run it!“ Unter der sprichwörtlichen Haube arbeitet das Ops-Team daran, die für diese Funktionalität notwendigen Dienste bereitzustellen.
Abb. 3: Container-Orchestrierungs-Plattformen ebnen den Weg für eine völlig neue Aufteilung von Zuständigkeitsbereichen innerhalb von DevOps-Teams
Bevor Kubernetes oder eine vergleichbare Plattform einsatzbereit ist, müssen DevOps-Teams allerdings ein wenig Vorarbeit leisten. Zum Beispiel müssen sie den Deployment-Prozess für ihre Software auf allen Ebenen via Continuous-Deployment-Pipelines automatisieren. In die Entwicklungsteams sollte zudem ein DevOps-Engineer integriert werden, der nicht nur die Arbeitsweise der Entwickler kennt, sondern sich auch mit den Betriebsressourcen bestens auskennt. Diese vielschichtigen Arbeitsabläufe einzustudieren und komplexe Technologien für Entwicklung und Deployment von Software einzusetzen, ist einfacher, wenn DevOps-Kultur im Unternehmen gelebt wird. Sie erleichtert den dringend nötigen Wissensaustausch zwischen den Abteilungen.
