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?

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.