FAQ: Container mit Docker und die Feinheiten von Docker-Compose

Container sind ein bequemer Weg, (Server-)Software zu betreiben. Wir haben Antworten auf häufige Fragen zusammengetragen und beseitigen Missverständnisse.

In Pocket speichern vorlesen Druckansicht 4 Kommentare lesen
Container gestapelt

(Bild: Valdas Miskinis / Pixabay)

Lesezeit: 8 Min.
Von
  • Jan Mahn
  • Peter Siering
Inhaltsverzeichnis

Mit der Container-Plattform Docker lassen sich Prozesse isolieren, um diese unabhängig voneinander auszuführen. So können Sie mehrere Prozesse und Apps getrennt voneinander betreiben und Server-Software komfortabel ausprobieren. Für Container-Zusammenstellungen ist Docker-Compose das Mittel der Wahl. In unserer FAQ erklären wir, was sie beim Splitten von Docker-Compose-Dateien beachten müssen, damit sich die Container weiterhin untereinander finden. Wir erläutern die Vorteile von Registries wie quay.io oder ghcr.io und zeigen, wie Sie Container auch auf Systeme bringen, die keine Verbindung zum Internet haben.

Meine Container verwalte ich in YAML-Dateien und starte sie mit Docker-Compose. Bisher habe ich docker-compose up eingegeben, jetzt lese ich in Ihren Artikeln docker compose up, also ohne Bindestrich. Was ist richtig?

Früher war Docker-Compose ein separates Projekt, das unabhängig vom Docker-CLI in Python entwickelt und per docker-compose aufgerufen wurde. Mittlerweile gibt es Version 2: Docker-Compose ist jetzt eine in Go geschriebene Erweiterung des Docker-CLI. Seitdem hört Docker-Compose auf den Befehl docker compose, der Funktionsumfang unterscheidet sich nicht. In Docker Desktop wird die neue Version direkt installiert. Wie Sie einen Server aktualisieren, der noch die alte Python-Variante nutzt, haben wir in einem Artikel beschrieben.

Auf einem Server mit Docker sammeln sich ja allerhand Container an. Ein HTTP-Router wie Traefik, ein Update-Werkzeug wie Watchtower, eine Oberfläche wie Portainer ... Sollte ich alles in einer Docker-Compose-Datei verwalten oder die Dateien auftrennen?

Das ist Geschmackssache. Vieles spricht dafür, die ganzen Werkzeuge in einem Projekt separat von der eigentlichen Software zu verwalten. Die persönliche Grundausstattung für einen Docker-Server legt man sich komfortabel in ein Git-Repository und installiert sie schnell auf jedem neuen Server. Wichtig beim Splitten von Docker-Compose-Dateien: Damit sich die Container untereinander finden, muss man ein Docker-Netzwerk einrichten und das in allen Compose-Dateien mit den Containern verknüpfen.

Docker-Compose stellt immer den Namen des Verzeichnisses voran, in dem die Projektdatei liegt. Ich finde zwar eine Option, dieses Präfix zu überschreiben, aber keine, um es ganz unter den Tisch fallen zu lassen. Gibt es einen Trick?

Auch in GitLab finden Images in einer eigenen Registry ein Zuhause. Das funktioniert auch in der selbstgehosteten Open-Source-Version.

Eine Möglichkeit, das Präfix mit dem Setzen einer einzigen Option zu beseitigen, kennen wir nicht. Sie können zwar in der Projektdatei die Namen aller Container explizit mit container_name setzen, damit Docker-Compose das Präfix nicht voranstellt. Dann sind Sie aber dafür verantwortlich, dass es keine Namenskonflikte gibt. Und dieses Vorgehen widerspricht der Container-Philosophie, Instanzen nicht als Haus-, sondern als Nutztiere zu betrachten, ihnen also keine Namen zu geben und sie schnell zu ersetzen.

Wenn mehrere Instanzen eines Containers laufen sollen, ist es widersinnig, einen Namen zu vergeben. Darüber hinaus hat dieses Vorgehen keinen Einfluss auf projektspezifische Ressourcen, etwa benannte Volumes und Netzwerke; denen verpasst Docker-Compose stets das Präfix. Wenn Sie der Name des Projektverzeichnisses nervt, setzen Sie mit der Option –p von Docker-Compose am besten ein kurzes Präfix.

Docker-Compose verpasst ja auch sogenannten Named Volumes generierte Namen, denen es das Projektpräfix voranstellt. Ich würde jetzt gern ein solches Volume samt Datenbestand von einem in ein anderes Projekt mitnehmen. Kann man das irgendwie bewerkstelligen?

Das geht, ist aber nicht der von Docker empfohlene Weg, weil man sich per Hand um Berechtigungen kümmern muss. Sie können in einer Shell-Umgebung das standardmäßig in /var/lib/docker/volumes für jedes benannte Volume angelegte Verzeichnis umbenennen. Dazu sollten die Container, die mit dem Volume gearbeitet haben respektive arbeiten sollen, weder laufen, noch existieren – das Löschen der Container lässt die benannten Volumes nicht verschwinden.

Dann können Sie das jeweilige Verzeichnis umbenennen, etwa von alt_meinweb zu neu_meinweb in /var/lib/docker/volumes/. Wenn Sie jetzt den Container meinweb mit dem Präfix neu starten lassen, wird Docker-Compose behaupten, das Volume neu zu erstellen, bindet tatsächlich aber die vorhandenen Daten ein. Gegebenenfalls müssen Sie aber die Eigentumsverhältnisse des Wurzelverzeichnisses _data in /var/lib/docker/volumes/alt_meinweb beziehungsweise neu_meinweb anpassen: Bei unseren Versuchen hatte Docker-Compose diese bei der Übernahme zurück auf root:root gesetzt. Schauen Sie sich am besten die Eigentumsverhältnisse vor dem Starten des Containers mit dem umbenannten Volume an.


Docker lebt davon, dass es Images, also quasi die Vorlagen für Container, aus einer Registry herunterlädt. Kann man Container auch auf Systeme bringen, die gar keine Verbindung zum Internet haben?

Klar: Mit dem Befehl docker save meincontainer > save.tar.gz weisen Sie Docker an, das Image für einen Container in einem tar.gz-Archiv zu sichern. Die Software schreibt eine Art Repository in die Datei. Diese Datei transportieren Sie auf das System ohne Internet und importieren das Image dort mit docker load < save.tar.gz. Anschließend verwenden Sie es mit Docker-Compose oder Docker, als hätten Sie es gerade aus einer Registry heruntergeladen.

Bisher habe ich den Docker-Hub als Registry für meine Abbilder benutzt. Bei anderen Projekten begegnen mir andere Registries wie quay.io oder ghcr.io. Welche Vorteile haben die?

Als Docker erfunden wurde, gab es nur den Docker-Hub der Firma Docker Inc. Das hat sich grundlegend geändert: Die Firma Docker Inc. hat die Spezifikation, die eine Registry beschreibt, an eine Stiftung übergeben (OCI) und es sind viele Registries entstanden. Quay.io kommt von Red Hat – ihre Fans hat sie daher vor allem unter Podman-Nutzern. ghcr.io ist die Registry von GitHub, die man gut in Kombination mit der CI/CD-Umgebung GitHub Actions nutzen kann. Eine weitere CI/CD-Umgebung mit Container-Registry bietet GitLab an, das man auch kostenlos selbst hosten kann. Im Prinzip verhalten sich alle Registries aber weitgehend gleich, nur die Weboberflächen sehen anders aus.

Funktioniert im Kern wie der Docker-Hub: Quay.io ist die Container-Registry von Red Hat.

Wie beim Docker-Hub gilt bei den alternativen Registries: Öffentliche Abbilder sind kostenlos, für private Abbilder muss man zahlen. Wenn Sie bisher mit dem Docker-Hub zurechtkamen, gibt es keinen Grund zu wechseln.

Und wenn ich meine Abbilder nicht in fremde Hände, also in eine Registry bei Dritten, legen will? Muss ich dann immer wie weiter oben beschrieben mit tar.gz-Archiven hantieren?

Zum Glück nicht. Sie können eine Registry auch selbst betreiben – im lokalen Netz oder mit Authentifizierung im Internet. Minimalistisch gelingt das mit dem Docker-Image namens registry. Wenn Sie eine Benutzer- und Projektverwaltung brauchen, sollten Sie sich das Projekt goharbor.io ansehen. Das eignet sich auch für große Firmen, die ihre Abbilder selbst verwalten wollen. All diese Anwendungen sind Open-Source-Software.


Ich habe einen Container, den ich von Hand pflege und den ich nur gelegentlich, aber nicht automatisch aktualisieren möchte. Zu Fuß ist das aber aufwendig, gibt es einen Trick, die Schritte gefahrlos auszuführen?

Nicht nur automatische Updates funktionieren reibungslos mit Watchtower, einem Container mit erhöhten Rechten und Update-Mechanismus. Er überwacht die laufenden Container und hält Ausschau nach neuen Versionen der Images. Findet er solche, spielt er sie ein. Neuere Versionen des Watchtower-Images (containrrr/watchtower) berücksichtigen, dass der Docker-Hub als Standard-Registry nur noch eine begrenzte Zahl von Zugriffen zulässt (100 Abfragen in 6 Stunden für nicht angemeldete Benutzer, 200 mit einem kostenlosen Account) und fragen seltener bei der Registry nach. Sie können Watchtower ebensogut von Hand aufrufen, um einen einzelnen Container gezielt zu aktualisieren:

docker run --rm

-v /var/run/docker.sock:

/var/run/docker.sock

--run-once containrrr/watchtower

Die Option --run–once lässt Watchtower das Update durchführen und die Option --rm den Update-Container im Anschluss spurlos ableben.


c’t – Europas größtes IT- und Tech-Magazin

Alle 14 Tage präsentiert Ihnen Deutschlands größte IT-Redaktion aktuelle Tipps, kritische Berichte, aufwendige Tests und tiefgehende Reportagen zu IT-Sicherheit & Datenschutz, Hardware, Software- und App-Entwicklungen, Smart Home und vielem mehr. Unabhängiger Journalismus ist bei c't das A und O.

(jam)