我今天看到一篇网友分享的 php 环境下的Docker持续集成案例。笔者大胆的试用后尝到了容器技术的甜头，也在文中提出了一个没有解决的困惑。 原来他是把代码放在容器外面，通过挂载目录的方法把代码加到容器里面运行的。这样虽然跑起来很快，但笔者感觉这和 Docker 的口号 build、ship、run 还是有很大的区别。当然，他把代码放在镜像里，每次变动都需要花上十几分钟等镜像build，push 到仓库后才能run发布，这个过程笔者也接受不了。这个网友的疑惑是构建镜像本身拖慢了集成的速度，这和一般情况下采用新技术能提高生产力的故事在直觉上是说不通的。

我想提提自己的看法。首先，Docker镜像本身是一个压缩包，每次即使只改几个文件，也需要把整个项目压缩一遍，没法增量压缩。所以，如果你的开发过程中需要频繁的改内容的时候，用 Docker 先打镜像再发布的流程就是一种反作用力，直接降低你的生产力。这个时候，你巧借 Docker 容器的环境一致性，直接把源码挂载到容器里面运行的做法应该是一个好办法。

我也意识到 Docker 对 CI这一块并没有考虑那么周到，还是需要我们自己来解决遇到的问题。比如本地的测试，可以考虑使用 vagrant 来解决，如下面的例子，很巧妙：

如果我们把 CI 的问题再扩展到 CD，上面源码是否放到镜像里面，仍然有很多可以讨论的地方。对于 Docker 的 build，ship，run一样有很多冲突，我是这么理解的：

1. build过程，从Docker 宣传的口号来说，源码作为服务组件的组成部分，确实应该放在镜像当中。但是，在没有 Docker之前，我们的源码也是打包的，这方面系统方面的安装包已经足够强大。但之前的安装包一定是需要你编写依赖环境的，每一种系统要写一个 spec。在有了 Docker 之后，这个困难就没有了。因为，你的依赖环境就在镜像里面，不需要额外的考虑环境的变化。所以，代码挂载进来也不会影响环境。
2. ship 是为镜像仓库为中心，你可以把 镜像存到仓库里面，也可以把镜像拉在主机上。代码作为经常变化的部分，并不能把镜像作为不可变的组件特性给发挥到极致。所以，源码在镜像里面打包分发也不一定是好事。
3. run 的部分是秒开应用以及依赖的环境。把源码打包到镜像里面后，Run 新版本的镜像，就需要 stop 老镜像。毕竟有一个停起的过程，如果没有灰度发布的过程，这个更新镜像的过程就是中断服务的。

上面的困惑虽然小，也能让我们看到 Docker 的使用是需要花心思的。盲从的乱用 Docker 并不能给你带来甜头，反而会让你更烦恼。希望大家一起探讨起来，一起发现一些困惑，一起来探讨解决。