Pourquoi Docker-in-Docker est-il considéré comme mauvais?

22

En août 2013, Jérôme Petazzoni a créé Docker dans Docker, dindbref, cela a permis de créer des conteneurs Docker à l'intérieur de Docker Containers, cette fonctionnalité s'est avérée très populaire, ce qui a permis au référentiel GitHub de Jérôme de recevoir plus de mille étoiles et trois cents fourchettes.

À partir de Docker 1.8, sorti deux ans plus tard en août 2015, Docker dans Docker est directement pris en charge par Docker prêt à l'emploi. Cependant, l'utilisation de Docker dans Docker est accompagnée d'un avertissement, apparemment lié à la publication de Jérôme: Utiliser Docker-in-Docker pour votre CI ou votre environnement de test? Réfléchissez bien. qui se concentre sur les raisons pour lesquelles Docker dans Docker n'est pas un excellent choix pour l'intégration continue.

Pourquoi est-il considéré comme mauvais d'utiliser Docker dans Docker? Est-ce simplement un cas pour éviter les tortues tout le long? ou des considérations de performance?

Des tortues tout le long!

Richard Slater
la source
Je ne suis pas familier avec Docker à part l'avoir lu. Mais en y réfléchissant, on a l'impression d'avoir le système d'exploitation hôte sur le matériel, cet hôte charge un conteneur, puis ce conteneur en charge un autre. On dirait beaucoup de frais généraux étant donné que l'idée est de déployer une image. Une image d'une image d'une image ... Également intéressé par les réponses réelles à cette q.
Aucun remboursement Aucun retour
Vous liez la réponse à votre question ... ou est-ce que je manque quelque chose?
AnoE

Réponses:

17

Préoccupations liées à l'intégration continue

En bref: Docker dans Docker (dind) ne gère pas bien la concurrence.

La raison pour laquelle vous ne devriez pas utiliser dind pour CI est que Docker a été conçu pour avoir un accès exclusif au répertoire qu'il utilise pour le stockage (normalement /var/lib/docker). Dind ne respecte pas cela car tous les processus enfants utilisent ce répertoire simultanément. Chaque fois que vous reconstruisez (à partir de CI par exemple), tout ce qui concerne votre application dans ce répertoire peut être effacé et forcé de recommencer à zéro. Comment vos utilisateurs apprécieraient-ils s'ils entraient leurs informations de paiement, cliquaient sur "Acheter" et se retrouvaient soudainement sur l'écran de connexion comme s'ils n'avaient jamais rien fait? Ce n'est tout simplement pas bon UX. Deux reconstructions se produisent à la fois? Cela va vraiment mal se terminer pour toutes les personnes impliquées (y compris l'intégrité de vos données).

Autres préoccupations

Du lien publié par l'OP, des problèmes de sécurité surviennent car le système tentera d'appliquer des politiques de sécurité d'une manière très "CSS" où un conteneur inférieur pourrait avoir accès aux ressources d'un conteneur externe, sauf interdiction explicite. Vous vous souvenez quand vous pouviez accéder aux ressources du serveur Web en faisant quelque chose comme "monwebsite.com/../another_folder/private_resource.txt"? De plus, parfois, les systèmes de fichiers ne fonctionnent pas bien ensemble lorsqu'ils sont imbriqués de cette manière.

The Fix

Heureusement, le blog du PO a une bonne solution pour le problème. À moins que vos besoins ne soient pas satisfaits par «construire / exécuter / pousser des conteneurs Docker à partir de votre système CI lui-même fonctionnant sur Docker», vous pouvez utiliser le -vmode (ajouter un volume de données à votre conteneur) sur le socket Docker (généralement /var/run/docker.sock:/var/run/docker.sock) pour permettre le type de l'accès dont vous avez besoin au volume de données "partagé". Ces conteneurs seront démarrés à côté du parent, au lieu d'en dessous, forçant des E / S synchrones. Maintenant, vous avez (presque) la même chose que dind mais sans les inconvénients qui viennent avec Docker qui n'est pas construit pour la concurrence.

Référence (depuis OP): Utilisation de Docker-in-Docker pour votre CI ou environnement de test? Réfléchissez bien.

Peter G
la source
Voici un exemple d'approche (dood) décrite pour Jenkins, mais plusieurs problèmes ont été signalés lors de son utilisation hub.docker.com/r/psharkey/jenkins-dood
rombob
D'après cette explication, je ne peux toujours pas vraiment dire si Dind doit être évité dans mon cas ... Mon agent de construction s'exécute dans un conteneur Docker et fait ce qui suit: 1. Checkout repo.2. Start container & mount repo.3. Run some build-/test script inside container.Par agent, il n'y en a jamais qu'un ' dind'-container en cours d'exécution. Y a-t-il encore des problèmes avec dind dans ce cas d'utilisation?
helmesjo