Neun Best-Practices für Container

IT-Prioritäten verschieben sich: Waren es früher Konsolidierung und Kostenreduktion, stehen heute Agilität und Geschwindigkeit ganz oben auf der Agenda. Neue IT-Modelle, Entwicklungs- und Betriebsprozesse wie Container, DevOps und Microservices gewinnen daher zunehmend an Bedeutung.

Die Vorteile von Containern liegen auf der Hand: Erstens definieren sie ein einheitliches Format für Applikationen, die deshalb erheblich schneller produktiv eingesetzt werden können (Time-to-Market), zweitens kapseln Container Anwendungen von der darunterliegenden Hardware und machen sie deshalb wesentlich portabler. Die Gleichartigkeit von Container-basierten Anwendungen beim Starten, Stoppen und dem Auslesen von Metriken und Logs bildet die Basis effizienter Betriebsprozesse. Außerdem benötigen Container keinen Hypervisor, sondern nutzen Betriebssystemfunktionen, sodass sie sehr ressourcenschonend und schneller im Vergleich zu virtuellen Maschinen
arbeiten (Abb. 1). Trotz all dieser Vorteile fällt es Unternehmen nach wie vor schwer, Container-Technologien einzuführen und sie in die vorhandene IT-Systemlandschaft zu integrieren.

Einer der Gründe dafür: Die Container-Technologie erfordert einen grundlegenden Wandel, denn das Silodenken zwischen der Software-Entwicklung, der Storage- und Netzwerk-Administration und dem Server-Betrieb muss überwunden werden. Wenn neue Software-Releases nach dem DevOps-Modell schneller und häufiger bereitgestellt werden sollen, müssen bei der Integration von Container-Technologien in die Unternehmens-IT vorhandene Prozesse angepasst und neue etabliert werden. Neun Best-Practices unterstützen Unternehmen bei der Einführung der Container-Technologie.

VMs und Container - Linux-Container teilen sich einen Container-Host und Kernel und verwenden gleichzeitig Kernel-Technologien wie cgroups, SELinux und Kernel-Namensräume, sodass ein Container weder auf die anderen Container, die auf demselben Host laufen, noch auf den Host selbst zugreifen oder diese beeinflussen kann (Quelle: Red Hat). (Abb. 1)

VMs und Container – Linux-Container teilen sich einen Container-Host und Kernel und verwenden gleichzeitig Kernel-Technologien wie cgroups, SELinux und Kernel-Namensräume, sodass ein Container weder auf die anderen Container, die auf demselben Host laufen, noch auf den Host selbst zugreifen oder diese beeinflussen kann (Quelle: Red Hat). (Abb. 1)

1. Transparenz herstellen und Wertschöpfung definieren

Ein wichtiger Startpunkt besteht darin, dass alle Beteiligten aus der Software-Entwicklung und dem IT-Betrieb ein gemeinsames Verständnis schaffen, was es heißt, Software in den IT-Betrieb zu überführen. Entscheidend ist dabei der Unterschied zwischen Lead-Time und Processing-Time. Die Lead-Time beginnt mit der Spezifikation einer Anforderung und endet, wenn der Auftrag erledigt ist. Die Processing-Time läuft erst dann, wenn die eigentliche Arbeit anfängt; Liegezeiten zählen nicht dazu. Je kürzer die Durchlaufzeit, desto besser.

Dazu gehört eine Klärung folgender Fragen: Welcher Schritt im Prozess dauert wie lange? Wie viel Zeit vergeht, bis eine bestimmte Funktion in den produktiven Betrieb eingeführt wird? In der traditionellen Software-Entwicklung kann das einige Wochen oder gar Monate dauern. Relevant ist die Zeit, bis die Software produktiv läuft und einen Nutzen erzielt. In vielen Fällen ist bislang der Prozess der Software-Entwicklung eine Black-Box. Durch eine Visualisierung wird der Prozess transparent: Welche Schritte gibt es? Welches Team ist wofür zuständig? Wo gibt es Liegezeiten? Eines der Werkzeuge dafür ist Value-Stream-Mapping (VSM), bei der die Wertschöpfungskette dargestellt wird.

2. Grundprinzipien effizienter Prozesse berücksichtigen

Value-Stream-Mapping ist eine Methode, die ihren Weg aus der Fertigung in die Software-Entwicklung gefunden hat und kommt nun auch immer häufiger bei der Software-Entwicklung zum Einsatz. Die entsprechenden Tools zeichnen den Materialund Datenfluss vom Lieferanten bis zu den Kunden nach. Damit sind auf einen Blick Ursachen für Verzögerungen im Workflow erkennbar, aber auch Engpässe, die sich auf den Produktionsprozess auswirken. Entstanden ist VSM in engem Zusammenhang mit dem Toyota-Production-System, bei dem es unter anderem darum geht, wie Prozesse im Allgemeinen optimiert werden können.

Eine der Aktivitäten besteht darin, Arbeitsschritte sichtbar zu machen. In der agilen Software-Entwicklung gibt es dazu Techniken wie das Kanban-Board, mit dem sich die Arbeitseinheiten visualisieren lassen. Das gibt es beispielsweise auch in digitaler Form mit der Projektmanagement-Software Trello. Eine wichtige Kenngröße ist Work-in-Progress und die Ermittlung, wie viele und welche Arbeitsschritte parallel stattfinden. Idealerweise sollten so wenig Schritte wie möglich parallel durchgeführt werden. Ein weiterer Aspekt ist, die Größe der
Software-Pakete zu begrenzen. Je größer die Pakete, desto größer auch das Risiko, dass sich Fehler einschleichen, die erst im produktiven Einsatz bemerkt werden – und nur aufwendig zu beheben sind. Werden kleinere Pakete in die Produktion gebracht, sinkt das Fehlerrisiko.

3. Geeignetes Pilotprojekt auswählen

Bei einem Greenfield-Projekt gestaltet sich aus organisatorischer Sicht die Einführung von Container-Technologien einfacher als bei einem Brownfield-Projekt, bei dem manchmal mit allen Mitteln versucht wird, vorhandene Applikationen in die Container-Welt zu migrieren. Vor allem aber sind bei neuen Projekten die Komplexität und die Abhängigkeiten geringer und damit auch die Risiken des Scheiterns. Zudem hat es sich in der Praxis bewährt, dass in der Anfangsphase der Container-Einführung eher Entwickler beteiligt sein sollten, die als innovativ gelten und neuen Technologien gegenüber aufgeschlossen sind.

Von der technischen Seite gesehen, eignen sich für ein Pilotprojekt häufig Web-basierte Applikationen. Diese sind in der Regel einfacher strukturiert und lassen sich in Programmiersprachen wie Java, PHP oder Perl erstellen. Zudem sollte die Anwendung nicht zu viele Komponenten haben und außerdem sollte diese möglichst wenig zustandsbehaftet sein (Stateless vs. Stateful). Ideale Voraussetzungen liegen vor, wenn die IT-Abteilung mit Microservices experimentiert. Microservices und Container passen perfekt zusammen. Aber auch für Brownfield-Anwendungen werden Container immer interessanter: Selbst die Anbieter von Standard-Software orientieren sich immer stärker
in Richtung Container.

4. DevOps-Kultur etablieren

Grundsätzlich gilt: Es existiert keine universell gültige DevOps-Definition. Allerdings gibt es eine Reihe von wichtigen Rahmenbedingungen.
Dazu gehören die offene Kommunikation zwischen den Team-Mitgliedern, ein gutes Vertrauensverhältnis und die offene Aussprache über Fehler. In der DevOps-Kultur gelten Fehler als Möglichkeiten zur Verbesserung. Es wird versucht, Fehler mit Swarming-Technologien zu beheben. Wenn etwa ein Software-Release in der Produktion nicht funktioniert, wird die Weiterentwicklung gestoppt bis das Problem durch das gesamte Team, bestehend aus Entwicklung und Betrieb, gelöst wird. Vor allem aber soll aus dem Vorfall gelernt werden, um in künftigen Situationen schneller reagieren zu können. Dazu gehört auch, schnell und regelmäßig Feedback zwischen allen Beteiligten auszutauschen.

Dieser Lösungsweg stammt ebenfalls aus dem Toyota-Production-System, bei dem es eine sogenannte Andon-Cord gibt. Kommt es im Produktionsprozess zu Problemen, zieht ein Mitarbeiter diese Reißleine. Das Grundprinzip dahinter: Es wird sofort auf Fehler reagiert. Jeder Mitarbeiter hat in diesem Prozess die gesamte Wertschöpfung und nicht nur seine „kleine Insel“ im Blick. Das unterscheidet sich stark davon, wie heute noch in siloartigen Organisationsformen in der IT gearbeitet wird. Hier wird bestenfalls das eigene Silo, nicht aber das große Ganze optimiert. Gerade die Einführung der Container-Technologie bietet die Möglichkeit, das Silodenken zu überwinden. Denn bei der Nutzung von Containern müssen Mitarbeiter aus der Entwicklung, dem Storage- und dem Networking-Bereich zusammenarbeiten.

5. Schrittweise Automatisierung einführen

Dadurch, dass Container, bedingt durch die zugrundeliegende Technologie und das einheitliche Format, Anwendungen gleichartig aussehen lassen, bieten sie die ideale Grundlage für die Automatisierung. Es muss beispielsweise nur einmal ein Prozess implementiert werden, um Daten zu verschieben oder Artefakte zu deployen. Vor allem aber lässt sich die Automatisierung auch schrittweise einführen.

Die IT-Abteilung kann beispielsweise mit Continuous-Integration (CI) – also mit dem täglichen Erstellen von lauffähigen Software-Paketen – anfangen. Der nächste Schritt ist der Aufbau von Continuous-Deployment (CD)-Pipelines, um Container von einer Betriebsumgebung in die nächste zu bringen (Abb. 2). Dazu kommt schließlich das automatisierte Testen. Hier wird mit Unit-Tests gearbeitet, um die Qualität, Wiederholbarkeit und Verlässlichkeit beim Testen zu optimieren. CI und CD funktionieren mit Containern deutlich einfacher als mit traditionellen Mitteln; hier nutzt jede Umgebung ihre eigenen Verfahren. Container ermöglichen es, CI und CD für sehr viele Applikationen auf eine einheitliche und einfache Art und Weise zu betreiben.

Continuous-Delivery-Pipelinie - Durch eine Kombination von Red Hat Ansible Automation und Red Hat OpenShift Container Platform können Unternehmen die Bereitstellung und Verteilung hybrider Anwendungen automatisieren, und diese auf OpenShift sowie auf anderen On-Premises- und Cloud-Plattformen implementieren und betreiben (Quelle: Red Hat). (Abb. 2)

Continuous-Delivery-Pipelinie – Durch eine Kombination von Red Hat Ansible Automation und Red Hat OpenShift Container Platform können Unternehmen die Bereitstellung und Verteilung hybrider Anwendungen automatisieren, und diese auf OpenShift sowie auf anderen On-Premises- und Cloud-Plattformen implementieren und betreiben (Quelle: Red Hat). (Abb. 2)

6. Grundlegende Sicherheitsmaßnahmen berücksichtigen
Als die Container-Technologie vor einigen Jahren aufkam, hat man sich anfangs noch nicht so stark wie heute mit dem Thema Sicherheit beschäftigt. Ein Applikations-Container verschnürt bekanntlich den Programm-Code zusammen mit dessen Laufzeitabhängigkeiten in einem Paket. Es ist daher unabdingbar, dass die zugehörigen Images und das Container-Betriebssystem regelmäßig mit den neuesten Sicherheits-Updates aktualisiert werden.
Darüber hinaus muss der Kernel Funktionen bieten, die einen sachgemäßen Umfang von Isolation und Begrenzung bieten. Diese Anforderungen erfüllen etwa SELinux, als integraler Bestandteil von Red Hat Enterprise-Linux, Seccomp oder Namespaces. SELinux isoliert Container voneinander und erlaubt nur den Zugriff auf notwendige Ressourcen. Zudem befasst sich seit Neustem auch das BSI (Bundesamt für Sicherheit in der Informationstechnik) mit der Container-Sicherheit und hat dazu einen Grundschutzbaustein entworfen.
7. Auf Standards setzen
Innerhalb weniger Jahre haben sich Container-Technologien von einem Nischenstatus zu einem zentralen Faktor für die Applikations-
Bereitstellung weiterentwickelt. Das Herzstück dabei sind Linux-Container auf Basis des OCI-Formatd (Open Container Initiative), das von vielen führenden IT-Unternehmen, darunter Amazon, Google, Hewlett Packard Enterprise, IBM, Microsoft und Red Hat unterstützt wird. Das OCI-Container-Format ist aus dem Docker-Format hervorgegangen und gilt in der Zwischenzeit als Industriestandard unter Schirmherrschaft der Linux-Foundation. Nicht nur Software-Hersteller, sondern auch Unternehmen, die mit Linux-Containern Anwendungen entwickeln und betreiben, beteiligen sich aktiv in der Linux-Foundation.
OCI besteht erstens aus einem Format für die Container-Images selbst – ein Pendant zu den Docker-Images des Unternehmens Docker.
Dazu kommt zweitens die sogenannte Runtime-Specification, die das Laufzeit-Management von Containern definiert.
Mitte 2017 publizierte die OCI die Version 1.0 der Standards für die Runtime-Spezifikation und die Image-Format-Spezifikation für Linux-Container. Mit diesen Standards als Basis können Container-Anbieter, aber auch Unternehmen, Lösungen entwickeln, die erweiterte Funktionen enthalten und dennoch miteinander kompatibel sind.
8. Eine Orchestrierungsplattform einsetzen
Die Standardisierung ist darüber hinaus auch ein Trend bei der Orchestrierungsplattform. Anfangs hatte nahezu jeder Anbieter seine eigene Container-Orchestrierungsplattform. In der Zwischenzeit hat sich Kubernetes als Industriestandard durchgesetzt. Kubernetes ermöglicht es, Container auf Clustern physischer, virtueller Maschinen oder auch in der Cloud bereitzustellen und auszuführen.
Linux und eine Container-Runtime bilden Schlüsseltechnologien für Kubernetes. Linux betreibt die Container und ist für das Ressourcen-Management und die Sicherheit zuständig. Die Container-Runtime verwaltet die Instanziierung und die Ressourcenzuweisung auf dem Host. Red Hat OpenShift Container-Platform beispielsweise kombiniert Enterprise-Grade-Kubernetes mit leistungsstarken Funktionen für die Erstellung, die Implementierung und das Management von Applikations-Containern (Abb. 3).
Pakettierung einer Applikation als Container mit Red Hat OpenShift (Quelle: Red Hat). (Abb. 3)

Pakettierung einer Applikation als Container mit Red Hat OpenShift (Quelle: Red Hat). (Abb. 3)

9. Mit anderen Anwendern vernetzen
Um mit Applikations-Containern erfolgreich zu sein, ist es grundsätzlich wichtig, im Unternehmen eine DevOps-Kultur aufzubauen. Das haben viele Anwender erkannt und beteiligen sich daher zusätzlich an den unterschiedlichsten Meetups und Anwender-Communities oder gründeten bei Bedarf selbst welche.
Ziel dabei ist es, Erfahrungen in der eigenen Organisation, aber auch unternehmensübergreifend auszutauschen. Möglichkeiten dafür bieten darüber hinaus vielfältige Open-Source-Communities rund um Container-Technologien, die sich durch ein offenes Modell und die enge Zusammenarbeit von Software-Herstellern, Anwendern und freiberuflichen Open-Source-Entwicklern auszeichnen. Wie geht man bestimmte Herausforderungen an? Welche konkreten Erfahrungen haben andere Entwickler gemacht? Welche Lösungswege haben sie bei bestimmten Problemen gefunden? Wie lassen sich Innovationen vorantreiben?
Die Kubernetes-Community befasst sich beispielsweise mit Cluster-Stability, Extensibility, Service-Automation, Security-Improvements und Workload-Diversity. Umfangreiche Informationen zu Kubernetes und zu Experten-Treffen finden sich unter anderem in der deutschsprachigen OpenShift-Anwender-Community.
Fazit:
Die generelle Empfehlung für den Einstieg in die Container-Technologie lautet klein anzufangen, beispielsweise mit einer neuen stateless Web-Applikation, die nicht allzu komplex sein sollte. Anschließend können IT-Teams iterativ vorgehen, um dann sukzessive die weiteren Möglichkeiten zu testen und zu erschließen. In dieser Phase stehen dann Themen wie CI und CD, automatisiertes Testen und der Einsatz einer Orchestrierungsplattform auf der Tagesordnung.
Da die Welt aber nur zu einem geringen Teil aus Greenfield-Anwendungen besteht, sollten Unternehmen sich auch frühzeitig Gedanken machen, was mit den Brownfield-Anwendungen geschehen soll. Wie lassen sich diese in die Container-Welt überführen? Die einfachste Form ist „Lift and Shift“. Dabei wird die Applikation selbst jedoch nicht modernisiert, sie wird lediglich neu paketiert und in die Cloud migriert und dort betrieben. Beim „Re-Platforming“ – der nächsten Stufe – analysieren Entwickler, welche Teile einer Applikation am meisten von Containern profitieren und bearbeiten diese dann gezielt und setzen sie beispielsweise in Microservices um oder ergänzen sie um einen API-Layer. Am aufwendigsten ist ein „Re-Factoring“, bei dem eine Applikation eine völlig neue Architektur erhält und zum Beispiel komplett mit Microservices umgesetzt wird. Für diese letzte Stufe sollte jedoch ein passender Business-Case vorhanden sein.


Sebastian Faulhaber ist Senior Solution Architect, Technical Teamlead Middleware D/A bei Red Hat.
Sebastian Faulhaber hat über acht Jahre als technischer Berater mit den Schwerpunkten Business Integration und Business Process Management (BPM) bei IBM gearbeitet. 2013 kam er als Solution Architect zu Red Hat. In dieser Funktion setzt Faulhaber seine umfassende Praxiserfahrung ein, um Kunden bei der erfolgreichen Implementierung der Open-Source -Technologien von Red Hat zu unterstützen.

Weitere Links:
https://bit.ly/2BH9YQS
https://www.openshift-anwender.de/

Carolyn Molski


Leave a Reply