尧图网站建设 
Loki Operator 镜像构建与推送策略全解析从 Dockerfile 到 CI/CD 工作流【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki本文围绕 Grafana Loki Operator 的镜像构建与推送机制展开系统讲解 operator 镜像loki-operator、OpenShift 捆绑包镜像loki-operator-bundle以及存储容量计算工具镜像storage-size-calculator在 DockerHub 与 Quay.io 两大注册中心的构建、打标签与发布策略。读者阅读后可完整掌握 Loki Operator 的持续集成镜像流水线、release-please 驱动的版本化发布流程、多平台amd64/arm64/arm交叉构建原理以及如何在本地复现这些镜像的构建过程。镜像构建与推送总览Loki Operator 仓库采用「一套构建逻辑、多注册中心分发」的策略所有镜像构建逻辑收敛到复用的构建工作流中再由各 CI 工作流按场景日常开发 vs 正式发布调用。整个体系由三部分组成持续集成构建latest 标签推送main分支仅operator/**路径变更或手动触发时构建并推送所有 operator 相关镜像标签为latest正式发布构建版本号标签release-please 创建新 Release 时构建并推送带语义化版本号{major}.{minor}.{patch}的镜像复用构建工作流集中处理多平台构建linux/amd64、linux/arm64、linux/arm与基于注册中心的认证逻辑供其他工作流workflow_call调用。对应的工作流文件与镜像 Dockerfile 均位于仓库根目录可对照查阅operator-images.yaml、operator-release-please.yml、operator-reusable-image-build.yml以及 operator/Dockerfile、operator/calculator.Dockerfile、operator/bundle/openshift/bundle.Dockerfile。构建与推送策略DockerHubdocker.io官方文档声明loki-operator镜像同时面向 DockerHub 分发。在仓库的实际工作流中DockerHub 的推送经由 Google Artifact Registryus-docker.pkg.dev下的grafanalabs-global/dockerhub-loki-prod-mirror仓库完成即先将镜像推送到 GAR 的镜像仓库再同步/镜像至 DockerHub 命名空间镜像触发时机组织标签工作流文件loki-operator推送 main 分支grafana经grafanalabs-global/dockerhub-loki-prod-mirror中转latestoperator-images.yamlloki-operator创建 Release同上{major}.{minor}.{patch}operator-release-please.ymlQuay.ioQuay.io 是 OpenShift 生态的分发主阵地面向openshift-logging组织推送三款镜像其中 operator 主镜像与 bundle 捆绑包镜像配合可被 OpenShift OperatorHub / OLM 直接消费镜像触发时机组织标签工作流文件loki-operator推送 main 分支openshift-logginglatestoperator-images.yamlloki-operator-bundle推送 main 分支openshift-logginglatestoperator-images.yamlstorage-size-calculator推送 main 分支openshift-logginglatestoperator-images.yaml值得注意的是实际工作流在 Quay.io 侧还额外发布了第 4 个镜像passthrough-gateway基于 operator/passthrough-gateway.Dockerfile对应 operator/cmd/passthrough-gateway 入口用于 OpenShift 上的多租户网关场景属于对文档表格的运行时扩展。工作流文件逐层拆解operator-images.yaml持续集成构建operator-images.yaml 是 daily CI 的入口触发条件为push到main分支且变更路径命中operator/**即只有 operator 相关代码变动才触发镜像构建避免无关提交浪费构建资源workflow_dispatch手动触发便于运维人员随时重新构建。该工作流在同一文件内声明了 5 个并行 job全部通过uses: ./.github/workflows/operator-reusable-image-build.yml复用统一构建逻辑仅通过with传入不同的构建参数JobDockerfileRegistry组织/仓库镜像名标签publish-grafana-operatoroperator/Dockerfileus-docker.pkg.devgrafanalabs-global/dockerhub-loki-prod-mirrorloki-operatorlatestpublish-openshift-operatoroperator/Dockerfilequay.ioopenshift-loggingloki-operatorlatestpublish-openshift-bundleoperator/bundle/openshift/bundle.Dockerfilequay.ioopenshift-loggingloki-operator-bundlelatestpublish-openshift-size-calculatoroperator/calculator.Dockerfilequay.ioopenshift-loggingstorage-size-calculatorlatestpublish-openshift-passthrough-gatewayoperator/passthrough-gateway.Dockerfilequay.ioopenshift-loggingpassthrough-gatewaylatest每个 job 都显式声明id-token: write权限这是 OIDC 无密钥认证Workload Identity Federation的前提——推送到 GAR 时不再依赖静态账号密码。operator-reusable-image-build.yml集中式构建核心operator-reusable-image-build.yml 是整套体系的「心脏」采用workflow_call可复用事件对外暴露 5 个必填输入image_name镜像名称dockerfile构建所用的 Dockerfile 路径tag镜像标签registry目标注册中心us-docker.pkg.dev或quay.ioorganization注册中心下的组织/项目名。其执行步骤完整呈现了现代多平台镜像 CI 的标准姿势checkout 代码使用actions/checkoutv7.0.1拉取仓库并设置persist-credentials: false防止令牌泄漏配置 QEMU通过docker/setup-qemu-action注册模拟器使构建机能够为linux/arm64、linux/arm等非宿主架构执行跨平台编译配置 Buildx通过docker/setup-buildx-action启用 BuildKit 多平台构建能力认证按注册中心分流目标为 GARus-docker.pkg.dev时调用grafana/shared-workflows/actions/login-to-gar完成 OIDC 登录目标为 Quay.io 时先调用get-vault-secrets从 Vault 读取openshift-credentials用户名/密码再通过docker/login-actionv4.6.0带logout: true登录构建并推送调用docker/build-push-actionv7.3.0关键参数如下- name: Build and push uses: docker/build-push-actionv7.3.0 with: # 根据镜像名推断构建上下文 # bundle 镜像使用 operator/bundle/openshift其余使用 operator context: ${{ inputs.image_name loki-operator-bundle operator/bundle/openshift || operator }} file: ${{ inputs.dockerfile }} platforms: linux/amd64,linux/arm64,linux/arm push: true tags: ${{ inputs.registry }}/${{ inputs.organization }}/${{ inputs.image_name }}:${{ inputs.tag }}工作流中的注释特别说明了 context 的推断逻辑采用条件表达式而非直接暴露context输入是为了规避 zizmorGitHub Actions 静态安全扫描工具对「输入可能展开为攻击者可控代码」的高危告警——这是 CI 供应链安全加固的典型实践。operator-release-please.yml版本化发布流水线operator-release-please.yml 定义了正式发布流程触发条件为推送main分支且变更operator/**。其流程分为三个串联阶段releasePlease job使用googleapis/release-please-actionv5.0.0分析 Conventional Commits自动推进版本号并创建 Release。其行为由 operator/release-please-config.json 控制核心配置包括bump-minor-pre-major: true0.x 阶段升 minor 而非 major、include-component-in-tag: true、tag-separator: /形成operator/vX.Y.Z形式的 tag、PR 标题模板chore(operator): Community release ${version}以及changelog-path: CHANGELOG.md。该 job 还会输出operator--release_created、operator--tag_name、operator--major/minor/patch等关键结果供下游消费。认证使用 GitHub Apploki-gh-app生成的临时令牌避免使用机器人账号密码publishImages jobif: ${{ needs.releasePlease.outputs.release_created }}守卫——仅当 release 真正创建后才执行。复用operator-reusable-image-build.yml构建loki-operator但标签不再是latest而是拼接为{major}.{minor}.{patch}的正式版本号推送到us-docker.pkg.dev/grafanalabs-global/dockerhub-loki-prod-mirrorpublishRelease job依赖前两个 job 成功通过gh release edit将 Release 从草稿状态release-please 默认draft: true转为正式发布并标记为非最新--latestfalse确保版本的发布状态与镜像推送结果保持一致。该设计实现了「版本号生成 → 镜像构建推送 → Release 正式发布」的原子化闭环镜像构建失败则 Release 不会转正。镜像清单与 Dockerfile 深入解读loki-operator主 Operator 二进制镜像构建文件为 operator/Dockerfile采用经典的两阶段构建# 阶段一编译 FROM golang:1.26.6sha256:0d1d3a794be25f809dd2cb3160d8c73276c4056a9f8242a138e908ddeee7b6b6 as builder WORKDIR /workspace # 先复制 go.mod/go.sum 与 api 模块缓存依赖层 COPY api/ api/ COPY go.mod go.mod COPY go.sum go.sum RUN go mod download # 再复制源码避免源码变更导致依赖层失效 COPY cmd/loki-operator/main.go cmd/loki-operator/main.go COPY internal/ internal/ RUN CGO_ENABLED0 GOOSlinux GO111MODULEon go build -modreadonly -o manager cmd/loki-operator/main.go # 阶段二精简运行镜像 FROM gcr.io/distroless/static:nonroot WORKDIR / COPY --frombuilder /workspace/manager . USER 65532:65532 ENTRYPOINT [/manager]几个值得注意的工程细节依赖缓存先COPY go.mod go.sum并执行go mod download再复制源码利用 Docker 层缓存避免每次提交都重新下载依赖静态编译CGO_ENABLED0 GOOSlinux产出纯静态二进制可安全运行于不含 glibc 的 distroless 基础镜像最小攻击面最终镜像基于gcr.io/distroless/static:nonroot无 shell、无包管理器并以非 root 用户UID 65532运行入口ENTRYPOINT 直指编译产物/manager对应 operator 主程序入口 operator/cmd/loki-operator/main.go。storage-size-calculator容量计算工具镜像构建文件为 operator/calculator.Dockerfile结构与主镜像完全对称在golang:1.26.6builder 阶段编译 operator/cmd/size-calculator/main.go产物为size-calculator运行阶段同样基于 distroless 并以非 root 运行ENTRYPOINT [/size-calculator]。该工具用于计算 LokiStack 各组件如查询、写入、存储的资源与容量需求与 operator 内的 size-calculator 逻辑呼应。loki-operator-bundleOpenShift OLM 捆绑包镜像构建文件为 operator/bundle/openshift/bundle.Dockerfile它与前两者完全不同——不包含任何二进制而是 OLMOperator Lifecycle Manager规范下的元数据镜像FROM scratch # Core bundle labels. LABEL operators.operatorframework.io.bundle.mediatype.v1registryv1 LABEL operators.operatorframework.io.bundle.manifests.v1manifests/ LABEL operators.operatorframework.io.bundle.metadata.v1metadata/ LABEL operators.operatorframework.io.bundle.package.v1loki-operator LABEL operators.operatorframework.io.bundle.channels.v1stable LABEL operators.operatorframework.io.bundle.channel.default.v1stable LABEL operators.operatorframework.io.metrics.builderoperator-sdk-unknown LABEL operators.operatorframework.io.metrics.mediatype.v1metricsv1 LABEL operators.operatorframework.io.metrics.project_layoutgo.kubebuilder.io/v4 # Labels for testing. LABEL operators.operatorframework.io.test.mediatype.v1scorecardv1 LABEL operators.operatorframework.io.test.config.v1tests/scorecard/ # Copy files to locations specified by labels. COPY ./manifests /manifests/ COPY ./metadata /metadata/ COPY ./tests/scorecard /tests/scorecard/基于scratch的捆绑包镜像通过一组operators.operatorframework.io.*标签声明其 OLM 元数据布局并复制三个关键目录manifests/包含 ClusterServiceVersionloki-operator.clusterserviceversion.yaml、CRDloki.grafana.com_lokistacks.yaml、loki.grafana.com_alertingrules.yaml、loki.grafana.com_recordingrules.yaml、loki.grafana.com_rulerconfigs.yaml、RBAC 与 ServiceMonitor 等清单见 operator/bundle/openshift/manifestsmetadata/存放annotations.yaml供 OLM 索引解析 bundle 元数据见 operator/bundle/openshift/metadatatests/scorecard/scorecard 测试配置用于在发布前对 operator 进行 smoke test。OLM 依据channels.v1stable与channel.default.v1stable将loki-operator暴露在stable频道OpenShift 集群用户可通过 OperatorHub 直接订阅安装。本地复现镜像构建在仓库根目录下可以通过 Makefile 提供的 target 在本地验证 operator 镜像构建流程。Makefile 中定义# Loki Operator loki-operator-image: ## build the operator docker image $(OCI_BUILD) -t $(OPERATOR_IMAGE) -f operator/Dockerfile ./operator其中OPERATOR_IMAGE : $(IMAGE_PREFIX)/loki-operator:$(IMAGE_TAG)执行make loki-operator-image即会以operator/为构建上下文、operator/Dockerfile 为构建文件产出镜像。这与 CI 中context: operator、file: operator/Dockerfile的调用完全一致本地产物与线上流水线行为可对齐验证。若需完全复刻 CI 的多平台构建可参照 operator-reusable-image-build.yml 中的 Buildx 配置在本地启用 buildx 后指定--platform linux/amd64,linux/arm64,linux/arm进行交叉构建。小结Loki Operator 的镜像交付体系可以归纳为「一个可复用构建工作流 两条发布通道 三类镜像」一个核心operator-reusable-image-build.yml 统一承担多平台构建、注册中心认证与推送通过workflow_call被 CI 与发布流水线共享最大程度消除构建逻辑分叉两条通道operator-images.yaml 负责日常latest构建operator-release-please.yml 负责 release-please 驱动的版本化发布并通过「Release 草稿转正依赖镜像构建成功」的依赖关系保证发布原子性三类镜像operator 主程序镜像、bundle 捆绑包元数据镜像供 OLM 消费、工具类镜像容量计算分别由三份职责清晰的 Dockerfile 产出且主程序与工具镜像均以 distroless 非 root 形态交付。对需要自建或改造 Operator 镜像 CI 的团队而言这套策略在触发粒度operator/**路径过滤、跨平台构建、OIDC/密钥分级认证、安全加固zizmor 告警规避、最小基础镜像以及发布闭环release-please 与镜像联动等方面都提供了可直接借鉴的模板。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Loki Operator 镜像构建与推送策略全解析：从 Dockerfile 到 CI/CD 工作流
Loki Operator 镜像构建与推送策略全解析从 Dockerfile 到 CI/CD 工作流【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki本文围绕 Grafana Loki Operator 的镜像构建与推送机制展开系统讲解 operator 镜像loki-operator、OpenShift 捆绑包镜像loki-operator-bundle以及存储容量计算工具镜像storage-size-calculator在 DockerHub 与 Quay.io 两大注册中心的构建、打标签与发布策略。读者阅读后可完整掌握 Loki Operator 的持续集成镜像流水线、release-please 驱动的版本化发布流程、多平台amd64/arm64/arm交叉构建原理以及如何在本地复现这些镜像的构建过程。镜像构建与推送总览Loki Operator 仓库采用「一套构建逻辑、多注册中心分发」的策略所有镜像构建逻辑收敛到复用的构建工作流中再由各 CI 工作流按场景日常开发 vs 正式发布调用。整个体系由三部分组成持续集成构建latest 标签推送main分支仅operator/**路径变更或手动触发时构建并推送所有 operator 相关镜像标签为latest正式发布构建版本号标签release-please 创建新 Release 时构建并推送带语义化版本号{major}.{minor}.{patch}的镜像复用构建工作流集中处理多平台构建linux/amd64、linux/arm64、linux/arm与基于注册中心的认证逻辑供其他工作流workflow_call调用。对应的工作流文件与镜像 Dockerfile 均位于仓库根目录可对照查阅operator-images.yaml、operator-release-please.yml、operator-reusable-image-build.yml以及 operator/Dockerfile、operator/calculator.Dockerfile、operator/bundle/openshift/bundle.Dockerfile。构建与推送策略DockerHubdocker.io官方文档声明loki-operator镜像同时面向 DockerHub 分发。在仓库的实际工作流中DockerHub 的推送经由 Google Artifact Registryus-docker.pkg.dev下的grafanalabs-global/dockerhub-loki-prod-mirror仓库完成即先将镜像推送到 GAR 的镜像仓库再同步/镜像至 DockerHub 命名空间镜像触发时机组织标签工作流文件loki-operator推送 main 分支grafana经grafanalabs-global/dockerhub-loki-prod-mirror中转latestoperator-images.yamlloki-operator创建 Release同上{major}.{minor}.{patch}operator-release-please.ymlQuay.ioQuay.io 是 OpenShift 生态的分发主阵地面向openshift-logging组织推送三款镜像其中 operator 主镜像与 bundle 捆绑包镜像配合可被 OpenShift OperatorHub / OLM 直接消费镜像触发时机组织标签工作流文件loki-operator推送 main 分支openshift-logginglatestoperator-images.yamlloki-operator-bundle推送 main 分支openshift-logginglatestoperator-images.yamlstorage-size-calculator推送 main 分支openshift-logginglatestoperator-images.yaml值得注意的是实际工作流在 Quay.io 侧还额外发布了第 4 个镜像passthrough-gateway基于 operator/passthrough-gateway.Dockerfile对应 operator/cmd/passthrough-gateway 入口用于 OpenShift 上的多租户网关场景属于对文档表格的运行时扩展。工作流文件逐层拆解operator-images.yaml持续集成构建operator-images.yaml 是 daily CI 的入口触发条件为push到main分支且变更路径命中operator/**即只有 operator 相关代码变动才触发镜像构建避免无关提交浪费构建资源workflow_dispatch手动触发便于运维人员随时重新构建。该工作流在同一文件内声明了 5 个并行 job全部通过uses: ./.github/workflows/operator-reusable-image-build.yml复用统一构建逻辑仅通过with传入不同的构建参数JobDockerfileRegistry组织/仓库镜像名标签publish-grafana-operatoroperator/Dockerfileus-docker.pkg.devgrafanalabs-global/dockerhub-loki-prod-mirrorloki-operatorlatestpublish-openshift-operatoroperator/Dockerfilequay.ioopenshift-loggingloki-operatorlatestpublish-openshift-bundleoperator/bundle/openshift/bundle.Dockerfilequay.ioopenshift-loggingloki-operator-bundlelatestpublish-openshift-size-calculatoroperator/calculator.Dockerfilequay.ioopenshift-loggingstorage-size-calculatorlatestpublish-openshift-passthrough-gatewayoperator/passthrough-gateway.Dockerfilequay.ioopenshift-loggingpassthrough-gatewaylatest每个 job 都显式声明id-token: write权限这是 OIDC 无密钥认证Workload Identity Federation的前提——推送到 GAR 时不再依赖静态账号密码。operator-reusable-image-build.yml集中式构建核心operator-reusable-image-build.yml 是整套体系的「心脏」采用workflow_call可复用事件对外暴露 5 个必填输入image_name镜像名称dockerfile构建所用的 Dockerfile 路径tag镜像标签registry目标注册中心us-docker.pkg.dev或quay.ioorganization注册中心下的组织/项目名。其执行步骤完整呈现了现代多平台镜像 CI 的标准姿势checkout 代码使用actions/checkoutv7.0.1拉取仓库并设置persist-credentials: false防止令牌泄漏配置 QEMU通过docker/setup-qemu-action注册模拟器使构建机能够为linux/arm64、linux/arm等非宿主架构执行跨平台编译配置 Buildx通过docker/setup-buildx-action启用 BuildKit 多平台构建能力认证按注册中心分流目标为 GARus-docker.pkg.dev时调用grafana/shared-workflows/actions/login-to-gar完成 OIDC 登录目标为 Quay.io 时先调用get-vault-secrets从 Vault 读取openshift-credentials用户名/密码再通过docker/login-actionv4.6.0带logout: true登录构建并推送调用docker/build-push-actionv7.3.0关键参数如下- name: Build and push uses: docker/build-push-actionv7.3.0 with: # 根据镜像名推断构建上下文 # bundle 镜像使用 operator/bundle/openshift其余使用 operator context: ${{ inputs.image_name loki-operator-bundle operator/bundle/openshift || operator }} file: ${{ inputs.dockerfile }} platforms: linux/amd64,linux/arm64,linux/arm push: true tags: ${{ inputs.registry }}/${{ inputs.organization }}/${{ inputs.image_name }}:${{ inputs.tag }}工作流中的注释特别说明了 context 的推断逻辑采用条件表达式而非直接暴露context输入是为了规避 zizmorGitHub Actions 静态安全扫描工具对「输入可能展开为攻击者可控代码」的高危告警——这是 CI 供应链安全加固的典型实践。operator-release-please.yml版本化发布流水线operator-release-please.yml 定义了正式发布流程触发条件为推送main分支且变更operator/**。其流程分为三个串联阶段releasePlease job使用googleapis/release-please-actionv5.0.0分析 Conventional Commits自动推进版本号并创建 Release。其行为由 operator/release-please-config.json 控制核心配置包括bump-minor-pre-major: true0.x 阶段升 minor 而非 major、include-component-in-tag: true、tag-separator: /形成operator/vX.Y.Z形式的 tag、PR 标题模板chore(operator): Community release ${version}以及changelog-path: CHANGELOG.md。该 job 还会输出operator--release_created、operator--tag_name、operator--major/minor/patch等关键结果供下游消费。认证使用 GitHub Apploki-gh-app生成的临时令牌避免使用机器人账号密码publishImages jobif: ${{ needs.releasePlease.outputs.release_created }}守卫——仅当 release 真正创建后才执行。复用operator-reusable-image-build.yml构建loki-operator但标签不再是latest而是拼接为{major}.{minor}.{patch}的正式版本号推送到us-docker.pkg.dev/grafanalabs-global/dockerhub-loki-prod-mirrorpublishRelease job依赖前两个 job 成功通过gh release edit将 Release 从草稿状态release-please 默认draft: true转为正式发布并标记为非最新--latestfalse确保版本的发布状态与镜像推送结果保持一致。该设计实现了「版本号生成 → 镜像构建推送 → Release 正式发布」的原子化闭环镜像构建失败则 Release 不会转正。镜像清单与 Dockerfile 深入解读loki-operator主 Operator 二进制镜像构建文件为 operator/Dockerfile采用经典的两阶段构建# 阶段一编译 FROM golang:1.26.6sha256:0d1d3a794be25f809dd2cb3160d8c73276c4056a9f8242a138e908ddeee7b6b6 as builder WORKDIR /workspace # 先复制 go.mod/go.sum 与 api 模块缓存依赖层 COPY api/ api/ COPY go.mod go.mod COPY go.sum go.sum RUN go mod download # 再复制源码避免源码变更导致依赖层失效 COPY cmd/loki-operator/main.go cmd/loki-operator/main.go COPY internal/ internal/ RUN CGO_ENABLED0 GOOSlinux GO111MODULEon go build -modreadonly -o manager cmd/loki-operator/main.go # 阶段二精简运行镜像 FROM gcr.io/distroless/static:nonroot WORKDIR / COPY --frombuilder /workspace/manager . USER 65532:65532 ENTRYPOINT [/manager]几个值得注意的工程细节依赖缓存先COPY go.mod go.sum并执行go mod download再复制源码利用 Docker 层缓存避免每次提交都重新下载依赖静态编译CGO_ENABLED0 GOOSlinux产出纯静态二进制可安全运行于不含 glibc 的 distroless 基础镜像最小攻击面最终镜像基于gcr.io/distroless/static:nonroot无 shell、无包管理器并以非 root 用户UID 65532运行入口ENTRYPOINT 直指编译产物/manager对应 operator 主程序入口 operator/cmd/loki-operator/main.go。storage-size-calculator容量计算工具镜像构建文件为 operator/calculator.Dockerfile结构与主镜像完全对称在golang:1.26.6builder 阶段编译 operator/cmd/size-calculator/main.go产物为size-calculator运行阶段同样基于 distroless 并以非 root 运行ENTRYPOINT [/size-calculator]。该工具用于计算 LokiStack 各组件如查询、写入、存储的资源与容量需求与 operator 内的 size-calculator 逻辑呼应。loki-operator-bundleOpenShift OLM 捆绑包镜像构建文件为 operator/bundle/openshift/bundle.Dockerfile它与前两者完全不同——不包含任何二进制而是 OLMOperator Lifecycle Manager规范下的元数据镜像FROM scratch # Core bundle labels. LABEL operators.operatorframework.io.bundle.mediatype.v1registryv1 LABEL operators.operatorframework.io.bundle.manifests.v1manifests/ LABEL operators.operatorframework.io.bundle.metadata.v1metadata/ LABEL operators.operatorframework.io.bundle.package.v1loki-operator LABEL operators.operatorframework.io.bundle.channels.v1stable LABEL operators.operatorframework.io.bundle.channel.default.v1stable LABEL operators.operatorframework.io.metrics.builderoperator-sdk-unknown LABEL operators.operatorframework.io.metrics.mediatype.v1metricsv1 LABEL operators.operatorframework.io.metrics.project_layoutgo.kubebuilder.io/v4 # Labels for testing. LABEL operators.operatorframework.io.test.mediatype.v1scorecardv1 LABEL operators.operatorframework.io.test.config.v1tests/scorecard/ # Copy files to locations specified by labels. COPY ./manifests /manifests/ COPY ./metadata /metadata/ COPY ./tests/scorecard /tests/scorecard/基于scratch的捆绑包镜像通过一组operators.operatorframework.io.*标签声明其 OLM 元数据布局并复制三个关键目录manifests/包含 ClusterServiceVersionloki-operator.clusterserviceversion.yaml、CRDloki.grafana.com_lokistacks.yaml、loki.grafana.com_alertingrules.yaml、loki.grafana.com_recordingrules.yaml、loki.grafana.com_rulerconfigs.yaml、RBAC 与 ServiceMonitor 等清单见 operator/bundle/openshift/manifestsmetadata/存放annotations.yaml供 OLM 索引解析 bundle 元数据见 operator/bundle/openshift/metadatatests/scorecard/scorecard 测试配置用于在发布前对 operator 进行 smoke test。OLM 依据channels.v1stable与channel.default.v1stable将loki-operator暴露在stable频道OpenShift 集群用户可通过 OperatorHub 直接订阅安装。本地复现镜像构建在仓库根目录下可以通过 Makefile 提供的 target 在本地验证 operator 镜像构建流程。Makefile 中定义# Loki Operator loki-operator-image: ## build the operator docker image $(OCI_BUILD) -t $(OPERATOR_IMAGE) -f operator/Dockerfile ./operator其中OPERATOR_IMAGE : $(IMAGE_PREFIX)/loki-operator:$(IMAGE_TAG)执行make loki-operator-image即会以operator/为构建上下文、operator/Dockerfile 为构建文件产出镜像。这与 CI 中context: operator、file: operator/Dockerfile的调用完全一致本地产物与线上流水线行为可对齐验证。若需完全复刻 CI 的多平台构建可参照 operator-reusable-image-build.yml 中的 Buildx 配置在本地启用 buildx 后指定--platform linux/amd64,linux/arm64,linux/arm进行交叉构建。小结Loki Operator 的镜像交付体系可以归纳为「一个可复用构建工作流 两条发布通道 三类镜像」一个核心operator-reusable-image-build.yml 统一承担多平台构建、注册中心认证与推送通过workflow_call被 CI 与发布流水线共享最大程度消除构建逻辑分叉两条通道operator-images.yaml 负责日常latest构建operator-release-please.yml 负责 release-please 驱动的版本化发布并通过「Release 草稿转正依赖镜像构建成功」的依赖关系保证发布原子性三类镜像operator 主程序镜像、bundle 捆绑包元数据镜像供 OLM 消费、工具类镜像容量计算分别由三份职责清晰的 Dockerfile 产出且主程序与工具镜像均以 distroless 非 root 形态交付。对需要自建或改造 Operator 镜像 CI 的团队而言这套策略在触发粒度operator/**路径过滤、跨平台构建、OIDC/密钥分级认证、安全加固zizmor 告警规避、最小基础镜像以及发布闭环release-please 与镜像联动等方面都提供了可直接借鉴的模板。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考