依托Docker运行的后端服务（如数据库，缓存，存储等）感觉相当完美，但对于编译语言，Docker却并未本地开发的理想之选。
我一直在尝试使用Docker作为本地开发环境，最近我又尝试了一遍，结果发现依然行不通。但是这次尝试我得出了进一步的结论，那就是对于大多数的开发堆栈而言，将Docker作为本地开发环境毫无意义，除了引入更多的复杂性外，几乎没有任何优势。
若要实现高效的代码编写、编译、运行周期，意味着本地开发环境的容器没必要和生产环境的容器保持一致。这等于是否定了容器最重要的优势之一。换句话说，基于容器的开发环境根本无法达到非容器的本地开发环境的高效和流畅。
先看看我的要求，一个高效的coding、编译和运行周期需要单独的“非生产环境”的容器。首先，如果将生产环境的容器用于开发环境，容器必须包含某些预编译的组件，或者更甚，比如在你的Dockerfile中运行编译。这样，每次微小改动都需要重建容器。你的E/C/R（编辑、编译、运行周期）看起来像这样：
- docker-compose up -d #启动所有的容器，并运行
- # edit myservice
- make myservice # 构建服务
- docker-compose build myservice
- docker-compose restart myservice
按这种方式，整个重建的周期要花很长时间（超过30秒，还不包括服务自身的构建时间）来触发无聊至极的上下文切换。这绝对是生产力杀手。
你可以说这是个实现上的问题，并且最终这一重建周期将会大大加快，但是对比本地环境，构建和重启过程需要几乎无感。我也不觉得这会有效利用到Docker的镜像缓存。
如果愿意放弃使用生产容器作为本地开发容器的想法，或者运行一个没有构建过程的解释性堆栈，你或许可以改变游戏规则。你可将资源库目录装载到容器中，进而监听文件的变更，在容器内使用实时装载工具或刷新机制来重新编译和发布应用。
在一系列愚蠢的步骤下，这种方式也可工作的很好。比如我们将花时间寻找和设置docker-osx-dev开发环境，装载并与源文件夹高效的同步，又将花几个小时摆弄boot2docker以便使inotify正常工作起来，但是我们的确找到了解决方案。
但当我们回顾并看看这一变态的过程，我们竟然找不到令人信服的优势所在。我们在本地使用foreman启动所有服务，对比docker-compose up，foreman start速度难以置信的快。除了Docker容器本身，我们也继承了管理boot2docker所带来的复杂性。配置文档长度也增加了三倍。
我们的初衷是使用Docker作为本地开发环境，打破在本地只能运行如Memcached和Elasticsearch的几种关键服务。最终，我们得到结论，通过docker-compose运行后端服务是很有意义的，但配置和运行本地开发环境需要尽量简单。另外，我们又回到了通过foreman来运行本地微服务的方式。从此不再回头。
本文作者：Andrew
来源：51CTO