本文讲的是DockOne微信分享（一三二）：58 赶集基于 Docker 的自动化部署实践【编者的话】随着 58 业务的发展，机器和服务数量也日益庞大，在多环境下，服务的管理和依赖难以维护。基于 Docker 带来的技术红利，我们借助 Docker 和 Kubernetes 提供了镜像的自动打包，单一镜像在测试-沙箱-生产-稳定四个环境的流转，以及测试环境统一的 Nginx 入口。至此，开发同学可以不再为资源和环境问题困扰，提高了生产效率。
【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题，包括：Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。
在这个现状下，我们提出了『基于 Docker 的自动化部署』项目，在不破坏现有项目管理流程的基础上，实现接管所有环境的部署，提高生产效率。
一个典型的 Dockerfile 模板如下：
运行
在此基础上，我们还实现了自动打包流程，在完成提测之后，触发自动打包的流程，在 Kubernetes 中用跑一个 Job，完成镜像构建的步骤，同时上传本次运行日志，方便定位未知的问题。这样在部署阶段，业务线 RD 只需要选择集群名，需要部署的环境和版本号就能部署容器了。
现有的部署系统『USP』接管了线上环境的部署，能实现自动从产品库拉取代码包，完成部署，摘流量，重启服务等操作。对于剩下三种环境，基本上是各自为政的状态，大多由RD、QA 同学手动搭建，比较混乱。
为了实现单一镜像能在不同的环境下正常生成容器，首先要解决不同环境配置文件的问题。我们写了一个切换配置文件的脚本，然后把此脚本和所有环境的配置文件在打包阶段均置入到镜像中，然后在不同环境运行时，添加代表当前环境的系统环境变量，这样在不同环境生成的容器就能启用对应的配置文件了。
测试 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: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赶集内部大多数业务有以下四种环境：
现有的部署系统『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 就能定位到容器了。
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 保持心跳来自动踢掉故障的实例。
以上内容根据2017年07月18日晚微信群分享内容整理。分享人史祥阳，58赶集运维开发高级工程师。DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesa，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
原文发布时间为：2017-07-19
本文作者：史祥阳
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：DockOne微信分享（一三二）：58 赶集基于 Docker 的自动化部署实践
