harbor是容器镜像自动化发布的可信枢纽，需通过预置部署、机器人账号鉴权、api驱动全生命周期管理（项目创建、推送、扫描、同步、清理），并集成https、rbac、漏洞扫描与策略准入等安全机制。
构建基于容器镜像的自动化发布流，核心在于把代码变更、镜像构建、安全校验和镜像推送串联成可重复、可审计、低干预的闭环。Harbor 不只是存储仓库，更是这个流程里的可信枢纽——它提供项目隔离、机器人账号、漏洞扫描和策略执行能力。关键不在于“能不能推”，而在于“谁在什么条件下推、推的是不是合规、推完有没有被验证”。
明确 Harbor 项目结构与权限模型
Harbor 的项目（Project）是权限和策略的基本单位。不要直接用 admin 或普通用户账号对接 CI 系统，应为每个业务线或流水线创建独立项目，并启用“私有”或“公开”策略。更重要的是：使用机器人账号（Robot Account）而非人工账号。它自动生成唯一用户名和密钥，支持设置过期时间、操作范围（如仅限 push/pull），且不会因员工离职导致凭证泄露风险。一个典型命名如 robot-ci-order-service，便于追踪来源。
在 CI 流水线中完成三步关键操作
以 Bitbucket Pipelines、GitLab CI 或 GitHub Actions 为例，流水线脚本需稳定完成以下动作：
-
登录 Harbor：用
docker login -u $HARBOR_USERNAME -p $HARBOR_PASSWORD $HARBOR_URL，确保 URL 带协议（https://），否则会默认走 Docker Hub -
构建并打标签：镜像名必须符合
$HARBOR_URL/$HARBOR_PROJECT/$IMAGE_NAME:$TAG格式，例如harbor.example.com/prod/order-api:v1.2.3或harbor.example.com/prod/order-api:sha-abc1234。避免使用latest作为唯一标签，它无法追溯、不利于回滚 -
推送并验证响应：执行
docker push后，建议加一行docker pull $HARBOR_URL/$HARBOR_PROJECT/$IMAGE_NAME:$TAG验证是否真正可拉取（尤其当 Harbor 启用内容信任时，推送成功不等于立即可用）
启用 Harbor 内置安全机制反向驱动流程
自动化发布不能只关注“推上去”，更要确保“推上去的是安全的”。Harbor 提供两项关键能力，应主动集成进流程：
- 自动镜像扫描：在项目配置中开启“自动扫描新推送镜像”，扫描结果可通过 Harbor API 查询。CI 脚本可在 push 后轮询 API，若发现 CRITICAL 级别漏洞，直接失败当前流水线，阻断发布
- 策略驱动准入控制：通过 Harbor 的“项目策略”（如“阻止高危漏洞镜像”、“仅允许已签名镜像”）设定硬性规则。一旦违反，push 请求会被 Harbor 直接拒绝，无需 CI 侧额外判断
镜像元数据与可观测性补全
发布后的镜像应自带上下文信息，方便排查与审计：
- 在 Dockerfile 中使用
LABEL注入构建信息，例如：LABEL org.opencontainers.image.source="$BITBUCKET_REPO_OWNER/$BITBUCKET_REPO_SLUG"<br>LABEL org.opencontainers.image.revision="$BITBUCKET_COMMIT"<br>LABEL org.opencontainers.image.created="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
- Harbor UI 中可直接查看这些标签；配合审计日志，能快速定位某次生产事故对应的构建源头、提交人、时间点
- 若使用 GitOps 模式，还可将镜像 digest（如
@sha256:abcd...）写入 Kubernetes 清单，实现不可变部署
