Gitlab CI/CD

概念

DevOps

Development 和 Operations 的组合，传统的软件组织讲开发和 IT 运营以及质量保障设为分离的部门，Devops 是在敏捷开发模型上进一步发展而来的。满足了产品研发所要求的持续开发、持续测试、持续集成、持续部署。

CI/CD

即 Continuous Integration（持续集成）和 Continuous Delivery（持续交付）Continuous Deployment（持续部署）。

pipeline

配置好的 CI/CD 的流程，比如安装依赖包，进行代码 review、构建、编译、发布等一整套的流程。

GitLab Runner

执行流水线的环境，所有 CI/CD 的任务都是在他内部去进行执行的，GitLab负责代码管理，Runner是流水线，CI/CD 的执行环境，它可以在在 GNU/Linux、K8s、Docker、macOS 和 Windows 上

工具

• GitLab-Runner

• Git

• Node

• npm or Yarn

安装docker以及gitlab-runner

连接服务器

ssh root@10.0.0.xxx

安装docker

curl -fsSL get.docker.com -o get-docker.sh
sudo sh get-docker.sh --mirror Aliyun

开启服务和权限配置

sudo groupadd docker  # 创建 docker 用户组
sudo usermod -aG docker $USER  # 将当前用户加入到 docker 的用户组中

启动 Docker

sudo systemctl enable docker
sudo systemctl start docker
//验证 Docker 环境安装成功
docker info

安装GItlab

sudo docker run --detach \
  --hostname 115.159.52.223 \
  --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

--detach：后台运行，如果去掉，会看到执行的整个过程日志。
--hostname：指定运行的 hostname，可以是域名也可以是 IP。
--publish：端口的映射，可以缩写成 -p 443 用于 HTTPS 协议访问，222 用户 SSH 协议访问，因为 22 端口已经被占用。
--name：容器的名称。
--restart：重启的方式，会自动重启。
--volume：指定本地卷，配置、日志、数据，使用本地卷后，删除容器，不会删除配置、数据。

no：默认策略，在容器退出时不重启容器
on-failure：在容器非正常退出时（退出状态非 0），才会重启容器
on-failure:3：在容器非正常退出时重启容器，最多重启 3 次
always：在容器退出时总是重启容器
unless-stopped：在容器退出时总是重启容器，但是不考虑在 Docker 守护进程启动时就已经停止了的容器

Install GitLab Runner | GitLab

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

安装gitlab-runner

curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64"
chmod +x /usr/local/bin/gitlab-runner
useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
gpasswd -a gitlab-runner docker
newgrp docker
gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
gitlab-runner start

2.注册Gitlab-runner

路径 设置 > CI/CD > Runner > Expand 如图

docker方式

docker run --rm -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register \
  --non-interactive \
  --executor "docker" \
  --docker-image node:16.15.1 \
  --url "http://gitlab.example.com/" \
  --registration-token "TOKEN" \
  --description "runner" \
  --tag-list "docker,coronary" \
  --run-untagged="true" \
  --locked="false" \
  --access-level="not_protected"

进入Runner容器内

docker exec -it gitlab-runner bash
gitlab-runner register ...

普通方式

gitlab-runner register \
  --non-interactive \
  --url "http://gitlab.example.com/" \
  --registration-token "TOKEN" \
  --executor "docker" \
  --docker-image node:16.15.1 \
  --description "runner" \
  --tag-list "docker,coronary" \
  --run-untagged="true" \
  --locked="false" \
  --access-level="not_protected"

取消注册runner

gitlab-runner unregister --url http://example.com/ --token xxxxxxxx

url修改成自己的http://gitlab.exmaple.com/

registration-token修改成自己的TOKEN

2022-06-24-11-19-43-image.png

gitlab后台注册的可用runner

除了 url 和 registration-token 还有几个属性：

1. executor：执行器，可选 docker、k8s、shell

2. description：runner 的描述

3. tag-list：runner 的 tag，使用逗号分隔，如果一个项目有多个 Runner，需要根据 tag 来指定使用那个 Runner 来运行任务

4. locked：是否锁定，锁定后，只能适用于被项目，不能被其他项目使用

关键词

script 被 runner 执行的 shell
script after_script 在 job 之后执的脚本
allow_failure 是否允许 job 失败
artifacts 在 job 成功后将一个文件列表或目录列表制成制品上传
before_script 在 job 之前执行的脚本
cache 缓存在随后的 job 的一些文件、目录
coverage 代码覆盖率设置
dependencies 依赖某个 job 的制品并下载到当前的 job 中
environment job 依赖的环境变量
except 限制那些情况 job 不会被触发
extends job 的继承的配置项
image 依赖的 Docker 镜像
include 运行 job 包含额外的 yml 文件
interruptible 定义当作业因较新的运行而变得冗余时是否可以取消。
only 限制 job 何时可以被触发
pages 上传 job 的结果到 极狐GitLab Pages
parallel 一个 job 应该并行运行多少个实例。
release 通知 runner 生成一个
release resource_group 限制 job 的并发性
retry 是否重试 重试几次
rules 与 only/except 类似，限制 job 的调起
services 使用 Docker 镜像服务
stage 阶段
tags 选择 runner 的 tag
timeout 超时
trigger 定义下游
pipelines 触发器
variables 定义 job 级别的变量
when 何时触发任务

only 和 except 中可以使用特殊的关键字：

• 当一个作业没有定义 only 规则时，其默认为 only: ['branches', 'tags'] 。
• 如果一个作业没有定义 except 规则时，则默认 except 规则为空。

only 和 except高级用法

• only 和 except 支持高级策略，refs 、 variables 、 changes 、 kubernetes 四个关键字可以使用。
• 如果同时使用多个关键字，中间的逻辑是 逻辑与AND 。

only:
    refs:
      - master
      - schedules

 only:
    refs:
      - branches
    variables:
      - $RELEASE == "staging"
      - $STAGING

only:
    changes:
      - package.json

//结合使用
only:
    refs:
      - master
    changes:
      - package.json

//当md文件发生变化时，会忽略CI作业
except:
    changes:
      - "*.md"

//一旦合并请求中修改了js文件或者修改了utils目录下的文件，都会触发Docker构建
only:
    refs:
      - merge_requests
    changes:
      - /^*.js$/
      - utils/**/*

gitlab-ci.yml文件

阮一峰 YAML 教程

branch分支触发构建流程

# 定义node镜像
image: node:16.15.1

before_script:
  - echo "每个job之前都会执行"
  - node -v
  - npm -v
  - git --version
  - npm install -g cnpm --registry=https://registry.npm.taobao.org
  # - yarn -v

variables:
  GIT_SUBMODULE_STRATEGY: recursive

# 阶段
stages:
  - install
  - init
  - build
  - deploy

cache:
  paths:
    - node_modules/
    - build/

# 安装依赖
install:
  stage: install
  # 此处的tags必须填入之前注册时自定的tag
  tags:
    - docker
  # 规定仅在package.json提交时才触发此阶段
  only:
    changes:
      - package.json
  # only:
  #   - dev-mguo
  #   - /^dev-*$/
  # 执行脚本
  script:
    - cnpm install

init:
  stage: init
  tags:
    - docker
  only:
    - dev-mguo
  # 执行脚本
  script:
    - git submodule init && git submodule update && cd framework && git checkout dev && git pull && cd ../

# 打包项目
build:
  stage: build
  only:
    - dev-mguo
  tags:
    - docker
  script:
    - npm run build
  # 将此阶段产物传递至下一阶段
  artifacts:
    paths:
      - build/

# 部署项目
deploy:
  stage: deploy
  only:
    - dev-mguo
  tags:
    - docker
  script:
    # 直接编译上传
    npm run deploy
  # when: manual

# tags 触发

tags触发流程

//新建tag
git tag -a v1.0 -m "Release v1.0"
//查看tag
git tag
//显示tag附注信息
git show v1.0
//提交本地tag到远程仓库
git push origin v1.0
//提交本地所有tag到远程仓库
git push origin --tags
//删除本地tag
git tag -d v1.0
//删除远程tag
git push origin :refs/tags/v1.0
//获取远程版本
git fetch origin tag v1.0

//git-ci.yml配置
only:
  - tags
except:
  - branches

流水线触发

only:
  - triggers

except:
  - triggers

镜像使用

image: node:16.15.1表示使用nodejs 16.15.1版本最为基础镜像，pipelines触发后会pull Nodejs的镜像，npm install、npm run build、npm run deploy的使用需要node的镜像环境。

编写job

before_script代表是每个script脚本执行前的脚本，

stage定义的是阶段的执行顺序

# 阶段
stages:
  - install
  - init
  - build
  - deploy

执行顺序就是 install > init > build > deploy

# 打包项目
build:
  stage: build
  only:
    - dev-mguo
  tags:
    - docker
  script:
    - npm run build
  # 将此阶段产物传递至下一阶段
  artifacts:
    paths:
      - build/
  # when: manual

build代表的是job的名字

stage代表的是执行的阶段

only代表的是在什么分支来执行

tags代表的是执行使用的runner标签

script代表的是执行的脚本

artifacts代表执行的阶段缓存文件

cache代表的是执行过程中缓存的文件

when: manual代表的是手动触发

• on_success ：只有前面的阶段的所有作业都成功时才执行，这是默认值。
• on_failure ：当前面阶段的作业至少有一个失败时才执行。
• always : 无论前面的作业是否成功，一直执行本作业。
• manual ：手动执行作业，作业不会自动执行，需要人工手动点击启动作业。
• delayed : 延迟执行作业，配合 start_in 关键字一起作用， start_in 设置的值必须小于或等于1小时，start_in 设置的值示例： 10 seconds 、 30 minutes 、 1 hour ，前面的作业结束时计时器马上开始计时。

其中 cache 指的是缓存, 常用于依赖安装中, 如几个jobs都需要安装相同的依赖, 可以使用依赖, 此时可以加快依赖的安装进度;
对于artifacts则是将某个工件上传到GitLab提供下载或后续操作使用, 由于每个job启动时, 都会自动删除.gitignore中指定的文件, 因此对于依赖安装目录, 即可以使用cache, 也可以使用artifacts.

两个主要有以下几个区别:

cache不一定命中，artifacts肯定命中, 能否使用cache取决当当前机器是否生成过cache, artifacts则每次都会从GitLab下载
重新安装时因为使用的是缓存, 所以很有可能不是最新的
特别是开发环境, 如果每次都希望使用最新的更新, 应当删除cache, 使用artifacts, 这样可以保证确定的更新
4.artifacts中定义的部分, 会自动生成, 并可以传到下面的job中解压使用, 避免了重复依赖安装等工作
如果使用Docker运行Gitlab-Runner, cache会生成一些临时容器, 不容易清理
artifacts可以设置自动过期时间, 过期自动删除，cache不会自动清理
artifacts会先传到GitLab服务器, 然后需要时再重新下载, 所以这部分也可以在GitLab下载和浏览

到这我们已经做好了项目的 CI持续集成，CD 持续部署还没有做，最常用的是将 build 后的静态文件放到服务器上或者做成Docker 镜像，可以运行在任何一个服务器上。

隐秘变量使用

在 .gitlab-ci.yml 中使用一些密码、私钥，直接使用时非常不安全的。极狐GitLab 提供了一种在 CI/CD 中安全使用隐秘变量的方式，添加变量后在 .gitlab-ci.yml 中使用 $+变量名 的方式来使用，如镜像名、运行的容器名、用户名、密码等。如下图添加变量

2022-06-29-18-09-55-image.png

部署方式

docker方式

# 定义构建镜像
build-image:
  image: $DOCKER_IMG # 依赖的基础镜像
  stage: build
  script:
    - docker login -u $HARBOR_USERNAME -p $HARBOR_PWD $HARBOR_URL # 登录镜像仓库
    - docker build -t $APP_IMAGE_NAME . # 构建镜像
    - docker push $APP_IMAGE_NAME # 推送镜像
    - docker rmi $APP_IMAGE_NAME # 删除本地镜像
  only:
    - master

deploy:
  image: $DOCKER_IMG
  stage: deploy
  script:
    # 如果有容器名为$APP_CONTAINER_NAME 的容器在运行则强行上删除
    - if [ $(docker ps -aq --filter name=$APP_CONTAINER_NAME) ]; then docker rm -f $APP_CONTAINER_NAME; docker image rm -f $APP_IMAGE_NAME;fi

    # 登录镜像仓库
    - docker login -u $HARBOR_USERNAME -p $HARBOR_PWD $HARBOR_URL

    # 使用 8001 端口,镜像名为$APP_CONTAINER_NAME 的后台方式 运行一个镜像
    - docker run -d -p 8001:80 --name $APP_CONTAINER_NAME $APP_IMAGE_NAME
    - echo 'deploy product websit success'
  only:
    - master
  when: manual # 手动执行,需要点击

ssh方式

Runner 跑在机器 A，应用部署在机器 B，那么 Runner 对前端项目 build 之后，怎样将 build 后的静态文件，上传到机器 B？在机器 A 和机器 B 之间创建一个免密登录，在机器 A build 项目之后，静默地调用指令将文件上传到机器 B，从而实现部署。

创建 SSH key并上传

ssh-keygen -t rsa -b 2048 -C "email@example.com"
scp -r id_rsa.pub root@1.2.3.4:/root/.ssh/authorized_keys

将公钥 id_rsa.pub 上传到服务器 authorized_keys 文件中，第一次会保存 known hosts，并且要求输入密码，上传成功后，再次执行上面的命令就不需要输入密码了，免密构建成功，就要配置 CI/CD 了

创建一个 SSH_PRIVATE_KEY 的变量，将秘钥复制进去。接着修改.gitlab-ci.yml 文件

deploy-server:
  stage: deploy
  before_script:
    # 如果没有安装 `ssh-agent`,就安装，基于 RPM 的镜像可以将 apt-get 替换为 yum
    - 'command -v ssh-agent >/dev/null || ( apt-get update -y && apt-get install openssh-client -y )'
    - eval $(ssh-agent -s) # 运行 ssh-agent
    - echo "$SSH_PRIVATE_KEY"| tr -d '\r' | ssh-add -

    # 创建对应的目录并给相应的权限
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh

    - ssh-keyscan ipaddress >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
  script:
    - npm run build
    - scp -r dist/* root@ipaddress:/usr/local/www/hello-vue
  only:
    - master

代码解释：

任务是在 Docker 容器中运行的，所以要使用 ssh 必须要确保已经安装必要的软件。 如果没有安装 ssh-agent，就安装，基于 RPM 的镜像可以将 apt-get 替换为 yum。 注意目录 /usr/local/www/hello-vue 需要配置了 Nginx 映射才能够访问。

trigger触发

use cURL

curl -X POST \
     -F token=TOKEN \
     -F ref=REF_NAME \
     http://gitlab.example.com/api/v4/projects/projectId/trigger/pipeline

curl -X POST \
     -F token=TOKEN \
     -F ref=dev-mguo \
     http://gitlab.example.com/api/v4/projects/projectId/trigger/pipeline

use .gitlab-ci.yml

script:
  - "curl -X POST -F token=TOKEN -F ref=REF_NAME http://gitlab.example.com/api/v4/projects/370/trigger/pipeline"

//添加变量
curl -X POST \
     -F token=TOKEN \
     -F "ref=REF_NAME" \
     -F "variables[RUN_NIGHTLY_BUILD]=true" \
     http://gitlab.example.com/api/v4/projects/370/trigger/pipeline

Use webhook

http://gitlab.example.com/api/v4/projects/370/ref/REF_NAME/trigger/pipeline?token=TOKEN

http://gitlab.example.com/api/v4/projects/370/ref/dev-mguo/trigger/pipeline?token=TOKEN

//添加变量
http://gitlab.example.com/api/v4/projects/370/ref/REF_NAME/trigger/pipeline?token=TOKEN&variables[RUN_NIGHTLY_BUILD]=true

子模块策略Git submodule strategy

• GIT_SUBMODULE_STRATEGY 类似于 GIT_STRATEGY ，当你的项目需要包含别的项目代码时，可以将别的项目作为你的项目的子模块，这个时候就可以使用 GIT_SUBMODULE_STRATEGY 。
• GIT_SUBMODULE_STRATEGY 默认取值 none ，即拉取代码时，子模块不会被引入。
• GIT_SUBMODULE_STRATEGY 可取值 normal ，意味着在只有顶级子模块会被引入。
• GIT_SUBMODULE_STRATEGY 可取值 recursive ，递归的意思，意味着所有级子模块会被引入。

子模块需要配置在 .gitmodules 配置文件中，下面是两个示例：

场景：

• 你的项目地址： https://gitlab.com/secret-group/my-project ，你可以使用 git clone git@gitlab.com:secret-group/my-project.git 检出代码。
• 你的项目依赖 https://gitlab.com/group/project ，你可以将这个模块作为项目的子模块。

子模块与本项目在同一个服务上，可以使用相对引用：

子模块与本项目不在同一个服务上，使用相对绝对URL：

详细可参考 Using Git submodules with GitLab CI

Release功能

参考链接：Releases API | GitLab

[gitlab] release功能

//Create a release POST /projects/:id/releases curl --header 'Content-Type: application/json' --header "PRIVATE-TOKEN: <your_access_token>"
--data '{ "name": "New release", "tag_name": "v0.3", "description": "Super nice release", "milestones": ["v1.0", "v1.0-rc"], "assets": { "links": [{ "name": "hoge", "url": "[https://google.com](https://google.com)", "filepath": "/binaries/linux-amd64", "link_type":"other" }] } }'
--request POST "[https://gitlab.example.com/api/v4/projects/24/releases](https://gitlab.example.com/api/v4/projects/24/releases)"

//简单命令 curl --header 'Content-Type: application/json' --header "PRIVATE-TOKEN: XXXXXXXXXXXXX" --data '{ "name": "'release名称'", "tag_name": "'标签名'", "ref":"'标签名'" ,"description": "'描述信息'" }' --request POST [http://ip地址/api/v4/projects/工程id/releases](http://ip%E5%9C%B0%E5%9D%80/api/v4/projects/%E5%B7%A5%E7%A8%8Bid/releases)

//PRIVATE-TOKEN //projectId curl --header 'Content-Type: application/json' --header "PRIVATE-TOKEN: XXXXXXXXXXX" --data '{ "name": "'release名称'", "tag_name": "'标签名'", "ref":"'标签名'" ,"description": "'描述信息'" }' --request POST [http://gitlab.example.com/api/v4/projects/工程id/releases](http://gitlab.example.com/api/v4/projects/%E5%B7%A5%E7%A8%8Bid/releases)

PRIVATE-TOKEN

获取方式 ,参考TOKEN

2022-06-30-14-07-20-image.png

projectId

每个gitlab中的项目都有一个唯一识别号，我们称之为project id

2022-06-30-14-08-21-image.png

Tag

中文翻译为标签。某些程度上面，tag和release你都可以认为是快照的概念。
release基于tag，因此需要先打标签：

[图片上传失败...(image-401706-1661138216072)]

如果没有其他操作，生成release就是把某个版本牵出来，里面都是该版本的源码，将会生成4种文件: zip, tar.gz, tar.bz2 和 tar

问题汇总

1.python

node镜像版本问题 image: node:15.16.1

2022-06-24-16-01-39-image.png

2.npm

需要安装node镜像 image: node:15.16.1

2022-06-24-16-03-18-image.png

gitlab-runner的无权限问题 - 芭菲雨 - 博客园

ps aux|grep gitlab-runner  #查看当前runner用户

sudo gitlab-runner uninstall  #删除gitlab-runner

gitlab-runner install --working-directory /home/gitlab-runner --user root   #安装并设置--user(例如我想设置为root)

sudo service gitlab-runner restart  #重启gitlab-runner

ps aux|grep gitlab-runner #再次执行会发现--user的用户名已经更换成root了

3. fatal: could not read Username for 'https://gitserver.com/ ': No such device or address

   修改成相对路径解决问题（不知道为啥绝对路径会出问题）

   解决方案：Gitlab CI 拉取 submodules

4. 使用yarn报错

   尝试删除 yarn.lock
   尽量使用同一个源

   yarn config set strict-ssl false

   yarn config set registry https://registry.npmjs.org

   链接：

5.docker容器时间戳使用与本地不同问题

docker cp /etc/localtime <container_id>:/etc/

前端项目 CI/CD 最佳业务配置思路

一个好的 CI/CD 流程，应该包含以下几点

• 权限可控
• 缓存使用得当
• 分支作用明确
• 根据 tag 创建稳定的 release
• 极狐GitLab Runner 可伸缩
• 流水线异常多渠道通知
• 支持多个微服务一键同步部署
• 隐秘信息使用声明变量
• 使用镜像时要配置 .dockerignore

权限可控是指发布正式环境，或者预发布环境只有指定的人才能发布，合并代码必须要经过 CI 验证后才能合并。

缓存使用得当，可以加快流水线的构建，也使的发布流程更加顺畅，缓存可以使用第三方的，也可以用本地，另外需要指定缓存的删除策略，不然一直增加缓存机器会爆掉的。缓存可以使用单个文件的 hash 值来缓存，也可以直接缓存一个目录，分支作用明确之后才能规划分支的发布流程，有些分支只能发布开发环境，有些分支只能发布 test 环境，而且只有一个分支才能发布正式环境。

一个版本发布后需要给代码的打一个 tag，标注增加了那些功能，修复了那些问题，做了那些优化，然后发布一个 release。这部分也可以使用 CI/CD 自动构建，流水线异常多渠道通知是指，发布或构建过程中出错了，要能及时让人及时感知，快速解决问题，一个流水线构建有的需要 10 分钟，不可能每次都要一直等在哪里，所有可以接入钉钉通知、邮件通知，或接入第三方应用通知。

微服务的流行使 CI/CD 迎来了更大的挑战，目前 极狐GitLab 已经支持了多流水线构建，方便一次版本同时发布多个应用，避免有的应用丢失。使用.dockerignore 将不需要的文件在构建镜像时忽略，以加快构建速度。

预定义变量

There are also Kubernetes-specific deployment variables.

学习链接

实战：从 0 到 1 极狐GitLab CI/CD 前端持续部署_拿我格子衫来的博客-CSDN博客

在CI/CD中演示前端三种部署方案，镜像部署，服务器部署，OSS部署_拿我格子衫来的博客-CSDN博客

🛫 前端自动化部署：借助Gitlab CI/CD实现 - 掘金

Docker安装Gitlab和Runner并实现CICD_包含如何创建自己的docker

gitlab CI流水线配置文件.gitlab-ci.yml详解

GitLab如何使CI/CD仅限指定用户使用_sandaawa的博客-CSDN博客

Release命令测试

文档链接：Releases API | GitLab

release ci

release:
  stage: release
  only:
    - master
    # - /^dev$/
    # - dev-mguo
  tags:
    - docker
  retry: 2
  script:
    - echo '快照备份'
    - echo $TIMESTAMP
    - 'curl -H "Content-Type: application/json" -H "PRIVATE-TOKEN: $RELEASE_TOKEN" -d ''{ "name": "''$TIMESTAMP''", "tag_name": "''$TIMESTAMP''", "ref": "''$CI_COMMIT_SHA''", "description": "''$TIMESTAMP-$CI_COMMIT_SHA''"}'' --request POST $PROJECT_RELEASE_URL'
  when: manual

创建release

curl -H "Content-Type: application/json" -H "PRIVATE-TOKEN: your token" -d '{ "name": "v2.1.8-alpha1-1656989338", "tag_name": "v2.1.8-alpha1-1656989338", "ref":"4b8756a1f27e3a8b0608ebe3a9ecde1255b6ba54" ,"description": "测试release"}' --request POST http://gitlab.com/api/v4/projects/projectId/releases

删除release

curl --request DELETE --header "PRIVATE-TOKEN: your token" "http://gitlab.com/api/v4/projects/projectId/releases/:tag_name"