docker镜像管理策略围绕“可追溯、可复用、可信任、可清理”四目标，明确生命周期、统一标签规范（禁用latest、启用dct）、分层构建与分级存储、强制安全扫描及审计闭环。
定 Docker 镜像管理策略，核心是围绕“可追溯、可复用、可信任、可清理”四个目标来设计，不是堆砌工具或流程，而是匹配团队规模、发布节奏和安全要求。
明确镜像生命周期边界
先划清哪些镜像归谁管、存多久、怎么退役。比如：
- 开发环境镜像（带 -dev 或 -snapshot 标签）保留最近 7 天，自动清理
- 测试环境镜像（-test）需绑定 Git 提交哈希，保留至对应需求上线后 14 天
- 生产环境镜像（-prod）必须打语义化版本标签（如 api-gateway:2.4.1-prod），且不可覆盖，只允许新增
- 基础镜像（如 node:18-alpine、python:3.11-slim）由平台组统一维护，各业务线禁止自行构建同类基础层
统一标签命名与推送规范
标签混乱是运维事故的常见源头。推荐采用固定格式：服务名:主版本.次版本.修订号-环境-构建序号，例如 order-service:1.3.0-prod-20260729-001。关键约束包括：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 禁止使用 latest 标签用于生产部署（CI 流水线中应直接报错）
- 所有推送前必须通过 docker tag 命名，确保仓库路径含组织/项目前缀（如 registry.example.com/backend/order-service）
- Git Tag 推送时自动触发构建，生成对应镜像并打双重标签（如 v1.3.0 和 1.3.0-prod）
- 镜像推送必须启用 Docker Content Trust（设置 DOCKER_CONTENT_TRUST=1），未签名镜像拒绝入库
分层构建 + 存储分级管理
镜像体积和复用率直接受构建方式影响，存储成本则取决于仓库架构：
- 强制使用多阶段构建：编译型语言（Go/Rust）剥离构建环境；解释型语言（Node.js/Python）用 .dockerignore 过滤 dev 依赖和文档
- 私有仓库按用途分级：dev 仓开放读写，test 仓只读+扫描准入，prod 仓仅 CI 系统可推，人工禁止操作
- 基础镜像层统一托管在内网 Harbor，并配置自动同步 upstream（如 Docker Hub 的 nginx、redis 官方镜像），避免重复拉取公网资源
- 定期执行镜像垃圾回收：对 30 天无 pull 记录的非 prod 标签自动标记为待清理，7 天后物理删除
安全与审计闭环设计
管理策略若不嵌入安全检查，就只是纸面流程。必须做到：
- 所有镜像入库前强制静态扫描（Clair/Trivy），高危漏洞（CVSS ≥ 7.0）阻断推送
- 镜像 manifest 记录构建主机 IP、CI Job ID、代码 commit hash，支持一键溯源
- 每季度审计镜像仓库权限：清理离职人员令牌、禁用密码明文登录、验证 RBAC 分组是否最小权限
- 关键服务镜像启用不可变标签（immutable tag），一旦推送无法覆盖或删除，仅能新增
