在我去年的一篇博客自动化的高效团队开发环境提到了用vagrant来统一开发团队的开发环境。用vagrant基本上解决了开发环境异构的问题,但VM(vagrant使用virtual box)footprint很大,不便于频繁更新,启动销毁速度还很慢。所以,对于文中提到的并行开发的场景,尤其是快速迭代的开发周期,支持起来还是很别扭:
以图中week 3第一天为例:Dalian已经部署到线上,Edingburgh交付测试,而Florence正在开发中。此刻Dalian随时会爆出优先级很高的customer issue;Edingburgh可能会有大量的QA issue等待修复;而Florence上的任务还如火如荼。
这意味着每周要生成至少一个公共VM,对应当前版本的代码和样本数据。如有需要(比如Dalian同时爆出几个bug,需要多人同时跟进调试),相关的工程师每人还需要一个自己的私有VM。
对于devops,这是管理的梦魇。
还好,docker出现了。我们看看docker有什么本领:
头两点让docker在系统中的footprint很小,使用或者不使用docker对应用程序来说几乎没有差别。最后一点是最关键的,它让你能灵活地基于某个现存的image,和最新的软件版本,最新的线上样本数据一起,构建一个container。
vagrant无法做到这一点。一旦你创建了一个VM,你的环境,应用程序和数据都被绑定到一起了,同一个环境,不同的应用程序版本(或数据),需要创建不同的VM。
这是我之前构想的用vagrant构建的开发环境的一个例子:
如果使用docker,则简单很多。多数时候我们可以使用相同的image,配以不同的运行时软件和数据,如下图所示:
对应上图vagrant的开发环境,docker的开发环境可以是这样子的:
docker(或者类似思想的软件)是(服务端)软件开发和部署的未来,对此,我深信不疑