1使用Docker-in-Docker来运行CI或集成测试环境？三思.docVIP

使用Docker-in-Docker来运行CI或集成测试环境？三思 作者Jér?me Petazzoni Docker-in-Docker的主要目的是帮助Docker本身的发展。很多人用它来运行CI系统（例如Jenkins），这初看起来还不错，但会遇到很多“有趣”的问题，这些问题可以通过将Docker socket绑定安装进Jenkins容器中解决。 让我们来看看这是什么意思。如果你只是想要快速解决方案而不是细节，直接滚动到到这篇文章的底部。 Docker-in-Docker：优点 两年多前，我为-privileged flag in Docker贡献了代码并写了first version of dink。目的是为了帮助核心团队更快速地进行Docker开发。在Docker-in-Docker之前，典型的开发流程是： hackity hack 构建 停止正在运行的Docker进程 运行新的Docker进程 测试 重复 如果你想要一个良好可复用的构建（例如在一个容器中）,稍微有一点复杂： hackity hack 确认有一个可工作版本的Docker在运行 使用旧Docker构建新Docker 停止Docker进程 启动新的Docker进程 测试 停止新的Docker进程 重复 随着Docker-in-Docker的到来，这个过程简化为： hackity hack 一步构建和运行 重复 好多了，不是么？ Docker-in-Docker：缺点 然而，出乎人们的预料，Docker-in-Docker不是百分之百完美和健壮。我的意思是，有几个问题需要注意。 一是关于LSM（Linux Security Modules）比如AppArmor和SELinux：当启动一个容器，那个“内部Docker”可能尝试应用安全配置文件并导致“外部Docker”产生混乱或者冲突。当你尝试去合并带有-privileged参数的原始实现的时候这可能是最难解决的问题。我的修改在我的Debinan机器和Ubuntu测试虚拟机上可以运行（并且所有的测试都通过了），但在Michael Crosby的机器上（我没记错的话是Fedora）却功败垂成。我不记得问题的具体原因，但是这可能是由于Mike是个聪明的家伙，在SELINUX=enforce（我在使用AppArmor）的情形下运行而我的修改没有将SELinux考虑在内。 Docker-in-Docker：丑陋 第二个问题和存储驱动有关，当你在Docker中运行Docker时，外部的Docker运行在正常的文件系统（EXT4、BTRFS等等你有的）之上而内部Docker运行在写时复制的系统（AUFS、BTRFS、Device Mapper，依赖于外层Docker所使用的文件系统）之上。有许多组合不能工作。例如，你不能在AUFS之上运行AUFS。如果你在BTRFS之上运行BTRFS，开始时会正常运行，一旦你嵌入subvolumes，移除父级subvolumes会失败。Device Mapper没有命名空间，所以如果多个Docker实例在一台机器上使用它，它们会看见（和影响）其它的镜像和容器备份装置。这样不好。 问题有很多解决方法；例如，如果你想在内部Docker中使用AUFS，将/var/lib/docker升级为volume就会解决问题。Docker为Device Mapper目标名称添加了一些基础的命名空间，所以在一台机器上运行多个实例，就不会互相干扰。 目前为止，设置并不是完全一步到位，你可以看在GitHub的dind仓库中的这几个issues。 Docker-in-Docker：更加糟糕 关于构建缓存？这同样相当棘手。人们经常问我，“我在运行Docker-in-Docker，怎么样我才能使用主机上的镜像而不是重新将所有东西拉入内部Docker？”。 一些胆大的人试图从主机绑定安装/var/lib/docker到Docker-in-Docker容器中。有时候在多容器之间共享/var/lib/docker。 Docker进程明确地被设计为独占/var/lib/docker的访问。没有什么可以触碰隐藏在那里的任何文件。 为什么是这样？这是从使用dotClound的时候开始的惨痛教训。dotCloud容器引擎工作于多进程同时访问/var/lib/dotcloud。像原子文件替换（代替编辑）这样的小窍门将代码强制锁定，其它safe-ish系统的实验就像SQLite和BDB，当我们重构我们的容器引擎（最终成为Docker），一个大的设计决策是收集一个单一进程的所有的容器操作和所有的并发访问。 （不要误会我的意思：完全有可能做一些漂亮的、可靠的和快速的涉及多个进程和先进的并发管理，但我们认为Docker的单一角色模型更简单，以