Im August 2013 erstellte Jérôme Petazzoni Docker in Docker. dindDies ermöglichte es, Docker-Container innerhalb von Docker Containers zu erstellen. Diese Funktionalität erwies sich als sehr beliebt. Das GitHub-Repository von Jérôme erhielt über tausend Sterne und dreihundert Gabeln.

Seit Docker 1.8, das zwei Jahre später im August 2015 veröffentlicht wurde, wird Docker in Docker direkt von Docker unterstützt. Die Verwendung von Docker in Docker ist jedoch mit einer Warnung verbunden, die anscheinend mit Jérômes Beitrag zusammenhängt: Verwenden von Docker-in-Docker für Ihr CI oder Ihre Testumgebung? Denke nochmal nach. Hier geht es um die Gründe, warum Docker in Docker keine gute Wahl für die kontinuierliche Integration ist.

Warum wird es als schlecht angesehen, Docker in Docker zu verwenden? Ist es nur ein Grund, Schildkröten aus dem Weg zu gehen? oder Leistungsüberlegungen?

Kontinuierliche Integrationsbedenken

Kurz gesagt: Docker in Docker (dind) behandelt Parallelität nicht gut.

Der Grund, warum Sie dind nicht für CI verwenden sollten, ist, dass Docker (normalerweise /var/lib/docker) exklusiven Zugriff auf das Verzeichnis hat, das für die Speicherung verwendet wird . Dind beachtet dies nicht, da alle untergeordneten Prozesse dieses Verzeichnis gleichzeitig verwenden. Jedes Mal, wenn Sie eine neue Version erstellen (z. B. von CI), wird möglicherweise alles, was mit Ihrer App in diesem Verzeichnis zu tun hat, gelöscht und muss bei null beginnen. Wie würde es Ihren Benutzern gefallen, wenn sie ihre Zahlungsdaten eingeben, auf "Kaufen" klicken und plötzlich wieder auf dem Anmeldebildschirm sind, als hätten sie noch nie etwas getan? Das ist einfach keine gute UX. Zwei Neuerstellungen gleichzeitig? Das wird für alle Beteiligten wirklich schlimm enden (einschließlich Ihrer Datenintegrität).

Andere Bedenken

Aus dem Link, den das OP veröffentlicht, ergeben sich Sicherheitsbedenken, da das System versucht, Sicherheitsrichtlinien in einer sehr "CSS-ähnlichen" Weise anzuwenden, bei der ein unterer Container Zugriff auf die Ressourcen eines äußeren Containers haben könnte, sofern dies nicht ausdrücklich untersagt ist. Erinnern Sie sich, wann Sie auf Webserver-Ressourcen zugreifen konnten, indem Sie etwas wie "mywebsite.com/../another_folder/private_resource.txt" ausführen? Außerdem spielen Dateisysteme manchmal nicht gut miteinander, wenn sie auf diese Weise verschachtelt sind.

Die Reparatur

Zum Glück hat der Blog-Beitrag im OP eine gute Lösung für das Problem. Sofern Ihre Anforderungen nicht durch "Docker-Container von Ihrem CI-System selbst erstellen / ausführen / pushen" erfüllt werden, können Sie den -vModus (Hinzufügen eines Datenvolumens zu Ihrem Container) am Docker-Socket (normalerweise /var/run/docker.sock:/var/run/docker.sock) verwenden, um die Art der Docker-Container zuzulassen Zugriff benötigen Sie auf das "freigegebene" Datenvolumen. Diese Container werden nicht darunter, sondern neben dem übergeordneten Container gestartet, um synchrone E / A-Vorgänge zu erzwingen. Jetzt haben Sie (fast) das Gleiche wie dind, aber ohne die Nachteile, die damit verbunden sind, dass Docker nicht für die gleichzeitige Verwendung entwickelt wurde.

Referenz (von OP): Verwenden Sie Docker-in-Docker für Ihr CI oder Ihre Testumgebung? Denke nochmal nach.