持续集成和持续部署（CI/CD）管道已成为现代软件开发的重要组成部分，使开发人员能够快速高效地构建、测试和部署代码更改。通过自动执行构建和部署应用的流程，CI/CD 管道可以帮助团队提高代码质量，减少错误，并缩短新功能和应用的上市时间。
GitLab Runner 是在 GitLab.com 和自托管 GitLab 实例上处理 CI/CD 作业的应用。GitLab.com 提供自己的托管运行程序，供网站用户共享，但您也可以通过几种不同的安装类型为项目设置专用的私有运行程序。对于喜欢在云端管理自己的管道基础架构的企业或个人，GitLab Runner Operator 作为 OpenShift 中的红帽认证 Operator，可提供轻松快捷的 GitLab Runner 云原生安装体验。
为了展示 GitLab Runner Operator 的简易性和功能性，我想同时介绍 Fedora Linux 中一些令人兴奋的进展，并使用 GitLab Runner Operator 为 Fedora Silverblue 构建自定义基础镜像，这将会非常有趣。
Fedora Silverblue 是 Fedora Linux 的一个非常先进的不可变发行版。最近，其混合镜像和软件包管理系统 rpm-ostree 实现了从 OCI 容器启动的功能。这样，用户或企业就可以使用熟悉的 Dockerfiles 和 Containerfiles 工作流构建自己的自定义基础镜像。
在以下教程中，我们将使用 GitLab Runner Operator 为 Fedora Silverblue 镜像设置一个全自动构建系统。
前提条件
您将需要一些之前配置和安装的资源，本教程中不作介绍：
- OpenShift 集群
- 现有的 Fedora Silverblue 安装（如果您想实际使用自定义镜像）
- GitLab.com 帐户
安装和配置 GitLab Runner Operator
在 OpenShift 集群侧栏中打开“Operator”标题，然后单击 OperatorHub。搜索 GitLab Runner Operator，然后单击“认证”选项（也提供该 Operator 的社区版本，但本教程将坚持使用 OpenShift 上的认证版本）。在单击 安装之前，请注意 Operator 说明中的“前提条件”部分。GitLab Runner Operator 要求首先安装 cert-manager：
oc apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.yaml
执行此操作后，单击 安装 以安装 GitLab Runner Operator。
在下一屏幕中，系统将提示您更改任何默认安装选项。如果您需要或想要将范围限制到特定的命名空间，请立即执行此操作，否则请继续使用默认选项。此外，建议将 更新批准 设置为 自动 ，因为这是使用 Operator 的一个关键优势。
稍等片刻以完成安装，然后导航到 已安装的 Operator 和“GitLab Runner Operator”。在这里，您将看到与之前相同的信息文本，并且 提供的 API 下有一个链接，您可以在其中创 建一个运行程序实例。下面的信息文本中提供了将运行程序链接到 GitLab 存储库的说明，我们现在将按照说明进行操作。
创建并注册运行程序实例
1.创建注册令牌密钥
首先，我们必须创建一个带有 GitLab 注册令牌的密钥，我们的新运行程序将使用它来注册到存储库。打开 GitLab.com 或您的私有 GitLab 实例，然后打开要注册的存储库。依次导航到“设置”和“CI/CD”。展开标题为 运行程序 的部分，然后查看 项目运行程序部分。在这里，我们可以找到注册令牌，以及您将用于注册运行程序实例的 URL。
如果您使用的是 GitLab.com，另请注意 共享的运行程序 部分。这些是 GitLab.com 提供的公共运行程序。禁用此项目的共享运行程序，因为我们将使用自己的私有运行程序。
创建您的密钥，将存储库的注册令牌插入到 runner-registration-token 字段。您可以在 Web 控制台中或通过终端界面执行此操作。我创建了一个名为 gitlab-runner-secret.yml 的文件，然后将它添加到我的集群：
apiVersion: v1
kind: Secret
metadata:
name: gitlab-runner-secret
type: Opaque
stringData:
runner-registration-token: YOUR_TOKEN_HERE
oc apply -f gitlab-runner-secret.yml
2.使用 ConfigMap 配置运行程序
在创建运行程序之前，我们还需要创建一个包含一些自定义选项的 ConfigMap。GitLab Runner 通常可以使用 config.toml 文件进行配置。在 Kubernetes 上下文中，我们可以使用包含 config.toml 文件的 ConfigMap 来添加这些 自定义设置 。
由于我们是在 OpenShift 集群环境中运行构建容器，我们需要确保构建容器在没有升级特权的情况下 以非 root 用户 身份运行（注：如果您确实需要具有特权的构建环境， 有多种方法 可以绕过这个限制，但我们将坚持使用非 root 设置）。下面是一个简单的 config.toml ，它指定运行程序容器集为以非 root 用户 1000 的身份运行：
[[runners]]
name = "gitlab-runner"
url = "https://gitlab.com"
executor = "kubernetes"
[runners.kubernetes]
[runners.kubernetes.pod_security_context]
run_as_non_root = true
run_as_user = 1000
将此作为 ConfigMap 添加到我们的集群：
oc create configmap my-runner-config --from-file=config.toml
3.启动运行程序实例
现在，我们可以创建实际的运行程序实例。同样，您可以使用 Web 控制台执行此操作，方法是单击 GitLab Runner Operator 页面上的 创建实例 ，也可以通过终端来创建。无论采用哪种方式，我们都要确保自定义资源定义包含正确的 GitLab URL、注册令牌密钥的名称和 ConfigMap 的名称，并且标签中包含“openshift”（最后一项“openshift”标签是作业传递到集群所必需的）。以下是一个名为 gitlab-runner.yml 的基本 CRD，它符合我们的所有条件：
apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
name: gitlab-runner
spec:
gitlabUrl: https://gitlab.com
token: gitlab-runner-secret
tags: openshift
config: my-runner-config
安装到我们的集群：
oc apply -f gitlab-runner.yml
现在，您可以在 Web 控制台中或通过终端使用 oc get runners来检查新运行程序的状态。我们还应该签入 GitLab 项目的 CI/CD 设置，以确保运行程序正确链接到我们的存储库。您现在应该会在标题 已分配的项目运行程序 下看到一个运行程序，其名称与我们创建和安装的 CRD 相同。
使用我们的运行程序构建 Silverblue 镜像
1.定义 GitLab CI/CD 管道作业
现在，我们的运行程序已经安装、配置并链接到项目，我们可以编写 GitLab CI 文件来定义镜像构建了。GitLab 针对不同类型的项目，提供了许多 gitlab-ci.yml 文件结构 示例 。我们将自行编写，利用 buildah 构建 Silverblue 镜像。
我们将使用的 gitlab-ci.yml 如下所示：
stages:
- build
buildah-build:
stage: build
tags:
- openshift
image: quay.io/buildah/stable
variables:
STORAGE_DRIVER: vfs
script:
- export HOME=/tmp
- buildah login --username "$CI_REGISTRY_USER" --password "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
- buildah build -t "$CI_REGISTRY_IMAGE:latest" .
- buildah push "$CI_REGISTRY_IMAGE:latest"
- buildah logout "$CI_REGISTRY"
此文件中有几个重要元素需要注意。
- 如前文所述，我们至少需要包含
openshift标签，以便让 GitLab Runner Operator 接管我们的作业。 - 我们使用 Quay.io 中托管的官方稳定版 Buildah 镜像作为构建镜像。
- 由于 overlay-on-overlay 文件系统存在 问题 ，我们将存储驱动程序设置为
vfs。使用vfs是目前最简单的解决方案。 - 我们将
$HOME更改为/tmp，以确保能够写入，因为 OpenShift 中的大多数容器文件系统都是只读的。
最后一部分 script列出了我们的构建作业将运行的命令。在这里，我们利用 GitLab CI 的 预定义变量 登录 GitLab 容器镜像仓库，构建并标记镜像，最后将镜像推送到镜像仓库，然后再注销。
2.为自定义Silverblue 镜像编写 Containerfile
将 gitlab-ci.yml 添加到存储库后，我们还需要添加要构建的 Containerfile 。对于我们的自定义 Fedora Silverblue 镜像，我依赖于 Universal Blue 社区所做的出色工作。他们一直在为不同的用例开发各种版本的 Silverblue；如果您或您的团队有兴趣为 Fedora Silverblue 系统创建自定义的不可变基础镜像，这也是一个很好的资源。
我认为创建一个包含我日常使用的所有 OpenShift 和 Operator 工具的最新版本的基础镜像会有所帮助。由于我们将其设置为每日构建，这样不仅我的基础镜像会更新到最新的 Fedora 软件包，而且我也不会错过那些通常需要手动更新的 OpenShift 和 Operator 工具的最新版本。
ARG FEDORA_MAJOR_VERSION=38
FROM quay.io/fedora-ostree-desktops/silverblue:${FEDORA_MAJOR_VERSION}
# Starting with Fedora 39, the new official location for these images is quay.io/fedora/fedora-silverblue
# See https://pagure.io/releng/issue/11047 for more information
# Install Openshift tools -- oc, opm, kubectl, operator-sdk, odo, helm, crc from official OpenShift sources
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/latest/opm-linux.tar.gz | tar xvzf - -C /usr/bin
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/operator-sdk/latest/operator-sdk-linux-x86_64.tar.gz | tar xvzf - --strip-components 2 -C /usr/bin
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/linux/oc.tar.gz | tar xvzf - -C /usr/bin
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/helm/latest/helm-linux-amd64 -o /usr/bin/helm && chmod +x /usr/bin/helm
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/odo/latest/odo-linux-amd64 -o /usr/bin/odo && chmod +x /usr/bin/odo
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/crc/latest/crc-linux-amd64.tar.xz | tar xfJ - --strip-components 1 -C /usr/bin
# Install awscli
RUN curl -SL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip && unzip awscliv2.zip && ./aws/install --bin-dir /usr/bin --install-dir /usr/bin
# Install overrides and additions, remove lingering files
RUN rpm-ostree install podman-docker
RUN rm -rf aws && \
rm -f awscliv2.zip && \
rm -f /usr/bin/README.md && \
rm -f /usr/bin/LICENSE
下面简要介绍一下此 Containerfile 中发生的情况：
- 首先，我们指定要构建的 Fedora 版本，本例中为当前的稳定版本 38
- 接下来，我们指定要用于构建的基础镜像，即
FEDORA_MAJOR_VERSION替换后的silverblue:38（请参阅 Containerfile 中有关这些镜像位置的注释） - 在最大的部分中，我们运行几个
curl命令来下载要安装的所有 OpenShift 程序，并确保将其二进制文件放入/usr/bin目录中 - 我们还要安装
awscli，这涉及解压缩.zip文件并运行安装脚本 - 最后，我们使用
rpm-ostree从 Fedora 软件包存储库安装podman-docker（这实际上是将所有docker命令别名为podman，方便我们这些习惯于使用docker的用户），然后删除awscli解压过程中的一些残留文件
正如我之前提到的，如需更多 Silverblue 自定义灵感，请访问 Universal Blue社区。在学习这一工作流的过程中，我在很大程度上依赖于他们的工作，他们已经在 Silverblue 中开发了许多令人兴奋的可引导 OCI 功能的新应用。
3.使用和监控管道作业
我们应该将此 Containerfile 或您希望构建的任何 Containerfile 或 Dockerfile 添加到项目存储库的根目录中，因为 gitlab-ci.yml 指定 buildah 使用当前工作目录作为 Containerfile 参数。根据您在此存储库中提交所有更改的方式，您可能已收到有关管道作业失败的通知，或者如果您一次性提交所有更改，将看到第一次尝试运行构建作业的过程现在开始。您可以查看构建日志，方法是导航到 GitLab.com 项目页面上的 CI/CD 标题，单击 管道 或 作业 ，然后按步骤单击，直至看到名为 buildah-build的作业的日志输出。
如果我们正确设置了所有内容，应该会看到日志描述了我们所编写的 gitlab-ci.yml 和 Containerfile 的每一步，并在完成时显示“作业成功”。如果我们的作业成功，那么我们还应该能够在项目注册表中看到完成的容器。在左侧导航栏中，单击 软件包和镜像仓库 ，然后单击 容器镜像仓库。您应该会看到一个以您的项目命名的镜像，带有一个标签“最新”。此镜像将位于 registry.gitlab.com/{YOUR_USERNAME}/{YOUR_REPOSITORY_NAME}中。
我们编写的作业将在每次提交到 main 分支时运行，但您可以在 gitlab-ci.yml 文件中自定义此行为。如果要安排定期构建，可以在存储库页面上 CI/CD 设置中的 计划 部分下执行此操作。单击 新建计划 ，以配置管道的时间和频率。有关 GitLab.com 管道调度的更多信息，请单击 此处。对于自定义 Silverblue 镜像，您需要至少每天构建一次，以与官方镜像的构建频率相一致。
使用我们的自定义镜像
要实际将此镜像用作Silverblue 的可引导基础，您首先需要从 官方镜像 安装 Fedora Silverblue（如果您还没有安装）。完成安装并登录后，我们可以将安装变基到自定义镜像。
请记住， 从 OCI 镜像启动仍然是一项实验性功能，因此，如果您要在个人或生产计算机上使用此功能，请自行判断并慎重使用。不过，Silverblue 的设计可以抵御破坏，因此如果您的自定义镜像无法按预期工作，您应该能够回滚到原始的基础镜像。为确保不会删除原始基础，我们可以运行 sudo ostree admin pin 0 来固定当前镜像。这可确保不会在后续更新中丢失引用，因为 Silverblue 通常仅保留当前和以前的镜像引用。要实际变基到我们的自定义镜像，我们可以运行：
rpm-ostree rebase ostree-unverified-registry:registry.gitlab.com/{YOUR_USERNAME}/{YOUR_REPOSITORY_NAME}:latest 然后重新启动。
重启后，我们可以通过查看 rpm-ostree status 的输出来验证我们正在运行自定义镜像。您当前的部署（由左侧的圆圈/点标识）应显示自定义镜像的 ostree-unverified-registry URI。您也可以尝试在终端运行我们添加的任何 OpenShift 工具，如 oc、 operator-sdk 或 helm。
您还应该会在 rpm-ostree status 的输出中看到我们的固定部署以及旧的基础引用。如果要回滚，只需运行 rpm-ostree rollback 并重新启动。有关 Fedora Silverblue 管理的更多信息，请参阅 文档
成果
假设一切顺利，我们现在就有了一个在自己的 OpenShift 集群上运行的自托管 CI/CD 管道，它会定期创建新的自定义Silverblue 镜像。我们的运行程序应该不需要人工干预，除非我们希望重新配置构建作业标签或创建更多运行程序来处理更多并发作业。构建将按照我们设定的时间间隔开始，并在我们向 main 分支提交新代码时触发；如果我们在 Silverblue 安装上运行自定义镜像，则只需运行 rpm-ostree update 即可获取每日更新。
本教程示例简单说明了 GitLab Runner Operator 和 GitLab CI/CD 系统的功能。两者都能够管理更复杂的 CI/CD 需求，而且通过在 OpenShift 上运行经认证的 GitLab Runner Operator，您可以省去运行程序本身的大部分手动设置和维护工作，从而节省时间和精力以了解构建的实际内容和配置。
我已在 此处创建了一个参考存储库，其中包含本教程中使用的所有文本文件。另请参阅下方实用参考资料列表。
