2013年8月，JérômePetazzoni在Docker中创建了Docker，dind简而言之，这允许在Docker Containers中创建Docker容器，这一功能非常受欢迎，导致Jérôme的GitHub Repository获得了上千个星星和300个分支。

从两年后（2015年8月）发布的Docker 1.8开始，Docker便直接提供了Docker中的Docker支持。但是，在Docker中使用Docker会带来警告，似乎与Jérôme的文章：在您的CI或测试环境中使用Docker-in-Docker？三思而后行。这着重说明了为什么Docker中的Docker并不是持续集成的绝佳选择的原因。

为什么在Docker中使用Docker不好？这是避免海龟全程下降的简单案例吗？还是性能方面的考虑？

持续集成问题

简而言之：Docker（dind）中的Docker不能很好地处理并发性。

之所以不应该使用dind来配置CI，是因为Docker被设计为可以独占访问其用于存储的目录（通常是/var/lib/docker）。Dind不尊重这一点，因为所有子进程同时使用此目录。每次重建时（例如，从CI重建），此目录中与您应用相关的所有内容都可能被清除，并从零开始。如果您的用户输入了付款明细，单击“购买”，然后突然发现自己回到登录屏幕，就像从未做过任何事情，您会如何？那只是不好的用户体验。一次进行两次重建？对于涉及的每个人（包括您的数据完整性）来说，这实际上将是非常糟糕的结局。

其他问题

从OP发布的链接中，会出现安全问题，因为系统将尝试以非常类似于CSS的方式应用安全策略，除非明确禁止，否则下层容器可以访问外部容器的资源。还记得您何时可以通过执行“ mywebsite.com/../another_folder/private_resource.txt”之类的操作来访问Web服务器资源吗？而且，有时文件系统以这种方式嵌套时，它们之间的相互影响就不好。

修复

幸运的是，OP中的博客文章为该问题提供了很好的解决方案。除非“通过在Docker上运行的CI系统本身构建/运行/推送Docker容器”无法满足您的需求，否则您可以在Docker套接字（通常为）上使用-v模式（向容器中添加数据卷/var/run/docker.sock:/var/run/docker.sock）以允许访问您需要的“共享”数据量。这些容器将与父容器一起启动，而不是从下面开始，从而强制进行同步IO。现在，您（几乎）拥有与dind相同的东西，但是没有为并发而构建Docker的缺点。

参考（来自OP）：将Docker-in-Docker用于您的CI或测试环境？三思而后行。