spring boot项目搭建gitlab CI CD持续集成环境之配置gitlab-runner & gitlab-ci pipeline

回系列博客主目录及代码地址 spring boot项目基于docker搭建gitlab CI CD持续集成环境

Gitlab 官方提供一个模块 Gilab CI可以实现项目CICD，通过在项目根路径下的配置文件.gitlab-ci.yml来定义CI&CD pipeline，当push commit到gitlab repo时，会trigger CI&CD pipeline执行，进而实现项目持续集成和持续部署。
而执行根据配置文件去执行构建管道pipeline的正是gitlab runner, gitlab runner 跟gitlab服务器是分开的，可以安装在不同的机器，只需要在gitlab上配置即可。

emmm，有官方介绍：gitlab CI

gitlab ci pipeline配置

gitlab ci pipeline 配置语法知识

gitlab-ci.yml定义了如何构建项目，在spring-boot项目根路径下新建.gitlab-ci.yml,如下直接贴出本项目的 .gitlab-ci.yml

default:
  image: 'maven:3.6.3-openjdk-8'

stages:
  - prepare
  - test
  - analysis
  - package
  - deploy

prepare:
  stage: prepare
  cache:
    key: m_m2
    paths:
      - .m2/repository/
  script:
    - mvn -v && java -version
    - mvn clean install -s settings.xml
  tags:
    - SHARE_MAVEN_JDK

tests:
  stage: test
  cache:
    key: m_m2
    policy: pull
    paths:
      - .m2/repository/
  script:
    - mvn clean install -P tests -s settings.xml
  artifacts:
    when: on_success
    paths:
      - target/failsafe-reports
      - target/surefire-reports
      - target/classes
      - target/test-classes
      - target/site
      - target/*.exec
  coverage: '/Code coverage: \d+\.\d+/'
  tags:
    - SHARE_MAVEN_JDK

analysis:
  stage: analysis
  image:
    name: sonarsource/sonar-scanner-cli:latest
    entrypoint: ['']
  variables:
    SONAR_TOKEN: '67296badea93b1a60d324330852a6256a1fec8b4'
    SONAR_HOST_URL: "http://sonar-server-ip:9000"
    GIT_DEPTH: 0
    SONAR_PROJECT_BASE_DIR: ./
  script:
    - pwd
    - ls -l
    - sonar-scanner -Dsonar.qualitygate.wait=true
  tags:
    - SONAR_SCANNER
  only:
    - master

package:
  stage: package
  cache:
    key: m_m2
    policy: pull-push
    paths:
      - .m2/repository/
  script:
    - mvn clean install -P skipTests -s settings.xml
  artifacts:
    when: on_success
    paths:
      - target/spring-boot-test-ci-1.0.0.jar
  tags:
    - SHARE_MAVEN_JDK

deploy:
  stage: deploy
  image: ictu/sshpass:latest
  script:
    - pwd
    - ls -l
    - ls ./target/
    - sshpass -p ci scp -o StrictHostKeyChecking=no target/spring-boot-test-ci-1.0.0.jar ci@localhost:/home/ci/appsrc/spring-boot-ci/spring-boot-test-ci.jar
    - sshpass -p ci scp -o StrictHostKeyChecking=no deploy/Dockerfile ci@localhost:/home/ci/appsrc/spring-boot-ci/Dockerfile
    - sshpass -p ci scp -o StrictHostKeyChecking=no deploy/docker-compose.yml ci@localhost:/home/ci/appsrc/spring-boot-ci/docker-compose.yml
#    - sshpass -p ci ssh -o StrictHostKeyChecking=no ci@localhost 'docker build -f /home/ci/appsrc/spring-boot-ci/Dockerfile -t spring-boot-test-ci:v1 /home/ci/appsrc/spring-boot-ci/'
    - sshpass -p ci ssh -o StrictHostKeyChecking=no ci@localhost 'docker stop spring-boot-ci'
    - sshpass -p ci ssh -o StrictHostKeyChecking=no ci@localhost 'docker-compose -f /home/ci/appsrc/spring-boot-ci/docker-compose.yml up -d --build'
  tags:
    - SSH_REMOTE_DEPLOY
  only:
    - master

• 解析
  一个pipeline一般包含多个stage，一个stage可以对应多个job，如上例子具有5个stage：prepare, test, analysis,package,deploy， 具有五个job：prepare, test, analysis,package,deploy，如package这个job指定的是stage是prepage。你也可以指定另个job如package2使用stage是prepare。

prepare2:
  stage: prepare
  cache:
    key: m_m2
    paths:
      - .m2/repository/
  script:
    - mvn -v && java -version
    - mvn clean install -s settings.xml
  tags:
    - SHARE_MAVEN_JDK

pipeline执行顺序：按照stages定义依次执行每一个stage对应的job，如果一个stage有两个job，那么这两个job则并行执行。以上pipline例子执行如下:

如果一个stage有多个job，例如：

• 配置项解析

配置项	配置项说明
stages	定义管道有哪些stage，stage按定义顺序执行，本例子定义了 prepare, test, analysis,package,deploy五个stage
default: image	默认使用该指定的image去执行构建stage，如果在stage中指定，则使用stage的image
prepare:stage: prepare	定义一个job：prepage，其指定的stage是prepare
cache	定义path指定的路径文件存储在缓存中，该缓存可以在job之间共享，上一个job push到cache中的文件，可以在下一个job中pull下来使用，例如在prepare这个job我已经将maven的repo依赖存储在缓存中，那么在下一个job：test执行maven命令的时候就不需要再次pull maven依赖了
script	定义job要执行的命令：maven install
tags	指定哪一个gitlab runner可以pickup这个job去执行，每个gitlab runner都有一个tag
artifacts	定义那些文件需要在下一个job使用，一般是用于上一个job构建的结果文件需要在下一个job去使用，例如本例子test构建后产生targe下的测试覆盖率等加过文件，使用artifacts供下一个job：analysis做sonar分析
job: image	在job中定义image，则会使用改image去执行该job，不定义则使用defaut的image，如果在.gitlab-ci.yml中也没有定义defaut的image，则会使用gitlab-runner中默认的image来执行（每个gitlab-runner都会定义默认的docker image）
variables	定义job执行时所需要使用的环境变量
only	指定哪些branch的push commit会触发执行该job，本例子指定只有master才会执行deploy这个job
script	配置项说明

详细的语法参考官方文档咯： .gitlab.yml reference

新建.gitlab-ci.yml

在你的spring-boot项目下新建.gitlab-ci.yml配置文件，不建议一次性就直接copy上面列出的所有jobs，我们一步一步来，第一步先能够build成功项目，并且测试能跑过，内容如下：

default:
  image: 'maven:3.6.3-openjdk-8'

stages:
  - prepare
  - test
  - 
prepare:
  stage: prepare
  cache:
    key: m_m2
    paths:
      - .m2/repository/
  script:
    - mvn -v && java -version
    - mvn clean install -s settings.xml
  tags:
    - SHARE_MAVEN_JDK

tests:
  stage: test
  cache:
    key: m_m2
    policy: pull
    paths:
      - .m2/repository/
  script:
    - mvn clean install -P tests -s settings.xml
  tags:
    - SHARE_MAVEN_JDK

OK，在gitlab-ci.yml我们定了连个job，prepare和test，第一个job：prepare是为了准备maven依赖，然后第二个job：test就只需要将cache pull下来执行测试构建即可。（cache不指定policy默认是push+pull）
另外指定的gitlab-runner是使用tag为SHARE_MAVEN_JDK这个runner，那接下来就来配置gitlab-runner.

配置gitlab-runner

gitlab runner介绍

gitlab runner顾名思义就是执行pipeline job的执行器，在一个.gitlab-ci.yml中，不同的job可以执行相同的runner，也可以执行不同的runner。当有一个新的push commit提交到gitlab repo以后，相应的gitlab-runner就会pickup job去执行构建。
主要有三种 gitlab-runner： share runner、specific runner、group runner

• share runner - 共享runner，gitlab上所有的project都可以通过指定tag去使用，可以在Settings > CICD > runner中查看，如果某个project不想使用share runner，可以Settings > CICD > runner下disable，默认一般是enable
• specific runner - 专门为某个project配置的runner，可以在对应的project -> setttings > CICD > runners下查看
• group runner - 为一个组projects配置的runner，可以在对应的project -> setttings > CICD > runners下查看
  
  在gitlab admin area中可以管理你gitlab所有注册的runners，share runner可以转为group runner或者specific runner，但是不可以逆转。
  
  官方介绍：gitlab runners

注册 gitlab runner

本文介绍的是使用docker container去运行一个 gitlab runner：install gitlab runner as docker service

• run a gitlab runner container

docker run -d --name gitlab-runner --restart always \
  -v /home/ci/volumes/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

gitlab-runner提供了一些命令来管理 runners，使用 docker exec -it gitlab-runner bash 去到容器中执行：gitlab-runner -h，说明安装gitlab runner成功了。

• 注册一个specific runner
  specific runner是专门给某个project配置的，在gitlab上打开project下的settings > CICD > runners，可以看到：
  

1. 使用命令 docker exec -it gitlab-runner bash 进入到docker中，执行gitlab-runner register, 填入上图中的url：http://localhost:7090/，注意不要用localhost,将localhost替换成你机器的ip：http://ip:7090/，
   填入url后回车即可到下一步。
   
2. 填入Token回车
   
3. 输入描述
   
4. 填入runner的tag，该tag就是上文所说的在.gitlab-ci.yml中指定的tags
   
5. 输入使用的执行器，有很多种执行器，这里选择docker
   
6. 输入默认使用的执行imge，用于之后默认的构建镜像
   
   至此，成功注册了一个gitlab runner. 可以使用gitlab-register list查看
   
   然后也可以在gitlab上查看下：
   

• 注册 share runner
  注册share runner跟注册specific runner是一样的，不同在于使用的token不同，其使用的token在root用户的admin area > runners下的token：
  
• 查看runners配置： config.toml
  素有注册的runners可以在该配置中看到，你也可以根据自己的需求修改配置
  

注册tag为SHARE_MAVEN_JDK的share runner

这个tag只是个名字，随便取的呢。
注册好runer以后，就可以提交一个push commit去trigger一个pipliene build了，当然你也可以在.gitlab-ci.yml中指定使用的是specific runner.

在执行pipeline job的时候，gitlab runner会使用指定的image临时build一个container来执行job，那么首先在container中会先pull你的project的代码，通过看log可以看到：

这里有一小坑，如果你的pull代码的git地址如果使用的机器名，那么在这个临时的container里面它是不认识你的机器名的，所以会导致pull代码失败。这个时候需要在config.toml相应的runner中机上一个配置：extra_hosts = [“hostname:ip”]，这样就可以映射到ip了。

最后

至此，基于spring boot的gitlab CI已经完成了，之后你的每次push都会trigger gitlab的CI，也就是说项目的持续集成已经完成。