目录
安装gitlab
安装包方式安装
修改配置后的初始化
gitlab-ctl reconfigure
启动
sudo gitlab-ctl start
停止
sudo gitlab-ctl stop
重启
sudo gitlab-ctl restart
开机启动
systemctl enable gitlab-runsvdir.service
禁止开机自启动
systemctl disable gitlab-runsvdir.service
docker方式部署gitlab-ce
sudo docker run --detach
--hostname 10.0.0.6
--publish 443:443 --publish 80:80 --publish 222:22
--name gitlab
--restart always
--volume /srv/gitlab/config:/etc/gitlab
--volume /srv/gitlab/logs:/var/log/gitlab
--volume /srv/gitlab/data:/var/opt/gitlab
gitlab/gitlab-ce:latest
修改默认的管理员密码
默认用户名密码：
root
除非您在安装过程中提供了自定义密码，否则将随机生成一个密码并在/etc/gitlab/initial_root_password. 使用此密码和用户名root登录
docker exec -it gitlab bash
gitlab-rails console
user = User.where(id: 1).first
user.password = '12345678'
user.password_confirmation = '12345678'
user.save!
用户名：admin@example.com
密码：12345678
doceker方式部署docker-runner
sudo docker run -d --name gitlab-runner --restart always
-v /srv/gitlab-runner/config:/etc/gitlab-runner
-v /var/run/docker.sock:/var/run/docker.sock
gitlab/gitlab-runner:latest
docker-runner注册到gitlab
docker run --rm -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register
--non-interactive
--executor "docker"
--docker-image python:latest
--url "http://10.0.0.6/"
--registration-token "Sui6mVh96k2HXzJAhcGW"
--tag-list "docker"
--run-untagged="true"
--locked="false"
--access-level="not_protected"
注册命令解释
docker run --rm -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register
--non-interactive
--executor "docker" 执行方式 docker （dockershellk8s）
--docker-image alpine:latest 指定docker使用的基础镜像
--url "http://10.0.0.6/" gitlab的url地址
--registration-token "Sui6mVh96k2HXzJAhcGW" token值
--tag-list "test-cicd2,docker-cicd2" 标签
--run-untagged="true" 是否运行没有标签的任务
--locked="false" 是否为锁定状态
--access-level="not_protected" 运行级别
gitlab-runner的执行器
shell
docker
K8S
完整版如下图：
对支持的执行器功能进行了对比
✗ 为不支持
✓ 为支持
| Executor | SSH | Shell | VirtualBox | Parallels | Docker | Kubernetes | Custom |
|---|---|---|---|---|---|---|---|
| Clean build environment for every build | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | conditional (4) |
| Reuse previous clone if it exists | ✓ | ✓ | ✗ | ✗ | ✓ | ✗ | conditional (4) |
| Runner file system access protected (5) | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | conditional |
| Migrate runner machine | ✗ | ✗ | partial | partial | ✓ | ✓ | ✓ |
| Zero-configuration support for concurrent builds | ✗ | ✗ (1) | ✓ | ✓ | ✓ | ✓ | conditional (4) |
| Complicated build environments | ✗ | ✗ (2) | ✓ (3) | ✓ (3) | ✓ | ✓ | ✓ |
| Debugging build problems | easy | easy | hard | hard | medium | medium | medium |
命令解释（help为主 man手册有待补充）
gitlab-runner的命令解释
gitlab-runner
exec 在本地执行构建
list 此命令列出了保存在配置文件中的所有运行程序
run 运行多程序服务
register 默认交互模式下使用，非交互模式添加--non-interactive
install 下载服务
uninstall 卸载服务
start 启动服务
stop 停止服务
restart 重新启动服务
status 获取服务的状态
run-single 单程起跑
unregister 使用令牌注销
gitlab-runner unregister --ur http://10.0.0.6/ --token xxxx
gitlab-runner unregister --name test-runner 使用名称注销
gitlab-runner unregister --all-runners 注销所有
verify 此命令检查注册的runner是否可以连接，但不验证gitlab服务是否正在使用runner。 --delete 删除
artifacts-downloader 下载并提取构建工件
artifacts-uploader 创建和上传构建工件
cache-archiver 创建和上载缓存工件
cache-extractor 下载并提取缓存工件（内部）
cache-init 已更改缓存路径的权限（内部）
health-check 检查特定地址的运行状况
read-logs 从kubernetes执行器使用的文件读取作业日志
help, h
gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
#--user 指定将用于执行构建的用户
#--working-directory 指定将使用shell executor 运行构建时所有数据都将存储在其中的根目录
gitlab-runner uninstall #该命令停止运行并从服务中卸载gitlab runner
gitlab-runer start #该命令启动gitlab-runner服务
gitlab-runer stop #停止gitlab-runner服务
gitlab-runer restart #重启gitlab-runner服务
gitlab-runer status #此命令显示gitlab-runner服务。当服务正在运行时，退出代码为0；当服务未运行时，退出代码未非零。
gitlab-ctl的命令解释
omnibus-ctl: command (subcommand)
check-config
检查gitlab.rb中是否有在指定版本中删除的任何配置
deploy-page
打开部署页面
diff-config
将用户配置与软件包可用配置进行比较
prometheus-upgrade
将Prometheus数据升级至受支持的最新版本
remove-accounts
删除此包使用的*所有*用户和组
reset-grafana
通过删除数据目录将Grafana实例重置为其初始状态
set-grafana-password
重置Grafana的管理员密码
upgrade
在包升级后运行迁移
General Commands:
cleanse
删除*所有*gitlab数据，从头开始。
help
Print this help message.
reconfigure
重新配置应用程序。
show-config
显示重新配置将生成的配置。
uninstall
终止所有进程并卸载进程管理器（数据将被保留）。
Service Management Commands:
graceful-kill
尝试优雅的停止，然后关闭整个进程组。
hup
发送服务一个HUP。
int
向服务发送一个INT。
kill
发送服务一个杀手锏。
once
如果服务关闭，请启动服务。如果它们停止，请不要重新启动它们。
restart
如果服务正在运行，请停止服务，然后重新启动它们。
service-list
列出所有服务（启用的服务显示为*）
start
Start services if they are down, and restart them if they stop.
status
显示所有服务的状态。
stop
停止服务，不要重新启动它们。
tail
查看所有已启用服务的服务日志。
term
发送服务一个期限。
usr1
将服务发送到USR1。
usr2
将服务发送到USR2。
Backup Commands:
backup-etc
备份GitLab配置[接受目录路径]
Let's Encrypt Commands:
renew-le-certs
续订现有证书让我们加密证书
Database Commands:
pg-password-md5
以PostgreSQL格式生成用户密码的MD5哈希
pg-upgrade
将PostgreSQL数据库升级至受支持的最新版本
revert-pg-upgrade
运行此操作以还原到数据库的早期版本
set-replication-password
设置数据库复制密码
Container Registry Commands:
registry-garbage-collect
gitlab-backup
Usage: gitlab-backup COMMAND [OPTIONS]
OPTIONS:
-h, --help Display this help message and exits. Use `COMMAND --help`
for more information on a command.
COMMANDS:
create 创建新备份。
restore 从备份中恢复
gitlab-psql
psql is the PostgreSQL interactive terminal.
Usage:
psql [OPTION]... [DBNAME [USERNAME]]
General options:
-c, --command=COMMAND 仅运行单个命令（SQL或内部）并退出
-d, --dbname=DBNAME 要连接到的数据库名称（默认值：“gitlab psql”）
-f, --file=FILENAME 从文件中执行命令，然后退出
-l, --list 列出可用的数据库，然后退出
-v, --set=, --variable=NAME=VALUE
将psql变量名设置为VALUE
(e.g., -v ON_ERROR_STOP=1)
-V, --version 输出版本信息，然后退出
-X, --no-psqlrc 不读取启动文件（~/.psqlrc）
-1（“一”），--单笔交易
作为单个事务执行（如果非交互式）
-?, --help[=options] show this help, then exit
--help=commands 列出反斜杠命令，然后退出
--help=variables 列出特殊变量，然后退出
Input and output options:
-a, --echo-all 从脚本回显所有输入
-b, --echo-errors 回显失败的命令
-e, --echo-queries 发送到服务器的回显命令
-E, --echo-hidden 显示内部命令生成的查询
-L, --log-file=FILENAME 将会话日志发送到文件
-n, --no-readline 禁用增强的命令行编辑（readline）
-o, --output=FILENAME 将查询结果发送到文件（或|管道）
-q, --quiet 安静运行（无消息，仅查询输出）
-s, --single-step 单步模式（确认每个查询）
-S, --single-line 单行模式（行尾终止SQL命令）
Output format options:
-A, --no-align 未对齐表输出模式
-F, --field-separator=STRING
未对齐输出的字段分隔符（默认值：“|”）
-H, --html HTML表格输出模式
-P, --pset=VAR[=ARG] 将打印选项VAR设置为ARG（请参阅pset命令）
-R, --record-separator=STRING
未对齐输出的记录分隔符（默认值：换行符）
-t, --tuples-only 仅打印行
-T, --table-attr=TEXT 设置HTML表格标记属性（例如，宽度、边框）
-x, --expanded 打开扩展表输出
-z, --field-separator-zero
将未对齐输出的字段分隔符设置为零字节
-0, --record-separator-zero
将未对齐输出的记录分隔符设置为零字节
Connection options:
-h, --host=HOSTNAME 数据库服务器主机或套接字目录（默认值：“本地套接字”）
-p, --port=PORT 数据库服务器端口（默认值：“5432”）
-U, --username=USERNAME 数据库用户名（默认值：“gitlab psql”）
-w, --no-password 从不提示输入密码
-W, --password 强制密码提示（应自动发生）
For more information, type "?" (for internal commands) or "help" (for SQL
commands) from within psql, or consult the psql section in the PostgreSQL
documentation.
Report bugs to <pgsql-bugs@postgresql.org>.
gitlab-rails
The most common rails commands are:
generate 生成新代码（简写别名：“g”）
console 启动Rails控制台（快捷别名：“c”）
server 启动Rails服务器（快捷别名：“s”）
test 运行系统测试以外的测试（简写别名：“t”）
test:system 运行系统测试
dbconsole 为config/database.yml中指定的数据库启动控制台
(short-cut alias: "db")
new 创建一个新的Rails应用程序。”rails new my_应用程序“创建一个
“/my_应用程序”中名为MyApp的新应用程序
gitlab-rake
rake [-f rakefile] {options} targets...
Options are ...
--backtrace=[OUT] 启用完全回溯。OUT可以是stderr（默认值）或stdout。
--comments 仅显示已评论的任务
--job-stats [LEVEL] 显示作业统计信息。级别=历史记录显示完整的作业列表
--rules 跟踪规则解决方案。
--suppress-backtrace PATTERN 抑制与regexp模式匹配的回溯线。如果--trace打开，则忽略。
-A, --all 显示所有任务，即使是未注释的任务（与-T或-D组合使用）
-B, --build-all 构建所有先决条件，包括最新的先决条件。
-D, --describe [PATTERN] 描述任务（匹配可选模式），然后退出。
-e, --execute CODE 执行一些Ruby代码并退出。
-E, --execute-continue CODE 执行一些Ruby代码，然后继续正常的任务处理。
-f, --rakefile [FILENAME] 使用FILENAME作为要搜索的rakefile。
-G, --no-system, --nosystem 使用标准项目Rakefile搜索路径，忽略系统范围的Rakefile。
-g, --system 使用系统范围（全局）rakefile（通常为“~/.rake/*.rake”）。
-I, --libdir LIBDIR 在所需模块的搜索路径中包括LIBDIR。
-j, --jobs [NUMBER] 指定并行执行的最大任务数(默认值为CPU核心数+4）
-m, --multitask 将所有任务视为多任务。
-n, --dry-run 在不执行操作的情况下进行试运行。
-N, --no-search, --nosearch 不要在父目录中搜索Rakefile。
-P, --prereqs 显示任务和依赖项，然后退出。
-p, --execute-print CODE 执行一些Ruby代码，打印结果，然后退出。
-q, --quiet 不要将消息记录到标准输出
-r, --require MODULE 在执行rakefile之前需要模块。
-R, --rakelibdir RAKELIBDIR, 自动导入RAKELIBDIR中的任何.rake文件(默认值为“rakelib”）
--rakelib
-s, --silent 比如--quiet，但也会抑制“目录中”公告。
-t, --trace=[OUT] 启用调用/执行跟踪，启用完全回溯跟踪。OUT可以是stderr（默认值）或stdout。
-T, --tasks [PATTERN] 显示带有描述的任务（匹配可选模式），然后退出-AT组合显示不包含任何说明的所有任务。
-v, --verbose 将消息记录到标准输出。
-V, --version Display the program version.
-W, --where [PATTERN] 描述任务（匹配可选模式），然后退出。
-X, --no-deprecation-warnings 禁用弃用警告
gitlab的config
文件名gitlab.rb
实在太长详细另一文件<gitlab配置文件-gitlab.rb详解>
gitlab-runner的config
文件名config.toml
官方解释链接<https://docs.gitlab.com/runner/configuration/advanced-configuration.html>
配置默认在/etc/gitlab-runner/config.toml,配置文件更改时不需要重启服务，每隔三秒gitlab runner会检查配置修改并重新加载。
[全局配置]
concurrent 限制可以同时运行的作业数量
log_level 日志级别
log_format 日志格式
check_interval 检查作业的间隔长度，默认为3秒
sentry_dsn 启用Sentry错误跟踪
listen_address http服务监听地址
[session_server]
listen_address 会话服务器的内部URL
advertise_address 访问会话服务器URL
session_timeout 作业完成后会话可以保持活动状态的秒数，默认值为1800秒
[runners]
name 描述
url GitLab 实例 URL
token runner的的特殊令牌（不是注册令牌）
tls-ca-file 使用 HTTPS 时验证对等方的证书的文件
tls-cert-file 使用 HTTPS 时与对等方进行身份验证的证书的文件
tls-key-file 使用 HTTPS 时要与对等方进行身份验证的私钥的文件
limit 限制同时处理作业数量，0（默认）表示不限制
executor 选择应如何构建项目
shell 生成脚本的 shell 的名称，默认值取决于平台。
builds_dir 构建存储在所选执行程序上下文中的目录的绝对路径。例如，本地、Docker 或 SSH
cache_dir 构建缓存存储在所选执行程序上下文中的目录的绝对路径。例如，本地、Docker 或 SSH。如果使用dockerexecutor，则需要在其volumes参数中包含该目录
environment 追加或覆盖环境变量。
request_concurrency 限制来自 GitLab 的新作业的并发请求数，默认为1
output_limit 最大构建日志大小，默认值为4096(4MB)
pre_clone_script 在克隆 Git 存储库之前执行的命令
pre_build_script 在克隆 Git 存储库之后但在执行构建之前执行的命令
post_build_script 在执行构建之后执行的命令
clone_url 覆盖 GitLab 实例的 URL
debug_trace_disabled 禁用CI_DEBUG_TRACE特性。当设置为true时，即使用户将CI_DEBUG_TRACE设置为true，调试日志(跟踪)也将保持禁用状态
referees 额外的工作，将结果作为工作工件传递给 GitLab
[executors]
shell 默认执行器
docker docker容器
docker-windows Windows的docker容器
docker-ssh docker容器 使用ssh连接
ssh 远程ssh
parallels Parallels VM，使用 SSH 连接
virtualbox VirtualBox VM，但使用 SSH 连接
docker+machine 类似docker，但使用自动缩放的 Docker 机器
docker+ssh+machine 类似docker-ssh，但使用自动缩放的 Docker 机器
kubernetes Kubernetes pods
[runners.docker]
allowed_images 可以在.gitlab-ci.yml文件中指定的镜像的通配符列表；如果不存在，则允许所有镜像（相当于["/:*"]）
allowed_services 可以在.gitlab-ci.yml文件中指定的服务的通配符列表；如果不存在，则允许所有镜像（相当于["/:*"]）
cache_dir 缓存目录，此路径可以是绝对路径，也可以是路径
cap_add 向容器添加额外的 Linux 功能
cap_drop 从容器中删除其他 Linux 功能
cpuset_cpus 对照组的CpusetCpus
cpu_shares 用于设置相对 CPU 使用率的 CPU 份额数，默认为1024
cpus CPU数量（在 Docker 1.13 或更高版本中可用）
devices 与容器共享其他主机设备
disable_cache 执行器有两个级别的缓存：全局缓存和基于 Docker 卷的本地缓存，此配置标志仅作用于禁用自动创建（未映射到主机目录）缓存卷的本地配置标志
disable_entrypoint_overwrite 禁用镜像覆盖entrypoint
dns 供容器使用的 DNS 服务器列表
dns_search DNS 搜索域列表
extra_hosts 应该在容器环境中定义的主机
gpus Docker容器的GPU设备使用与dockercli相同的格式查看Docker 文档中的详细信息
helper_image （高级）用于克隆存储库和上传工件的默认帮助程序镜像
helper_image_flavor 设置辅助镜像风格（alpine或ubuntu）默认为alpine.
host 自定义 Docker 端点默认为DOCKER_HOST环境或unix:///var/run/docker.sock.
hostname Docker 容器的自定义主机名
image 用于运行作业的镜像
links 应与运行作业的容器链接的容器
memory 内存限制
memory_swap 总内存限制
memory_reservation 内存软限制
network_mode 将容器添加到自定义网络
oom_kill_disable 如果发生内存不足 (OOM) 错误，不终止容器中的进程
oom_score_adjust OOM分数调整
privileged 使容器以特权模式运行
pull_policy 镜像拉取策略：never，if-not-present或always（默认）查看拉取策略文档中的详细信息您还可以添加多个拉取策略
runtime Docker 容器的运行时
security_opt 安全选项（–security-opt in docker run）获取:分隔键/值的列表
shm_size 镜像的共享内存大小（以字节为单位）
sysctls sysctl选项
tls_cert_path存储 ca.pem、cert.pem 或 key.pem 的目录，用于与 Docker 建立安全的 TLS 连接。在 boot2docker 中很有用。
tls_verify启用或禁用对 Docker 守护程序连接的 TLS 验证，默认禁用
userns_mode启用用户命名空间重新映射选项时，容器和 Docker 服务的用户命名空间模式，在 Docker 1.10 或更高版本中可用
volumes安装挂载卷与 Docker-v标志的语法相同
volumes_from从另一个容器继承挂载卷，访问级别默认为读写，但可以手动设置为ro（只读）或rw（读写）
volume_driver用于容器的挂载卷驱动程序
wait_for_services_timeout等待 Docker 服务的时间设置0为禁用默认为30
gitlab-ci的理论
gitlab-ci的工作流程
gitlab的ci流程的组成部分:
code:开发人员推送的代码
.gitlab-ci.yml 指定构建、测试和部署的脚本。
GitLab Runner 运行.gitlab-ci.yml脚本
gitlab-ci的工作流程：
①开发人员推送代码到指定分支
②触发gitlab-pipeline，自动检测运行.gitlab-ci.yml文件
③gitlab runner运行脚本，根据脚本内容进行build test deploy
gitlab-ci的工作原理
①将代码托管到git存储库
②在项目根目录创建ci文件 .gitlab-ci.yml，在文件中指定构建，测试和部署脚本。
③gitlab将检测到他并使用名为gitlab-runner的工具运行脚本
④脚本被分组为作业，他们共同组成一个pipeline
gitalb-ci的工作流程图
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-If6k5d1p-1629288433710)(C:Usersshiya.liuAppDataRoamingTypora ypora-user-imagesimage-20210818171625082.png)]](https://img-blog.csdnimg.cn/0245b0b5bfc141098167f918d26448ef.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjUwNjU5OQ==,size_16,color_FFFFFF,t_70)
gitlab-runner简介
1、gitlab-runner是一个开源项目，用于运行作业并将结果返回给gitlab
2、与gitlab-ci结合使用，gitlab-ci是gitlab随附的用于协调作业的开源持续集成服务。
3、gitlab-runner是使用go语言写的，可以在Linux macos Windows操作系统上进行运行
4、容器部署需要使用最新docker版本。gitlab-runner需要最少的docker v1.13版本
5、gitlab-runner版本应和gitlab版本进行同步（避免版本不一致导致差异化）
6、可以根据需要配置任意数量的runner
PS：ditlab-runner类似于Jenkins的agent，执行CI持续集成、构建的脚本任务。
gitlab-runner的特点
作业运行控制：同时执行多个作业
作业运行环境：
①在本地、使用docker容器、使用docker容器并通过SSH执行作业
②使用docker容器在不用的云和虚拟化管理程序上自动缩放
③连接到远程SSH服务器
支持bash、Windows batch和Windows powershell
允许自定义作业运行环境
自动重新加载配置，无需重启
易于安装，可作为Linux，macos和Windows的服务
gitlab-runner类型与状态
类型：
shared 共享类型，运行整个平台项目的作业（gitlab）
group 项目组类型，运行特定group下的所有项目的作业（group）
specific 项目类型，运行指定的项目作业（project）
状态：
locked 锁定状态，无法运行项目作业
pause的 暂停状态，暂时不会接受新的作业
job的运行流程
（根据job的输出日志进行分析）
Running with gitlab-runner 14.1.0 (8925d9a0) on c088e5ef43f3 RXcgCdUx #选择的gitlab-runner准备运行pipeline
Preparing the "shell" executor #准备“shell”执行器
Using Shell executor... #正在使用Shell执行器
Preparing environment #准备环境
Running on ea06ddae5852... #正在ea06ddae5852（container id）上运行
Getting source from Git repository #从Git存储库获取源代码
Fetching changes with git depth set to 50... #正在获取git深度设置为50的更改
Reinitialized existing Git repository in /home/gitlab-runner/builds/RXcgCdUx/0/root/shell/.git/ #在/home/gitlab runner/builds/rxgcdux/0/root/shell/.Git中重新初始化现有Git存储库/
Checking out 5b8e0163 as main... #查找对比
Skipping object checkout, Git LFS is not installed. #正在跳过对象签出未安装Git LFS。
Skipping Git submodules setup #正在跳过Git子模块安装程序
Executing "step_script" stage of the job script #执行作业脚本的“步骤脚本”阶段
$ ls
python-demo.py
test
$ ls
python-demo.py
test
$ sleep 10
$ echo "mvn clean"
mvn clean
$ sleep 3
$ touch /home/gitlab-runner/builds/RXcgCdUx/0/root/shell/test.txt
$ pwd
/home/gitlab-runner/builds/RXcgCdUx/0/root/shell
$ sleep 30
Job succeeded
(gitlab两大要素：gitlab-runner;.gitlab-ci.yml)
.gitlab-ci.yml的编写语法
pipeline语法1
job：
在每个项目中，使用名为.gitlab-ci.yml的问价配置gitlab ci cd 的pipeline。在文件中可以定义一个或多个job。每个job必须具有唯一的名称（不能使用关键字），每个job都是独立执行的。作业定义了在约束条件下进行的相关操作，每个job至少包含一个script。
例如：
job1:
script: "execute-script-for-job1"
job2:
script: "execute-script-for-job2"
这里在pipeline中定义了两个作业，每个作业运行不同的命令，命令可以是shell脚本。
script:
用于运行命令
before_script：
用于定义一个命令，该命令在每个作业之前运行，必须是一个数组。指定的是script与主脚本中指定的任何脚本串联在一起，并在单个shell中一起执行；
类似于before_script&&script 这样在一个shell中执行，如果before_script失败则script不会执行。
befor_script失败导致整个作业失败，其他作业将不再执行。作业失败不会影响after_script运行。
after_script与before_script&&script不是在一个shell中执行，所以他们的失败不会影响到after_script的执行。
after_script:
用于定义将每个作业（包括失败的作业）之后运行的命令。
这必须是一个数组。
指定的脚本在新的shell中执行，与任何before_script或script脚本分开。、
after_script失败不会导致作业失败。
举例：
build:
stage: build
tags:
- shell
only:
- main
before_script:
- echo "这是before_script脚本，表示要和script进行串行执行命令了"
script:
- echo "mvn clean"
- echo "mvn install"
after_script:
- echo "这是after_script脚本，表示before_script&&script脚本执行顺序已经过了，但是并不代表他们是否执行成功，这个job即将执行完成"
stages:
用于定义作业可以使用的阶段，并且是全局定于的
同一阶段的作业并行运行，不同界阶段按顺序运行。
阶段的名字可以随意起名
.pre和.post
.pre始终是整个管道的第一个运行阶段，.post始终是整个管道的最后一个运行阶段。用户定义的阶段都在两者之间运行。.pre和.post的顺序无法更改。如果pipeline仅包含.pre和.post阶段的作业，则不会创建pipeline。
stage:
是按照job定义的，并且依赖于全局定义的stages。它允许将作业分为不同的阶段，并且同一个stage作业可以并行执行（取决特定条件）
举例：
stages:
- build
- deploy
编译:
stage: build #使用stages定义的阶段，进行执行。
...
...
variabls
定义变量，pipeline变量、job变量。job变量优先级最大。
举例：
variabls:
DOMAIN: example.com
pipeline语法2
pipeline语法2
tags:
用于允许运行该项目的所有runner列表中选择特定的runner，在runner注册期间，可以指定runner的标签
allow_failure：
允许失败
allow_faulure允许作业失败，默认值是false。启用后，如果job失败，该job将在用户界面显示橙色警告，到那是，pipeline的逻辑流程将认为job执行通过，并且不会阻塞。假设所有其他job均为成功，则该job的阶段以及他的pipeline将显示相同的橙色警告。但是，关联的提交将被标记为“通过”，而不会发出警告。不会影响下个job的执行。
when：
on_success 前面阶段中的所有job都成功时才执行job，是默认值
on_failure 当前面阶段出现失败时执行
always 总是执行job
manual 手动执行job
delayed 延迟执行job
retry：
重试
配置在失败的情况下重试job的次数
当job失败并配置了retry，将再次处理该作业，直到达到retry关键字指定的次数
如果retry设置为2，并且job在第二次运行成功（第一次重试），则不会再次重试，retry值必须是一个整数，等于或大于0，但小于等于2（最多两次重试，总共运行3次）。
retry也可以设置精确匹配错误
默认情况下，在失败情况下重试job。max:最大重试次数 when：重试失败的错误类型。
always ：在发生任何故障时重试（默认）.
unknown_failure ：当失败原因未知时。
script_failure ：脚本失败时重试。
api_failure ：API失败重试。
stuck_or_timeout_failure ：作业卡住或超时时。
runner_system_failure ：运行系统发生故障。
missing_dependency_failure: 如果依赖丢失。
runner_unsupported ：Runner不受支持。
stale_schedule ：无法执行延迟的作业。
job_execution_timeout ：脚本超出了为作业设置的最大执行时间。
archived_failure ：作业已存档且无法运行。
unmet_prerequisites ：作业未能完成先决条件任务。
scheduler_failure ：调度程序未能将作业分配给运行scheduler_failure。
data_integrity_failure ：检测到结构完整性问题。
timeout：
job级别的超时可以超过项目级别的超时，但不能超过runner特定的超时。
三个超时：job的超时、项目的超时、runner的超时
示例1：
runner超时时间设置为24小时，项目的CICD超时设置为2小时，该工作将在2小时后超时；
示例2：
runner不设置超时时间，项目的CICD超时设置为2小时，该工作将在24小时后超时
示例3：
runner超时设置为30分钟，项目的CICD超时设置为2小时，该工作在30分钟后将超时
timeout的应用场景：
防止某个项目占用runner时间过长，防止runner被长时间占用
parallel：
并行作业
配置要并行运行的作业实例数，此值必须大于等于2并且小于等于50
这将创建N个并行运行的同一作业实例，他们从job_name_1到job_name_N依次命名。
举例：
codescan:
tags:
- training
stage: codescan
script:
- echo "run codesacn"
- sleep 3;
when: on_success
parallel: 5
before_script: #全局设定执行job前的输出（优先级小于job内定义的before_script）
- echo "before-script!!" #输出内容
variables: #定义的全局变量
DOMAIN: example.com #变量内容的key:value
stages: #定义job要执行的内容 配合stage进行选定，定义了执行顺序
- build
- test
- codescan
- deploy
build: #注意 这里的build是job的名字 stages中的要真正执行的内容
before_script: #job内定义的要执行前输出的内容
- echo "before-script in job"
stage: build #选定执行的内容
script:
- echo "mvn clean "
- echo "mvn install"
- echo "$DOMAIN"
after_script: #执行完成后输出的内容
- echo "after script in buildjob"
unittest: #job名字
stage: test #选择的执行内容
script:
- ech "run test"
when: delayed #设置延时30秒的job
start_in: '30'
allow_failure: true #开启允许job运行失败
deploy: #job名
stage: deploy #选择要执行的内容
script:
- echo "hello deploy"
- sleep 2;
when: manual #设定手动执行
codescan: #job名
stage: codescan #绑定stages中设置的阶段名
script:
- echo "codescan"
- sleep 5;
when: on_success #当前面都执行成功再执行这个job
after_script: #全局定义job执行完成后输出的语句，如果job中没定义则会执行全局的after_script
- echo "after-script"
- ech
pipeline语法3
pipeline语法3
only：
定义那些分支和标签的git项目将会被job执行（用分支策略来限制job的构建，写在那个步骤，那个步骤就不会执行）
except：
定义那些分支和标签的git项目将不会被执行（用分支策略来限制job的构建）
rules：
构建规则
rules允许按顺序评估单个规则，直到匹配并为工作动态提供属性
rules不能和only/except进行组合使用
可用规则：
if（如果条件匹配）
changes（指定文件发生变化）
exists（指定文件存在）
rules-if条件匹配
如果DOMAIN的值匹配，则需要手动执行
不匹配on_success
条件判断从上到下，匹配即停止
多条件匹配可以使用&& ||
举例：
codescan:
tags:
- training
stage: codescan
script:
- echo "run codesacn"
- sleep 3;
rules:
- if: '$DOMAIN == "example.com"'
when: manual
- if: '$DOMAIN == "aexample.com"'
when: delayed
start_in: '5'
- when: on_success
rules-changes 文件变化
接受文件路径数组
如果提交中文件发生的变化则为true
rules-exists
文件存在
接受文件路径数组
当仓库中存在指定的文件时操作
workflow：
控制pipeline的运行
顶级workflow关键字适用于整个pipeline，并将确定是否运行pipeline
when 可以设置为always或never，如果未提供，则默认值为always
pipeline语法4
pipeline语法4
cache:缓存
存储编译项目所需的运行时依赖想项，指定项目工作空间中需要在job之间缓存的文件或目录
全局cache定义在job之外，针对所有job生效。job中cache优先于全局中的cache。
cache：paths
在job build中定义缓存，将会缓存target目录下的所有.jar文件
当在全局定义了cache:paths会被job中定义的cache所覆盖。
问题：
由于缓存是在job之间共享的，如果不同的job使用不同的路径就出现了缓存覆盖的问题
如何让不同的job缓存不同的cache呢？
解决：设置不同的cache:key
cache:key-缓存标记
为缓存做个标记，可以配置job，分支为key来实现分支、作业特定的缓存。
为不同job定义了不同的cache:key时，会为每个job分配一个独立的cache。
cache:key变量可以使用任何预定义变量，默认default
从gitlab9.0开始，默认情况下所有内容都在pipeline和作业之间共享。
按照发分支设置缓存
cache:
key: ${CI_COMMIT_REF_SLUG}
cache:key:files 文件变化自动创建缓存
files:文件发生变化自动重新生成缓存（files最多指定两个文件），提交的时候检查指定的文件。根据指定的文件生成密钥计算SHA校验，如果文件未改变，值就为default
cache:policy 缓存策略
默认：在执行开始下载时下载文件，并在结束时重新上传文件
policy:pull跳过下载步骤，policy：push，跳过上传步骤
artifacts：
制品
用于指定在作业成功或者失败时应附加到作业的文件或目录的列表。作业完成后，工件将被发送到gitlab，并在gitlab ui中提供下载
artifacts:expose_as关键字可用于在合并请求UI中公开作业工件，每个合并请求最多可以公开10个作业工件
artifacts:name 制品名称
通过name指令定义所创建的工件存档的名称。可以为每个档案使用唯一的名称。
artifacts:name默认名称是artifacts，下载artifacts改为artifacts.zip
artifacts:when 制品创建条件
用于在作业失败时或者成功后再上传工件
on_success仅在作业成功时上传工件，默认值
on_faulure仅在作业失败时上传工件
always 上传工件，无论作业状态如何
artifacts:expire_in 制品保留时间
制品的有效期，从上传和存储到gitlab的时间开始计算。如果未定义过期时间，则默认30天
expire_in的值以秒为单位的经过时间，除非提供了单位。
artifacts:reports:junit 单元测试报告
单元测试报告功能默认关闭（因为消耗资源严重）
收集junit单元测试报告，收集的junit报告将组为工件上传到gitlab，并将自动显示在合并请求中。
开启artifacts:reports:junit单元测试报告功能步骤：
$gitlab-rails console
$Feature.enable(:junit_pipeline_view)
=> true
artifacts:reports:cobertura-覆盖率
需要做maven集成cobertura插件
在maven中配置完成后执行mvn cobertura:cobertura 运行测试并产生Cobertura覆盖率
dependencies获取制品
定义要获取工件的作业列表，只能从当前结点之前执行的节点定义作业，定义一个空数组将跳过下载该作业的任何工件不会考虑先前作业的状态，因此，如果他是失败或者未运行的手动作业，则不会发生错误。如果设置为依赖项的作业的工件已过期或者删除，那么依赖项作业将失败。
pipeline语法5
pipeline语法5
needs：（parallel是并行运行job，needs是并行运行阶段）
阶段并行
可无序执行作业，不需要按照阶段顺序运行某些作业，可以让多个阶段同时运行。如果needs设置为指向因only/execpt规则而未实例化的作业，或者不存在，则创建pipeline时会出现yaml错误。
include:
local引入本地配置，引入同一存储库中的文件，使用相对于根目录的完整路径进行引用，与配置文件在同一分支上使用。
可以允许引入外部yaml文件，文件具有扩展名.yml
使用合并功能可以自定义和覆盖包含本地定义的CI/CD配置
引入同一存储库中的文件，使用相对于根目录的完整路径进行引用，与配置文件在同一分支上使用。
file:
引入其他项目的文件
template：https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates
只能使用官方提供的模板
remote:引入远程配置
用于通过HTTP/HTTPS包含来自其他位置的文件，并使用完整URL进行引用，远程文件必须可以通过简单的GET请求公开访问，因为不支持远程URL中的身份验证框架。
extends:
继承作业配置
举例：
stages:
- test
variables:
RSPEC: 'test'
.test:
script: echo "mvn test"
stage: test
only:
refs:
- branches
testjob:
extends: .test
script: echo "mvn clean test"
only:
variables:
- $RSPEC
trigger:
当gitlab从trigger定义创建的作业启动时，将创建一个下游管道。允许创建多项目和子管道。将trigger与when: manual一起使用会导致错误。
多项目管道：跨多个项目设置流水线，以便一个项目中的管道可以触发另一个项目中的管道。
父子管道：在同一个项目中管道可以触发一组同时运行的子管道，子管道仍然按照阶段顺序执行其每个作业，但是可以自由地继续执行各个阶段，而不必等待父管道中无关的作业完成。
image:
默认在注册runner的时候需要填写一个基础的镜像，只要使用执行为docker类型的runner所有的操作都会在容器中运行。如果全局指定了image则所有作业使用此image创建容器并在其中运行。全局未指定image，再次查看job中是否有指定，如果job中有指定则按照指定镜像创建容器运行，没有则使用注册runner时指定的镜像。
services
工作期间运行的另一个docker镜像，并link到image关键字定义的docker镜像，这样就可以再构建期间访问服务镜像。
服务镜像可以运行任何应用程序，但是最常见的用例是运行数据库容器，例如MySQL。于每次按照项目时都安装MySQL相比，使用现有镜像并将其作为附加容器运行更容易，更便捷。
services:
- name: msyql:latest
alias: mysql-1
environment
工作期间运行的另一个docker镜像，并link到image关键字定义的docker镜像，这样就可以再构建期间访问服务镜像。
inherit
使用或禁用全局定义的环境变量（variables）或默认值（default）
使用true和false决定是否使用，默认是true
总结->.gitlab-ci.yml文件中共有27个关键词
job #要运行的任务
script #指定脚本内容
before_script #执行job前运行脚本 分为全局和局部
after_script #执行job后运行脚本 分为全局和局部
stages #全局定义作业可用阶段
.pre&.post #.pre始终是第一个运行的阶段；.post始终是最后以一个运行的阶段
stage #配合stages进行引用，按照job进行定义的
variables #定义变量
tags #用于指定runner的标签
allow_failure #允许失败 不影响下一个job的运行
when (manualon_successon_failurealwaysdelayed) #设置触发运行的方式（手动、当前面job成功、当前面job失败、总是执行、延时执行）
retry(maxwhen) #重试
timeout #设置允许超时时间
parallel #并行作业
only&except #定义运行策略跳过某个执行或者进行某个执行
rules(rules:if
ules:changes
ules:exists
ules:allow_faulureworkflow:rules) 定义构建规则
cache(cache:pathscache:keycache:policy) #设置缓存
artifacts(artifacts:pathsartifacts:expose_asartifacts:nameartifacts:whenartifacts:exp ire_inartifacts:reportsartifacts:reports:cobertura) #用于指定在作业成功或者失败时应附加到作业的文件或目录的列表。
dependencies #定义特定的job运行规则
needs #阶段并行 （parallel是并行运行job，needs是并行运行阶段）
include(localfile emplate
emote) #引入配置
extends #集成配置
trigger #当gitlab从trigger定义创建的作业启动时，将创建一个下游管道。
image #定义job执行时使用的镜像
services #工作期间运行的另一个docker镜像，并link到image关键字定义的docker镜像。
environment #定义此作业完成部署的环境名称
inherit #使用或禁用全局定义的环境变量
设置gitlab-runner运行job时不每次都拉取镜像
[[runners]]
name = "26fe27c2cc92"
url = "http://10.0.0.6/"
token = "okWxn2xa6cdAbyR8oLCM"
executor = "docker"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[runners.docker]
pull_policy = "if-not-present" #此配置是设置先检查本地是否有此镜像，没有再去拉取。
tls_verify = false
image = "python:latest"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"]
shm_size = 0
自定义CI配置文件路径
默认情况下，在项目的根目录中查找，.gitlab-ci.yml文件，如果需要，可以指定备用路径和文件名，包括项目外部的位置。
.gitlab-ci.yml
.my-custom-flie.yml
my/path/.gitlab-ci.yml
my/path/.my-custom-file.yml
http://example.com/generate/ci/config.yml
.gitlab-ci.yml@mygroup/another-project
my/path/.myu-custom-file.yml@mygroup/anothner-project
将配置文件托管在单独的项目中，可以更严格地控制配置文件，创建一个公共项目来承载配置文件，仅向被允许编辑文件的用户授予对项目的写权限。其他用户和项目将能够访问配置文件而无需对其进行编辑。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Nab8BUAj-1629288433718)(C:Usersshiya.liuAppDataRoamingTypora ypora-user-imagesimage-20210816162616153.png)]
问题记录
Q:gitlab-runner和gitlab是什么关系？
A:gitlab-runner是跑gitlab上的pipelines的
Q.gitlab-ci.yml的作用是什么？
A:控制job的运行逻辑顺序，定义pipeline，定义job的工作方式、具体细节等。
Q:gitlab的cicd 与gitlab(只存储代码)+Jenkins cicd的方式目的是一样的嘛？两者区别是什么？
A: 只能说目的是一样的，查阅了一些devops的博客、书籍，其实这是两个不同的工具而已， 目的都是更好的服务公司业务的便捷。
Q:燧原公司内部是选择gitlab-cicd做ci工具的，但是燧原公司也有Jenkins，Jenkins在燧原公司的ci流程中是作为什么角色呢？这两个结合使用嘛？
A:是在做迁移，之前是Jenkins（应该是遇到了瓶颈），后转为gitlab-ci。如果是这样的，那么gitlab-ci为什么比Jenkins更适合燧原的业务？（需要慢慢了解）
Q:在gitlab-runner中结合docker进行目标机器的deploy是怎么选择指定机器的？
A:应该是根据gitlab-runner的所在机器，类似于gitlab-runner是agent，gitlab-ci是server。
Q:在gitlab-ci中是不是常常结合docker进行一个交付部署，在不适用docker的场景下gitlab-ci还适用嘛？
支持shell（Jenkins就是基于shell的方式进行的cicd）;具体支持的执行器见上面<gitlab-runner的执行器>
Q：在gitlab-ci中 使用的基础镜像是aplin:latest 可以更改吗？
A:可以的，关键字image执行gitlab-runner执行时运行的镜像。
共分为三部分 ①注册gitlab-runner时指定的镜像：runner的镜像；
②在.gitlab-ci.yml中分为全局变量：定义在job外的image关键词为全局变量：job中没有定义时使用此镜像；
③在job中image关键词指定了镜像，则执行job内的镜像；
Q：默认的提交代码后触发pipeline的方式是什么？
A:修改文件后会触发pipeline的执行也可以设置计划任务来进行手动点击执行
Q:执行docker的解释器时 是怎么执行的，比如我执行echo.sh脚本，pipeline会自动把脚本拷贝到镜像中吗？脚本的执行位置是container还是宿主机？
A:不是拷贝到镜像中，而是拉取项目代码。关于脚本执行的位置，是需要看docker-runner的执行器类型的。如果是shell执行器 则是在gitlab-runner上运行
如果是docker类型的执行器，则会在gitblab-ci上启动新的容器来完成阶段性任务，完成后退出。
Q:指定机器运行 是靠指定gitlab-runner来实现的吗？
A：gitlab-ci 在.gitlab-ci.yml中指定要在那个gitlab-runner上运行。前提是需要在目标机器上运行并注册了gitlab-runner
Q:stage中设置并行执行 是真正的并行吗 我通过观察pipeline运行来看，是串行执行的。
A:进行并行运行需要修改配置文件
vim /srv/gitlab-runner/config/config.toml
concurrent = 10
不需要重启就可生效
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Lac0xLwG-1629288433722)(C:Usersshiya.liuAppDataRoamingTypora ypora-user-imagesimage-20210812152746026.png)]](https://img-blog.csdnimg.cn/5529bf3a8f9545e2a01b86cab1819fca.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjUwNjU5OQ==,size_16,color_FFFFFF,t_70)
Q:.gitlab-ci.yml中怎么设置stages进行并行运行，怎么设置 跳过某个stage进行下面的job
A:设置并行运行就是将一个stages中设置的阶段，在多个job中进行指定stage 进行运行。
stages:
- build
- deploy
编译:
stage: build
tags:
- shell
only:
- main
before_script:
- echo "这是before_script脚本，表示要和script进行串行执行命令了"
script:
- echo "mvn clean"
- echo "mvn install"
after_script:
- echo "这是after_script脚本，表示before_script&&script脚本执行完成了，这个job即将执行完成"
部署:
stage: build
tags:
- docker
only:
- main
script:
- echo "hello deploy"
补充 CI概念以及CI常规流程
CI:持续集成简称CI ，指的是频繁的将代码集成到主干，持续集成的目的就是让产品可以快速迭代同时能保证高质量。核心是必须通过自动化测试，只要有一个测试用例失败，就不能集成。
从代码提交到生产有几个步骤：
1、提交
流程的第一步，是开发者向代码仓库提交代码，所有后面的步骤都始于本地代码的一次提交
2、测试
代码仓库对提交操作配置了钩子，只要提交代码或者合并主干，就会跑自动化测试
3、构建
通过第一轮测试，代码就可以合并主干，算是可以交付了
交付后，就先进行构建，再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源。
4、部署
通过了第二轮测试，当前代码就是一个可以直接部署的版本。将这个版本的所有文件打包存档，发到生产服务器。
5、回滚
一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简答的做法就是修改一下符号连接，指向上一个版本的目录。
CD:持续交付和持续部署称为CD
gitlab-ci的工具链集成
模板库规划
SonarQube代码扫描
Artifactory制品库（gitlab中也有制品库）
阿里云镜像仓库/harbor等
jmeter接口测试简介
gitlab集成自动化测试
minion对象存储
邮件通知pipeline结果
未完待续