基于Docker的自动化部署

概述

相较于传统的部署方式,Docker以镜像为分发单元的部署方式更容易进行应用迁移,各个公有云服务商类似于码头港口,Docker容器类似于集装箱,因此这种迁移可以在不同的公有云服务商之间。当一个新的应用需要依赖某个新的软件库时,只需要把这个依赖库打包到该应用的Docker镜像中,然后用这个镜像来启动容器即可,不需要在容器的宿主机中安装这个依赖包。每个应用一个容器的部署方式,也使得问题得到分解,有助于故障定位。

部署架构图

上面的架构图中,每个项目在Gitlab上分别对应3个Project,一个放置代码,一个放置测试环境的配置文件,另外一个放置生产环境的配置文件。而在Jenkins中,需要建立4个Project,其中3个Project和Gitlab上的Project一一对应,当Gitlab上的项目有更新时,对应的Jenkins项目会被调用。Jenkins的第4个Project在Gitlab没有对应的Project,也就没有跟任何Web Hook关联,需要运维管理员手动触发构建。

在我们的项目中,测试环境和生产环境目前分别对应阿里云的一台虚拟服务器,从Docker的角度看,这两台虚拟机就是Docker容器的宿主机。再回到架构图,两个环境都有Deploy Agent,也就是一个轻量级的部署服务,运行在宿主机中。CMS,API等应用都分别运行在自己的Docker容器中,每个容器都有Nginx和PHP环境,这样容器里面Nginx的配置就很简单了。每个环境都有一个Nginx Proxy容器,这个容器起到反向代理的作用,所有对CMS等应用的请求都先经过Nginx Proxy容器。新增一个后端容器应用时,只需要在Nginx Proxy的配置文件中添加一条代理配置即可。

部署流程

部署流程主要涉及到两个角色,即开发者和运维管理员,触发构建或部署分为4个场景,分别如下:

  • 开发者将代码合并到某个项目的master分支:

Git的Web Hook调用Jenkins中src-build-project项目,Jenkins项目将自动从Gitlab下载对应master分支的代码,并从Test配置库和Product配置库下载最新配置文件,执行构建脚本,分别生成Test环境和Product环境的项目镜像并上传到Docker私有镜像服务器。然后Jenkins通知Test环境的Deploy Agent有哪些更新,Deploy Agent根据通知内容将刚刚更新的镜像从镜像服务器拉到Test环境并进行部署(停止旧的容器,使用新镜像启动新容器)。

  • 开发者将配置文件上传或更新到某个配置项目:

Git的Web Hook调用Jenkins中test-config-project项目,Jenkins自动从Gitlab下载对应项目master分支的代码和Test配置库中的配置文件,执行预先写好的编译构建脚本,生成Test环境镜像并上传到Docker私有镜像服务器。然后Jenkins通知Test环境的Deploy Agent有哪些更新,Deploy Agent根据通知内容将刚刚更新的镜像从镜像服务器拉到Test环境并进行部署。

  • 运维管理员将配置文件上传或更新到某个配置项目:

Git的Web Hook调用Jenkins中product-config-project项目,Jenkins自动从Gitlab下载对应项目master分支的代码和Product配置库中的配置文件,执行构建脚本生成Product环境镜像并上传到Docker私有镜像服务器。

  • 运维管理员手动触发Jenkins进行生产环境部署:

运维管理员登录到Jenkins的Web界面,选择deploy-project,选择带参数的构建方式,这样就可以把需要部署的版本号等信息以参数的形式传递给deploy-project,接着这些信息被传递到生产环境的Deploy Agent,根据这些信息Deploy Agent就会从镜像服务器拉取相应的镜像进行部署。

欢迎微信扫码,进入【技术人成长】社群逛逛。