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

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

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

(题图来自:tutum.co)

背景和问题

美团的代码自动部署系统承载着美团所有业务的代码上线工作。代码部署系统一开始基于简单的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上传定制镜像(可选)。

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

  1. 开发人员提交代码到Stash;
  2. 触发自动构建;
  3. 自动构建根据配置生成任务;
  4. 在Docker服务器上启动容器完成构建;
  5. 将构建好的包上传到美团云对象存储服务(MSS);
  6. 发布时从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的公司有所启发。 

原文发布时间:2015-05-19

本文来自云栖合作伙伴“linux中国”

时间: 2024-11-01 09:54:11

基于容器的自动构建:Docker在美团的应用的相关文章

基于Nginx和Consul构建高可用及自动发现的Docker服务架构

本文讲的是基于Nginx和Consul构建高可用及自动发现的Docker服务架构[编者的话]本文对于Docker和Consul Template以及Nginx如何结合使用做了较为详细的介绍. [上海站|3天烧脑式微服务架构训练营]培训内容包括:DevOps.微服务.Spring Cloud.Eureka.Ribbon.Feign.Hystrix.Zuul.Spring Cloud Config.Spring Cloud Sleuth等. 导读 如果你在大量接触或使用微服务的话,你可能会碰到一个问

阿里云镜像服务:基于Tag的Docker自动构建

构建规则 一旦您的Tag符合"release-v$version"的形式,将触发自动构建:1)若您有$version相关的Tag构建规则,则以$version的Tag规则帮您构建:2)若您没有$version相关的Tag构建规则,则帮您以$version的Tag规则进行构建,生成对应的$version镜像: 具体示例 1)首先,需要确认您已经在阿里云镜像服务上创建了镜像仓库,并且开启了"代码变更时自动构建镜像". 2)之后,在镜像仓库对应的源代码仓库上提交相应的Ta

DockOne微信分享(七十九):基于容器技术构建企业级PaaS云平台实践

本文讲的是DockOne微信分享(七十九):基于容器技术构建企业级PaaS云平台实践[编者的话]企业级容器化PaaS平台旨在为企业应用提供底层支撑能力,覆盖应用开发.应用交付.上线运维等环节,包括代码的管理.持续集成.自动化测试.交付物管理.应用托管.中间件服务.自动化运维.监控报警.日志处理等,本次分享主要介绍基于容器技术构建PaaS平台所采用的相关技术.涉及的核心功能模块以及相关方案. 为满足以上需求,MoPaaS企业版基于Cloud Foundry及Kubernetes等开源技术框架和智能

构建基于容器的本机监控系统 应该注意什么?

本文讲的是构建基于容器的本机监控系统 应该注意什么?[IT168 评论]容器技术是目前非常火爆的一个技术,能够大大提升工作效率.本文中,我们将描述容器本机监控的含义,其核心是对动态容器环境进行监控,并解决在此环境中完全堆栈可见性的具体挑战.当然这个解释很模糊,下文中我们会详细讨论. 单个容器并不重要 在云环境中,经常会有"宠物与家畜"的比喻,传统服务器是你所关心的,被称作"宠物",而在云中,你处理的是动态的实例,这些实例很容易被替换,因此表现为"家畜&qu

Docker在云平台上的最佳实践:基于容器技术的DevOps探索

12月9日,在云栖计算之旅线下沙龙上,阿里云容器服务团队的高级研发工程师秦妤嘉分享了<基于容器技术的DevOps探索>.首先介绍了DevOps和CD,接着分析了Docker如何打破传统CD壁垒,最后讲解了怎样从零开始搭建一个持续交付系统. 视频回顾 DevOps与Continuous Delivery DevOps 在一个较成熟的软件和服务交付的团队里,就技术层面来说主要分为三个组成部分:开发.测试和运维.开发测试团队比较关注的是代码能否运行,而运维比较关注的是系统能否在上线后稳定运行,于是隔

在容器技术改造与应用上,美团云如何做到择善而从?

摘要: 今天我将分享<美团云容器实践之路>,我会先点明为什么美团要开始探索容器,再介绍我们在容器方面做了哪些事情,以及做这些事情的效果,最后也会提到美团云未来的一些发展思路.    一.引进容器技术的原因    有了美团云后,美团整体的基础设施交付效率有了很大的提升. 今天我将分享<美团云容器实践之路>,我会先点明为什么美团要开始探索容器,再介绍我们在容器方面做了哪些事情,以及做这些事情的效果,最后也会提到美团云未来的一些发展思路.    一.引进容器技术的原因     有了美团云

基于容器服务的持续集成与云端交付(一)- 交付之禅

前言 随着微服务架构与容器虚拟化技术的发展,持续集成与持续交付的概念又重新回到了大家的视野,越来越多的公司开始使用持续集成的系统来解决频繁发布带来的质量问题:使用持续交付的工具来实现代码在不同环境上的自动部署.原本有些学院派乌托邦式的思想正被千千万万次的集成与部署证明着它应有的价值.那么究竟是因为什么让持续集成与持续交付这个已经不再年轻的软件开发与交付的思想重新焕发绽放迷人的光彩呢? 传统软件交付之殇 传统软件的开发与交付的周期都很漫长,一款普通的企业软件通常需要十几个开发人员,几个月的时间来完

支持HTTP2的cURL——基于Alpine的最小化Docker镜像

本文讲的是支持HTTP2的cURL--基于Alpine的最小化Docker镜像[编者的话]本文详细地描述了如何构建一个支持HTTP2的cURL镜像,并且尽可能地降低镜像的体积. cURL是我喜欢的开源软件之一.虽然cURL的强大常常被认为是理所当然的,但我真心地认为它值得感谢和尊重.如果我们的工具箱失去了curl,那些需要和网络重度交互的人(我们大多数人都是这样的)将会陷入到困境中.curl速度快.体积小,并且和大多数好工具一样,简洁干净,尽量不影响用户,只做它们需要做的事情. 如果有人想使用c

基于容器服务的持续集成与云端交付(三)- 从零搭建持续交付系统

前言 在上一篇文章中讨论了容器服务提供的交付能力,在本文中我们将讨论如何从零搭建一个持续交付系统. 对于大多数公司而言,选择一个合适自己的持续交付系统是尤为重要的一件事情,不同的公司.不同的业务使用的场景也各不相同,因此要根据自己的业务场景与发展方向来选择合适的方案.根据不同的业务场景与交付方式,阿里云容器服务提供了三种不同的持续交付方案. 基于Jenkins的持续交付方案 基于Jenkins的持续集成和持续交付方案是所有方案中最灵活.能力最强的方式,但也是需要客户自主运维的方案.对于现有提供持