Als Experten für einen effizienten Betrieb, schulen und praktizieren wir in unseren Projekten mit Kunden konsequent DevOps und setzen dafür auf Wissenstransfer und die Verbreitung aktueller Konzepte sowie Technologien. Containerisierung spielt dabei sowohl in Kundenprojekten, aber auch in Inhouse-Trainings eine große Rolle. Docker ist hier immer noch häufig anzutreffen. Viele unserer Kunden verlassen sich auf die Containerisierung von Software mit Werkzeugen der Firma Docker Inc.
Sprichst du Wal-isch?
Ob der Container herumschippernde Wal, als kleines Maskottchen von Docker, mit zum Erfolg der Technologie(n) beitrug, wissen wir nicht genau. Sicher ist: Dockers Verbreitung als Containerisierungswerkzeug in der Softwareentwicklung ist es geschuldet, dass es von vielen als DAS Werkzeug für den nachvollziehbaren und gekapselten Betrieb von Softwareeinheiten angesehen wird. Diese Leute haben meistens noch nichts von CRI-O, containerd, Podman oder rkt gehört. Nicht schlimm, denn wir wollen im Folgenden einige dieser Unklarheiten beseitigen.
Zuallererst: "Docker" ist für uns nicht nur ein Kommandozeilenbefehl, sondern eine Plattform für Containertechnologien, entwickelt von Docker Inc. Für unsere Recherchen haben wir uns auf die folgenden Produkte konzentriert: Docker-Desktop, Docker-CLI, Docker-Daemon und Docker-Compose. Wie eingangs erwähnt, ist nur Docker-Desktop von der Lizenzaktualisierung betroffen. Es bündelt auf Windows und MacOS die anderen genannten Produkte zu einer einzelnen leicht installierbaren Lösung und legt auch noch einen Kubernetes-Cluster inkl. einer Kubernetes-CLI oben drauf. Die Bestandteile haben folgende Verantwortlichkeiten:
- Docker-CLI: Kommandozeilenwerkzeug für die Interaktion mit Nutzer:innen.
- Docker-Daemon: Server-Komponente, die Befehle der CLI entgegennimmt.
- Docker-Engine: Kombination aus CLI und Daemon.
- Docker-Compose: Orchestrierungs- und Automatisierungswerkzeug für die Arbeit mit Docker-Containern.
Für weitere Informationen können wir auf die exzellente Dokumentation verweisen: https://docs.docker.com/
Abtauchen in den Docker-Desktop
Moment... Windows und MacOS? Was ist mit Linux? Diesen Dreiklang aus Betriebssystemen haben vielleicht nicht alle im Ohr, aber tatsächlich spielt Linux in der Welt der Containerisierung immer noch eine besondere Rolle. Denn nur der Linux-Kernel als basale Betriebssystemschicht stellt die Funktionen bereit, derer sich Container-Werkzeuge wie Docker bedienen. Deshalb ist Docker-Desktop letztendlich auch nur ein Produkt, das insgeheim eine virtualisierte Linux-Umgebung startet, dort den Docker-Daemon ausführt und den Zugriff darauf charmant per Benutzungsoberfläche und Kommandozeile für Nutzer*innen ermöglicht. Die folgenden Betrachtungen stufen Benutzungsoberflächen als zweitrangige Anforderung ein und klammern sie deshalb aus.
Doch wenn Docker-Desktop nur ein Bündel aus anderen Produkten ist und diese geschickt mit einer nutzungsfreundlichen Installation bereitstellt, lässt sich nicht auch ein anderer Weg in die Container-Welt finden? Die Antwort darauf war komplizierter als gedacht und fällt unterschiedlich je nach zu bedienender Anforderung aus. Bevor wir uns ihr vollkommen widmen, haben wir noch diese frohe Kunde: Ein simpler Weg besteht darin, für Docker-Desktop zu bezahlen. Das können wir allen empfehlen, die keine Zeit und Lust auf Erkundungsfahrten in neue Gefilde haben. Wir als wissensdurstige Abenteurer*innen wollen euch nun zeigen, worauf wir auf unserer Reise gestoßen sind.
Licht im Dunkeln der Tiefsee
Anhand des Einsatzes von Docker in unseren Projekten haben wir drei typische Use Cases für Docker und seine Alternativen identifiziert. Zwei davon adressieren einen ähnlichen Lösungsraum, deshalb fassen wir sie folgend zusammen.
Use Case 1:
Lokales Bauen von Images und Starten von Containern
Die Kernfunktionen von Docker lassen sich auch ohne Docker-Desktop unter Windows und MacOS nutzen, solange ein Weg gefunden wird, eine virtuelle Maschine zu betreiben. Die linke Hälfte des Flussdiagramms (siehe Abbildung) zeigt die Vielzahl an unterschiedlichen Möglichkeiten.Dem zuvor erwähnten Podman kommt eine besondere Rolle zu, denn die Firma RedHat ist mit den wendigen Seehunden von Podman dem Alpha-Wal Docker Inc. dicht auf den Fersen. Architekt*innen und Security-Spezialist*innen, denen die Client-Server-Architektur der Docker-Engine oder deren Root-Rechte zwei Dornen in den Augen waren, finden in Podman eine ernstzunehmende Konkurrenz. Gleiches gilt für Containerorchestrierungs-Fans, die Pods als skalierbare Deployment-Einheit nicht nur in Produktion nutzen wollen. Möglich wird der Tausch von Docker durch andere Werkzeuge aufgrund deren gemeinsamen Nenner, dem Containerstandard der OCI (Open Container Initiative). Was mit Docker große Verbreitung fand, entwickelte sich über die Etablierung dieses Standards zu einem Eisberg, mit Kommandozeilenwerkzeugen wie Podman und Docker an dessen Spitze. Insbesondere Podman geht hier anstelle eines monolithischen Ansatzes den (UNIX-) Weg des Teilens und Herrschens, indem unterschiedliche spezialisierte Lösungen miteinander integriert werden.
Use Cases 2 und 3:
Lokale Orchestrierung weniger Container und produktionsähnliche Umgebung starten
In unseren Projekten ist Docker-Compose überwiegend ein Werkzeug, um lokal Software von Drittanbietern zu betreiben. Dabei handelt es sich um Systeme, die in der Infrastruktur später von verantwortlichen Betriebsabteilungen bereitgestellt werden. Für die lokale Entwicklung wird eine leichtgewichtige Kopie dieser Infrastruktur benötigt. Docker-Compose übernimmt die Orchestrierung dieser Systeme lokal, in Produktion haben wir es bisher nicht gesehen. Dort hat sich der Container-Steuermann Kubernetes (griechisch κυβερνήτης) breit gemacht und als De-Facto-Standard etabliert.
Deshalb bescheinigen wir Docker-Compose eine kleiner werdende Rolle bei der Containerorchestrierung und empfehlen stattdessen lokal auf eine der zahlreichen Kubernetesdistributionen (minikube, k3s, KinD) umzusteigen. In der Regel läuft unsere Software jenseits des Entwicklungsgerätes vermehrt auf dem Industriestandard Kubernetes. Wer für Kubernetes entwickelt, sollte sich aus diesem Grund also bereits mit dessen lokalen Betrieb zu Entwicklungszwecken befassen. Die Lernkurve ist nicht zu unterschätzen, aber als echter DevOps Experte eigentlich ein MUSS. In der Produktionsumgebung ist es schon im Einsatz und dessen Infrastructure-as-Code können, korrekt parametrisiert, auch gleich lokal mitverwendet werden.
Schön und gut, aber wie startet man nun in Kubernetes, was ehemals Docker-Compose verantwortete? Etwa in dem man Tools wie kompose für die Konvertierung zu Kubernetes-Manifesten einsetzt oder gleich Helm nutzt. Helm hat sich schon als Paketmanager für Kubernetes etabliert. Sogenannte Helm Charts gibt es inzwischen für jede gängige Drittanbietersoftware von dessen Hersteller selbst oder beigesteuert von der Open-Source-Community. Wir haben festgestellt, dass sich der Umstieg lohnt, weil wir einerseits eine Vereinheitlichung der Werkzeuge unabhängig von der Ausführungsumgebung erreichen und andererseits den Umgang mit Deploymentkonzepten für Produktivumgebungen erlernen.
Neue Ufer
Diese Erkenntnisse zu möglichen Docker-Alternativen nutzen wir künftig auch im Rahmen unserer Projekte, da aktuell vermehrt Kunden ihre Containerisierungslösungen neu bewerten. Das dabei entstehende Feedback werden wir Ihnen regelmäßig bereitstellen und unsere Empfehlungen kontinuierlich an die neuesten Erkenntnisse anpassen.
In Kürze erhalten Sie deshalb an dieser Stelle eine interaktive Infografik als PDF-Download, mit weiterführenden Informationen zur Nutzung von Docker-freien Containerisierungslösungen.
Noch Fragen?
Weitere Informationen rund um DevOps und Betriebsmodellen der Zukunft erhalten Sie unter: https://www.iteratec.com/de/care/anyops/
Steven Berlin - ist Senior Software Engineer bei der iteratec GmbH in Hamburg. In Projekte
n und als Mitglied des DevOps-Kernteams beschäftigt er sich intensiv mit dem notwendigen Mindset, der Methodik, Technologie und Architektur für effiziente und erfolgreiche Softwareentwicklung und den folgenden Betrieb.
Fabian Knoll - ist als Senior Software Architect am Standort München tätig. Im Zuge dessen beschäftigt er sich leidenschaftlich mit den Themen Software-Entwicklung/-Architekturen und DevOps, und dem damit verbundenem Tooling, in seinem täglichen Projektleben.