【编者的话】随着 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 的实现原理如下图:
- 首先借助于腾讯 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 保持心跳来自动踢掉故障的实例。