1.CI/CD定义

持续集成，持续交付，持续部署

简单定义：CI/CD是一种持续开发软件的方法，可以不断进行构建、测试、部署代码迭代更改。这种迭代有助于减少基于错误或者失败的版本进行开发新代码的可能性。

CI：continuous Integration

CD: continuous delivery/deployment

Gitlab的CI/CD过程：

2.环境配置

2.1镜像

docker pull gitlab/gitlab-ce:16.2.4-ce.0
​
docker pull gitlab/gitlab-runner:v16.2.1

2.2 gitlab

基于原有版本数据运行gitlab（用于版本升级）

1. 运行gitlab容器，映射原有gitlab容器的数据卷

   docker run -d --hostname 192.168.239.142 \
   ​
   -p 443:443 -p 80:80 --name gitlab-ce1 \
   ​
   --restart always \
   ​
   --volumes-from gitlab-ce \
   ​
   --shm-size 256m \
   ​
   gitlab/gitlab-ce:latest

安装新的gitlab

1.运行gitlab容器

docker run -d --hostname 192.168.239.142 \
-p 443:443 -p 80:80 --name gitlab-ce \
--restart always \
#-v ：将宿主机的目录挂载到容器中 \
-v $HOME/work/gitlab/config:/etc/gitlab \
-v $HOME/work/gitlab/logs:/var/log/gitlab \
-v $HOME/work/gitlab/data:/var/opt/gitlab \
--shm-size 256m \
gitlab/gitlab-ce:latest

//查看容器初始密码
docker exec gitlab-ce grep 'Password:' /etc/gitlab/initial_root_password
// 查看gitlab 版本信息
docker exec gitlab-ce gitlab-rake gitlab:env:info

2.root 用户登录

3.修改root用户登录密码

4.注册开发者角色新用户区别于root用户

5.管理员审核

6.登录新用户选择开发者角色

7.创建组

2.3 gitlab-runner

1.拉取最新的gitlab-runner镜像

docker pull gitlab/gitlab-runner:latest

2.运行gitlab-runner，注意，若需要将应用部署到swarm集群，那么需要在管理节点上部署gitlab-runner

# 运行runner
docker run -d --name gitlab-runner1 --restart always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /srv/gitlab-runner/config:/etc/gitlab-runner \
gitlab/gitlab-runner:latest

# 查看版本
docker exec gitlab-runner1 gitlab-runner -v

3.gitlab创建runner，并获得token

4.注册runner

//非交互方式注册
docker run --rm -v /srv/gitlab-runner/config:/etc/gitlab-runner \
gitlab/gitlab-runner register \
-n \
--url "http://192.168.239.142" \
--token "glrt-QyCnwt6m_d71MiABzyMu" \
--name "gitlab-runner1" \
--executor "docker" \
--docker-image docker:24.0.5 \
--docker-volumes /var/run/docker.sock:/var/run/docker.sock \
--docker-pull-policy if-not-present

# 重启容器
docker restart gitlab-runner1

5.runner注册成功

2.4 .gitlab-ci.yaml

2.4.1yaml相关资料

关键词参考文档：https://docs.gitlab.com/ee/ci/yaml/gitlab_ci_yaml.html

CI/CD预定义变量参考文档：https://docs.gitlab.com/ee/ci/variables/

关键词 描述
全局关键词：
default 为某些关键词设置全局的默认值
include 将外部的yaml文件包括到当前配置，例如：将一个长的.gitlab-ci.yml文
件分为多个文件，通过include来引入各个小文件，用于提高可读性
stages 阶段，用于定义作业组的阶段，流水线默认阶段包
括：.pre,build,test,deploy,.post
workflow 通过规则控制流水线的行为Job关键词：
after_script 使用after_script定义在每个作业（包括失败的作业）之后运行的命令数组
allow_failure 使用allow_failure确定作业失败时管道是否应继续运行
artifacts 使用artifacts指定要保存为作业工件的文件。作业工件是作业成功、失败或
始终附加到作业的文件和目录的列表
before_script 使用before_script定义一组命令，这些命令应在每个作业的脚本命令之前运行，
但应在工件恢复之后运行
cache 使用缓存可以指定要在作业之间缓存的文件和目录的列表。只能使用本地工作副本中的路
径 co
verage 将覆盖率与自定义正则表达式一起使用，可以配置如何从作业输出中提取代码
覆盖率
dast_configuration 使用dast_configuration关键字可以指定要在CI/CD配置中使用的站点配置文件
和扫描仪配置文件
dependencies 使用dependencies关键字可以定义从中获取工件的作业列表。您还可以设置一个
作业，以完全不下载工件
environment 定义环境变量或指定作业部署的环境
extends 使用extends可重用配置节。它是YAML锚的一种替代方案，并且更加灵活和
可读
hooks 使用钩子指定在作业执行的某些阶段（如检索Git存储库之前）在运行程
序上执行的命令列表
id_tokens 使用id_tokens创建JSON web令牌（JWT），以通过第三方服务进行身份验
证 im
age 使用image指定作业运行的Docker映像
inherit 使用inherit控制默认关键字和变量的继承
interruptible 如果在作业完成之前新管道启动时应取消作业，请使用可中断
needs 使用needs无序执行作业
only / except only和except来控制何时将作业添加到管道
pages 使用pages定义将静态内容上载到GitLab的GitLab页面作业。然后将
内容发布为网站
parallel 使用parallel在单个管道中并行运行作业多次
release 创建一个发布版本
resource_group 使用resource_group可以创建一个资源组，以确保作业在同一项目的不同管道之间互
斥 re
try 使用“重试”配置作业失败时重试的次数。如果未定义，则默认为0，并且
作业不会重试
rules 使用rules包括或排除管道中的作业
script 使用script为运行程序指定要执行的命令
secrets 使用secrets将CI/CD中的机密信息指定为：1.外部secrets检索提供程
序；2.在作业中作为ci/cd的变量
services 使用services指定脚本成功运行所需的任何其他Docker映像
stage 使用阶段定义作业在哪个阶段运行。同一阶段中的作业可以并行执行
tags 使用标记从项目可用的所有runner列表中选择特定runner
timeout 使用timeout为特定作业配置超时。如果作业运行的时间超过超时时间，则作
业将失败
trigger 使用触发器声明作业是启动下游管道的“触发器作业”
variables 使用变量定义作业的CI/CD变量
when 使用wen配置作业运行的条件。如果未在作业中定义，则默认值为：
on_ccess

2.4.2编写实例

1.在项目中创建gitlab-ci文件

gilab-ci文件内容

#流水线的stages的顺序可以自己定义
#相同阶段的任务将会并发的执行，上一个阶段的任务完整的结束之后，下一个阶段的任务才会开始执行 
stages:
  - check_code 
  - build
  - deploy 
job1:
  stage: check_code
  script:
     - echo 'stage1 job ，读取变量为:' $param1
 
 
job2:
  stage: build
  script:
     - echo 'stage2 job  ，读取变量为:' $param2
 
job3:
  stage: deploy
  script:
     - echo 'stage3 job  ，读取变量为:' $param3
​
​

2.配置gitlab-ci文件中的变量

$param1,$param2,$param3这3个就是变量 进入Settings->CI/CD->Variables

设置参数值 param1=变量1 param2=变量2 param3=变量3 这些值我们在等下运行pipeline时看看是否在gitlab-ci被引用到

3.配置gitlab runner

配置过程参照2.3

4.运行pipeline

进入CI/CD->Pipelines->Run pipeline

运行后看到3个job，这就是stage定义的对应的job

点击job1，可以看到输出的日志，我打印出的信息，看到输出了param1定义的值“变量1”

依次点job2，job3也可以看到输出日志

在job1看到他分几个步骤

1. Preparing the "docker" executor（准备docker执行器，即容器运行环境这里默认加载的镜像是maven:3.5.2-jdk-7）
2. Preparing environment（准备环境）
3. Getting source from Git repository（拉取代码）
4. Executing "step_script" stage of the job script（执行脚本）
​

返回pipeline列表看看运行的pipeline

可以看到job1，job2，job3都是打钩的状态都是正常，点击可以查看该阶段的日志

具体gitlab-ci文件的其他属性，参照2.4.1文档