Containerisierung in der modernen IT

In der modernen Anwendungsentwicklung wird die Containertechnologie immer häufiger eingesetzt, sei es für die Ausführung von Backend- oder Frontend-Diensten oder sogar für Entwickler-Tools. Viele Organisationen wie Systemintegratoren, unabhängige Softwareanbieter und Spezialisten für Cloud-Lösungen übernehmen die Containerisierung, um mit den Anforderungen von großen, verteilten und modernen Entwicklungs- und Betriebspraktiken Schritt zu halten. Viele andere springen auf den Container-Zug auf, weil alle es zu tun scheinen. Anstatt blindlings mitzulaufen, ist es gut, einige wesentliche Fragen zu untersuchen und zu beantworten. Was sind zwingende Gründe für den Einsatz von Containern oder der Containertechnologie und was bedeutet es, sie als Grundlage für Ihre Anwendungsentwicklung zu verwenden?

10 zwingende Gründe für den Einsatz der Containertechnologie.

1. Höherer Grad der Hardware-Abstraktion

Die Verwendung von Containern für die Ausführung Ihrer Software bedeutet, dass Sie Hostcomputer auf einer Ebene nutzen, auf der der einzelne Computer keine Rolle mehr spielt. Anstatt sich um einzelne Rechner mit bekannten Namen zu kümmern und diese zu warten und zu patchen, kann sich das Betriebsteam auf einen Cluster von Host-Rechnern konzentrieren. Dieser Cluster ist ein Gefüge aus Host-Rechnern, die von der Cluster-Software zu einem zusammenhängenden Satz von Ressourcen für Datenverarbeitung, Arbeitsspeicher und Storage zusammengefügt werden. Jeder Rechner besteht aus handelsüblicher Hardware und ist entbehrlich. Der Cluster kann wachsen und schrumpfen, wenn neue Hosts hinzukommen oder defekte Hosts außer Betrieb genommen werden. Die Container laufen auf der Ansammlung von Ressourcen, die von der Cluster-Software verwaltet werden, ohne dass sie die einzelnen Rechner kennen oder sich um sie kümmern. Es ist ein wichtiger Trend bei der Nutzung von Cloud-Anwendungen, nur für die tatsächlich verbrauchten Ressourcen zu zahlen. Container ermöglichen eine optimalere Nutzung der Ressourcen im Cluster. Die Cluster-Software weist die laufenden Container auf der Grundlage der Anforderungen zu, die die Container-Images und die Anwendungsregistrierung angeben. Zu diesen Anforderungen können ein bestimmtes Betriebssystem, Speicherbeschränkungen und die erforderlichen CPU-Ressourcen gehören. Sie kann entscheiden, was und wo ausgeführt werden soll, und dabei die gegebenen Einschränkungen berücksichtigen. Der Cluster kann auch Container verschieben, wann immer er dies für sinnvoll hält, um die verfügbaren Ressourcen besser zu nutzen. Letztendlich ist es möglich, eine viel höhere Dichte an laufenden Containern und damit Anwendungen auf dem Cluster zu erreichen, als wenn die Anwendungen auf dedizierten Rechnern laufen. Es werden weniger Rechner benötigt, um die gleiche Arbeitslast auszuführen, was zu geringeren Betriebskosten führt.

2. Skalierbar

Der Cluster bietet einen Pool von Ressourcen, die die Container für Operationen anfordern können. Wenn der Bedarf an mehr Ressourcen und größerer Skalierung entsteht, kann der Cluster zusätzliche Container-Instanzen aus den Images aufsetzen und bei Bedarf mehr Ressourcen pro Container zuweisen. Solange es einen Überschuss an Ressourcen gibt, ist es einfach, die Skalierung zu erhöhen und danach wieder zu verringern. Wenn die Ressourcen zur Neige gehen, sorgt eine gute Kapazitätsplanung dafür, dass dem Cluster weitere Hosts für die Bereitstellung von Containern hinzugefügt werden. Eine intelligentere Cluster-Software kann die Skalierung besser verwalten. Da Container sehr schnell hochgefahren werden können, ist der Skalierungsprozess selbst eine Sache von Sekunden anstatt von Minuten oder Stunden.

3. Freiheit beim Hosting

Idealerweise wird die Cluster-Software auf virtuellen Maschinen installiert, um bei Bedarf einfach einen neuen Cluster bereitzustellen oder neue Hosts hinzuzufügen, ohne sich um die eigentliche Hardware kümmern zu müssen. Diese virtuellen Maschinen können sich in der Cloud bei einem beliebigen Cloud-Anbieter wie Amazon AWS, Google Cloud oder Microsoft Azure befinden, aber auch vor Ort in Ihrem eigenen Unternehmen aufgestellt werden. Es gibt keine Einschränkung, den Cluster an einem bestimmten Ort zu betreiben, obwohl es in manchen Situationen von Vorteil ist, sich für einen bestimmten Cloud-Anbieter zu entscheiden. Microsoft bietet zum Beispiel den Azure Container Service an, der die automatische Bereitstellung von Kubernetes-, Docker Swarm- oder DC/OS-Clustern ermöglicht. Die verschiedenen Cluster-Softwareangebote laufen auf unterschiedlichen Betriebssystemen, sowohl auf Linux-basierten als auch auf verschiedenen Windows Server-Editionen.

 

4. Container-Images sind unveränderlich

Das DevOps-Team erstellt neue Anwendungskomponenten, indem es Code schreibt und testet und ihn zu Binärdateien kompiliert. In einer Container-Welt bereiten sie auch die Container-Images vor, die alle Voraussetzungen für die Komponenten enthalten, und stellen die neuen Komponenten auf diesen Images bereit. Das Container-Image wird so konfiguriert, dass es ordnungsgemäß läuft, und dann in einem zentralen Image-Repository bereitgestellt. Von diesem Repository kann der Host die Images herunterladen und ausführen. Sobald das DevOps-Team das Container-Image für das Repository freigegeben hat, kann es nicht mehr geändert werden. Die Images sind unveränderlich und kommen garantiert ohne Änderungen auf den Hosts an. Alle Änderungen betreffen den Zustand eines laufenden Containers, aber niemals das Image. Das DevOps-Team hat die volle Kontrolle darüber, was in den Containern ausgeführt wird, und ist nicht auf menschliche Eingriffe bei der Konfiguration angewiesen. Außerdem muss man sich nicht mehr fragen, ob ein Container-Image zu einem späteren Zeitpunkt noch korrekt ausgeführt werden kann. Wann immer ein kompatibler Cluster mit dem richtigen Betriebssystem und der richtigen Kernel-Version verfügbar ist, können Container-Images garantiert ausgeführt werden, da es sich um einen eingefrorenen Satz von Code und Konfiguration handelt, der seit der Erstellung nicht verändert wurde. Das Zurücksetzen von Implementierungen und die Wartung einer laufenden Anwendung wird plötzlich viel einfacher.

5. Container-Images sind Code und Konfiguration

Container-Images vereinen die aus dem Code erstellten Binärdateien und die Konfiguration des Rechners in einer einzigen Einheit. Diese untrennbare Einheit bietet eine bessere Kontrolle, Stabilität und Vorhersagbarkeit als zuvor. In herkömmlichen Bereitstellungsszenarien wird der Code getrennt von der Konfiguration auf den Zielcomputern bereitgestellt. Dies führte zum Aufkommen der Desired State Configuration, bei der ein Skript oder eine deklarative Sprache in irgendeiner Form die Konfiguration für den Anwendungscode und seine Anforderungen auf Host-Ebene beschreibt. Der Code und die daraus resultierenden Binärdateien wurden in der Regel vom Entwicklungsteam bearbeitet. Das Team beschreibt die erforderliche Konfiguration auch in der Dokumentation. Das Betriebsteam erhielt dann Skripte vom Entwicklungsteam, um die Host-Rechner vorzubereiten und die endgültige Konfiguration der Softwarekomponenten vorzunehmen. Dies erwies sich nicht nur als fehleranfällig, sondern erforderte auch mehrere Umgebungen, um die verschiedenen Phasen im Lebenszyklus einer Anwendung, wie z.B. Test, Abnahme und Produktion, voneinander zu trennen. Container stellen sicher, dass unsere Anwendungen auf verschiedenen Container-Hosts immer in genau demselben Kontext ausgeführt werden.

6. Etappen statt Umgebungen

Entwicklungs-, Test-, Abnahme- und Produktionsumgebungen (kurz DTAP) könnten der Vergangenheit angehören, wenn Container und Cluster ins Spiel kommen. Traditionell gibt es separate Umgebungen, um den Grad der Qualität und des Vertrauens in Ihre Anwendung und ihre Komponenten anzuzeigen. Jetzt können Sie sich vorstellen, dass die verschiedenen Umgebungsstufen, die eine Anwendung durchläuft, von den Versionen Ihrer Container-Images widergespiegelt werden. Sie könnten die Versionen für DTAP in einem einzigen Cluster ausführen, und zwar an verschiedenen Endpunkten, die von der Cluster-Software verwaltet werden. Falls erforderlich, kann man immer noch einen produktiven von einem nicht-produktiven Cluster trennen, aber dies wird hauptsächlich aus Sicherheitsgründen geschehen und weniger aus Gründen der Stabilität und Verfügbarkeit der Phasen im Lebenszyklus der Anwendung. Die gesamte Umgebung kann sogar als Code durch Kompositionsdateien beschrieben werden, die die verschiedenen Elemente und Container beschreiben. Das Tool Docker Compose beispielsweise verwendet YML-Dateien, um die verschiedenen Teile einer Umgebung für eine oder mehrere Anwendungen zu beschreiben. Der Übergang von einer Umgebung zur nächsten, z.B. von der Staging- zur Produktionsumgebung, kann durch die Weitergabe dieser Dateien erfolgen.

7. Anpassung und Abstimmung mit verteilten Architekturen

Der Übergang zu containerbasierten Anwendungen passt gut zu modernen Architekturstilen wie Microservices. Groß angelegte und stark verteilte Anwendungen profitieren von einer solchen Architektur und folglich von der Verwendung der Containertechnologie. In den vorgenannten Architekturen enthalten einzelne Container in der Regel einzelne Prozesse, wie z.B. einen Dienst für Web-API, Website-Hosting oder Hintergrundverarbeitung. Dies erfordert ein Umdenken beim Design der Anwendung in kleinen, isolierten und verwaltbaren Teilen. In der Regel wird jedes der Container-Images mehrfach ausgeführt, um Ausfallsicherheit, Robustheit und Skalierbarkeit zu gewährleisten. Darüber hinaus gibt es viele separate Container-Images, die zusammen die komplette Anwendung bilden. Jede der laufenden Container-Instanzen ist vom Netzwerk getrennt, um eine inhärent verteilte Anwendung zu erstellen. Die Anwendungsarchitektur muss dies berücksichtigen. Sie sollten sorgfältig bedenken, dass andere Komponenten das Netzwerk für die Kommunikation nutzen. Das hat seinen Preis und birgt ein Risiko. Der Aufruf einer anderen Komponente ist zeitlich nicht billig, wenn er über HTTP oder TCP erfolgt, verglichen mit einem prozessinternen oder maschineninternen Aufruf. Außerdem besteht die Möglichkeit, dass der Prozess in einem anderen Container nicht verfügbar oder erreichbar ist. Gegenmaßnahmen für den Fall von Ausfällen müssen in die Anwendung eingebaut werden. Implementierungsmuster wie Circuit Breaker und Retry werden Teil des Portfolios des Entwicklers. Es ist wahrscheinlich, dass eine solche Architektur Auswirkungen auf die Art und Weise hat, wie die Teams und das Unternehmen organisiert sind. Die Vorteile dieses neuen Architekturtyps sind eine sehr gute Abstimmung mit dem Container-Ansatz und mit den DevOps-Teams, die die Anwendungen erstellen und betreiben. Diese Ausrichtung ergibt sich aus der Isolierung mehrerer kleinerer Teile im System, die darauf ausgelegt ist, mit potenziell kurzen Lebenszeiten oder der Nichtverfügbarkeit der Dienste umzugehen. Die Kosten einer solchen Architektur und verschiedener Implementierungsmuster liegen in ihrer Komplexität und Lernkurve.

 

8. Unterstützung bei Anwendungsframeworks und Werkzeugen

Es gibt eine Fülle von Frameworks, die die Entwicklung von Code für Komponenten und Dienste zur Ausführung in Containern erleichtern. Die Architektur und das Entwicklungsmodell erlauben die freie Wahl der Technologie für jeden der Container, da diese lose gekoppelt sind und keine binären oder technischen Abhängigkeiten voneinander haben. Bei der Wahl des Frameworks für die Entwicklung gibt es keine spezifische Herstellerbindung. Es wird jedoch dringend empfohlen, eine zweckmäßige Auswahl zu treffen. Was die Werkzeuge betrifft, so hat sich die Welt der Container auf Docker als De-facto-Standard für die Interaktion mit Container-Instanzen, Images und Hosts geeinigt. Mit der Standardisierung rund um Docker als Container-Interaktionsprotokoll und Docker als Unternehmen, das die Low-Level-Tools bereitstellt, haben sich andere Unternehmen und Software dazu entschlossen, sich anzuschließen. Entwicklungsumgebungen bieten Tools und Integration mit dem Docker-Ökosystem. Docker-Images werden als Image-Format für Container-Cluster verwendet, um neue Komponenten im Cluster einzusetzen. In zunehmendem Maße werden Webanwendungsdienste von Docker-Images aus bereitgestellt, anstatt sie per Installer oder Dateikopie bereitzustellen.

 

3 Gründe, keine Container zu verwenden

Die oben genannten Gründe mögen überzeugend sein, um morgen mit Containern zu beginnen. Wie fast immer gibt es auch eine andere Seite, die Sie berücksichtigen müssen. Container sind vielleicht nicht das, was für Sie, Ihre Anwendungen oder Ihr Unternehmen das Beste ist.

1. Die Containertechnologie ist kein Allheilmittel

Auch wenn Container vor allem bei Entwicklern und Betreibern beliebt sind, sind sie nicht die Lösung für alle Probleme bei der Bereitstellung von Anwendungen und Architekturen. Der Wechsel zu Containern als Basis für Ihre Anwendung löst oder verhindert nicht unbedingt Probleme mit der Leistung, Stabilität oder Skalierung. Container passen nicht zu jedem Teil einer Anwendung oder zu der größeren Landschaft, in die sie eingebettet ist. Es bedarf sorgfältiger Überlegungen, um zu entscheiden, wann der Einsatz von Containern sinnvoll ist und wann nicht.

2. Die Vorteile von Containern haben ihren Preis

Die Entwicklung einer Anwendung, die Container nutzt, erfordert das Erlernen der Technologie und die Investition von Zeit, um die Architektur und die Einsatzstrategien zu ändern. Verschiedene Entwurfsmuster müssen von den Entwicklern implementiert werden, um eine widerstandsfähige, robuste verteilte Anwendung zu erstellen. Die Build- und Release-Pipelines müssen für die Erstellung und Bereitstellung von Container-Images geändert werden. Dies ist komplizierter als eine traditionelle monolithische Anwendung und ihr Lebenszyklus. Die neue Art, Entwicklung und Betrieb in DevOps zu vereinen, erfordert einen Wechsel der Teams und eine Anpassung der Organisation an die Geschäftsbereiche. Die Vorteile, die eine Anwendung und die Landschaft durch den Einsatz von Containern haben werden, gibt es also nicht zum Nulltarif. Es bedeutet, dass man investieren muss, bevor man die Vorteile nutzen kann, und es gibt keine Garantie dafür, dass die Vorteile am Ende die Kosten überwiegen, insbesondere bei einfacheren und kleineren Anwendungen.

3. Das Anwendungsparadigma bewegt sich weiter

Container sind relativ neu und viele sind noch dabei, sich mit ihrer Anwendung in der Anwendungsentwicklung vertraut zu machen. Die Welt der modernen Anwendungsentwicklung entwickelt sich in rasantem Tempo weiter und es entstehen andere, neuere Wege zur Erstellung verteilter Anwendungen. Serverless Computing ist eine neu entstehende Form des Computing, die eine nahezu unbegrenzte Skalierung und ein Kostenmodell ermöglicht, das nach verbrauchten Millisekunden abrechnet. Es führt eine noch höhere Abstraktionsebene der Hardware ein, da es nicht einmal Hosts benötigt, wie es bei einem Cluster der Fall wäre. Außerdem konzentriert sich die Art und Weise, wie Serverless Computing implementiert wird, auf die eigentliche Logik und nicht auf einen Großteil der Installationen, die bei Container-Implementierungen immer noch erforderlich sind. Dies bedeutet, dass die Kosten für die Erstellung und den Betrieb von Anwendungen niedriger sein können, wenn Sie sich für ein serverloses Modell entscheiden.

Abschließende Gedanken

Die Containertechnologie nimmt einen wichtigen Platz im heutigen Ansatz der Anwendungsentwicklung und des Hostings ein. Es spricht viel dafür, auf Container als Technologie für moderne Cloud-Anwendungen umzusteigen. Wählen Sie weise und modernisieren Sie Ihre IT mit Containern, ... wenn es Sinn macht. </>