GitLab CI-CD 学习笔记
导读：概述.1. CI/CD.CI（持续集成）指开发人员一天内进行多次合并和提交代码操作，并通过自动化测试，完成构建.CD（持续部署）指每次代码更改都会自动部署到对应环境.CI/CD 结合在一起，可以加快开发团队交付成果的效率，减少时间成本.2. Gitlab-CI/CD.gitlab
概述
1. CI/CD
CI（持续集成）指开发人员一天内进行多次合并和提交代码操作，并通过自动化测试，完成构建
CD（持续部署）指每次代码更改都会自动部署到对应环境
CI/CD 结合在一起，可以加快开发团队交付成果的效率，减少时间成本
2. Gitlab-CI/CD
gitlab-ci 是 gitlab8.0 之后自带的一个持续集成系统，中心思想是每一次 push 到 gitlab 就会触发一次脚本执行，脚本内容包括测试、编译、部署等一系列内容
gitlab-ci 的脚本需要 gitlab-runner 来执行，代码 push 之后，webhook 检查到代码变化，就会触发 gitlab- ci，分配到各个 Runner 来运行相应的脚本
gitlab-ce
1. 安装 gitlab-ce
gitlab 有 ce 和 ee 两个版本，ce 是社区版，开源免费，ee 是企业版，需要付费
下面以 Ubuntu18.04.6 为例，安装 gitlab-ce
安装依赖软件
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates tzdata perl
添加 gitlab 软件源镜像
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
安装 gitlab-ce
sudo apt-get install gitlab-ce
如果命令行能看到 Gitlab 的 Logo 打印，就说明安装成功了
打开 gitlab 配置文件
vim /etc/gitlab/gitlab.rb
为了能在浏览器访问 gitlab，还需要配置 gitlab 的访问地址和端口
# ip:port 改成自己的,也可以用域名
external_url 'http://192.168.66.100:82'
重载配置并重启
gitlab-ctl recofigure
gitlab-ctl restart
在浏览器输入 http://192.168.66.100:82 即可访问 gitlab，当然了，前提是你的端口要放开
初始用户名为 root，初始密码记录在 /etc/gitlab/initial_root_password 文件，密码有效期为 24
小时，建议登录后尽快修改密码
登录以后，就可以创建项目了，其余的基本的 git 操作这里就不赘述了
2. 其他问题
gitlab-ctl recofigure 过程，有可能出现卡在 ruby_block[wait for logrotate service
socket] action run 的情况，解决办法如下：
ctrl + c 强行结束
运行
systemctl restart gitlab-runsvdir再次运行
gitlab-ctl recofigure
安装结束以后，访问 web 端报 502，最可能的原因是端口被占用了，需要修改端口
vim /etc/gitlab/gitlab.rb
# 修改为没有被使用的端口即可
puma['port'] = 9091
gitlab-runner
1. 安装 gitlab-runner
下面以 Ubuntu18.04.6 为例，安装 gitlab-runner
添加 gitlab 软件源镜像
curl https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
安装 gitlab-runner
sudo apt-get install gitlab-runner
2. gitlab-runner 注册
首先获取 gitlab-ci 的 token：项目主页->Setting->CI/CD->Runners Expand
使用命令注册 gitlab-runner
gitlab-runner register
按照步骤输入：
- GitLab instance URL：如上图所示 URL
- registration token：如上图所示 Token
- description：关于该 Runner 的描述
- tags：用于标记该 Runner，后续需要使用这个 tag 来指定 gitlab-runner
- optional maintenance note：没搞懂有啥用，随意写
- Enter an executor：选择执行器，gitlab-runner 提供了许多执行器，可用在不同场景中运行构建，这里选择 shell
完成以后，刷新页面，即可在 Runners Expand 看到新增了一个 Runner
3. 简单示例
下面我们简单测试一下 Runner 是否能正常运行，随意新建一个 SpringBoot 项目
在根目录下创建一个 .gitlab-ci.yml 文件，这里只是简单输出一段语句
stages:
- deploy
deploy-job:
tags:
- prod
stage: deploy
script:
- echo "hello world!!!"
push 到 gitlab 后，会发现脚本已经自动执行了，绿勾代表执行成功
点击绿勾，在下方 Pipeline 点击 deploy-job 可以查看执行过程
pipeline 语法
1. job & script
.gitlab-ci.yml 文件中可以定义一个或多个作业（job），每个作业独立执行，必须有唯一的名称（不能使用关键字）以及包含一个 script，这里定义了三个作业 build、test、deploy，script 可以是 shell 命令
build:
script:
- echo "build"
test:
script:
- echo "test"
deploy:
script:
- echo "deploy"
- echo "finish"
2. before_script & after_script
before_script 用于定义一个命令，在每个作业运行之前运行，before_script 失败将导致整个作业失败，其他作业不再执行，如果在作业中定义了 before_script，则该作业不会运行全局的 before_script
after_script 用于定义一个命令，在每个作业运行之后运行，作业失败不影响 after_script 的运行，如果在作业中定义了 after_script，则该作业不会运行全局的 after_script
before_script:
- echo "before script"
build:
before_script:
- echo "before script in buildjob"
script:
- echo "build"
after_script:
- echo "before script in buildjob"
test:
script:
- echo "test"
deploy:
script:
- echo "deploy"
- echo "finish"
after_script:
- echo "after script"
3. stages & stage
用于定义作业可以使用的阶段，并且是全局定义的，同一阶段的作业并行运行，不同阶段按顺序执行
before_script:
- echo "before script"
stages:
- build
- test
- deploy
build:
before_script:
- echo "before script in buildjob"
stage: build
script:
- echo "build"
after_script:
- echo "before script in buildjob"
test:
stage: test
script:
- echo "test"
deploy:
stage: deploy
script:
- echo "deploy"
- sleep 5
after_script:
- echo "after script"
4. .pre & .post
.pre 始终是整个 pipeline 的第一个运行阶段，.post 始终是整个 pipeline 的最后一个运行阶段，无法修改，用户自定义的 stage 则在这两者之间，如果一个 pipeline 仅包含 .pre 和 .post，则不会创建 pipeline
before_script:
- echo "before script"
stages:
- build
- test
- deploy
codescan:
stage: .pre
script:
- echo "codescan"
build:
before_script:
- echo "before script in buildjob"
stage: build
script:
- echo "build"
after_script:
- echo "before script in buildjob"
test:
stage: test
script:
- echo "test"
deploy:
stage: deploy
script:
- echo "deploy"
- sleep 5
after_script:
- echo "after script"
5. variables
定义变量，可以定义 pipeline 变量、job 变量，job 变量优先级最高
before_script:
- echo "before script"
variables:
DOMAIN: example.com
stages:
- build
- test
- deploy
codescan:
stage: .pre
script:
- echo "codescan"
build:
before_script:
- echo "before script in buildjob"
stage: build
script:
- echo "build"
- echo "$DOMAIN"
after_script:
- echo "before script in buildjob"
test:
stage: test
script:
- echo "test"
deploy:
stage: deploy
script:
- echo "deploy"
- sleep 5
after_script:
- echo "after script"
6. tags
用于指定特定的 job 在特定的 runner 运行，如果 job 不指定 tags，则默认在共享的 runner 运行
windows_job:
stages:
- build
tags:
-windows
script:
- echo "windows job"
linux_job:
stages:
- build
tags:
-linux
script:
- echo "linux job"
7. allow_failure
allow_failure 表示是否允许作业失败，默认值 false 不允许失败，改为 true 后，如果该作业失败也不会被阻塞
job1:
stage: test
script:
- "..."
allow_failure: true
8. when
when 用于控制作业运行：
on_success：前面阶段的所有作业成功才执行该作业，默认 on_success
on_failure：前面阶段出现失败时执行
always：总是执行作业
manual：手动执行作业
delayed：延迟执行作业
job1: stage: test script: - “…” when: delayed # 表示延迟30s执行 start_in: “30”
9. retry
配置作业失败后重试作业的次数
job1:
stage: test
script:
- "..."
retry: 2
也可以精确匹配到某一错误，即出现某一错误时才重试
job1:
stage: test
script:
- "..."
retry:
max: 2
when:
- script_failure # 脚本失败时重试
10. timeout
作业级别的超时可以超过项目级别的超时，但不能超过 Runner 特定的超时
job1:
stage: test
script:
- "..."
timeout: 3h
11. parallel
配置要并行运行的作业的实例数，此值必须大于等于 2 并小于等于 50，这将创建 N 个并行运行的同一作业实例
job1:
stage: test
script:
- "..."
parallel: 5
12. rules
rules 允许按顺序评估单个规则，直到匹配为止：
if：如果条件匹配，多条件匹配可以使用 && ||
variables: DOMAIN: example.comjob1: stage: test script: - “…” rules: # DOMAIN值匹配,则手动运行,否则 - if: ‘\(DOMAIN == "example.com"' when: manual - if: '\)DOMAIN == “example2.com”’ when: delayed start_in: ‘5’ - when: on_success
changes：指定文件发生变化
job1: stage: test script: - "..." rules: - changes: - fimeName # 文件名 when: manual - when: on_successexists：指定文件存在
job1: stage: test script: - "..." rules: - exists: - fimeName # 文件名 when: manual - when: on_success
13. workflow-rules
workfolw 关键字适用于整个管道，并确定是否创建管道
variables:
DOMAIN: example.com
workflow:
rules:
- if: '$DOMAIN == "example.com"'
when: always # 默认always,可以设置never
- when: never
14. cache
存储编译项目时所需的运行时依赖项，指定项目工作空间中需要在 job 之间缓存的文件或目录
全局 cache 定义在 job 之外，针对所有 job 生效，job 中的 cache 优于全局
cache:
paths: # 在全局定义缓存
- my/files
job:
script: "..."
cache:
key: job # 为缓存设置唯一key,会为该job分配一个独立的cache
paths: # 在job中定义缓存,缓存target目录下的所有.jar文件,该缓存将覆盖全局缓存
- target/*.jar
# policy: pull # pull:不下载缓存,push不上传缓存,默认会在job执行之前下载缓存,并在结束之后上传缓存
15. artifacts
用于指定作业成功或失败时应附加到作业的文件或目录的列表，可在 Gitlab UI 中下载
build:
script:
- mvn package
artifacts:
name: "$ARTIFACTS_NAME" # 指定所创建的制品名称,默认为artifacts,下载为artifacts.zip
paths:
- target/*.jar
when: always # 制品创建条件,on_success:作业成功时创造制品,on_failure:作业失败时创建制品,always:总是创建制品
expire_in: 1 week # 制品有效期,从存储到gitlab开始算起,默认30天
16. dependencies
获取当前阶段之前的制品
build:
stage: build
script:
- mvn package
artifacts:
name "$ARTIFACTS_NAME"
paths:
- target/*.jar
deploy:
dependencies:
- build
stage: deploy
script:
- ... # 部署制品
17. needs
可以让作业无需按照阶段顺序运行，下述的例子表示：deploy-a 在 build-a 完成之后就可以执行，deploy-b 在 build-b 完成之后就可以执行
stages:
- build
- deploy
build-a:
stage: build
script:
- ...
build-b:
stage: build
script:
- ...
deploy-a:
stage: deploy
script:
- ...
needs: ["build-a"]
deploy-b:
stage: deploy
script:
- ...
needs: ["build-b"]
18. include
可以引入外部 yaml 文件，使用合并功能可以自定义和覆盖本地定义的 CI/CD 配置
local
引入同一存储库的文件，使用相对于根目录的完整路径进行引用，必须保证走到同一分支
假设有 ci/localci.yml 文件
stages:
- deploy
deploy-job:
stage: deploy
script: ...
在 .gitlab-ci.yml 引入 ci/localci.yml 文件，如果存在相同名称的作业，它们的配置会进行合并，并且原文件 .gitlab- ci.yml 的配置优先生效
include:
local: "ci/localci.yaml"
stages:
- build
- test
- deploy
build-job:
stage: build
script: ...
test-job:
stage: test
script: ...
file
引入其他项目的 yaml 配置
include:
project: demo/demo-java-service
ref: master
file: .gitlab-ci.yml
template
引入官方提供的模板，可以访问 https://gitlab.com/gitlab- org/gitlab/tree/master/lib/gitlab/ci/templates 查看有哪些模板
include:
template: Auto-DevOps.gitlab-ci.yml
remote
引入远程文件
include:
remote: "https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml"
19. extends
继承作业配置，相同配置覆盖，不同则继承
.tests:
script: mvn test
stage: test
only:
refs:
- tags
test-job:
extends: .tests
script: mvn clean test
only:
variables:
- $RSPEC
最终得到的作业配置如下
test-job:
stage: test
script: mvn clean test
only:
variables:
- $RSPEC
refs:
- tags
20. trigger
当 gitlab 从 trigger 定义创建的作业启动时，将创建一个下游管道，允许创建多项目管道和子管道：
多项目管道：跨多个项目设置流水线，以便一个项目的管道可以触发另一个项目的管道
stagging: variables: ENVIROMENT: stagging # 该变量会传递给下游管道,如果上下游定义了相同名称的变量,上游变量将优先 stage: deploy trigger: project: demo/demo-java-service # 指定下游项目的完整路径 branch: master # 指定项目的分支名称 strategy: depend # 将自身状态从触发的管道合并到源作业父子管道：同一项目的管道可以触发一组同时运行的子管道
子管道 ci/child.yml
stages:
- build
child-build-job:
stage: build
script: ...
父管道
stages:
- deploy
stagging:
stage: deploy
trigger:
include: ci/child.yml
strategy: depend21
21. image
首先注册一个工作类型为 docker 的 runner，只要使用该类型的 runner，所有运行操作都会在容器中运行
gitlab-runner register \
--non-interactive \
--executor "docker" \
--docker-image alpine:latest \ # 默认使用该镜像
--url "http://192.168.1.200:30088/" \
--registration-token "JRzzw2j1Ji6aBjwvkxAv" \
--description "docker-runner" \
--tag-list "docker" \
--run-untagged="true" \
--locked="false" \
--access-level="not_protected"
默认注册 runner 会指定一个基础镜像，如果全局指定 image 则所有作业使用该镜像创建容器并运行，如果全局未指定 image，则查看 job 中是否有指定，有则按照 job 指定的镜像创建容器并运行，否则使用默认镜像
image: maven:3.6.3-jdk-8 # 全局定义
...
deploy-job:
stage: deploy
tags:
- docker
script: ...
image: maven:3.6.3-jdk-8 # 局部定义
22. services
工作期间运行的另一个 Docker 服务镜像，将其 link 到 image 定义的 Docker 镜像，这样可以在构建期间访问该服务镜像
...
services:
- name: mysql:latest
alias: mysql
build-job:
stage: build
tags:
- docker
script: ...
image: maven:3.6.3-jdk-8 # 局部定义
23. environment
可用于在 gitlab ui 追踪作业运行情况，
deploy-job:
stage: deploy
tags:
- docker
script: ...
environment:
name: production # 应用名称
url: http://www.baidu.com # 应用地址
上一篇：Redis持久化
下一篇：软件开发项目文档系列之十二如何撰
