用镜像label实现自动化归档，核心是将生命周期、合规要求等上下文固化为结构化元数据（如policy、scope、source、created），构建时注入，归档工具据此扫描、判断、执行移动/标记/删除，并结合tag确保操作可靠与可追溯。
直接用镜像 Label 实现自动化归档，核心是把归档所需的上下文（如生命周期、所属系统、合规要求）固化进镜像元数据，并让归档工具能可靠读取和决策。Label 本身不执行动作，但它是触发归档逻辑的“开关”和“依据”。
归档所需的关键 Label 字段设计
归档不是简单删镜像，而是按策略移动、标记、保留或脱敏。需要在构建阶段就注入可被识别的结构化信息：
-
com.company.archival.policy：值为
retain-90d、move-to-cold、delete-after-7d等，明确定义归档行为 -
com.company.archival.scope：标明适用范围，如
pci-dss、gdpr-backup、ci-artifact，便于按合规域批量处理 -
com.company.archival.source：记录原始来源，例如
git://repo.git#refs/tags/v2.3.0或jenkins/job/build-1234，确保归档后仍可追溯 -
org.opencontainers.image.created：使用 RFC3339 格式（如
2026-04-15T08:22:10Z），作为时间判断基准，避免依赖本地时区
构建阶段统一注入 Label
Label 必须在 docker build 时写入，后期无法补加。推荐用 --label 参数集中控制，避免 Dockerfile 中分散定义导致继承混乱：
- CI 脚本中动态生成：
docker build -t myapp:2.3.0 \
--label "com.company.archival.policy=retain-90d" \
--label "com.company.archival.scope=production" \
--label "org.opencontainers.image.created=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
. - 若标签较多，可存为
archival.labels文件（每行key=value），用--label-file archival.labels批量加载 - 禁用
latest类模糊标签参与归档流程——归档系统应只处理带明确语义化版本（如v2.3.0）和完整 Label 的镜像
归档脚本如何基于 Label 自动执行
归档不是手动操作，而是一套可调度、可审计的检查-判断-执行流程。关键逻辑如下：
- 扫描镜像仓库（如 Harbor API）或本地镜像列表，筛选出含
com.company.archival.policy的镜像 - 解析
org.opencontainers.image.created，计算是否到达归档窗口（如retain-90d表示创建满 90 天后转入冷库存储） - 根据
com.company.archival.scope匹配对应归档规则：PCI 相关镜像需加密压缩并上传至专用对象存储；CI 构建产物可直接打archived标签并移出主命名空间 - 执行后写入归档日志，包含镜像 ID、Label 内容、操作类型、时间戳，供审计追踪
与镜像 Tag 协同提升归档可靠性
Label 提供元数据，Tag 提供引用路径，二者结合才能闭环。例如：
- 归档前，先将待归档镜像打上
archived-v2.3.0-20260501这类带日期的临时 Tag，避免归档中被误删或覆盖 - 归档完成后，原 Tag（如
v2.3.0）保留在仓库中，但镜像配置中追加com.company.archival.status=completed，防止重复处理 - 清理脚本只清理同时满足“无运行中容器引用 + Label 中 policy 为 delete-after-* + 已超期”的镜像，不碰任何带
archived-前缀的 Tag
