基于 Docker 持续交付平台建设的实践

作为创业公司和推行 DevOps 工程师们来说，都遇到过这样的问题：

1. 硬件资源利用率的问题，造成部分成本的浪费

在网站功能中不同的业务场景有计算型的，有 IO 读写型的，有网络型，有内存型的，集中部署应用就会导致资源利用率不合理的问题。比如，一个机器上部署的服务都是内存密集型，那么 CPU 资源就都很容易浪费了。

2. 单物理机多应用无法对应用进行有效的隔离，导致应用对资源的抢占和相互影响

一个物理机器跑多个应用，无法进行所使用的CPU，内存，进程进行限制，如果一个应用出现对资源的抢占问题，就会引起连锁反应，最终导致网站部分功能不可用。

3. 环境、版本管理复杂，上线部署流程缺乏，增加问题排查的复杂度

由于内部开发流程的不规范，代码在测试或者上线过程中，对一些配置项和系统参数进行随意的调整，在发布时进行增量发布，一旦出现问题，就会导致测试的代码和线上运行的代码是不一致的，增加了服务上线的风险，也增加了线上服务故障排查的难度。

4. 环境不稳定，迁移成本高，增加上线风险

在开发过程中存在多个项目并行开发和服务的依赖问题，由于环境和版本的复杂性很高，不能快速搭建和迁移一个环境，导致无法在测试环境中无法模拟出线上的流程进行测试，很多同学在线上环境进行测试，这里有很高的潜在风险，同时导致开发效率降低。

5. 传统虚拟机和物理机占用空间大，启动慢，管理复杂等问题

传统虚拟机和物理机在启动过程进行加载内核，执行内核和init进行，导致在启动过程占用很长时间，而且在管理过程中会遇到各种各样的管理问题。

基于Docker容器技术，运维技术团队开发了五阿哥网站的容器云平台。通过容器云平台95%的应用服务已经实现容器化部署。

这些应用支持业务按需拓展，秒级伸缩，提供与用户友好的交互过程，规范了测试和生产的发布流程，让开发和测试同学从基础的环境配置和发布解放出来，使其更聚焦自己的项目开发和测试。

结合五阿哥容器云平台和docker容器技术的实践，本文先介绍如何实现7*24小时“一站式”的持续交付，实现产品的上线。

容器云平台架构图

Docker镜像标准化

众所周知，Docker的镜像是分层的。对镜像分层进行约定：

第一层是操作系统层，由 CentOS/Alpine 等基础镜像构成，安装一些通用的基础组件；

第二层是中间件层，根据不同的应用程序，安装它们运行时需要使用到的各种中间件和依赖软件包，如 nginx、tomcat 等；

第三层是应用层，这层仅包含已经打好包的各应用程序代码。

Docker Image分层

经验总结：如何让自己的镜像变的更小，PUSH 的更快？

Docker Image 优化前后对比

dockerfile 构建应用镜像，在中间件层遇到一些需要安装的软件包时，尽可能的使用包管理工具（如yum）或以 git clone 方式下载源码包进行安装，目的是将软件包的 copy 和安装控制在同一层，软件部署成功后清除一些无用的rpm包或源码包，让基础镜像的尺寸更小。
Java 应用镜像中并没有将 jdk 软件包打入镜像，将 jdk 部署在每台宿主上，在运行镜像时，通过挂载目录的方式将宿主机上的 java 家目录挂载至容器指定目录下。因为它会把基础镜像撑得非常大；
在构建应用镜像时，docker 会对这两层进行缓存并直接使用，仅会重新创建代码出现变动的应用层，这样就提高了应用镜像的构建速度和构建成功后向镜像仓库推送的速度，从整体流程上提升了应用的部署效率。

容器的编排管理

编排工具的选型：

Docker 编排工具对比

Rancher 图形化管理界面，部署简单、方便，
可以与 AD、LDAP、GITHUB 集成，基于用户或用户组进行访问控制，快速将系统的编排工具升级至 kubernetes 或者 swarm，同时有专业的技术团队进行支持，降低容器技术入门的难度。

Rancher架构图

基于以上优点我们选择 Rancher 作为我们容器云平台的编排工具，在对应用的容器实例进行统一的编排调度时，配合 Docker-Compose 组件，可以在同一时间对多台宿主机执行调度操作。

同时，在服务访问出现峰值和低谷时，利用特有的 rancher-compose.yml 文件调用“SCALE”特性，对应用集群执行动态扩容和缩容，让应用按需求处理不同的请求。(https:/zhuanlan.zhihu.com/p/29093407)

容器网络模型选型：

Docker 网络对比

由于后端开发基于阿里的 HSF 框架，生产者和消费者之间需要网络可达，对网络要求比较高，需要以真实 IP 地址进行注册和拉取服务。所以在选择容器网络时，我们使用了 Host 模式，在容器启动过程中会执行脚本检查宿主机并分配给容器一个独立的端口，来避免冲突的问题。

持续集成与持续部署

持续集成

监测代码提交状态，对代码进行持续集成，在集成过程中执行单元测试，代码Sonar 和安全工具进行静态扫描，将结果通知给开发同学同时部署集成环境，部署成功后触发自动化测试（自动化测试部分后续会更新）。

持续集成

静态扫描结果：

静态扫描结果

持续部署

持续部署是一种能力，这种能力非常重要，把一个包快速部署在你想要的地方。平台采用分布式构建、部署，master 管理多个 slave 节点，每个 slave 节点分属不同的环境。在 master 上安装并更新插件、创建 job、管理各开发团队权限。slave用于执行 job。

持续部署

基于上述架构，我们定义了持续部署规范的流程：

（1）开发同学向 gitlab 提交代码；

（2）拉取项目代码和配置项文件，执行编译任务；

（3）拉取基础镜像，将编译好的应用包打入生成最新的应用镜像，推送到镜像仓库；

（4）根据当前应用及所属环境定制化生成 docker-compose.yml 文件，基于这个文件执行 rancher-compose 命令，将应用镜像部署到预发环境（发布生产前的测试环境，相关配置、服务依赖关系和生产环境一致）。

（6）预发环境测试通过后将应用镜像部署至线上环境，测试结果通知后端测试同学。

容器的运行管理

应用容器现在已经部署到线上环境，那么在整个容器的生命周期中，还需要解决下面两个问题：

（1）如何保存应用程序产生的运行日志和其它业务日志；

（2）如何在后端服务出现变化后 nginx 能够自动发现并完成配置更新。

日志管理

容器在运行时会在只读层之上创建读写层，所有对应用程序的写操作都在这层进行。当容器重启后，读写层中的数据（包含日志）也会一并被清除。

虽然可以通过将容器中日志目录挂载到宿主机解决此类问题，但当容器在多个宿主机间频繁漂移时，每个宿主机上都会有留存应用名的部分日志，增加了开发同学查看、排查问题的难度。

综上所属，日志服务平台作为五阿哥网站日志仓库，将应用运行过程中产生的日志统一存储，并且支持多种方式的查询操作。

日志管理

通过在日志服务的管理界面配置日志采集路径，在容器中部署 agent 把应用日志统一投递到 logstore 中，再在 logstore 中配置全文索引和分词符，以便开发同学能够通过关键字搜索、查询想要的日志内容。

经验总结：如何避免日志的重复采集问题？

日志服务的agent需要在配置文件“ilogtail_config.json”中增加配置参数“check_point_filename”，指定 checkpoint 文件生成的绝对路径，并且将此路径挂载至宿主机目录下，确保容器在重启时不会丢失 checkpoint 文件，不会出现重复采集问题。

服务的注册

etcd 是一个具备高可用性和强一致性的键值存储仓库，它使用类似于文件系统的树形结构，数据全部以“/”开头。etcd 的数据分为两种类型：key 和 directories，其中 key 下存储单独的字符串值，directories 下则存放 key 的集合或者其他子目录。

应用注册

在五阿哥环境中，每个向 etcd 注册的应用服务，它们的根目录都以”/ ${APP_NAME}_$ {ENVIRONMENT}”命名。根目录下存储每个应用实例的Key信息，它们都以“IP-{PORT}”的方式命名。

下图是使用上述约定，存储在etcd上某应用实例的数据结构：

etcd 数据存储结构

可以看到我是使用 get 方法向 etcd 发送请求的，请求的是部署在预发环境（PRE）的搜索服务（search）；在它的根目录“/search_PRE”下，仅存储了一个应用实例的信息，这个实例的key是“172.18.100.31-86”；对应的value是“172.18.100.31:86‘’，整个注册过程是这样的：

① 通过代码为容器应用程序生成随机端口，和宿主机正在使用的端口进行比对，确保端口没有冲突后写入程序配置文件；

② 把通过 python 和 etcd 模块编写的服务注册工具集成在脚本中，将 IP 地址和上一步获取的随机端口以参数的方式传递给服务注册工具；

③ 待应用程序完全启动后，由服务注册工具以约定好的数据结构将应用实例的写入 etcd 集群，完成服务注册工作；

④ 容器定时向 etcd 发送心跳，报告存活并刷新 ttl 时间；

⑤ 容器脚本捕获 rancher 发送至应用实例的 singnal terminal 信号，在接收到信号后向 etcd 发送 delete 请求删除实例的数据。

注：在 ttl 基础上增加主动清除功能，在服务正常释放时，可以立刻清除 etcd 上注册信息，不必等待 ttl 时间。

经验总结：容器在重启或者意外销毁时，让我们一起看一下这个过程中容器和注册中心都做了什么事情？

应用在注册是携带 key 和 value 时携带了 ttl 超时属性，就是考虑到当服务集群中的实例宕机后，它在etcd中注册的信息也随之失效，若不予以清除，失效的信息将会成为垃圾数据被一直保存，而且配置管理工具还会把它当做正常数据读取出来，写入web server的配置文件中。

要保证存储在etcd中的数据始终有效，就需要让etcd主动释放无效的实例信息，来看一下注册中心刷新的机制，代码直接奉上：

服务的发现

confd 是一个轻量级的配置管理工具，支持 etcd 作为后端数据源，通过读取数据源数据，保证本地配置文件为最新；不仅如此，它还可以在配置文件更新后，检查配置文件语法有效性，以重新加载应用程序使配置生效。这里需要说明的是，confd 虽然支持 rancher 作为数据源，但考虑易用性和扩展性等原因，最终我们还是选择了 etcd。

和大多数部署方式一样，我们把 confd 部署在 web server 所在的 ECS 上，便于 confd 在监测到数据变化后及时更新配置文件和重启程序。confd 的相关配置文件和模板文件部署在默认路径 /etc/confd 下，目录结构如下：

/etc/confd/
├── conf.d
├── confd.toml
└── templates

confd.toml 是 confd 的主配置文件，使用 TOML 格式编写，因为我们 etcd 是集群部署，有多个节点，而我又不想把 confd 的指令搞的又臭又长，所以将 interval、nodes 等选项写到了这个配置文件里。

cond.d 目录存放 web server 的模板配置源文件，也使用 TOML 格式编写。该文件用于指定应用模板配置文件路径（src）、应用配置文件路径（dest）、数据源的 key 信息（keys）等。

templates 目录存放 web server 下每个应用的模板配置文件。它使用Go支持的text/template语言格式进行编写。在 confd 从 etcd 中读取到最新应用注册信息后，通过下面的语句写入模板配置文件中：

{{range getvs "/${APP_NAME}/*"}}
server {{.}};
{{end}}

服务发现

通过 supervisor 管理 confd 进程。confd 在运行后会每隔5秒对 etcd 进行轮询，当某个应用服务的 K/V 更新后，confd 会读取该应用存储在 etcd 中的数据，写入到模板配置文件中，生成这个应用配置文件，最后由 confd 将配置文件写入到目标路径下，重新加载 nginx 程序使配置生效。

总结

本文是五阿哥运维技术团队针对 Docker 容器技术在如何在持续交付过程中探索和实践，目前已经将发布部署权限开放给应用开发的 owner，实现7*24小时“一站式”的持续交付，整体提高了公司的研发过程的交付能力。

接下来会不断优化持续交付过程中遇到的各种场景，逐渐完善容器云平台，同时会将容器云平台各种功能，总结的经验和教训不断分享给大家，给大家在工作中一些参考，避免走重复的“弯路”。

作者：布道，大型互联网公司运维技术负责人，拥有10年的互联网开发和运维经验。一直致力于运维工具的开发和运维专家服务的推进，赋能开发，提高效能。广告时间：最后给自己代个盐~~欢迎大家有空时翻下我牌子(知乎号：布道 )，看看之前的文章，再点个赞呗，顺便关注下专栏“开发运维”。
本文转载自知乎专栏
链接：https://zhuanlan.zhihu.com/p/31760826

更多相关文章阅读

如何实现多维智能监控？--AI运维的实践探索

IT 从业者必备的20个效率工具，亲测有效

腾讯赵建春：AI浪潮下的高效运维思考及实践

AI运维、爱标准 | GOPS2017上海站精彩实录【附PPT】

Jenkins创始人带您探访国内首届Jenkins用户大会（附PPT）

点击阅读原文下载 GOPS2017·上海站演讲PPT（密码: egeq）

今天看啥 - 高品质阅读平台
本文地址：http://www.jintiankansha.me/t/JHRA08MM4D