Docker容器化应用持续交付实践
背景介绍
随着当前微服务架构与DevOps的流行，持续交付（Continuous Delivery）正被越来越多的企业所重视。持续交付讲求以短周期、细粒度、自动化的方式频繁的交付软件，力求能更有效地降低交付过程所耗费的成本并提高效率，从而尽早实现软件的价值。
容器的出现和兴起大大简化了自动化的持续交付流程，为微服务、CI/CD、DevOps都带来了无限的可能。本文将以我们在网盟合一（零号DSP）项目过程中建立起来的通用容器化交付系统EMC（http://emc.baidu.com）为案例，分享我们基于Docker的容器化应用持续交付实践经验。
公司某重点项目采用微服务架构，系统由20+独立服务构成。全新的架构模式，需要诸多基础设施的支撑，如服务构建、服务交付、服务治理、弹性计算等。整体的微服务实施路径如图1所示。
图1. 微服务实施路径
微服务架构模式下，服务交付环节，传统交付方法已经无法满足快速迭代的交付需求，服务交付方式、快速部署、环境隔离、环境一致性等诸多问题亟待解决。经过调研，最终引入Docker容器来解决服务交付问题，理由如下：1）相对虚拟机来讲，Docker是一种轻量级容器。2）Docker对操作系统的侵入性很低，因其仅依赖Linux内核提供的虚拟化技术，部署相当容易。3）Build, Ship, and Run Any App, Anywhere。4）docker的社区生态很好，有很多可以直接使用的工具。
图2. EMC流程图
Docker的引入，相比传统的CI流程，额外增加的工作，如镜像封装、环境的治理，缺少相应的服务交付支撑系统，对此我们与公司JPaaS平台深度合作，打通jenkins/agile等CI工具，构建了一套通用的Docker容器化应用交付系统EMC，着力解决容器化封装与交付、基础镜像灵活定制、环境治理三大问题。整体的交付流程如图2所示。通过应用与配置分离等手段，实现一份镜像，到处部署，满足持续交付的单一制品原则（Single Source Of Truth，Single Artifact）。
容器化封装与交付
在传统的持续集成得到了构建产物之后，由于Docker的引入，首先面临的是以下两个问题：1）如何以标准化的方式来将应用封装成Docker镜像；2）如何通过自动化的手段完成镜像的构建。
标准化Docker镜像
图3. 标准化镜像结构图
基于Docker的分层文件系统，我们将镜像分为3层，如图3所示。基础镜像基于OS镜像层，应用镜像基于基础镜像层，有了这样一种分层之后，每次应用镜像制作便不必从上到下全部封装一遍，如此既保证了应用镜像构建的速度，也降低了每次全部构建一遍引入失误的风险。
基础镜像定制
图4. EMC基础镜像定制示意图
从前面的标准化镜像结构可以看出，实际应用中，不同业务线对基础镜像的需求不尽相同。EMC在提供镜像自动化构建能力的基础上，同时也支持用户自助定义所需基础镜像。主要有如下特色：
基于组件的概念，将基础镜像抽象为基础操作系统与各个独立组件的组合。
内置通用组件，如jdk/tomcat/supervisor，满足多个业务线通用需求
支持用户自定义组件，满足业务线特定需求
支持用户已有镜像注册到EMC作为应用的基础镜像
自动化镜像构建
完成镜像标准制定后，需要通过Dockerfile描述具体的镜像，然后进行镜像制作。Docker整体架构上由3部分构成，Registry负责存储镜像，Host运行Docker Daemon环境，client与Daemon交互，完成各种操作。目前Docker提供命令行接口（CLI）与远程API（Remote Api）两种交互方式。
当前业界基于Docker持续交付方案中，大多基于CLI的方式来进行镜像的构建，这种方式使用简单，无需额外开发，直接在Docker环境下即可运行。
EMC选择的方案则是RemoteAPI，同时将多台HOST作为资源池动态的执行镜像构建任务。该方案主要具备如下优势：1）client与Docker Daemon解耦；2）便于将多台Docker Host作为资源池动态分配使用；3）client的运行并不强制要求宿主机具备Docker环境，公司当前机器内核版本很多还达不到Docker需求。
图5. EMC镜像构建架构
容器化环境治理
完成镜像构建之后，接下来就是如何将镜像发布到不同的平台，构建开发/测试/生产环境，以及后续的运维管理。然后这个过程中需要解决集群化的容器管理与调度、容器间网络通信、服务暴露、容器内日志收集等诸多问题。下面主要介绍业界开源产品与公司内部技术结合解决的几类典型问题。
集群管理与调度
Docker本身并未提供集群化的支持，需要有额外的集群化管理与调度框架来支持，当前业界主要有三种解决方案：
1、 Docker Swarm。Docker官方提供的集群管理框架，使用Docker标准API，结构与功能简单，尚不适宜在生产环境使用。
2、 Kubernetes。google开源的容器管理系统，基于label和pod的概念对容器进行逻辑单元划分，实现编排与调度。功能强大，同时复杂度也较高。
3、 Apache Mesos && Mesosphere Marathon。Twitter开源的老牌集群资源管理系统，主要面向数据中心资源管理，属重量级框架。
我们的实践过程中，与公司JPaaS平台深度合作，采用kubernetes管理Docker集群，实现服务编排与调度。集群内部Service使用NodePort方式对外暴露服务，同时在Replication Controller层面与公司BNS相结合，同一服务的一组实例对外提供统一的BNS，再上层则通过BFE进行请求转发与负载均衡。
容器运行时的管理
前面已经提到过，容器的实际应用中有许多问题需要解决，生命周期的管理就是其中之一。EMC在镜像构建以及容器运行阶段，均提供了一些技术手段来保障容器的正常使用。
镜像构建阶段，集成agent到应用镜像，完成服务与容器的适配，容器内进程监控，中间件的启动、绑定等工作；容器启动过程中，可通过环境变量注入的手段向容器内注入运行信息，借此实现启动时的差异化。
图6. EMC容器生命周期图
自动部署
基于公司内Jpaas KubernetesDocker集群的统一接口，EMC提供可视化的环境一键部署与各类管理功能。主要有如下特色：1）环境一键部署与可视化管理；2）namespace环境隔离与管理；3）运行时管理与信息注入；4）一份镜像，多套环境部署，彼此隔离。
总结与规划
本文是我们在实际项目中使用Docker进行持续交付的实践，作为公司内第一个大规模使用Docker的项目，我们与JPaaS深度合作，开发了EMC这样一套容器化交付系统，目前支撑了7条产品线的容器化交付以及环境治理工作，累计完成镜像构建和环境部署任务9000余次，给整个交付流程带来了极大的便利性。
整个交付流程中，深入融合公司CI工具链，多平台支持，灰度发布，环境快照等问题都是EMC当前尚未覆盖的，这些目前已纳入规划当中，期待EMC更好的支撑容器化交付工作。
百度MTC 百度移动云测试中心（MTC）通过4年沉淀,，厚积薄发，依托百度内部20多条过亿用户量移动App产品线测试经验的累积和验证, 将百度领先的测试技术对外输出, 以业内首发的完整测试质量标准为基准、结合云技术和众包模式，为开发者解决测试过程中遇到的缺设备、缺人力、缺技术三大困境与挑战。
公有云平台目前拥有15000台真机，覆盖1700款机型, 同时拥有200位测试专家, 10000名经验丰富的测试专员，为移动App提供自动化测试、专家测试服务，全面保证App测试质量。