郑钦洲 分布式实验室 

在当前DevOps的趋势下，持续集成（CI）和持续部署（CD）使得项目构建和发布更加的快捷频繁可靠，那么如何快速搭建CI/CD流水线就至关重要，本文讲解如何使用Ansible、Docker、GitLab Runner快速打造CI/CD工作流。

GitLab内置的CI/CD工具GitLab Runner

公司使用GitLab来管理代码，GitLab在生态环境上提供gitlab-runner来实现CI/CD。
安装搭建：下载rpm包安装，使用gitlab-runner命令注册到GitLab上，并使用Docker执行器。gitlab-runner start启动gitlab-runner服务。
使用：在项目根目录下，创建文件.gitlab-ci.yml，导入z_qz/cicd/templates/Maven.gitlab-ci.yml：

z_qz/cicd项目文件结构：

Demo项目以Maven打包为例。
Demo有两个流水线：build和deploy，并引入需要的操作步骤文件：

1. stages:

2.  - build

3.  - deploy

4. 
   

5. include:

6.  - local: /java/.before-script.yml

7.  - local: /java/maven_build.yml

8.  - local: /java/deploy.yml

在before-script.yml里声明了一些函数：

在maven_build.yml文件里实现Maven和Docker打包，并上传Docker镜像到Harbor上：

打包阶段：当环境变量YPSX_STAGE == BUILD才会触发build流水线，并且根据variables传递过来的JDK_VERSION来启动Maven容器，进行maven package，docker build操作。
在deploy.yml文件里实现部署应用到目标机器上：

SSH_PRIVATE_KEY变量参数在项目组里配置（可作用于组下面所有项目）：
组-> settings->CI/CD -> Variables
一些安全系数要求高的参数，可以在这边设置，像Harbor账户密码。

Docker&Harbor（私有Hub）

在maven package生成JAR文件，然后Docker将jar文件打包成应用镜像，上传到Harbor。
在Dockerfile里用了ARG，从docker build --build-arg里获取参数进行JAR文件路径和JAR文件替换，docker build找到JAR文件路径，拷贝JAR到镜像，制作应用镜像。
这边使用Harbor，使用docker-compose命令，就能安装启动，非常方便，以及提供镜像清理。

Ansible自动化运维工具

Ansible通过SSH管理目标机器，机器信息（inventory）使用该格式/etc/ansible/{env}_hosts管理各个环境机器。
使用ansible roles管理发布过程：

check检查Agent和Logspout容器是否存在（dockercontainerinfo new in ansible 2.8）：

installagent和installlogspout是应用安装前的初始化：

install_app安装升级APP，优雅关闭，检查服务状态，销毁应用容器，启动应用容器，检查应用是否启动成功：

发布系统

前端使用antd-pro[1]。
后端使用Golang Gin开发审批流程和批次发布等。
通过调用GitLab API创建Pipeline触发流水线[2]。

1. curl --request POST --header "PRIVATE-TOKEN: ********************" \

2. 
   

3. --header "Content-Type: application/json" \

4. 
   

5. --data '{ "ref": "test", "variables": [{"key": "YPSX_STAGE", "value":"BUILD"}, {"key": "JDK_VERSION", "value": "11"}] }' \

6. 
   

7. "https://gitlab.example.com/api/v4/projects/99/pipeline"

在Variables里传递：

1. JAR_PATH: jar文件的路径，相对项目根目录

2. 
   

3. JAR_FILE: jar文件名

4. 
   

5. 其他参数

还可以指定build流水线的镜像，这边传递JDK_VERSION=11。
镜像将使用Maven：3.6.3-jdk-11。
在没有Web管理系统前，我们可以骚气地操作，git tag dev_xxx针对当前的tag代码，打包、发布到dev环境：

  only:    variables:      - $CI_COMMIT_TAG =~ /^dev_.*/

Q&A

Q：有对照过Jenkins，Drone等其他CI/CD工具吗，出于什么考虑最后选择gitlab-runner，未来有考虑过Kubernetes这方面的集成吗？A：gitlab-runner，Jenkins，Drone都属于配置即操作的工具，因为使用GitLab来管理代码，gitlab-runner又很好贴近GitLab，维护成本也不高，类似Jenkins的Node，安装注册，就能拿来用。正在引入Kubernetes中。
Q：从镜像到部署到Kubernetes，是通过什么实现的，kubectl还是镜像更新触发？在这个过程中能不能调整一些deployment的配置，比如resource.cpu.request或者Ingress的一些配置？A：这边，现在没有使用Kubernetes（二季度将引入Kubernetes），只将应用Docker镜像，发布到目标机器上，如果引入Kubernetes，将开发调用Kubernetes的API server接口，传递yaml配置文件。
Q：对于项目是如何进行部署检测的？对tag进行监听吗？A：在项目根目录下添加配置文件.gitlab-ci.yml，有only和except数组，支持branch，tag，环境变量，MR，文件变动（像README.md）。
Q：相比Jenkins如何？A：轻量些，GitLab就是Server端，gitlab-runner就是节点。不需要配置git clone。
Q：gitlab-ci.yml放在根目录下， 是否会增加维护成本。这些文件的改动是业务研发修改，还是专人维护呢？A：.gitlab-ci.yml四行代码，就这四行固定，加到项目脚手架里，没有维护成本，通过include cicd项目，运维在cicd项目里进行维护打包和发布操作代码，对业务代码，零影响。
Q：请问有没有高并发拉取镜像的问题？有没有遇到过在高并发下GitLab性能下降的问题？A：Harbor（机器配置偏低）遇到过高并发拉取问题，在一次大量迁移的时候，没有按批次操作，平常开发发布，Harbor完全可以胜任，高并发下对GitLab影响不大，GitLab主要还是触发gitlab-runner去运行打包和发布，gitlab-runner机器配置稍微高些，因为除了Java的Maven和Gradle，我这边还将Node打包也集成在这个项目里。
Q：公司目前就20来个开发，适合自己搞这套吗？A：如果你们还在手动发布的话，建议你们使用gitlab-runner，可以使用git tag方式，发布，我们也是一步一步走过来的，先前没有发布系统，开发使用打tag方式发布，这个没有约束看开发个人，后面开发了套发布系统，在上面做了工作流管理。
相关链接：

1. https://preview.pro.ant.design/

2. https://docs.gitlab.com/ee/api/pipelines.html#create-a-new-pipeline