Docker und Podman sind auf Entwicklerrechnern und kleinen Servern zu Hause und die Grundlage für jedes Container-Projekt. Der Ein und Umstieg ist einfach; bei Security und Netzwerkverbindungen gilt es, auch unbekanntere Funktionen zu entdecken.
Sobald die Anforderungen steigen, reichen Docker und Podman nicht aus - das Wissen können Admins und Entwickler in die Kubernetes-Welt mitnehmen und steigen somit Stück für Stück in die Technik ein, die auch Dienste von Weltkonzernen betreibt.
Der erste Cluster läuft, die ersten Container sind umgezogen - Zeit für einen Blick auf erprobte Konzepte, die den Admin Alltag leichter machen. Und auf OpenSource Software, die alltägliche Probleme aus der Welt schafft.
Container verstehen und loslegen
Ab 2013 hat Docker die Containertechnik salonfähig gemacht. Von Kritikern erst als kurzfristiger Hype verschrien, sind Container mit Docker, Podman und Kubernetes wenig später zur etablierten Technik geworden. Für den Einstieg ist es lange noch nicht zu spät: wie Sie von Containern profitieren und Software mit und ohne Docker betreiben.
Von Jan Mahn
Bild: Albert Hulm
Container verstehen und loslegen
Die Container-Strategie
Container-Images mit Trivy durchleuchten
So harmonieren Docker und IPv6
Docker für Faule
Von Docker Desktop auf Podman wechseln
Rootless-Container mit Podman betreiben
Technische Neuerungen spalten oft die Gemüter: Auf der einen Seite gibt es die Early Adopter, die alles Neue sofort anfassen und ausprobieren müssen und mit dem Risiko leben, wenig später ein totes Pferd reiten zu müssen. Auf der anderen Seite stehen die Skeptiker, die sich das bunte Treiben lieber von außen anschauen und darauf warten, dass sich eine gewisse Stabilität einstellt - oft ist das eine gute Strategie, weil viele Hype-Themen nach wenigen Jahren still und leise in der Versenkung verschwinden. Auch bei Docker, eine Software, die 2013 erstmals erschien, war Vorsicht durchaus angebracht. Dennoch handelten viele die Technik eines kleinen Open-Source-Start-ups schnell als Quasi-Industriestandard.
Viele Baustellen im Docker-Unterbau haben sich rasanter verändert, als die Entwickler ihre Dokus und die Vertriebler ihre Prospekte anpassen konnten. Nicht nur die Open-Source-Software Docker selbst, auch das Geschäftsmodell der Docker Inc. hat einige Kurswechsel hinter sich.
Wer bisher abgewartet hat, konnte sich einige Sackgassen und Irrwege ersparen. Nach fast 10 Jahren auf dem Markt zeichnet sich aber ab: Container bleiben uns erhalten, ob mit oder ohne Docker. Und die Zeit der großen Umbrüche ist vorbei. Auf den Maschinen von Entwicklern laufen Docker oder Podman, um Images zu erproben, zu entwickeln. Auch in kleinen Produktivumgebungen sind Docker und Podman zu Hause.
Sobald die Anforderungen größer werden, kommen die Container in einen Kubernetes-Cluster. Der Umstieg ist vergleichsweise einfach, weil dieselben Images zum Einsatz kommen.
Seit etwa 2016 berichten wir in c't regelmäßig über Container-Technik im Allgemeinen und Docker im Speziellen, veröffentlichen Artikel mit Grundlagen und stellen viele Projekte auf Container-Basis vor, die Docker-Grundwissen voraussetzen. Häufig erreicht uns daher die Frage, welche schon veröffentlichten Artikel man lesen muss, um schnell ins Thema einzusteigen. Das ist nicht ganz so einfach: Weil sich vieles in der Containerwelt innerhalb kürzester Zeit weiterentwickelt hat, können wir oft schon zwei Jahre alte Artikel nicht mehr guten Gewissens empfehlen. Zeit, den Stand des Container-Universums nachzuzeichnen. Für alle, die sich Containern bisher verweigert haben, die eine gewisse Reife der Software abwarten wollten, oder die jetzt das Gefühl beschleicht, trotz Docker-Erfahrung in den letzten Jahren wichtige Neuerungen verpasst zu haben. Der Artikel beschränkt sich auf Container mit Linux-Unterbau - Windows-Container auf Windows-Servern sind eine eigene Baustelle. Wenn Sie Docker den Rücken kehren wollen und stattdessen einen Blick auf den Open-Source-Marktmitbewerber Podman werfen wollen, werden Sie im Artikel "Von Docker Desktop auf Podman wechseln" fündig. Fast alles, was unter Docker funktioniert, klappt auch mit Podman.
Was habe ich davon?
Als reiner Desktop-PC-Anwender (sei es unter Linux, Windows oder macOS) haben Sie nichts verpasst, wenn die Dockerei bisher an Ihnen vorbeiging. Docker ist eine Software, die für Admins und Entwickler gemacht wurde. Sinnvolles Einsatzgebiet sind Serverdienste, aber auch für Kommandozeilenwerkzeuge können Container durchaus nützlich sein. Mit etwas Bastelei kann man theoretisch auch grafische Anwendungen im Container betreiben, erste Wahl für Desktop-Software sind die Container aber nicht.
Um den Nutzen von Containern und die Funktionsweise zu verstehen, ohnt ein Blick auf die Arbeitsschritte, die ohne nötig sind, bis eine Serversoftware funktioniert. Anschauliches Beispiel ist die populäre Bloganwendung WordPress auf einem Linux-Server. Damit WordPress läuft, braucht man einen Ordner mit den WordPress-Dateien selbst, eine PHP-Engine, einen Webserver (Apache, Nginx .) und eine SQL-Datenbank (MariaDB oder MySQL).
Auf einem nackten Linux-Server würde man zur Installation damit beginnen, die Komponenten über den Paketmanager herunterzuladen, etwa per apt install in Debian, Mint oder Ubuntu. Anschließend konfiguriert man alle Bausteine einzeln in ihren Konfigurationsdateien (die unter Linux meist im Ordner /etc. liegen) und verdrahtet dann die Komponenten miteinander: Der Webserver muss mit der PHP-Engine sprechen und ihm Dateien mit der Endung .php zum Parsen vorwerfen, der PHP-Code muss die Datenbank erreichen und wissen, wo er hochgeladene Bilder im Dateisystem ablegen soll. Außerdem braucht der Webserver noch Regeln, damit hübsche URLs richtig übersetzt werden und WordPress die richtige Seite anzeigt. Bis man eine gute Schritt-für-Schritt-Anleitung zum Installieren von WordPress per Hand durchgespielt hat, vergehen etwa 30 Minuten.
Das große Problem mit solchen Installationen bemerkt man spätestens, wenn man auf die Idee kommt, auf dem Server mit der öffentlich zugänglichen Website noch eine Testumgebung einzurichten. In einer solchen möchte man typischerweise am Layout arbeiten, oder neue Versionen von WordPress, PHP oder der Datenbank ausprobieren. Auf derselben Maschine kann man solche Experimente meist vergessen. Schuld daran sind Abhängigkeiten und hartkodierte Pfade zu Konfigurationsdateien. Viele Anwendungen sind schlicht nicht darauf ausgelegt, dass in einem Betriebssystem mehrere Versionen parallel installiert sind. Schon zwei MariaDB-Instanzen verschiedener Versionen auf einer Maschine sind mit erheblichem Einrichtungsaufwand verbunden.
In ganz ferner Vergangenheit blieb einem nichts anderes übrig, als Hardware für einen zweiten Server anzuschaffen. Besser wurde das erst mit virtuellen Maschinen (VMs) - ein großer Fortschritt, weil man Hardware endlich ausreizen und mehrere Betriebssysteme parallel auf einer Maschine booten konnte. Hat man sich für das WordPress-Beispiel ein Installationsskript gebaut, das alle Einrichtungsschritte durchspielt, könnte man vergleichsweise zügig eine Testumgebung in einer virtuellen Maschine hochfahren und die virtuelle Festplatte auch mit Admin-Kollegen und Entwicklern teilen. Virtualisieren hat aber einen entscheidenden Nachteil: Jede VM bootet einen Kernel des eingesetzten Betriebssystems. Das blockiert, ohne dass eine Anwendung liefe, schon mal etwa ein Gigabyte Arbeitsspeicher (unter Windows Server etwas mehr). Außerdem blockiert eine VM recht viel Festplattenspeicher, weil auf der virtuellen Festplatte ein komplettes Dateisystem mit dem Betriebssystem liegt.
Containertechnik wird immer wieder mit Virtualisierung in einen Topf geworfen, unterscheidet sich aber grundsätzlich von ihr: Ein Container ist keine virtuelle Maschine, sondern ein gewöhnlicher Prozess, dem eine für ihn optimale Scheinwelt vorgegaukelt wird. Für einen Container wird kein Kernel gebootet, der Prozess im Container läuft mit dem Kernel des gastgebenden Systems, beansprucht daher nur so viel RAM wie der Prozess auch ohne Container bräuchte. Die Container-Runtime (eine solche steckt in Docker) ist dafür verantwortlich, die Scheinwelt aufrechtzuerhalten: Der Prozess im Container bekommt ein virtuelles Dateisystem vorgesetzt, in dem nur das existiert, was er braucht. Also die Anwendung selbst und alle Abhängigkeiten - in genau der richtigen Version.
Vom Rest des Betriebssystems sieht der Prozess nichts, keine anderen Prozesse und auch keine anderen Dateien. Unter Linux arbeitet Docker dabei mit einer Kernel-Funktion names Cgroups, die schon lange vor Docker erfunden wurde. Ganz von der Außenwelt abgeschnitten ist der Prozess im Container aber nicht, dann wäre er ja für nichts zu gebrauchen. Die Container-Runtime kann ihm zum Beispiel eine virtuelle Netzwerkkarte vorsetzen, über die er mit der Außenwelt sprechen kann.
Durch die Kapselung der Prozesse in ihrer maßgeschneiderten Hülle kann man problemlos alles Mögliche parallel auf einer einzigen Maschine mit installiertem Docker Daemon (einen solchen Server nennt man auch Docker-Host) betreiben: eine WordPress-Instanz mit PHP 7, eine weitere mit PHP 8, eine Datenbank auf MariaDB- und eine auf MySQL-Basis. Weil kein RAM für Virtualisierung verschwendet wird, laufen all diese Container auch problemlos nebeneinander auf einem Entwickler-Notebook mit überschaubarer Ausstattung. Das ist ein durchaus gängiges Szenario: Auf...
