Docker在美团的应用--基于容器的自动构建

问题导读

1.自动部署系统解决了美团什么问题？
2.美团为什么没有用虚拟机？
3.基于Docker容器的自动构建解决了哪些问题？

自动构建系统是从美团的自动部署系统发展出来的一个新功能。每当开发人员提交代码到仓库后，系统会自动根据开发人员定制的构建配置，启动新的Docker容器，在其中对源代码进行构建（build），包括编译（如Java、C++和Go）、预处理（如JavaScript和CSS）、压缩（如图片）等操作，生成最终需要上线的程序包。

背景和问题

美团的代码自动部署系统承载着美团所有业务的代码上线工作。代码部署系统一开始基于简单的Bash脚本，从一个中央主机上通过Rsync和SSH进行文件传输和命令执行。

图1  代码部署系统架构图

代码发布系统经过多番演进，增加了很多功能，但原来的中心式架构仍然保留了下来，见图1。发布者通过Web界面或者REST API控制中控机，中控机负责从Git服务拉取代码，构建应用程序包，然后通过Rsync上传程序包到应用集群，并用SSH执行远程命令。

图2  过去15个月的发布次数

自动部署系统为美团业务的快速发展提供了有力的支撑。由于我们采用了开发人员自助上线的方式，发布操作频繁，工作日每日上线达上千次。图2是过去15个月每个月的发布次数。为了持续优化发布速度，给发布人员提供良好的体验，我们把单次发布平均时间作为发布系统的一项重要的KPI。

然而，随着美团业务的迅速扩张，服务增多，发布应用数目也增多，中心化的架构的问题也凸显了出来。

• 问题1：资源竞争
  

多个构建任务同时进行，竞争中控机的资源，影响发布速度。有一次一个应用受到同时进行的某Java类应用发布的影响，通常两分钟的发布变成了十多分钟，严重影响发布体验。如果出现事故需要回滚，就是更严重的问题了。

• 问题2：环境冲突
  

不同应用的构建依赖环境在一台发布机上，需要考虑环境冲突和隔离的问题。例如，Java 1.6/1.7共存，应用需要通过JAVA_HOME变量指定使用的Java版本，Maven 2/3也存在同样的问题。npm的global包也需要兼容多个应用的构建。

• 问题3：安全隐患
  

应用的构建脚本运行在公共发布机上，脚本的Bug可能会影响到发布机的正常运行。例如某次一个构建脚本里面的sudo service nginx reload命令，本应是在应用服务器上执行的，但开发人员错误配置到了在发布机上执行的构建脚本里面。

解决方案

解决上述三个问题，我们首先想到的方案自然是重构为多台中控机的可横向扩展的方式。但由于某些应用的特殊性，改动比较麻烦，所以开始并没有走这个方向（现在已实现多中控机）。

那么另外一个思路：能不能把构建过程从中控机分离出来？这个思路受到了Travis CI（https://travis-ci.org）的启发。我们借鉴Travis CI，在代码提交时自动在一个新的环境中触发应用的构建。

因此，我们的解决方案可以概括为如下三点：

• 把构建过程放到Docker容器；
• 提交代码时自动触发构建；
• 发布时直接使用构建好的应用包。
  

使用前配置如下：

• 在发布系统配置发布项（build.yml）；
• 在Stash配置自动构建服务的URL；
• 在私有Docker registry上传定制镜像（可选）。
  

使用过程比较简单，主要有如下几个步骤：

• 开发人员提交代码到Stash；
• 触发自动构建；
• 自动构建根据配置生成任务；
• 在Docker服务器上启动容器完成构建；
• 将构建好的包上传到美团云对象存储服务（MSS）；
• 发布时从MSS拉取软件包并发布。
  

每次提交代码时会触发自动构建API。构建任务放进队列里，任务在Docker服务器执行。当发布时就不用再去编译，直接拉取软件包进行发布。从图6、图7两幅图中可以看到在发布过程中直接使用了已自动构建好的文件进行部署。

图3  自动构建的配置

图4  发布系统的配置界面

图5  自动构建架构图

图6  自动构建的日志

图7  嵌入了自动构建日志的发布日志

为什么没有用虚拟机？

美团的虚拟化比较彻底，自动构建也可以用虚拟机而非容器实现。但虚拟机都和业务相关，会长时间保留。其次，虚拟机和CMDB深度结合，创建后会上报基本信息，部署Agent，配置监控项等。此外，虚拟机的创建是比较慢的。综合考虑以上几点，我们使用了Docker而不是虚拟机作为自动构建的基本单元。

效果和收益

基于Docker容器的自动构建很好地解决了之前提到的三个问题：资源竞争、环境冲突和安全隐患。构建任务移出发布机，构建用Docker服务器可横向扩展，解决了资源竞争问题。每个构建都是独立的镜像，环境冲突问题不复存在。构建脚本运行在独立于发布机的Docker服务器上，对发布机造成的安全隐患自然就消除了。

除解决了以上三个问题外，自动构建还显著改善了发布速度。经统计，自动构建任务的平均执行时间是197s，而使用自动构建应用的平均发布时间是99s。如果不使用自动构建，那么这些应用的发布时间就是197s + 99s，大约是三百秒。可以看到，自动构建把应用的发布时间缩短了三分之二。

总结

自动构建是美团对Docker的首次应用。这个应用不是为了用Docker而用Docker的，而是在解决代码部署系统中的问题时，利用Docker很好地解决了我们遇到的问题。该应用只利用了Docker最核心的容器功能，并没有使用Docker集群管理、调度、自动扩容等高级的功能。自动构建的场景非常适合使用Docker。希望本文能够对计划开始使用Docker的公司有所启发。

作者介绍：潘永之，美团云运维开发技术负责人。2012年加入美团，所在的团队首次在美团的生产环境用起来Docker。（编辑/周建丁）

架构图太小了，根本没法了解整体框架是个什么样，仅凭这些文字看不出docker在架构中是如何与其他元素进行协调工作的。

nice！ docker 看上去还是蛮好用的