spring boot项目搭建gitlab CI CD持续集成环境之配置gitlab-runner & gitlab-ci pipeline
目录
-
- gitlab ci pipeline配置
-
- gitlab ci pipeline 配置语法知识
- 新建.gitlab-ci.yml
- 配置gitlab-runner
-
- gitlab runner介绍
- 注册 gitlab runner
- 注册tag为SHARE_MAVEN_JDK的share runner
- 最后
回系列博客主目录及代码地址 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，可以看到：
- 使用命令 docker exec -it gitlab-runner bash 进入到docker中，执行gitlab-runner register, 填入上图中的url：http://localhost:7090/，注意不要用localhost,将localhost替换成你机器的ip：http://ip:7090/，
填入url后回车即可到下一步。
- 填入Token回车
- 输入描述
- 填入runner的tag，该tag就是上文所说的在.gitlab-ci.yml中指定的tags
- 输入使用的执行器，有很多种执行器，这里选择docker
- 输入默认使用的执行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，也就是说项目的持续集成已经完成。