58 赶集基于 Docker 的自动化部署实践

【编者的话】随着 58 业务的发展，机器和服务数量也日益庞大，在多环境下，服务的管理和依赖难以维护。基于 Docker 带来的技术红利，咱们借助 Docker 和 Kubernetes 提供了镜像的自动打包，单一镜像在测试-沙箱-生产-稳定四个环境的流转，以及测试环境统一的 Nginx 入口。至此，开发同窗能够再也不为资源和环境问题困扰，提升了生产效率。

1. 项目背景

58现有的部署系统只管理线上环境，在资源和环境两个维度，分别存在如下问题：

资源	环境
业务线对服务器等资源利用率低	测试环境混乱
不一样业务对资源诉求不一致	没有稳定环境
分配效率低，资源不可控	各服务器线上环境不一致，难以迁移

在这个现状下，咱们提出了『基于 Docker 的自动化部署』项目，在不破坏现有项目管理流程的基础上，实现接管全部环境的部署，提升生产效率。

2. 自动打包

引入 docker 技术以后，首先给开发人员带来了编写 dockerfile 的问题。为了下降使用成本，咱们提供了若干标准的 dockerfile 模板，业务线 RD 同窗能够根据不一样业务场景选择合适的模板。同时提供标准 dockerfile 也带了其它好处，相似项目之间通用的 layer 比较多，减小了同类型集群镜像的差别性，在镜像存储，和拉取镜像的时候带来了方便。

一个典型的 dockerfile 模板以下：

FROM registry.58corp.com/base/centos6.8:14

MAINTAINER 58op

RUN yum install -y tomcat apr tomcat-native EXPOSE 8001
ENTRYPOINT sh /sbin/startup.sh WORKDIR /opt/web/{{CLUSTER_NAME}} ARG CACHE=1
RUN mkdir -p /opt/web/{{CLUSTER_NAME}}/ /opt/log/wormhole/{{CLUSTER_NAME}}/ && rsync -ac {{BUILD_IP}}::root/root/output/ /opt/web/{{CLUSTER_NAME}}/ && chown -R work:work /opt USER work复制代码

运行 docker build 的时候能够加上 --build-arg 参数，给构建环境的 CACHE 变量指定不同的值，防止后面的业务代码层被打包机缓存。

在此基础上，咱们还实现了自动打包流程，在完成提测以后，触发自动打包的流程，在 kubernetes 中用跑一个 Job，完成镜像构建的步骤，同时上传本次运行日志，方便定位未知的问题。这样在部署阶段，业务线 RD 只须要选择集群名，须要部署的环境和版本号就能部署容器了。

3. 全环境流转

目前在58赶集内部大多数业务有如下四种环境：

环境	数据源	用途
测试	线下库	RD 开发自测，QA 线下验证功能
沙箱	线上库	接入少许线上流量，预上线验证功能
线上	线上库	生产环境
稳定	线下库	给测试环境下游的服务提供依赖

现有的部署系统『USP』接管了线上环境的部署，能实现自动从产品库拉取代码包，完成部署，摘流量，重启服务等操做。对于剩下三种环境，基本上是各自为政的状态，大多由RD、QA 同窗手动搭建，比较混乱。

为了实现单一镜像能在不一样的环境下正常生成容器，首先要解决不一样环境配置文件的问题。咱们写了一个切换配置文件的脚本，而后把此脚本和全部环境的配置文件在打包阶段均置入到镜像中，而后在不一样环境运行时，添加表明当前环境的系统环境变量，这样在不一样环境生成的容器就能启用对应的配置文件了。

4. 测试 NGINX

因为分类信息业务的特殊性，58赶集的二级域名是城市分站缩写，不一样业务须要经过 URL 来区分，因此咱们可能有着业内最复杂的 NGINX 配置。对于不少业务，若是没有 NGINX 配置，直接 IP:端口 访问后端服务，是不能正常进行测试的，再加上测试环境须要频繁变动版本，还有多版本并行测试的状况，更是增长了测试 NGINX 的配置复杂程度。

测试 NGINX 的实现原理以下图：

1. 首先借助于腾讯 TGW（可用 LVS 代替），预先申请不少 VIP 放入资源池，并将后端 RS 绑定为咱们统一提供的 NGINX 机器。
2. 测试 NGINX 是线上 NGINX 的同步实例，配置能够同步更新。
3. 每次部署完成后，从 VIP 资源池中取出一个可以使用的 VIP，记录下部署容器和 VIP 的关系；同时更新 NGINX UPSTREAM 配置。
4. VIP 携带着集群、版本等部署信息，由于用户只面对版本号，那么容器=版本，版本=测试任务，VIP 也就携带了测试任务的信息，那么经过 VIP 就能定位到容器了。

Q&A

Q：如何更新 nginx upstream？

A：Nginx 机器上部署有 Agent，Web 类的业务有统一的框架，服务启动时会向 Consul 注册。Agent 订阅 Consul 中的节点数据，而后配合 nginx dyups 模块，动态修改 nginx upstream。

Q：打包好镜像后，使用镜像还用再进行配置吗，就是说还用手动配置吗？

A：不用配置，不一样环境之间流转的是同一个镜像，包含了各个环境的全部配置，经过启动容器的环境变量来识别切换。

Q：Docker 的正确的使用姿式，在本地环境已经构建了企业私有 Registry Harbor，那么我要构建基于业务的应用时，是先从 Linux 系列的像 Ubuntu 或 CentOS 的 Base 的 Docker 镜像开始，而后经过 Dockerfile 定制业务需求，来使用吗？

A：咱们基础镜像统一采用 CentOS 6.8，不一样的业务有不一样的 Dockerfile 模板，生成镜像的过程业务对 Dockerfile 是透明的。

Q：这里实现灰度发布了吗？可否不停交易更新？

A：实现了 PV 灰度，暂时没实现 UV 灰度，对于无状态的业务已经能知足需求了，对于有状态的业务，好比交易类型的主要仍是须要程序架构来实现。

Q：请问如何保证 NGINX 的高可用？

A：域名->CNAME（快速切换IP解析）->LVS（多个rip）->多个 NGINX 实例（平行实例）；NGINX 同时和 LVS 保持心跳来自动踢掉故障的实例。

原文连接：58 赶集基于 Docker 的自动化部署实践