观点 | Docker根本不适合用于本地开发环境


【编者的话】依托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 upforeman start速度难以置信的快。除了Docker容器本身,我们也继承了管理boot2docker所带来的复杂性。配置文档长度也增加了三倍。

我们的初衷是使用Docker作为本地开发环境,打破在本地只能运行如MemcachedElasticsearch的几种关键服务。最终,我们得到结论,通过docker-compose运行后端服务是很有意义的,但配置和运行本地开发环境需要尽量简单。另外,我们又回到了通过foreman来运行本地微服务的方式。从此不再回头。

原文链接:Can we stop pretending that Docker is great for development environments? (翻译:Andrew)

========================================================
译者介绍
Andrew,云计算从业者,PPTV技术总监,乐于分享对于云计算的一些想法和对未来科技的猜想。

9 个评论

又是不是万能素材,啥题材都能套
vagrant……
样本么
开发的确不需要docker,但开发过程中的联调测试,外部依赖用docker很适合。
我的机器是imac,在容器中,装了centos.现在所有的php环境,node环境都跑在容器中,利用ssh,vim工具编辑代码,已经用了两周了,表现还不错。
我看别人的文章,docker是支持增量构建的,你的构建需要30秒是全量构建吧?
docker的诞生之初是为了解决开发问题的,后来才用到了运维上,没可能不适合本地开发。
觉得这样好麻烦,不知道你是不是还在用这中方式使用docker。我也同意作者的观点,感觉docker不太适合开发中使用。我是把host的文件夹分享过去了一个,直接做修改,但是又遇到权限问题。不知道是不是方法错了。现在还在考虑回Vagrant。请赐教。

要回复文章请先登录注册