Vorteile der Containerisierung

Das Thema Containerisierung ist inzwischen ein alter Hut. Zumindest für uns als IT-Unternehmen. Das trifft aber a) nicht auf alle Unternehmen zu und b) ist nun, nach einigen Jahren des Produktiveinsatzes, ein guter Zeitpunkt, um Resümee zu ziehen, und Ihnen verraten zu können, mit welchen Vor- und Nachteile Sie bei der Containerisierung von Workloads rechnen können.

Das Wichtigste, aus meiner Sicht, ist die Antwort auf die Frage, hat sich die Containerisierung denn letztlich gelohnt? Und das kann ich mit einem dicken, fetten „Ja“ beantworten.

Ich will das gar nicht beschönigen. Ja, die Containerisierung bringt zahlreiche Stolpersteine mit sich, macht vieles komplizierter, vergrößert den Radius der Lernkurve bei allen Beteiligten und ist oft der Grund für Frust und genervte Ausrufe wie: „Früher war alles einfacher!“

Man muss aber sehen, was man dafür auf der Haben-Seite verbuchen kann, wenn letztlich alles steht.

Vorteile von Containerisierung:

• Reproduzierbarkeit von Laufzeitumgebungen
• Libraries und Systemkomponenten kommen sich nicht mehr in die Quere
• Kein Overhead für Abstraktionen, für die vorher eine volle Virtualisierung notwendig geworden wäre
• Es ist der erste und wichtigste Schritt hin zu einer per Code definierten Operating-Infrastruktur, Stichwort „Infrastructure As Code“
• Einfachere horizontale Skalierbarkeit. Klar: Was vorher nicht horizontal skaliert hat, wird auch durch das Verpacken in einen Container dazu nicht plötzlich befähigt. Aber die Containerisierung erzwingt einige Konzepte, die die nächsten Schritte auf dem Weg, hin zu einer horizontalen Skalierbarkeit auf jeden Fall erleichtern.
• Kein „Also bei mir auf der Kiste läuft das aber!“ mehr

Kurzum: Containerisierung ist keine Technik-Spielerei, sondern ergibt wirtschaftlich einfach Sinn, wenn man das Gesamtsystem betrachtet. Stichwort TCO (Total Cost of Ownership): Das Ziel muss natürlich sein, Abläufe zu formalisieren, zu standardisieren und damit zu vereinfachen und zu beschleunigen.

Diese Frage wurde im Netz vermutlich schon 1000 Mal beantwortet und ich leg’ da jetzt einfach noch eine Antwort obendrauf:

Auch wenn der Vergleich hinkt und unter der Haube etwas anderes passiert: aus Nutzersicht ist Containerisierung wie eine Virtualisierung. Ein Container ist quasi eine virtuelle Maschine (VM), jedoch ohne bzw. mit nur minimalem Overhead in puncto Ressourcenverbrauch.

Ob die Containerisierung nachher mit Docker, Containerd, CRI-O etc. geschieht, sei hier einmal außen vor gelassen. Alle Container Runtimes bringen einen irgendwie ans gleiche Ziel.

Kurz gesagt gibt es meist ein Dockerfile. Das ist eine Textdatei, die in Shell-Script-ähnlicher Weise ein Verweis auf ein Basis-Image (z.B. ein Debian-Linux 11), sowie Befehle enthält, die unseren Container, also unsere “virtuelle Maschine” (die Experten mögen mir den Begriff in diesem Zusammenhang verzeihen) provisionieren.

Sagen wir mal, dieses Dockerfile enthält die Information, dass es auf Basis von Debian 11 starten und dann noch einen nginx-Webserver installieren soll. Mit z.B. docker kann ich dann aus diesem Dockerfile einen Container erstellen. Wenn ich diesen Container dann starte, verhält er sich ziemlich genauso wie eine virtuelle Maschine, auf der ich gerade Debian 11 und einen nginx-Webserver erstellt habe: Er bekommt eine eigene IP adresse und ist über diese je nach Konfiguration auf Port 80/HTTP bzw. Port 443/HTTPS erreichbar.

Vorteil: Dieser Container braucht praktisch die gleichen Ressourcen, wie wenn ich nginx lokal installiert hätte. Eine echte Virtualisierung wäre also erheblich lastintensiver. Die Folge: Ich kann auf einer entsprechend leistungsstarken Maschine ohne Probleme einfach mal 100 Container mit unterschiedlichsten Inhalten hochfahren, die sich alle gegenseitig nicht in die Quere kommen. Und das muss keinen großen Server sein - das kann auch das eigene Entwickler-Notebook sein.

Genau daraus ergeben sich unzählige Anwendungsmöglichkeiten, die seinerzeit den Boom von Docker begründet haben. Und zwar mit Recht.

Ein typisches Beispiel – stark vereinfacht: Sagen wir mal, ich habe einen klassischen LAMP-Stack, also eine Webseite, die mit Linux (OS), Apache (Webserver), MySQL (DB) und PHP (Skriptsprache) betrieben wird.

Damit das ganze containerisiert ist, erstellen wir nun einzelne kleine „virtuelle Maschinen“, also Container, wie oben beschrieben. Einen für Apache, einen für MySQL und einen für PHP. Danach müssen diese Container nur noch so miteinander verschaltet werden, dass Anfragen von außen auf Port 443 des Apache-Containers landen, dieser dann via fcgi auf port 9000 mit dem php-Container spricht und der wiederum bei Bedarf auf Port 3306 mit dem MySQL-Container kommuniziert. Wie gesagt: stark vereinfacht dargestellt.

Damit auch die Verschaltung der einzelnen Container miteinander optimalerweise in Code definiert werden kann, existieren verschiedene Lösungen von einfach, wie docker-compose bis komplex wie Kubernetes. Und seien wir mal ehrlich: aktuell führt an Kubernetes eigentlich kein Weg vorbei, wenn man ein professionelles Container-Set-up verwalten möchte, das aus mehr als einer Handvoll Container oder mehreren Servern besteht.

Falsch! Die Containerisierung ist nur die halbe Miete. Irgendwie muss man die ganzen einzelnen Services auch noch koordinieren. Nachdem man sich also erst das Know-how für die Containerisierung von Softwarekomponenten eingetrichtert hat, kommt gleich der nächste Brocken in Form von Kubernetes oder ähnlichem? Ja! Zumindest gilt das für alle Workloads, die über ein gewisses Maß an Komplexität verfügen, das man bei einer durchschnittlichen Webseite eigentlich bereits erreicht haben dürfte.

Und diese Entwicklung ist inzwischen nicht mehr aufzuhalten – aus gutem Grund, denn insgesamt ergibt sie absolut Sinn, auch wenn man damit die Einstiegshürde in das Thema „Wir betreiben unsere eigene Operating-Infrastruktur“ natürlich bedeutend höher legt.

Wo sich die Kompetenz-Schere früher noch aufmachte zwischen: „Wir laden das einfach per FTP auf den Server“ und „Unser Jenkins deployt das automatisch auf Knopfdruck.“ - ist es heute eher das „Hier der Zugang zum Server“ vs. „Hier der Zugang zu unserem Kubernetes-Cluster“

Zusammenfassend: Die Themen Containerisierung und Kubernetes sind wichtig, spannend, unausweichlich und herausfordernd. Umso wichtiger, dass Sie einen starken, kompetenten Partner an der Seite haben, der Sie dabei unterstützt. Wenden Sie sich gerne jederzeit an uns, damit wir Ihnen mit Rat und Tat zur Seite stehen können. Details finden Sie auf unserer Seite zum Thema