一、模块内容预览
1、预准备环境
2、Gitlab DockerCompose搭建
3、Gitlab Runner DockerCompose搭建
4、Gitlab项目和GitlabRunner关联
5、.gitlab-ci.yml模板
6、Gitlab Runner之shell Excutor (.gitlab-ci.yml) 案例演示
7、Gitlab Runner之docker Excutor (.gitlab-ci.yml) 案例演示
8、.gitlab-ci.yml文件中的cache用法
9、runners配置
二、模块具体讲解
1、预准备环境
在开始后面的演示大家需要准备一台服务器或者多台服务器。其实在实际CICD的环境中应该是多台,因为GitlabRunner会和Gitlab服务器不在同一台上面。具体为什么大家往下看就清楚了,这里不做过多的解释,不啰嗦直接开搞。这里为了演示就拿一台服务器出来演示,多机是同样的道理学习还是得要有举一反三的能力,尤其是做技术的。没有一成不变的教程,就算教程是对的但是也不一定适合你所处的环境还是得要折腾一下才会有结果,在技术的道路上不要想着有100%对的答案,只有100%对的思想。
| ip | 基础环境 | 描述 | 操作系统 |
| 192.16.10.33 | Docker、DockerCompose以及其他环境。 | 宿主机 | Ubuntu |
重复说一下,你找的这台服务器一定要先安装Docker,DockerCompose没有安装的先安装docker不要着急看下面的。因为下面的所有的内容都是需要依赖Docker的环境。
不知道怎么安装Docker,DockerCompose可以参考我的另一篇文章:https://www.cnblogs.com/dszazhy/p/14718416.html
好像上面我忘记记录DockerCompose怎么搭建了,这里不浪费时间了大家自己抽时间百度一下吧很简单的,对自己要有信心哦,加油欧力给!
2、Gitlab DockerCompose搭建
gitlab部署文件docker-compose.yml文件,自己随便创建一个目录放入这个文件。
version: '3.1' services: gitlab:
#image: gitlab/gitlab-ce:latest
image: registry.cn-hangzhou.aliyuncs.com/dsz-docker/gitlab-for-chinise:11.1.4 container_name: gitlab restart: always privileged: true hostname: 'gitlab' environment: TZ: 'Asia/Shanghai' GITLAB_OMNIBUS_CONFIG: | external_url 'http://192.168.10.33:8686' #记住这里一定要带上端口否则gitlab项目clone地址也会没有端口导致gitlab-runner拉取不到项目,这里特意提示下。其他的就都跟着我的具体大家看情况配置就好了。 gitlab_rails['time_zone'] = 'Asia/Shanghai' gitlab_rails['smtp_enable'] = true gitlab_rails['gitlab_ssh_host'] = '192.168.10.33' gitlab_rails['gitlab_shell_ssh_port'] = 33 ports: - '8686:8686' - '443:443' - '33:22' volumes: - /home/docker_gitlab/config:/etc/gitlab - /home/docker_gitlab/data:/var/opt/gitlab - /home/docker_gitlab/logs:/var/log/gitlab
以上文件创建好以后执行docker-compose up -d这时候gitlab就会起来了。记住这个命令要在这个文件所在的目录执行,不要跑错了地方。这些都是docker-compose基本用法不是本文的重点,后续这种问题都将一笔带过。你若是想在别的任意目录下执行可以加上-f。好了点到为止,我们继续今天吧。
访问:192.168.10.33:8686就可以登录了,首次登陆会提示大家修改root用的密码,大家修改一下再次登录就好了。登录好以后大家记得创建一个SpringBoot可以测试的项目哦。
以下是上面的文件中external_url不带端口的话下面的地址就也没有端口,导致gitlab-runner会已这个没有端口的地址拉取项目,从而导致失败。

3、Gitlab Runner DockerCompose搭建
gitlab-runner部署文件docker-compose.yml文件
version: '3.1'
services:
runner-guanfang:
image: gitlab/gitlab-runner:latest
container_name: gitlab-runner
restart: always
privileged: true
volumes:
#务必保证 /home/runner/config有写的权限否则容器启动会失败
- /home/runner/config:/etc/gitlab-runner #容器与宿主机runner配置文件挂载,防止容器重启或者recreate数据丢失,这个很重要。
- /var/run/docker.sock:/var/run/docker.sock #用于runner容器共享宿主机的docker,不然在runner容器里起容器端口挂载就会有问题了。解决Docker in Docker的问题。
同样在这个文件的目下执行:docker-compose -d这样gitlab-runner就起好了。上面gitlab也起好了,这样基本所有的服务我们基本上都已经完成了。

以上表示启动成功过,容器名可能跟我当前文档演示的不一样不用纠结都是自定的,大家想怎么改就怎么改吧。
3、Gitlab项目和GitlabRunner关联
第1步:Gitlab中创建一个SpringBooot项目,下面红色的几个目录或者文件是我们重点要操作的内容。
本文演示的项目DEMO地址可以分享给大家:https://github.com/ShouZhiDuan/gitlab-runner

第二步:点击项目中的设置->CI/CD->Runner(这个就是跟我们部署的GitlabRunner有关系的地方)

第三步:点击Runner展开详情

黄色部分是等会用来关联GitlabRunner的两个重要参数。
蓝色部分是已关联的GitlabRunner列表,也就是跟当前项目关联成的GitlabRunner都会显示在这里。
红色部分是配置环境变量的地方,一般都用于GitlabRunner中job构建的参数。虽然.gitlab-ci.yml也可以配置环境变量,但是这里如果涉及到密码,例如docker仓库的密码等配置在这里相对会比较安全。
第四步:执行Gitlab项目与GitlabRunner关联操作。
#执行以下命令,第一个gitlab-runner是你的容器名称(根据实际你的容器名称为准),第二个gitlab-runner是容器中的默认授权用户,一般你启动没有特殊处理就默认输入这个。 docker exec -it gitlab-runner gitlab-runner register
>>>>>> #复制上面黄色部分的两个参数,第一个是项目仓库地址,第二个是token相当于仓库中项目的唯一标识以及免密获取项目信息,这样runner就可以通过这两个参数拉取需要构建的项目数据。 Runtime platform arch=amd64 os=linux pid=24 revision=c1edb478 version=14.0.1 Running in system-mode. Enter the GitLab instance URL (for example, https://gitlab.com/): http://192.168.10.33:8686/ #输入上面截图的黄色区域第一个参数 Enter the registration token: nZyc2xXijBorc1mTQgfT #输入上面截图的黄色区域第二个参数 Enter a description for the runner: 持续集成部署测试 #这个是当前绑定runner的一个自定义描述,相当于别名自己以后看到这个名字就知道这个runner可以干什么。 Enter tags for the runner (comma-separated): run-springboot #这是这个runner的tag很重要,自定义。但是需要记住,因为再后续.gitlab-ci.yml中的job会用到。指定哪个tag决定你用哪个runner来执行任务。 Registering runner... succeeded runner=nZyc2xXi Enter an executor: kubernetes, docker-ssh, parallels, ssh, docker-ssh+machine, docker+machine, custom, docker, shell, virtualbox: doker #excutor模式选择 #这里大家根据上面这一行提示的列表:kubernetes, docker-ssh, parallels, ssh, docker-ssh+machine, docker+machine, custom, docker, shell, virtualbox。 #选一个符合或者自己需要的方式,本文会给大家演示shell、docker两种方式。具体两者在用起来还是有很大的区别的。 #shell方式是基于我们启动的runner容器环境构建任务比如maven,jdk,docker等, #具体需要什么样的环境就看大家具体.gitlab-ci.yml文件job中执行的shell需要依赖什么环境了,所以大家在搭建前先想好自己项目在构建中需要什么环境。 #但是经过自己实操一把shell感觉还是存在一些问题,本文碰到的问题就是在构建过程中gitlab-runner用户权限的问题,导致构建过程shell脚本执行失败。但是也是可以解决,具体等会下面具体部署给大家说一下具体的场景具体的解决方式。 #docker方式感觉比shell方式友好很多,也不用在乎执行过程用户权限等其他的问题构建很顺畅甚至感觉性能比shell方式快好多,大大减少构建的周期,所以推荐大家用docker方式。具体的等会下面也会给大家演示一下部署。 Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
<<<<<<
操作完以上步骤出现Runner registered successfully表示关联成功了。这样就可以看到上面截图蓝色部分会出现自己刚才绑定runner进本信息。
5、.gitlab-ci.yml模板
excotor docker模式
before_script:
#befor_script表示一下每个任务执行开始前都要执行的一些内容,比如设置一些环节变量等。
#- export name=value #这样你就可以在下面任意一个环节通过${name}去使用
image:
#这里是excutor(docker)模式全局job构建环境,这里把java项目常用的构建环境全部集成了一下镜像。例如:jdk、maven、docker、docker-compose等。
#Dockerfile文件在项目/docker/Dockerfie,大家可以拉取代码参考根据自己的实际情况做修改升级调整等。
#这样以下每个stage构建需要的环境都有了。
name: registry.cn-hangzhou.aliyuncs.com/dsz-docker/runner-for-java:20210715-1
entrypoint: [""]
# 定义CI执行的阶段的JOB,这里可以自己根据情况定义多少个阶段
stages:
- whoami
- whoami2
- show_env
- build_image
- compile
- build
- run
#全局变量,在构建生命周期中大家都可以用到。
#以下参数大家可以根据自己测试时候的参数做调整,比如说docker仓库信息等。大家都是有经验的开发者,我就不多说了。
variables:
MAVEN_REPO: /.m2 #maven仓库,注意这里是容器里面的仓库地址,后面会把这个目录挂载到宿主机里面去,方式每次构建拉取jar影响构建性能。
PROJECT: demo
IMAGE_FULL_NAME: registry.cn-hangzhou.aliyuncs.com/dsz-docker/demo:20210716-2
gitla_runner_image: registry.cn-hangzhou.aliyuncs.com/dsz-docker/dsz-gitlab-runner:20210715-1
dsz_docker_hub: registry.cn-hangzhou.aliyuncs.com
docker_user: duanshouzhi516518
docker_pwd: xxxxxx #这个密码大家就可以配置到gitlab中我上面截图红色部分了使用方法一样任然可以${password}去使用,就可以防止敏感数据暴露问题。
#任务1
whoami:
#image: docker:latest
stage: whoami
tags:
#这里写大家在绑定Gitlab项目和GitlabRunner时候输入的tag,这样当前的job就会使用这个runner来跑任务。
#docker的模式会是每个任务都会分配一个docker容器环境来操作。
- gw-new-docker
script:
#测试shell,检查docker的版本。这个很好用,类似于给大家debug调试一些东西。
- whoami
- docker -v
#任务2
whoami2:
#这里的image不要要配了,因为上面配置了全局的,所以下面所有的job都不需要配置。推荐大家这样去做,不然每个job都要维护自己的image。
#这里也是excotor docker模式与shell模式比较大的区别。shell模式所有的环境都是基于runner容器的环境去操作的不需要特殊指定。
#但是这里配置image有点问题好像只能配置一个,如果大家在当前任务既要用到docker又要用到docker-compose这样的方式就会有问题,所以推荐大家跟我一样自己做一个全局的image然后让这个image集成全局所有的CICD环境这样就OK了。
#image: docker/compose:latest
stage: whoami2
tags:
- gw-new-docker
script:
- docker-compose -v
#任务3 注意这个任务前面有个.表示当前任务被注释不会被执行。
.show_env_1:
stage: show_env
tags:
- gw-new-docker
script:
- echo "测试变量配置值"
#$test_name可以在gitlab页面上设置,此处获取
- echo $test_name
#任务4 大家仔细观察发现上面的show_env_1和这个show_env_2所定义的stage都是show_env。意思是show_env这个stage会有两个子任务show_env_1和show_env_2会并行执行,待会截图大家就可以看的出来。
show_env_2:
stage: show_env
tags:
- gw-new-docker
script:
- echo "======当前环境变量======"
- env
#任务5
.build_image:
#image: docker:latest
stage: build_image
tags:
- gw-new-docker
script:
- cd docker
- docker login --username=$docker_user --password=$docker_pwd $dsz_docker_hub
# 这里的变量就是我们全局配置定义的了
- docker build -t $gitla_runner_image .
- docker push $gitla_runner_image
- rm -rf target
- docker rmi $gitla_runner_image
#任务6 构建springboot镜像
compile:
# image: maven:latest
# image: registry.cn-hangzhou.aliyuncs.com/dsz-docker/maven:latest
stage: compile
allow_failure: false
# 指定构建的分支
only:
- master
tags:
- gw-new-docker
# 运行脚本
script:
- env
- mvn -Dmaven.repo.local=$MAVEN_REPO clean package -Dmaven.test.skip=true
artifacts:
name: $PROJECT
expire_in: 1 days #设置maven打包的jar定时移除时间节省磁盘空间,这个很重要如果构建体量大了你会发现磁盘会暴增。
paths: #指定移除文件目录
- target/*.jar
# 任务7 构建SpringBoot镜像
#按理说这个任务我们都知道构建打包发布docker镜像SpringBoot标配会用到git、maven、docker环境,git在部署的runner里面会自带大家不用管。如果这里用image来配置环境的话就会满足不了。当然如果大家想这样做,可以换个思维吧当前的任务拆成多个子任务,这样每个子任务配置自己的环境应该也可以。 #我这里没有试过,大家可以试一下。但是我觉得在定义构建任务的时候还是尽量少点,因为毕竟每个任务都会启动一个docker容器来执行比较占用资源,从而影响构建时长。
build:
#image: docker:latest
stage: build
script:
# 这里的变量会自动获取你当前推送代码的gitlab用户和密码以及仓库地址
#- docker login --username $CI_REGISTRY_USER --password $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker login --username=$docker_user --password=$docker_pwd $dsz_docker_hub
# 这里的变量就是我们全局配置定义的了
- docker build -t $IMAGE_FULL_NAME .
- docker push $IMAGE_FULL_NAME
- rm -rf target
- docker rmi $IMAGE_FULL_NAME
only:
- master
tags:
- gw-new-docker
#任务8 启动SpringBoot容器
.run:
#image: docker:latest
#image: docker/compose:latest
stage: run
script:
#- docker stop $PROJECT || true
#- docker rm $PROJECT || true
- docker-compose down
- docker-compose up -d
only:
- master
tags:
- gw-new-docker
以上就是excutor docker的.gitlab-ci.yml文件,这个需要放在咋们自己项目的更目录下,这样gitlab-cicd会自动识别这个文件出发构建。
完成以上过程大家只要把代码push到gitlab上就会自动触发构建打包部署。下面贴几个图大家就清楚了,实际在部署的过程大家多点点就清楚了。
构建历史列表

构建任务详情


查看
查看job日志


查看构建结果

构建成功所有任务都是绿色的勾勾。
6、Gitlab Runner之shell Excutor (.gitlab-ci.yml) 案例演示(待续,休息中。。。。。。)
9、runners配置config.toml
更多可参考:https://www.cnblogs.com/wsl222000/p/12876464.html
concurrent = 1
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "192.168.10.34.runner"
url = "https://nvxg.nvxclouds.com:9443/"
token = "b97HrVA9KKn3TAxmgLdY"
executor = "docker"
clone_url = "https://nvxg.nvxclouds.com:9443"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.docker]
tls_verify = false
image = "maven:latest"
privileged = true
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache", "/home/.m2/:/.m2/"]
pull_policy = "if-not-present"
shm_size = 300000
[[runners]]
name = "1034-vte-admin"
url = "https://nvxg.nvxclouds.com:9443/"
token = "P6SPrHgUReafesaLntHF"
executor = "docker"
clone_url = "https://nvxg.nvxclouds.com:9443"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.docker]
tls_verify = false
image = "maven:latest"
privileged = true
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache", "/home/.m2/:/.m2/"]
pull_policy = "if-not-present"
shm_size = 300000
[[runners]]
name = "1034.vet.front"
url = "https://nvxg.nvxclouds.com:9443/"
token = "-53ktRjb5AtJwHFFNoZd"
executor = "docker"
clone_url = "https://nvxg.nvxclouds.com:9443"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.docker]
tls_verify = false
image = "node:12.22.1"
privileged = true
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
pull_policy = "if-not-present"
shm_size = 300000
[[runners]]
name = "1034.vte.admin"
url = "https://nvxg.nvxclouds.com:9443/"
token = "U-N3zbaD8zZaHHD17fjx"
executor = "docker"
clone_url = "https://nvxg.nvxclouds.com:9443"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.docker]
tls_verify = false
image = "node:12.22.1"
privileged = true
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
pull_policy = "if-not-present"
shm_size = 300000
