GitLab Runner作为CI/CD

参考：gitlab ci cd 不完全指南_gitlab cicd-CSDN博客

GitLab Runner作为CI/CD 配合GitLab使用以在管道中运行作业的应用程序。GitLab Runner由Golang语言开发轻量而高效，本身只提供客户端任务执行，不提供任何图形界面，其管理界面可以只在GitLab界面集成（可过滤了大量危险脚本操作），从而极大保障了业务平台的安全性。

什么是 CI、CD

CI（Continuous Integration）持续集成，CD（Continuous Deployment）持续部署（也包含了持续交付的意思）。

 CD 指的是在我们 CI 流程通过之后，将代码自动发布到服务器的过程，这个过程也是自动化的。

在开发人员提交代码之后，会触发 gitlab 的 CI 流水线。也就是上图的 CI PIPELINE，也就是中间的部分。
在 CI 流水线中，我们可以配置多个任务。比如上图的 build、unit test、integration tests 等，也就是构建、单元测试、集成测试等。
在 CI 流水线都通过之后，会触发 CD 流水线。也就是上图的 CD PIPELINE，也就是右边的部分。
在 CD 流水线中，我们可以配置多个任务。比如上图的 staging、production 等，也就是部署到测试环境、部署到生产环境等。

 gitlab CI、CD 中的一些基本概念：

pipeline：流水线，也就是 CI、CD 的整个流程，包含了多个 stage，每个 stage 又包含了多个 job。
stage: 一个阶段，一个阶段中可以包含多个任务（job），这些任务会并行执行，但是下一个 stage 的 job 只有在上一个 stage 的 job 执行通过之后才会执行。
job：一个任务，这是 CI、CD 中最基本的概念，也是最小的执行单元。一个 stage 中可以包含多个 job，同时这些 job 会并行执行。
runner：执行器，也就是执行 job 的机器，runner 跟 gitlab 是分离的，runner 需要我们自己去安装，然后注册到 gitlab 上（不需要跟 gitlab
在同一个服务器上，这样有个好处就是可以很方便实现多个机器来同时处理 gitlab 的 CI、CD 的任务）。
tag: runner 和 job 都需要指定标签，job 可以指定一个或多个标签（必须指定，否则 job 不会被执行），这样 job 就只会在指定标签的 runner 上执行。
cache: 缓存，可以缓存一些文件，这样下次流水线执行的时候就不需要重新下载了，可以提高执行效率。
artifacts: 这代表这构建过程中所产生的一些文件，比如打包好的文件，这些文件可以在下一个 stage 中使用，也可以在 pipeline 执行结束之后下载下来。
variables：变量，可以在 pipeline 中定义一些变量，这些变量可以在 pipeline 的所有 stage 和 job 中使用。
services：服务，可以在 pipeline 中启动一些服务，比如 mysql、redis 等，这样我们就可以在 pipeline 中使用这些服务了（常常用在测试的时候模拟一个服务）。
script: 脚本，可以在 job 中定义一些脚本，这些脚本会在 job 执行的时候执行。

cache 在安装依赖的 job 中才需要使用默认的 policy，也就是 pull-push，在其他不需要安装依赖的 job 中使用 pull 就可以了，不需要上传缓存。
cache 的 key 可以指定多个文件，这样在指定的文件变动的时候，缓存会失效，这往往用在依赖相关的文件中。
可以使用 services 关键字来指定需要启动的服务，比如 mysql、redis 等，在 job 中可以连接到这些 services，从而方便进行测试。
可以使用 yaml 的 anchor 机制来复用一些配置片段，可以少写很多重复的配置。
一个 job 必须运行在某个 runner 上，job 和 runner 的关联是通过 tag 来指定的。

需要特别注意的是：cache 是跨流水线共享的，而 artifacts 只会在当前流水线的后续 stage 共享。

gitlab runner 和 executor

gitlab runner 在 CI/CD 中是一个非常重要的东西，因为我们写的 CI/CD 的配置就是在 runner 上运行的，如果我们想要执行 CI/CD 任务，我们必须先安装配置 gitlab-runner。

其中 runner 是一台执行 CI/CD 脚本的机器（也就是安装了 gitlab-runner 的机器）。这个机器可以部署在 gitlab 服务器以外的任意一台电脑上，当然也可以跟 gitlab 在同一台服务器。

而每一个 runner 会对应一种特定的 executor，executor 就是我们执行 CI/CD 里面 script 的环境。比如如果我们指定了 executor 类型为 docker，那么我们 CI/CD 脚本里面的 script 将会在一个独立的 docker 容器中执行。

runner是执行 CI/CD 脚本的机器，这个机器上有不同类型的 executor，一个 executor 代表着一个不同类型的命令行终端，最常见的是 shell、docker，当然也支持 widnows 的 powershell。

gitlab 是通过 tags 来找到运行脚本的 runner 的，如果 job 的 tags 跟 runner 的 tags 匹配了，就可以将那个 job 放到 runner 上处理。

我们在两台机器上安装了 gitlab-runner，它们的 IP 是 192.168.2.123 和 192.168.2.234。
test-job 的 tags 中包含了 api 这个 tag，而 runner1 的 tags 也包含了 api 这个 tag，因此 test-job 会被 runner1 执行。
同理，npm-install 这个 job 会被 runner3 处理。

cache 是用来缓存依赖的，比如 node_modules 文件夹，它可以加快后续 pipeline 的执行流程，因为避免了重复的依赖安装。
artifacts 是用来缓存构建产物的，比如 build 之后生成的静态文件，它可以在后续的 stage 中使用。表示的是单个 pipeline 中的不同 stage 之间的共享。

CD - 如何同步代码到服务器
如果我们的项目需要部署到服务器上，那么我们还需要做一些额外的操作，比如同步代码到服务器上。
如果我们的 gitlab 是通过容器执行的（也就是说 gitlab 是通过 docker 启动的），或者我们的 runner 的 executor 是 docker，那么有一种比较常见的方法是通过 ssh 私钥来进行部署。

-------------------------------------------------------------------------------------------------------------------------

参考：github - Gitlab CI/CD - 个人文章 - SegmentFault 思否

• ci(持续构建)
  代码提交后触发自动化的单元测试，代码预编译，构建镜像，上传镜像等．
• cd(持续发布)
  持续发布则指将构建好的程序发布到各种环境，如预发布环境，正式环境．

gitlab ci/cd是由独立的runner程序完成，runner采用go语言编写，因此可以很好的进行跨平台，通常可以将runner部署到任何gitlab server之外的服务器，从而避免对gitlab server的影响．

gitlab ci/cd流程

gitlab通过在项目的根目录放置.gitlab-ci.yml文件来触发pipline，文件书写遵循yml语法，因此，概括来说gitlab ci/cd只需要两步，

• 写好.gitlab-ci.yml文件，并放置到项目根目录
• 配置好gitlab runner．

完成后，提交代码时会自动根据gitlab-ci.yml的触发条件进行执行相应的stage.

4.1 gitlab-ci.yml文件

# 定义项目的执行阶段
stages:
  # 测试阶段
  - test
  # 构建阶段
  - build
  # 部署阶段
  - deploy

# 测试作业
test:
  # 设置作业所在的阶段
  stage: test
  # 执行的脚本命令
  script: echo "Running tests"
  # 只对带标签的提交执行此作业
  only:
  - tags

# 构建作业
build:
  # 设置作业所在的阶段
  stage: build
  # 执行的脚本命令
  script: echo "Building the app"
  # 只对带标签的提交执行此作业
  only:
  - tags

# 部署到测试环境的作业
deploy_staging:
  # 设置作业所在的阶段
  stage: deploy
  # 执行的脚本命令
  script:
    - echo "Deploy to staging server"
  # 设置部署环境的名称和URL
  environment:
    name: staging
    url: https://staging.example.com
  # 只对带标签的提交执行此作业
  only:
  - tags

# 部署到生产环境的作业
deploy_prod:
  # 设置作业所在的阶段
  stage: deploy
  # 执行的脚本命令
  script:
    - echo "Deploy to production server"
  # 设置部署环境的名称和URL
  environment:
    name: production
    url: https://example.com
  # 设置为手动触发
  when: manual
  # 只对带标签的提交执行此作业
  only:
  - tags