Harbor需预置部署并深度集成CI/CD，通过API实现项目创建、镜像推送、漏洞扫描、跨环境同步与自动清理等全生命周期自动化管理，同时强化HTTPS、权限隔离与限流告警等安全稳定性设计。
在CI/CD流水线中部署Harbor并实现镜像全生命周期自动化管理，核心在于“环境可复现”和“操作可编程”。Harbor不是单纯部署完就结束的组件，而是要深度嵌入GitOps或CI/CD流程中——从项目创建、镜像推送、漏洞扫描、复制分发到清理归档，全部通过API驱动。
一、Harbor部署需适配CI/CD运行时环境
不建议在CI流水线中动态安装Harbor（耗时且不可靠），而应采用预置+配置即代码的方式：
- 使用Docker Compose或Helm Chart统一定义Harbor服务拓扑，所有参数（如域名、证书路径、数据库连接）通过环境变量注入
- 在Jenkins或GitLab Runner所在节点提前拉取Harbor离线包或镜像，确保无外网依赖
- 通过harbor.yml模板 + sed/yq工具动态替换配置项，再执行
install.sh完成轻量级部署 - 部署后调用
GET /api/v2.0/systeminfo验证API服务就绪，作为流水线下一步的准入检查
二、用API接管镜像全生命周期关键节点
Harbor v2.0+ API覆盖镜像从入库到下线的完整链路，无需登录Web控制台。以下为高频自动化场景对应接口：
-
项目准备：调用
POST /api/v2.0/projects按需创建私有项目，设置public=false与cve_whitelist策略 -
凭证安全注入：创建机器人账户（
POST /api/v2.0/projects/{project_id}/robots），仅授予pull/push权限，返回的token直接用于docker login --username=robot$xxx --password=xxx -
构建后自动推送：Jenkins/GitLab CI脚本中，在
docker build完成后执行docker push harbor.example.com/project/app:git-tag，触发Harbor内置扫描器 -
质量门禁拦截：推送后立即调用
GET /api/v2.0/projects/{pid}/repositories/{repo}/artifacts/{tag}/scan/log轮询扫描结果；若发现CRITICAL级别CVE，返回非零状态码中断流水线 -
跨环境同步：通过
POST /api/v2.0/replication/policies创建事件驱动型复制规则，源为dev/project/app，目标为prod/project/app，标签匹配release-* -
镜像自动清理：定时任务调用
GET /api/v2.0/projects/{pid}/repositories/{repo}/artifacts获取历史镜像，结合last_updated字段筛选过期镜像，再用DELETE /api/v2.0/projects/{pid}/repositories/{repo}/artifacts/{digest}批量删除
三、安全与稳定性必须前置设计
自动化意味着放大的风险面，以下三点不能妥协：
- 所有API请求强制启用HTTPS，校验Harbor服务端证书；客户端JWT Token有效期设为2小时，由CI系统定期刷新
- 为不同环境（dev/staging/prod）分配独立机器人账户，禁止跨项目写权限；审计日志中所有机器人操作标记为
robot@xxx，便于溯源 - 大镜像复制时启用带宽限流（Harbor配置
replication.bandwidth_quota），避免压垮CI网络出口；关键复制任务配置失败重试+钉钉/企业微信告警
四、与主流CI工具链的典型集成方式
不同平台接入方式略有差异，但底层逻辑一致：
-
GitLab CI：将Harbor机器人Token存为Project CI Variables（masked & protected），在
.gitlab-ci.yml中用before_script完成登录与环境准备 -
Jenkins：使用Credentials Plugin存储机器人账号，Pipeline脚本中通过
withCredentials安全注入，避免密码明文出现在日志中 -
Argo CD/GitOps：将Harbor项目配置、复制规则等声明为YAML资源，通过
harbor-operator（社区CRD）同步到集群，实现真正的Git驱动管理
