GitLab CI实现CI CD

写在前面
- 为什么使用GitLab
- 为什么要推荐使用持续继承和持续交付
搭建GitLab环境
- 流程梳理
- GitLab Runner
更新yum安装源
安装gitlab-runner
- 配置.gitlab-ci.yml
- 问题总结
相关参考

tags: [gitlab]
categories: [CICD]

写在前面

Linu系统 CentOS7
已安装GITLab
已安装Maven并配置好了环境变量
已安装了JDK8

为什么使用GitLab

界面干净简洁
通过YML配置，很方便，对新手较为友好
自己的代码仓库就是GitLab，正好一起使用了

为什么要推荐使用持续继承和持续交付

在我理解来看，主要还是为了两点
第一是减少重复操作，毕竟对于发布版本来说，打包，测试以及部署流程是重复劳动，使用工具来自动化完成可以节省时间，也避免了人为操作导致的发布版本出错
第二就是可以及时发布到环境里，避免测试和生产版本和实际开发版本产生较大的差异，提前发现问题，减少项目交付的风险

搭建GitLab环境

流程梳理

一般实际项目发布需要经过拉取代码、打包、移至发布目录、部署，GitLab CI也是一样，区别在于实际执行的GitLab Runner和GitLab是一家的，只要设置好关联关系，就会自动获取代码，我们只需要专注于后面步骤即可
接着使用Maven打包，然后移至部署目录，部署

GitLab Runner

GitLab Runner就像一个执行器，它是这一系列包括执行脚本，控制流程的实际执行者，通过配置文件.gitlab-ci.yml来定制它的行为

gitlab runner 安装 ```shell
更新yum安装源
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash

安装gitlab-runner

yum install gitlab-ci-multi-runner


2. gitlab runner 注册
```shell
gitlab-runner register

接着会有一系列信息需要补全，就是上图框框里面的信息，用于定义一个Runner，其中最重要的信息是和GitLab通讯的URL和Token,定义全局的Runner在管理员界面Runner设置中的URL和Token填入即可，定义和项目绑定的Token则在项目的CI / CD Settings中配置

注册完毕后就可以在Runner中看到该Runner了

配置.gitlab-ci.yml

在项目的根目录下新建.gitlab-ci.yml文件，这是依据代码仓库目录而构建的，聚合项目也是一样配置在根目录
具体配置说明可以参照下一篇博文

测试配置


stages:
  - build
  - deploy
job1:
  stage: deploy
  script:
    - echo 'job1'
job2:
    stage: build
  script:
    - echo 'job2'

就用以上的配置来，代码推送成功后，输出如下

job2
job1

我的配置

按照之前的思路实现，分别定义编译和部署两个阶段，编译阶段执行源代码的编译和打包以及文件移动，部署阶段使用pm2工具来启动服务，不使用该工具的人可以自己书写脚本启动

# 定义 stages（阶段，会依次执行）
stages:
  - build
  - deploy
variables:
  EUREKA_SERVER_TARGET_DIR: '/home/gitlab-runner/builds/U8Y_1HGM/0/zoombar/zoombar/EurekaServer/target'
  USER_CENTER_TARGET_DIR: '/home/gitlab-runner/builds/U8Y_1HGM/0/zoombar/zoombar/UserCenter/target'
  GATE_WAY_TARGET_DIR: '/home/gitlab-runner/builds/U8Y_1HGM/0/zoombar/zoombar/GateWay/target'
  CONFIG_TARGET_DIR: '/home/gitlab-runner/builds/U8Y_1HGM/0/zoombar/zoombar/Config/target'
# 打包并移至部署目录
zoombar_build:
  stage: build
  # 在哪个分支才会执行脚本
  only:
    # - dev
    # - release
    - master
  script:
    - echo '测试zoombar代码编译功能'
    - mvn clean install -Dmaven.test.skip=true
    - mv -f ${EUREKA_SERVER_TARGET_DIR}/eureka_server-exec.jar /opt/zoombar/
    - mv -f ${USER_CENTER_TARGET_DIR}/user_center-exec.jar /opt/zoombar/
    - echo 'build success'
  tags:
    - build
# 部署构建服务
zoombar_deploy:
  stage: deploy
  only:
    - master
  script:
    - echo '构建应用阶段'
    - pm2 restart 10
    - pm2 restart 9
    - echo 'deploy success'
  tags:
    - build

测试

我们push完毕代码后，GitLab会驱动相应的Runner来执行脚本，登录GitLab进入项目目录，可以观察到一个月牙型图标（我的已经部署好了所以是勾），代表Runner正在执行

点击该图标进入部署栏，点击相应的阶段可以观察到详细的日志打印输出

问题总结

问题1：Gitlab Runner提示无权限执行文件移动或者访问操作

遇到的第一个问题，通过whoami打印，知道了GitLab Runner实际执行使用的是gitlab runner这个用户，而项目目录和一些脚本时只有root用户才能访问和执行的
通过进程查询也能证明

ps aux|grep gitlab-runner
/usr/bin/gitlab-ci-multi-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner
--working-directory：设置工作目录, 默认是/home/{执行user}
--config：设置配置文件目录，默认是/etc/gitlab-runner/config.toml
--user：设置执行用户名，默认是gitlab-runner

所以这里需要修改gitlab runner的默认用户为root

# 删除gitlab-runner
sudo gitlab-runner uninstall
#安装并设置--user(设置为root)
gitlab-runner install --working-directory /home/gitlab-runner --user root
# 重启gitlab-runner
sudo service gitlab-runner restart

再次查询可以看到该用户已经为root了

问题2：mvn clean package后无target目录

这个问题困扰了我好半天，没想明白为什么我自己使用maven打包就有，但是用脚本执行就没有，一度以mvn clean install命令来代替，然后去maven本地仓库里面去拿包发版的😶
知道后来看文档时看到了有提及到Gitlab会删除掉 .gitignore文件中配置的目录和文件才明白，原来是GitLab自己删了，重新修改了.gitignore文件后就有了，但是生产就不能排除target目录了，索性一般都在master分支上这么配置，而master分支一般都是protected状态的，也就这样吧🤭

问题3：为GitLab配置了Https访问导致之前的Gitlab Runner失效了

查了好久才知道原因，因为Runner没有相关证书导致，无法通过https的链接和gitlab取得联系，需要指定上证书，我是重新注册了一个新的带证书的Runner，通过以下的命令来指定你的证书地址，同一个服务器上建议使用一个地址

## 使用指定属性去注册
gitlab-runner register --tls-ca-file /home/gitlab-runner/ssl/cert.cer -n \
 --url https://gitlab.zoombar.fun/ \
 --registration-token puuuyojFS8x24qJHMW_x \
 --name zoombar-front-runner \
 --tag-list deploy \
 --executor shell \
 --locked true \
 --run-untagged false

后续的优化，我发现事实上我们修改的配置是在目录/etc/gitlab-runner/config.toml该文件中，理论上我们在该文件中添加tls-ca-file，重启gitLab runner应该就可以了，但我就不试了，配置文件如下

concurrent = 1
check_interval = 0
[[runners]]
  name = "zoombar-runner"
  url = "https://gitlab.zoombar.fun/"
  token = "uiNqDnbTkTF1YzeHyzKR"
  tls-ca-file = "/etc/gitlab/ssl/cert.cer"
  executor = "shell"
  [runners.cache]