核心成分：
- gitlab-ci.yaml 定义部署的 jobs（操控 runner）
- gitlab runner 负责运行 jobs（注册 / 启动容器）
- pipeline：执行 gitlab-ci，将 jobs 分配给 runner（不用管）
- vault 存储环境变量（lets 拉取）
gitlab-runner：
不算特别了解
存在多种形式，可以是 docker 容器、k8s pod 或者整个 node。
runner 本身也可以定义 executor，如 docker 或 shell。如果是 docker，可以在 gitlab-ci 定义用哪个镜像。
HSD 在部署阶段在 20E 用 docker + shell executor 注册 runner，大致流程如下：
1). 从 gitlab 设置页面注册新的 runner，指定 tag 并记录 token
2). 用 token 设置 config 文件
3). docker run 运行 runner 镜像，并用 config 文件配置
gitlab-ci：
-
可以定义 stages 和 jobs。通常而言，按照 stages 的顺序执行，每个 stages 的所有 jobs 完成后再执行下一个。
-
jobs 需要设置的地方有 script、tag 和 image：
script 描述每个 job 执行的脚本
tag 指定分配给哪个 runner 执行
image 在 executor 是 docker / k8s 容器的情况下指定镜像 -
build job：
用了gcr.io/kaniko-project/executor的镜像。kaniko 专门用来编译镜像。编译完成后推送到 gitlab（在--destination定义推送的库）
在推送时，设置CI_COMMIT_SHORT_SHA为镜像版本 -
deploy job：
用 lets 拉取 vault 的变量，生成一长串代码 cmd，然后通过 ssh 在 20E 执行代码。
cmd 内容：用export赋值环境变量后执行docker pull。 -
环境变量：
CI_REGISTRY：gitlab 拉取镜像的 url。虽然 registry 和 repo 中文都算库，但 registry 包含多个 repo
CI_REGISTRY_IMAGE：默认的镜像注册 url，等于$CI_REGISTRY/$CI_PROJECT_PATH
CI_PROJECT_PATH：repo 的路径
CI_PROJECT_DIR：项目根目录在放 runner 的地址，用来获取文件
CI_COMMIT_TAG，CI_COMMIT_SHA，CI_COMMIT_SHORT_SHA：git commit 的编号。CI_COMMIT_SHORT_SHA是常用的8字符编码。
CI_REGISTRY_USER，CI_REGISTRY_PASSWORD：每个 job 自动生成的账户，用于推送 / 拉取 gitlab 仓库的镜像。
