DockOne微信分享（一三二）：58 赶集基于 Docker 的自动化部署实践

本文主要是介绍DockOne微信分享（一三二）：58 赶集基于 Docker 的自动化部署实践，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

本文讲的是DockOne微信分享（一三二）：58 赶集基于 Docker 的自动化部署实践【编者的话】随着 58 业务的发展，机器和服务数量也日益庞大，在多环境下，服务的管理和依赖难以维护。基于 Docker 带来的技术红利，我们借助 Docker 和 Kubernetes 提供了镜像的自动打包，单一镜像在测试-沙箱-生产-稳定四个环境的流转，以及测试环境统一的 Nginx 入口。至此，开发同学可以不再为资源和环境问题困扰，提高了生产效率。

【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题，包括：Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。

1. 项目背景

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

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

2. 自动打包

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

一个典型的 Dockerfile 模板如下：

dockerfile
FROM registry.58corp.com/base/centos6.8:14MAINTAINER 58opRUN 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赶集内部大多数业务有以下四种环境：

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

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

4. 测试 NGINX

由于分类信息业务的特殊性，58赶集的二级域名是城市分站缩写，不同业务需要通过 URL 来区分，所以我们可能有着业内最复杂的 NGINX 配置。对于很多业务，如果没有 NGINX 配置，直接 IP:端口访问后端服务，是不能正常进行测试的，再加上测试环境需要频繁变更版本，还有多版本并行测试的情况，更是增加了测试 NGINX 的配置复杂程度。

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

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