目录
回系列博客主目录及代码地址 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,也就是说项目的持续集成已经完成。