Ansible 会查看这个文件，并且通知 Docker 加载正确的镜像，然后在容器中启动。它还会把这些服务容器链接到应用容器。如果你想知道 Docker 容器的链接功能是怎么工作的，可以参考Docker 0.6.5 发布通知.
我的应用包括一个 Dockerfile，它详细指定了 Ruby Docker 镜像的信息，这里面的步骤能够保证把正确的 Ruby 版本加载到镜像中。
FROM howareyou/ruby:2.0.0-p353
ADD .//terrabox
RUN \
./.profile ;\
rm -fr /terrabox/.git ;\
cd /terrabox ;\
bundle install --local;\
echo '. /.profile && cd /terrabox && RAILS_ENV=test bundle exec rake db:create db:migrate && bundle exec rspec'>/test-terrabox ;\
echo '. /.profile && cd /terrabox && export RAILS_ENV=production && rake db:create db:migrate && bundle exec unicorn -c config/unicorn.rails.conf.rb'>/run-terrabox ;\
# END RUN
ENTRYPOINT ["/bin/bash"]
CMD ["/run-terrabox"]
EXPOSE 3000
第一步是复制应用的所有代码到 Docker 镜像，加载上一个镜像的全局环境变量。这个例子中的 Ruby Docker 镜像会加载 PATH 配置，这个配置能确保镜像加载正确的 Ruby 版本。
接下来，删除 git 历史，Docker 容器不需要它们。我安装了所有 Ruby 的 gems，创建一个名为“/test-terrabox”的命令，这个命令会被名为“test-only”的容器执行。这个步骤的目的是能正确解决应用和它的依赖关系，让 Docker 容器正确链接起来，保证在真正的应用容器启动前能通过所有测试项目。
CMD 这个步骤是在新的 web 应用容器启动后执行的。在测试环节结束后马上就执行/run-terrabox命令进行编译。
最后，Dockerfile 为应用指定了一个端口号，将容器内部端口号为3000的端口映射到主机（运行着 Docker 的机器）的一个随机分配的端口上。当 Docker 容器里面的应用需要响应来自外界的请求时，这个端口可用于反向代理或负载均衡。
Docker 容器内运行 Rails 应用没有本地 Docker 镜像，从零开始部署一个中级规模的 Rails 应用大概需要100个 gems，进行100次整体测试，在使用2个核心实例和2GB内存的情况下，这些操作需要花费8分16秒。装上 Ruby、MySQL 和 Redis Docker 镜像后，部署应用花费了4分45秒。另外，如果从一个已存在的主应用镜像编译出一个新的 Docker 应用镜像出来，只需花费2分23秒。综上所述，部署一套新的 Rails 应用，解决其所有依赖关系（包括 MySQL 和 Redis），只需花我2分钟多一点的时间就够了。
需要指出的一点是，我的应用上运行着一套完全测试套件，跑完测试需要花费额外1分钟时间。尽管是无意的，Docker 可以变成一套简单的持续集成环境，当测试失败后，Docker 会把“test-only”这个容器保留下来，用于分析出错原因。我可以在1分钟之内和我的客户一起验证新代码，保证不同版本的应用之间是完全隔离的，同操作系统也是隔离的。传统虚拟机启动系统时需要花费好几分钟，Docker 容器只花几秒。另外，一旦一个 Dockedr 镜像编译出来，并且针对我的某个版本的应用的测试都被通过，我就可以把这个镜像提交到一个私有的 Docker Registry 上，可以被其他 Docker 主机下载下来并启动一个新的 Docker 容器，而这不过需要几秒钟时间。
总结Ansible 让我重新看到管理基础设施的乐趣。Docker 让我有充分的信心能稳定处理应用部署过程中最重要的步骤——交付环节。双剑合璧，威力无穷。