Next Level Co-Op Container erhöhen die Effizienz von DevOps

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

ConSol Consulting & Solutions Software GmbH

Viele Unternehmen verzichten noch immer darauf, DevOps einzuführen. Andere trauen sich nicht an Container heran. Dabei steigert gerade die Kombination beider Technologien die Produktivität zwischen Entwicklern und IT-Betrieb.

Software-Entwicklung ist Teamarbeit, das war sie schon immer. Doch seitdem der DevOps-Ansatz Schule macht, hat sich auch das Verständnis der Industrie von der innerbetrieblichen Zusammenarbeit nachhaltig verändert.

Software-Unternehmen versuchen heute, Technologie- und Wissenssilos möglichst abzubauen, denn sie verursachen oft Probleme. Im Kern geht es bei DevOps also darum, dass Developer und IT-Betrieb (Operations) einen kompletten Software-Entwicklungsprozess gemeinsam verantworten, ohne ihre Zuständigkeiten strikt zu trennen.

Damit DevOps funktioniert, ist Vertrauen notwendig. Früher war die Betriebsumgebung beinahe hermetisch abgeriegelt und für Devs eine No-Go-Area. Heute ist es hingegen üblich, dass auch Entwickler unter kontrollierten Bedingungen auf sie Zugriff haben. Das Ops-Team kann so qualifizierte Hilfe von Entwicklern in Anspruch nehmen und steht nicht allein für Probleme beim Deployment der Software in der Produktion gerade.

DevOps sorgt so für eine effektivere und schnellere Lösung aller Schwierigkeiten und ermöglicht eine nachhaltige Ursachenbekämpfung, etwa in Form von Verbesserungen im Gesamtprozess und beim Testing. Noch besser ist es, wenn auf technischer Seite Container die Zusammenarbeit unterstützen.

„Läuft auf meiner Maschine“

Um zu verstehen, wie Container die Zusammenarbeit zwischen Devs und Ops positiv beeinflussen, ist ein Blick auf die Struktur eines Software-Projektes nötig. Gewöhnlich beginnt es in der Entwicklungsabteilung, die eine Software schreibt. Das Dev-Team programmiert die einzelnen Teile einer Anwendung und testet sie zunächst lokal.

Anschließend durchläuft die Software einen automatisierten Continuous-Integration-(CI)- beziehungsweise Continuous-Delivery-(CD)-Prozess, an dessen Ende ein Software-Artefakt entsteht, das alle Teile der fertigen Software enthält. Die Entwickler installieren das Software-Artefakt schließlich auf einem System für Integrations-Tests.

Dort prüft die Entwicklungsabteilung die im Artefakt enthaltenen Anwendungsbestandteile auf Bugs beim Zusammenspiel mit dem Rest der Software. Funktioniert die Anwendung auch im Integrations-Test ordnungsgemäß, übergeben die Devs das Artefakt an das Ops-Team, das die Software auf der Produktions-Umgebung ausrollt.

Die drei verschiedenen Umgebungen für lokale Tests, Integrations-Test und Produktion sind naturgemäß leicht unterschiedlich. Insbesondere die persönlichen Workstations der Entwickler haben wenig mit einem Server gemein. Aber auch die Integrations-Test-Umgebung und die Produktions-Umgebung sind selten identisch. Das kann zum einen an manuellen Konfigurationen liegen, aber auch daran, dass die Entwickler auf einem Integrations-System mehrere Softwares mit unterschiedlichen Hardwareanforderungen testen.

Genau hier liegt das Problem: Es kommt sehr häufig vor, dass Software die lokalen Tests und die Integrations-Tests der Entwickler fehlerfrei durchläuft, nur um dann in Produktion nicht richtig zu funktionieren. Daher kommt auch der berühmte Spruch „It works on my machine“.

Einmal erstellen, überall ausführen

Das DevOps-Prinzip hilft dabei, Reibung aus dem Entwicklungsprozess zu nehmen. Wobei DevOps allerdings nicht unbedingt hilft, ist Probleme zu erkennen, bevor die Software oder die neuen Features auf der Produktions-Umgebung ausgerollt werden. An dieser Stelle spielen Container eine gewichtige Rolle.

Das Prinzip, das der Container-Technologie zugrunde liegt, verdeutlicht der Leitspruch von Docker, dem wohl bekanntesten Container-Tool: „Build, Ship, Run“. Container machen die Unterschiede der verschiedenen Test- und Produktions-Umgebungen irrelevant, denn statt einem speziell für eine Umgebung erstellten Artefakt kommt ein Container-Image zum Einsatz. Dieses enthält alle relevanten Konfigurationen und Betriebssystem-Module.

Oder anders ausgedrückt: Für die Software selbst ist der Container die Umgebung. Voraussetzung für den Container-Betrieb ist lediglich eine Container-Runtime auf den Zielsystemen. Die einzigen Unterschiede bestehen ab diesen Zeitpunkt aus gewollt unterschiedlichen Detail-Konfigurationen, immerhin soll auch im containerisierten Entwicklungszyklus kein Testsystem auf die gleichen Datenbanken wie das Produktions-System zugreifen.

Container stellen unter anderem sicher, dass Probleme in der Produktion keinesfalls vom Unterschied zu den Test-Umgebungen herrühren kann. Außerdem kennen die Entwickler das eingesetzte Container-Image sehr gut – es handelt sich dabei um das exakt gleiche, mit dem sie vorher ihre Tests durchgeführt haben. Beide Umstände erleichtern die Fehleranalyse deutlich und die Entwickler können in die Container zusätzliche Features implementieren, die eine Fehleranalyse vereinfachen.

Container sind überdies nur eine recht kurzlebige Instanz und enthalten auch nur einen einzigen Software-Prozess. Daher ist es womöglich nicht schlimm, wenn die Entwickler in der Produktion Fehlersuche betreiben und dabei eventuell die Konfiguration verändern, was normalerweise das Hoheitsgebiet des Betriebs ist. Gibt es Probleme bei der Konfiguration, lassen sich Container sehr schnell und einfach durch neue ersetzen, die die richtige Konfiguration enthalten.

Der IT-Betrieb profitiert von Containern also insofern als sich das Ops-Team leichter damit tut, Entwicklern Produktionszugriff zu ermöglichen. Und – das sei an dieser Stelle noch einmal erwähnt – Vertrauen ist das A und O für eine gute DevOps-Praxis.

Kubernetes verändert alles

Noch einen Schritt weiter gehen DevOps-Teams, wenn sie eine Container-Orchestrierungs-Plattform wie Kubernetes einsetzen. Diese Plattformen bieten – neben dem puren Container-Betrieb – einen weiteren interessanten Vorteil: Devs und Ops bekommen durch sie wieder feste Zuständigkeitsbereiche.

Das klingt zunächst wie ein Rückschritt, allerdings sind diese Bereiche in diesem Fall auf die Anforderungen der beiden Parteien maßgeschneidert. Dafür sorgt eine Abstraktionsebene, die die Betriebsressourcen für die Verwaltung durch das Dev-Team aufbereitet und die notwendigen High-Level-Funktionalitäten bereits „out of the box“ zur Verfügung stellt.

Im Klartext bedeutet das, dass das Dev-Team den Betrieb für ihr eigenes Projekt weitestgehend im Alleingang managen kann. Das Ops-Team sorgt unterhalb dieser Ebene dafür, dass die notwendigen Dienste, die die Basis für diese Abstraktionsebene bilden, verfügbar sind. So etwas ist nur auf Basis von Containern möglich, die die notwendige Trennung der Software von der Hardware sicherstellen. Erst durch die Vermeidung dieser Abhängigkeit ist es möglich, den Betrieb so weit zu abstrahieren.

Um mit Kubernetes oder ähnlichen Plattformen durchstarten zu können, ist allerdings einiges an Vorarbeit nötig. So sollte beispielsweise der Deployment-Prozess auf der Integrations- und Produktions-Umgebung vollständig durch einen Continuous-Deployment-Prozess automatisiert werden. Zudem braucht das Dev-Team mindestens einen DevOps-Engineer, der sowohl den Arbeitsprozess in der Entwicklung kennt als auch die Arbeit mit den Betriebsressourcen. Im Idealfall sorgt die richtige DevOps-Kultur exakt an dieser Stelle für den notwendigen Wissensaustausch zwischen Ops-Team und Dev-Team.

* Oliver Weise, Principal Software Engineer bei Consol.

(ID:48368737)