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

58赶集运维开发高级工程师史祥阳

  1. 项目背景

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

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

  1. 自动打包

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

一个典型的 dockerfile 模板如下:

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

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

  1. 全环境流转

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

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

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

  1. 测试 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 就能定位到容器了。