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 现有的部署系统只管理线上环境,在资源和环境两个维度,分别存在以下问题:
TIM截图20170719101122.png

在这个现状下,我们提出了『基于 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赶集内部大多数业务有以下四种环境:
TIM截图20170719101318.png

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

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

4. 测试 NGINX

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

测试 NGINX 的实现原理如下图:
15002572262155.jpg

  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 保持心跳来自动踢掉故障的实例。
以上内容根据2017年07月18日晚微信群分享内容整理。分享人史祥阳,58赶集运维开发高级工程师。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesa,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

0 个评论

要回复文章请先登录注册