Wie (und warum) man Docker in Docker ausführt - CloudSavvy IT

Wenn Sie Docker in Docker ausführen, können Sie Images erstellen und Container in einer bereits containerisierten Umgebung starten. Es gibt zwei mögliche Ansätze, um dies zu erreichen, je nachdem, ob Sie untergeordnete oder gleichgeordnete Container starten möchten.

Der Zugriff auf Docker aus einem Docker-Container ist am häufigsten im Kontext von CI- und CD-Systemen wünschenswert. Es ist üblich, die Agenten, die Ihre Pipeline ausführen, in einem Docker-Container zu hosten. Am Ende verwenden Sie eine Docker-in-Docker-Strategie, wenn eine Ihrer Pipeline-Stufen Container abbildet oder mit ihnen interagiert.

Das Docker-in-Docker-Image

Docker wird als eigenständiges Image über das docker:dind Tag auf Docker Hub. Wenn Sie dieses Image booten, erhalten Sie eine funktionierende Installation des Docker-Daemons in Ihrem neuen Container. Es wird unabhängig davon ausgeführt, ob der Daemon Ihres Hosts den dind Behälter, also docker ps im Behälter ergeben unterschiedliche Ergebnisse docker ps auf Ihrem Gastgeber.

docker run -d --privileged --name docker -e DOCKER_TLS_CERTDIR=/certs -v docker-certs-ca:/certs/ca -v docker-certs-client:/certs/client docker:dind

Es gibt einen großen Nachteil bei der Verwendung von Docker-in-Docker auf diese Weise - Sie müssen den privilegierten Modus verwenden. Diese Einschränkung gilt auch dann, wenn Sie Container ohne Root verwenden. Der privilegierte Modus wird aktiviert durch die --privileged Flag im obigen Befehl.

Die Verwendung des privilegierten Modus gibt dem Container vollen Zugriff auf Ihr Hostsystem. Dies ist in einem Docker-in-Docker-Szenario erforderlich, damit Ihr interner Docker neue Container erstellen kann. Dies kann jedoch in einigen Umgebungen ein inakzeptables Sicherheitsrisiko darstellen.

Es gibt andere Probleme mit dind zu viel. Bei einigen Systemen können Konflikte mit Linux-Sicherheitsmodulen (LSM) wie AppArmor und SELinux auftreten. Dies geschieht, wenn der interne Docker LSM-Richtlinien anwendet, die der externe Daemon nicht vorhersehen kann.

Eine weitere Herausforderung sind Container-Dateisysteme. Der externe Daemon wird auf dem normalen Dateisystem Ihres Hosts ausgeführt, wie z ext4. Alle seine Container, einschließlich des internen Docker-Daemons, werden jedoch auf einem Copy-on-Write-Dateisystem (CoW) basieren. Dies kann zu Inkompatibilitäten führen, wenn der interne Daemon für die Verwendung eines p . konfiguriert istilote Speicher, der nicht auf einem bestehenden CoW-Dateisystem verwendet werden kann.

Montieren Sie stattdessen den Docker-Stecker Ihres Hosts

Die damit verbundenen Herausforderungen dind werden am besten behandelt, indem sie vollständig vermieden werden. In vielen Szenarien können Sie den gewünschten Effekt erzielen, indem Sie den Docker-Socket Ihres Hosts in einem docker Container:

docker run -d --name docker -v /var/run/docker.sock:/var/run/docker.sock docker:latest

Die Docker-CLI in der docker das Image interagiert mit dem Docker-Daemon-Socket, das es unter findet /var/run/docker.sock. Das Mounten des Sockets Ihres Hosts auf diesem Pfad bedeutet: docker Befehle, die innerhalb des Containers ausgeführt werden, werden auf Ihrem vorhandenen Docker-Daemon ausgeführt.

Dies bedeutet, dass sich die vom internen Docker erstellten Container auf Ihrem Hostsystem neben dem Docker-Container selbst befinden. Alle Container werden als gleichgeordnete Container existieren, auch wenn der verschachtelte Docker anscheinend ein untergeordnetes Element des übergeordneten Elements ist. Funktion docker ps führt zu den gleichen Ergebnissen, unabhängig davon, ob es auf dem Host oder in Ihrem Container ausgeführt wird.

Diese Technik lindert die Schwierigkeiten bei der Implementierung dind. Es macht auch die Verwendung des privilegierten Modus überflüssig, obwohl das Mounten des Docker-Sockets selbst ein potenzielles Sicherheitsproblem darstellt. Jeder mit Zugriff auf den Socket kann Anweisungen an den Docker-Daemon senden, um Container auf Ihrem Host zu starten, Images zu extrahieren oder Daten zu löschen.

Wann sollten die einzelnen Ansätze verwendet werden?

Docker-in-Docker über dind ist seit jeher in CI-Umgebungen weit verbreitet. Dies bedeutet, dass die "inneren" Container eine Isolationsschicht vom Host haben. Ein einzelner CI-Laufzeitcontainer unterstützt jeden Pipeline-Container, ohne den Docker-Daemon des Hosts zu beschädigen.

Dies funktioniert zwar oft, ist aber mit Nebenwirkungen behaftet und nicht der beabsichtigte Anwendungsfall für dind. Es wurde hinzugefügt, um die Entwicklung von Docker selbst zu erleichtern, nicht um Endbenutzerunterstützung für verschachtelte Docker-Installationen bereitzustellen.

Laut Jérôme Petazzoni, dem Schöpfer der dind Implementierung sollte der Socket-basierte Ansatz Ihre bevorzugte Lösung sein. Das Binden des Socket-Daemons Ihres Hosts ist sicherer, flexibler und genauso vollständig wie das Starten eines dind Empfänger.

Wenn Ihr Anwendungsfall bedeutet, dass Sie es unbedingt brauchen dind, gibt es eine sicherere Methode für die Bereitstellung. Das moderne Sysbox-Projekt ist eine dedizierte Container-Laufzeit, die andere Laufzeiten verschachteln kann, ohne den privilegierten Modus zu verwenden. Sysbox-Container ähneln virtuellen Maschinen, sodass sie Software unterstützen können, die normalerweise ohne Betriebssystem auf einer physischen oder virtuellen Maschine ausgeführt wird. Dazu gehören Docker und Kubernetes ohne spezielle Konfiguration.

Zusammenfassung

Das Ausführen von Docker in Docker ist eine relativ häufige Anforderung. Dies wird Ihnen wahrscheinlich bei der Konfiguration von CI-Servern auffallen, die Container-Image-Builds aus benutzerdefinierten Pipelines unterstützen sollen.

Verwenden von docker:dind gibt Ihnen einen unabhängigen Docker-Daemon, der in einem eigenen Container ausgeführt wird. Es erstellt effizient untergeordnete Container, die vom Host aus nicht direkt sichtbar sind. Obwohl es eine starke Isolation zu bieten scheint, dind ist eigentlich die Heimat vieler peripherer Fallprobleme und Sicherheitsprobleme. Diese sind auf Interaktionen des Docker-Betriebssystems zurückzuführen.

Mounten Sie den Docker-Socket Ihres Hosts in einem Container, der die docker Binär ist eine einfachere und vorhersehbarere Alternative. Dadurch kann der verschachtelte Docker-Prozess Container starten, die zu seinen eigenen Geschwistern werden. Bei Verwendung des Socket-basierten Ansatzes sind keine anderen Parameter erforderlich.