真正可落地的全公司镜像追踪看板，核心是强制镜像构建时嵌入标准化LABEL作为“身份证”，涵盖应用名、环境、团队、版本、提交哈希等字段，CI动态注入、门禁校验、API直连仓库生成动态看板。
靠人工查镜像、翻 Git 记录、问负责人——这种追踪方式在几十个服务时就已失效。真正可落地的全公司镜像追踪看板，核心不是堆监控图表，而是让每一张镜像从构建那一刻起，自带“身份证”和“履历表”。关键在于 LABEL 不是锦上添花的备注，而是强制嵌入的结构化契约。
统一定义必填 LABEL 字段，对齐 CMDB 资产模型
所有镜像必须携带以下字段，且键名、取值范围、格式全部标准化，与 CMDB 中“应用系统”“部署环境”“所属团队”等主数据严格一致：
-
org.opencontainers.image.name：对应 CMDB “应用系统名称”，如
order-service（禁止用模糊名如backend） -
com.company.env：仅允许
prod/staging/uat/dev四值，杜绝test、beta等非标写法 -
com.company.team：对应 CMDB “运维责任组”，如
payment-sre，小写+短横线，全公司唯一 -
org.opencontainers.image.version：语义化版本或 Git Tag，如
v2.5.0或release/2026-Q2 -
org.opencontainers.image.revision：构建时自动注入的完整 Git 提交哈希（
$(git rev-parse HEAD)）
CI 流水线中动态注入，禁止硬编码
所有 LABEL 值必须由 CI 环境实时生成，Dockerfile 中只声明占位符：
- Dockerfile 写法：
ARG APP_NAME ARG GIT_COMMIT LABEL org.opencontainers.image.name=$APP_NAME LABEL org.opencontainers.image.revision=$GIT_COMMIT - Jenkins/GitLab CI 中通过
--build-arg传参：docker build --build-arg APP_NAME=$(basename $(pwd)) --build-arg GIT_COMMIT=$(git rev-parse HEAD) -t $IMAGE . - 构建时间用 RFC3339 格式：
--label org.opencontainers.image.created=$(date -u +'%Y-%m-%dT%H:%M:%SZ')
构建后强制校验，不合规镜像直接阻断
把 LABEL 合规性变成门禁，而非事后检查：
- CI 构建完成但推送前，执行脚本检查：
docker inspect $IMAGE | jq -r '.[0].Config.Labels' | jq 'has("org.opencontainers.image.name") and has("com.company.env") and (.["com.company.env"] | IN("prod","staging","uat","dev"))' - 私有仓库（如 Harbor）配置准入策略：拒绝推送不含
org.opencontainers.image.name和com.company.env的镜像 - 校验失败时输出明确错误：“缺失 com.company.env，或值非法（仅接受 prod/staging/uat/dev）”
看板数据源直连镜像仓库 API，不依赖人工录入
看板不是静态报表，而是动态映射真实镜像状态：
- 对接 Harbor / Artifactory API，定时拉取所有镜像的
manifest和config层中的 LABEL 字段 - 按
org.opencontainers.image.name + com.company.env组合去重，生成“应用-环境”二维矩阵 - 每格显示：最新 version、对应 revision、构建时间、责任人（
com.company.team）、是否已扫描（读取安全扫描工具 webhook 结果） - 点击某镜像，直接跳转至对应 Git 提交页、CMDB 资产页、Harbor 镜像详情页
