用GitLab-Runner打造锋利的CI/CD

原文链接：https://juejin.im/post/5cb5309cf265da034c701d74

一、前言

本文介绍的内容包含：

• 理解CI/CD及其必要性
• gitlab-runner安装与注册
• gitlab-ci配置说明
• ssh免密登录
• rsync部署文件
• 多环境发布与回滚
• 高频出现的问题并解决

阅读本文需要你：

• 有一定的ssh知识基础，一份SSH操作指南
• gitlab ci/cd概念基础
• 花10min左右的时间

二、CI/CD科普

2.1 CI与CD

<font color="#ff502c">持续集成（Continuous Integration）</font>指开发人员在特性分支（频繁）提交代码，立即执行构建和单元测试，代码通过测试标准后集成到主干的过程。强调的是分支代码的提交、构建与单元测试，这个过程的产出是单元测试报告。

image
说明：这里的 test 是指unit test（图片来源见文末参考链接）

<font color="#ff502c">持续交互（Continuous Delivery）</font>是在持续集成的基础上，将构建的代码部署到「类生产环境」，完成QA测试之后手动部署到生成环境的过程。强调代码部署，这个过程产出测试报告。

image
说明：这里的 test 是真的test

<font color="#ff502c">持续部署（Continuous Deployment）</font>是持续交互的下一步，强调部署生产环境代码的过程自动化，同时可以处理上线通知等操作。

image
说明：与持续交互主要就是手动跟自动的区别。

2.2 CI/CD的必要性

以一言概之的话我想应该是：机械的事情让机器做。一个开发团队，没有CI/CD，我想可能是这样子的：无法管理代码多人多地协作（git repository也是CI的一部分），系列的shell需要人工处理，代码的发布需要登录服务器等等；相反，拥有CI/CD，这些事情都交给机器去完成，腾出的碎片时间去做更有意义的事情（比如摸鱼放松下）。

2.3 理想的CI/CD开发流应该是怎样的？

我认为理想的CI/CD开发流应该包含三个阶段：build、deploy和notify。build阶段专注做代码构建与单元测试，deploy阶段专注做test/gray/prod环境的代码部署，notify阶段专注做上线通知，如下图;

image

以下内容围绕build和deploy两个阶段完成从<font color="red">0到1的部署</font>。笔者的系统环境：<font color="red">Ubuntu 18.04.1 LTS</font>

三、Gitlab-Runner安装并注册

3.1 安装runner

sudo apt-get install gitlab-runner

官网文档 install gitlab-runner

3.2 注册runner

sudo gitlab-runner register

之后是QA式操作，按照提示语输入信息即可，可参考官网操作，需要注意：

①. gitlab host和token在你的gitlab项目上找，页面路径是：Settings >> CI/CD >> Runners

②. runner执行器选择 docker，image（镜像）输入 node:8.11.2-stretch

注册成功后，我们就能在：Settings >> CI/CD >> Runners下看到我们注册的runner

image

四、Gitlab-Runner配置

在项目根目录下新建 .gitlab.yml文件，加入如下内容：

image
unit_test、compile和deploy_test是自定义的job名字，另外几点配置说明：

• cache：
  cache设置缓存文件，这里缓存node_module依赖包，提高job构建效率，定义在全局，对所有的job生效；
• stage：
  设置build和deploy两个阶段
• artifacts：
  下载文件。定义compile产出的dist文件夹缓存到gitlab服务器，提供下载（gitlab web页面下载）或者在同一个stage的各job之间共享；
• only：
  定义job的触发条件，可以指定分支名、tags（打tag时触发）等（这些条件是或的关系，满足其中一个即触发）；
• when：
  定义job的触发时机，值可以为：on_success、always、manual等；
• dependencies：
  定义当前job所要依赖的job；
• environment：
  定义当前job所属的环境，对<font color="red">回滚操作非常有用</font>，后面详述；
• deploy_test这个job的 before_script 有很长一段内容，这里的作用是配置ssh免密登录，后面详述。

五、ssh免密登录

5.1 为什么需要免密登录？

• 构建产出的dist文件要传输到目标服务器（测试机/生成机），要么基于http网络协议、要么基于ssh协议（或其他文件传输协议？）
• 基于http需要写文件接收接口，这里直接使用基于ssh传输文件的rsync，简单、安全！
• runner内定义的一系列script是在一个docker容器内执行的，无法人工干预，那么登录服务器就要做成免密。

先在本机（注册runner所在的机器）配一遍免密登录服务器的流程：

5.2. 生成一对公私钥

使用rsa作为非对称加密方式：

ssh-keygen -t rsa -C "$(whoami)@$(hostname)-$(date -I)"

说明：一路enter就好了，切记 Enter passphrase 时直接enter，这样就是 no passphrase。如果你非要加个password，对不起，没救了！

5.3. 定义ssh config内容

在~/.ssh/config文件写入以下内容（文件不存在直接创建）：

Host any_name
  Port your_port
  HostName server_ip
  User user
  IdentityFile ~/.ssh/id_rsa

说明：定义ssh的config文件是为了快捷访问，就像你配置host一样，没有hostname，你只能访问ip。配置后你就可以通过 ssh any_name 登录服务器了。当然，不出意外，会要求你输入服务器的登录密码。

5.4. 免密登录

免密登录的精髓就是：<font color="red">把本机的公钥存储到目标服务器的authorized_keys文件内</font>（该文件服务器上不存在可以直接创建。）

ssh-copy-id -i ~/.ssh/id_rsa.pub username@ip

特别地：如果你的端口不是默认的22端口，则加上端口号 -p PORT

5.5. 验证登录

ssh any_name

不出意外，你应该可以直接登录服务器了。那么，我们回到gitlab的配置上～

六、gitlab上定义ssh配置信息

我们进入gitlab页面位置：Settings >> CI/CD >> Environment variables下定义 .gitlab.yml 上出现的几个变量：

image

• SSH_PRIVATE_KEY：把本机（runner所在机器）的私钥复制过来：~/.ssh/id_rsa
• TEST_CONFIG：把刚才ssh config定义的信息复制过来：~/.ssh/config
• TEST_KNOWN_HOST：定义这个变量是为了让ssh对服务器进行身份确认（不然会被ssh认为是一个不被信任的环境），变量值使用以下命令生成：

ssh-keyscan -p PORT IP

七、使用rsync传输文件

rsync -rve ssh dist/ user@hostname:project_path/dist

说明：hostname就是你在ssh config定义的Host值。rsync操作指南

八、定义environment

设置environment的好处是可以对各发布环境进行管理，特别是线上发布，出现bug可以及时操作回滚。
在gitlab web页面位置：Operations >> environments 可以查看当前项目下的environments，点击其右侧的预览按钮即可<font color="red">查看</font>对应环境的<font color="red">发布</font>效果

image
点击其中一个environment：test_env，可以查看当前环境下的所以发布记录，右侧的按钮可以执行<font color="red">回滚操作</font>。
image

九、踩坑小记

在整个搭建过程，很多都是关于ssh登录服务器的问题，择几个高频出现的问题说明下：

9.1. Host key verification failed

当我们初次使用ssh登录服务器的时候，ssh会要求验证远程服务器的身份，通过身份验证之后才允许连接。解决该问题有两种方式：

• 设置免身份认证：
  在ssh config配置中加一段StrictHostKeyChecking no，如此.gitlab.yml配置中就可以去掉关于known_hosts的设置了；
• 通过远程服务器的公钥指纹进行身份认证：

ssh-keyscan -p PORT IP

将脚本输出的结果保存在~/.ssh/known_hosts文件中（<font color="#ff502c">@gitlab上定义ssh配置信息</font>部分有提及），这样ssh在登录之前会从该文件中拿到目标服务器的公钥指纹进行身份确认。

9.2. Permission denied, please try again

出现这个问题是没有配置「ssh免密登录」，配置操作见<font color="#ff502c">@免密登录</font>部分

9.3. rsync: Failed to exec a: No such file or directory

这个问题一般情况下并不会出现，但却是个实实在在的坑。我在deploy的job里面通过rsync将构建生成的dist目录上传至服务器，抛出不存在该目录的错误。

我在compile这个job执行后，list出根目录下的文件/夹（gitlab-runner的输出）：

image
在本机查看根目录下的文件/夹：
image
可以看见，gitlab-runner执行构建后实实在在是生成了dist目录，但进入下一个job的时候却提示不存在！问题出在：
dist目录并不是由构建直接生成的文件夹，而是release-[timestamp]目录的<font color="red">软链接</font>（笔者用的是Ubuntu，在webpack配置里面设置了个骚操作：每次构建产出一个release-[timestamp]目录，同时建立一个软链。软链不是一个目录，它的内容就是目标文件夹的地址）。
在我的.gitlab.yml配置里面，artifacts缓存的是dist，没有把实际的文件夹release-[timestamp]缓存，那么进入下一个job的时候，自然就提示不存在该目录了。解决办法是：

cp dist public

在compile这个job里面，构建之后复制一份dist目录，再将public目录交由artifacts缓存。

参考文章

• 使用 SSH config 文件
• 利用 ssh-keyscan 获取集群机器 SSH 公钥指纹
• The Product Managers’ Guide to Continuous Delivery and DevOps