你可能会想，怎么才能看到编译的结果？这又不是本地环境。完全正确，我还没有讲到怎么请求访问到你的容器。
如果你以前一直在操作系统中开发而不是通过虚拟机，你可能经常使用:8000访问你的APP。在Docker和Docker Machine中，现在是两个完全不一样的抽象概念。
然后在发生交换时，增加了分离的概念。容器在孤立我们每一个服务的同时，我们也可以更好的了解什么是真正的服务。
为了达到和本地环境一样的简单级别，我们还必须做点什么才行。
就像我得Part1中所说的一样，一个小的dns服务器环境，不包括dnsmasq，Dev TLD的所有的请求都被路由到Docker Machine VM。我们只需要怎么把这些请求路由到正确的容器即可。不幸的是，默认的容器网络接口并没有暴露，VM内部容器的IP也是随机分配。你可以绑定主机的端口到容器的端口之上，但是必须仔细处理这之间的冲突。
这就是Jason Wilder的Nginx反转代理容器所讲的内容。它利用Docker内部的原理关注容器的开关，然后通过nginx反转代理实现动态配置。它也是通过绑定了VM的80端口实现。一个新的容器都包含VIRTUAL_HOST环境变量，可以将大量的流量路由到容器中。由于能都实时运行，我们就很容易添加两行代码进入Docker-compose.yml中：
...
environment:
- VIRTUAL_HOST=myapp.dev # For nginx proxy
停止容器（停止dev中的web），删除容器（删除dev中的web），然后启动所有的备份（dev环境）。这是另一个集中化环境需要转换思维的例子。首先我停止服务，然后更改新的环境变量，重新开启。因为新的环境变量加入新建的容器，最好的办法是删除容器，并重新开始。
反转代理也解决了对服务开发的问题：怎么定义两个我正在开发的服务之间的依赖关系？
把两个不同的服务定义在两个不同容器的docker-compose.yml中可以让他变得更复杂。他们每次构建一个其他容器时，会循环依赖引用另一个容器，从而进入噩梦。然而使用我们的dnsmasq容器，每一个dev的请求都被路由到nginx。只要你的服务在dev TLD而且注册在虚拟机下，那么每一个请求都能请求所有的链接。我们有自己的开发者入口，可以设置为ifttt.dev开发身份，这样就可以请求访问ifttt.dev内部的程序。如果你访问的程序不在运行，nginx会返回503。
对生产代码来说，Dockerfile一步一步安装相关联的程序包是很有意义的。对于Ruby项目来说，我们使用的是Bundler做的。我们创建镜像时可以运行bundler安装，但是你必须保证包存在情况下才可以运行成功。没必要但是整个Bundler打包的过程。
然而在开发环境不同，如果我们每次都安装一个完整的Bundler添加一个自己的gem，那将变得很脆弱。更糟糕的是如果你不包含在Dockerfile内，就不得不每次都重新启动一个新的容器！幸运的是，我们有更好的办法解决了这个问题：
...
volumes_from:
- bundler-cache
...
bundler-cache:
image: ruby:2.2
command: /bin/true
volumes:
- /usr/local/bundle
通过创建另一个以Ruby为基础的镜像服务作为我们的应用程序（使用Dockerfile定义），我们可以利用一些Docker内部更深的东西。bundler-cache容器定义了一个使用gem安装到系统路径的存储容量，一运行即可。即使容器没有激活，我们也可以从bundler-cache容器挂载在存储上使用。如果删除了这个web容器，我们依旧可以保持这个bundler-cache容器，等待下次重新创建容器时，直接挂载这个存贮容量后所有的gem就存在了。如果你想清除缓存并重启，很容易在开发直接删除bundler-cache即可。
对每一个项目都使用包管理的模式，我们发现这是一个非常方便快捷安装管理的方法。不过最大的问题是如果你以外地删除bundler-cache，你就必须重新安装所有的gem。
容器化与Docker在基础设施层是一个非常不错的工具。如果你计划以后转移到容器上，我非常推荐你在本地开发环境首先尝试。自从内部开始部署Dash，我们看到新开发员工的管理时间从几天到几小时不等。我们能够在一周之内做到迁移（包括实际更改Dash本身），我们的工程师们已经开始对此做出自己的贡献。
原文链接：Developing with Docker at IFTTT （翻译：ylzhang 审校：魏小红）
更多Docker相关教程见以下内容：