企业官网建设流程全解析

我做了这么多年的容器化落地，最常被问的一句话就是：“我们自己人拉镜像，有没有一个又全又稳的方案？”坦白讲，用公共仓库做生产镜像存储，痛点太多了。先不说安全合规这层，就那个偶尔抽风的速度和时不时蹦出来的限流提示，就够让人在发版前夜血压飙升。后来我统一给团队推了一套方案：搭建一套全功能Harbor作为企业内部的私有镜像中心。这篇文章就围绕这个标题展开，把从选型、规划到落地踩坑的整个过程掰开揉碎讲一遍，给你一条可以直接照着抄作业的路径。

这套方案面向谁？如果你是刚接触容器化的开发者，能明白为什么要自建仓库；如果你是要扛起公司基础设施的运维或平台工程师，能拿到一整套包含高可用、镜像复制、安全扫描、配额管控和备份恢复的实操清单。整套做下来，我们不仅把镜像拉取速度从“不可描述”拉回内网毫秒级，还把镜像资产纳入了统一的权限管控和审计体系里。

1. 整体设计与思路拆解：为什么偏偏是全功能Harbor

1.1 公共仓库的痛点和自建仓库的核心收益

先捋一下需求。当一个团队规模超过十个人，或者交付频率上来了以后，对镜像仓库的要求就远超“能存能拉”这四项字。公共仓库在这个阶段会暴露出几个非常现实的问题：首先是安全隐患，代码和业务配置都打到公共镜像里，等于把内部细节公开了；其次是稳定性不可控，公共仓库的限流策略和网络波动会直接影响生产效率；再次是缺少精细化管理手段，谁推了什么、谁能拉什么、镜像里有什么漏洞，完全没法管。

自建私有仓库解决的正是这些问题。全功能Harbor的价值体现在把镜像仓库从一个简单的存储变成了一个完整的制品管理平台。它把镜像存储、权限模型、安全扫描、复制同步、垃圾回收这些能力都收拢到一个系统里，而我们要做的就是在自己的机房或云环境里，把这个平台完整地跑起来。

1.2 方案选型对比：为什么不是其他仓库

在做方案选型时，我对比过几个主流选择。Docker Registry 是官方提供的裸仓库，胜在轻量，但它只有最基础的存储和拉取能力，权限、UI、配额、扫描这些通通没有，适合个人玩具项目，不适合企业级。有些云厂商托管的镜像仓库服务，用起来省心，但存在厂商绑定和内外网连通的问题。

相比之下，Harbor 的优势在于它是开源里功能覆盖最全的，而且它是CNCF的毕业项目，迭代节奏和社区活跃度都有保障。它的功能矩阵基本覆盖了企业镜像管理的全部需求：基于角色的访问控制、项目管理、镜像复制、漏洞扫描、内容签名、垃圾回收、配额管理、审计日志，几乎每个模块都能在生产环境里直接落地。再加上它支持多后端存储，可以适配本地磁盘、对象存储、S3等不同基础设施，这给了我们很大的设计自由度。

1.3 部署架构的规划思路

部署前要做的最重要的一件事，是把架构图画清楚，尤其是数据流和控制流的分层。

我推荐的硬件配置是两核CPU、8GB内存起步。Harbor的内存大头被三个组件吃掉：Nginx做流量入口，核心服务处理API请求和配置管理，Registry负责镜像层数据的读写。还有一个很容易被忽略的组件是数据库，默认用的是PostgreSQL，走的是独立容器，内存占用也不小。如果资源紧张，宁可把内存加到16GB也别用2GB的小机器硬扛，否则一次并发镜像扫描就能把节点拖垮。

存储方面建议至少划分出独立的镜像数据盘，容量规划按每日新增镜像量乘以保留周期再加一倍余量来计算。网络层面要给Harbor配置固定IP或稳定的域名入口，后面所有客户端都会用这个地址来登录和拉取镜像，如果这个入口变来变去，全公司所有构建节点都要跟着改配置，那种教训我经历过一次就再也不想经历第二次。

1.4 全功能理解：不只是仓库，是制品管理平台

很多团队的误区是把Harbor当成一个“私有的Docker Hub”，只用了它的存储和拉取功能，剩下的能力全部闲置。但“全功能”的含义是，这套系统应该深度嵌入交付链条。

举个实际场景。开发推送镜像后，Harbor可以自动触发漏洞扫描，扫描结果通过Webhook推送到IM群，不合格的镜像不会被生产环境拉取。合规审计要求每个镜像都能追溯到构建来源，Harbor的审计日志正好记录了每一次推送、拉取、删除的操作人、时间、来源IP。还有多环境交付场景，测试环境推送的镜像根据策略自动同步到生产环境的独立Harbor实例，整个过程没有人为干预。能做到这一层，Harbor才算真正发挥出它的全部价值。

2. 核心细节解析与实操要点：安装部署与组件功能全景

2.1 前置条件与环境准备

在动手安装Harbor之前，需要先确认基础环境满足要求。我建议使用Ubuntu 22.04或CentOS 7.9以上版本的系统，Docker版本不低于20.10，Docker Compose则需要V2版本。Harbor虽然也提供离线安装包，但本质上仍然是基于Docker Compose来编排多个容器的，所以docker和docker compose这两个基础工具必须提前装好。

环境准备阶段有一个容易踩的坑，就是操作系统防火墙和SELinux策略。我遇到过一次真实案例：Harbor容器全部起来了，但外部访问时80端口始终不通，排查到最后发现是防火墙默认区域没有放行端口。所以部署前先把防火墙规则和SELinux状态确认清楚，生产环境可以直接关闭SELinux，或者按Harbor文档配置对应的放行策略。

另一个前置条件是域名规划和证书准备。网上大多数教程都是IP加端口访问，但生产环境建议使用域名，比如 harbor.xxx.internal。有了域名就可以签发正规的HTTPS证书，而不是依赖HTTP或自签名证书。这里面的原因很实际：Docker客户端配置Registry地址时，如果是HTTP协议或不可信证书，需要在每个节点的daemon.json里配置insecure-registries，这样做不但繁琐，而且会成为安全隐患。用合规的HTTPS证书，客户端零配置即可直接访问。

2.2 安装包选择与配置文件深度解析

Harbor提供在线和离线两种安装方式。我强烈建议下载离线安装包。原因是离线包体积虽然大一点（几百MB），但它包含了所有需要用到的镜像，安装过程完全不依赖外部网络。对于内网环境来说，在线安装会被网络波动卡得欲哭无泪。

拿到离线包并解压后，首先要做的是复制一份配置文件模板：

tar xzf harbor-offline-installer-v2.11.0.tgz cd harbor cp harbor.yml.tmpl harbor.yml

harbor.yml是整个Harbor安装的核心，里面每一个关键配置都值得认真推敲。首先是hostname，这个必须改成你规划的域名或IP，它会被写进系统配置和返回给Docker客户端的地址里。然后是http和https两个端口块，二选一启用，生产环境肯定选https，并把证书路径指到准备好的公钥和私钥文件。

数据库密码可以留默认，但生产环境必须改掉。Harbor默认的数据库密码是公开的，直接把容器端口映射到外部的话，等于把数据裸奔给懂行的人。“全功能”意味着安全能力要配套，数据库密码尽量用不少于16位的随机字符串，并且不要让PostgreSQL端口对公网暴露。

还有一个容易被忽视的配置是data_volume，这是镜像数据存放路径。默认放在/data，你的镜像层数据会一直累积到这个目录下，几周之后这个目录的占用空间会非常可观。建议指向大容量磁盘的挂载点，比如/data/harbor。配置文件里还有log相关配置，生产环境建议开启rotate，控制日志文件大小和保留个数，避免日志把磁盘占满。

2.3 核心组件功能拆解：每个模块的定位与交互

Harbor安装完成后会拉起至少8个容器，很多新手看到这堆容器会懵，不知道各自干什么，出了问题也不知道该查谁。我把核心组件的分工梳理一下：

Nginx组件是统一入口，所有外部流量先经过它，HTTPS终结、TLS证书加载、路由转发都在这一层完成。通过docker logs nginx可以查看访问日志，排查登录不上或拉取失败问题，第一站就是看它有没有正常转发。

核心服务处理API请求、界面操作、认证鉴权和项目管理。用户登录、创建项目、配置复制规则这类操作都走这个组件。它也是连接其他组件的枢纽，比如触发扫描时由它调用扫描器组件。

Registry组件是镜像数据层本身，负责存储和分发镜像层数据。它本身是Docker Registry的上游开源项目的一个发行版，Harbor把需要扩展的功能通过插件的方式接入。

数据库组件基于PostgreSQL，所有元数据都存在这里：项目信息、用户信息、镜像标签、复制任务记录、操作审计日志。如果数据库掉了，整个Harbor控制台和API都会瘫痪。

Redis组件用作缓存层，主要缓存会话和部分热点查询。它挂了的话，界面可能还能打开，但登录会话和一部分性能会明显劣化。

扫描器组件是安全能力的核心，它负责漏洞扫描工作。Harbor默认集成了Trivy作为默认扫描器，它会不断更新漏洞库，对镜像层做CVE匹配。

其他还有注册器控制器、任务服务、图表仓库等组件，分别负责镜像复制任务调度和Helm Chart存储。

理解这些组件之后，排查问题的思路就清晰了：界面打不开但镜像能拉，优先查核心服务和数据库；镜像推不上去但界面正常，优先查Registry和存储空间；扫描任务一直卡住，去查扫描器组件和它的漏洞库更新状态。

2.4 安装与初始化操作实录

配置文件调整完毕之后，运行安装脚本：

sudo ./install.sh

脚本会先检查Docker环境，然后拉取所有镜像并启动容器。整个过程持续几分钟。安装完成的标志是看到Harbor has been installed and started successfully这行提示。

此时在浏览器访问你配置的域名或IP，就能看到Harbor的登录界面。默认管理员账号是admin，初始密码在harbor.yml中设置的harbor_admin_password字段。如果你是照着默认配置装的，密码就是Harbor12345。登录后第一个必须做的操作就是去“用户管理”里改掉这个默认密码，并开启两步验证，这是最低限度的安全操作。

初始化之后还有一个重要步骤：去“配置管理”里开启“仓库读写权限”的审计日志，并确认镜像删除和垃圾回收策略。默认情况下Harbor不会自动清理任何镜像，如果项目团队推送频繁且从不删旧镜像，存储告警只是时间问题。后面我会专门讲配额管理和垃圾回收的配合用法。

3. 实操过程与核心环节实现：从构建到生产拉取的完整闭环

3.1 项目划分与权限模型搭建

Harbor里的核心隔离单位是项目。它的权限模型设计得很好：一个项目就是一个命名空间，项目内的镜像仅对项目成员可见。这意味着不同团队之间的镜像不会互相干扰，也不存在越权拉取的问题。

项目权限分三级：项目管理员、开发者、访客。项目管理员能管理项目内所有成员和配置；开发者可以推送和拉取镜像；访客只有拉取权限。在新建项目时有一个“公开”选项需要慎重勾选。我遇到过一个事故：某团队为了方便，把项目设置成公开的，结果其他团队的CI脚本误用了他们的镜像标签，线上发布了错误版本。所以生产环境的项目一律设为私有，对外共享走单独的复制策略或专用项目，这个习惯要一开始就立好。

创建项目时建议按“业务线-环境”的格式命名，比如order-prod、order-dev。这样在复制策略、配额管理、审计追踪时，一眼就能看出镜像归属。有几个团队还喜欢按“应用名”建项目，短期没问题，但应用一多，项目数量爆炸式增长，管理和配额设置都会变得异常繁琐。建议一个业务域一个项目，镜像用tag区分版本。

3.2 配置HTTPS证书与客户端信任链

前面提到证书很重要，这一步具体操作一下。证书来源可以用企业内部CA签发，也可以使用公网可信证书。无论哪种，都需要两个文件：证书文件和私钥文件。Harbor在harbor.yml里的https部分需要配置这两个文件的路径：

https: port: 443 certificate: /data/certs/harbor.crt private_key: /data/certs/harbor.key

证书文件一定要包含完整证书链，尤其是使用企业内网CA签发的证书。如果证书链不完整，Docker客户端在拉取时可能报unknown authority错误。判断方法很简单：

openssl x509 -in harbor.crt -text -noout | grep "CA Issuers"

能看到CA Issuers字段就说明证书链是完整的。如果只是单一证书文件而缺少中间证书链，需要把服务器证书和中间证书按顺序拼接成一个文件。

Docker登录测试：

docker login harbor.xxx.internal

登录成功后会生成~/.docker/config.json的凭证文件。如果登录时报certificate signed by unknown authority，大多是证书问题，优先检查证书链，不要急着在daemon.json里加insecure-registries绕过。加了虽然能工作，但传输是明文的，等于安全能力打了一个大折扣。

3.3 镜像推送与拉取实战验证

项目创建好之后，模拟完整的镜像推送流程。假设打包好的镜像名叫my-app:v1.0.0：

docker tag my-app:v1.0.0 harbor.xxx.internal/order-prod/my-app:v1.0.0 docker push harbor.xxx.internal/order-prod/my-app:v1.0.0

push时会有两步输出：第一步传输各层数据，第二步是manifest上传。如果卡在第一步，最常见的原因是镜像层数据太大而网络带宽不足；如果直接在第一步报denied，说明当前账号对该项目没有推送权限，去项目成员里把这个账号加为开发者。

拉取侧的操作在客户端机器执行：

docker pull harbor.xxx.internal/order-prod/my-app:v1.0.0

到这里，一套最基本的“构建机器推包、生产机器拉包”的闭环就完整了。接下来做生产级的配置。

3.4 镜像复制策略：跨环境同步的生产级实践

多环境部署场景下，通常不会让生产环境的Harbor直接暴露给开发者推送，而是走一条更稳妥的链路：开发推送测试环境Harbor，测试通过后由复制策略同步到生产环境Harbor。这样既节省跨网络拉取时间，又能做到环境间隔离和审计追溯。

配置复制策略的地方在“系统管理-复制管理”中。创建规则时有几个关键字段需要说明：

• 源资源过滤器：按项目名和镜像名匹配要复制的对象。例如源项目为order-dev，可以设置镜像名称为my-app的镜像全量复制。
• 目标Registry：填写目标Harbor实例的地址和凭证。通常是生产环境的Harbor域名和专用账号。
• 触发模式：支持手动、定时和事件驱动三种。生产环境推荐事件驱动，即源仓库新推送镜像后立即触发复制。

复制机制实际执行时，会先比较源端和目标端的镜像摘要，只有发生变化的分层才会传输，这大大优化了跨地域同步的效率。有一个细节值得注意：复制策略用的账号建议单独创建，并仅授予目标Harbor的推包权限，不要把管理员账号直接用作复制账号，这样能避免账号权限过大导致的误操作风险。

3.5 漏洞扫描与镜像签名配置

开启漏洞扫描之前，建议先确认扫描器状态。在“系统管理-服务配置”里，Harbor默认绑定Trivy扫描器。首次使用前需要手动触发一次漏洞库更新，否则扫描器缺少CVE数据，扫出来的结果没有参考价值。更新漏洞库的命令在Harbor容器内部执行：

docker exec -it harbor-trivy-adapter sh # 容器内执行漏洞库更新 trivy image --download-db-only

这个下载过程依赖外部网络，内网环境可能需要配置代理。漏洞库更新完毕，项目可以开启“自动扫描”策略，设置成“推送镜像后自动扫描”。这样每次推包都会自动检查镜像的安全状态，有高危和严重漏洞的镜像会在界面上标红。

镜像签名这块需要额外部署工具。Harbor本身支持Docker Content Trust，用的是Notation签名机制。签名的意义是保证镜像在构建后没有被篡改过。部署Notation后，对镜像做一次签名：

notation sign harbor.xxx.internal/order-prod/my-app:v1.0.0

Harbor端开启“内容信任”后，未签名的镜像将无法被拉取。这是一道很强的安全关口，生产环境强烈建议启用。不过要提醒一点：签名增加了发布复杂度，开发流程里多一步操作，团队需要一段适应期。建议先在核心业务镜像上开启，等流程跑顺了再逐步推广。

3.6 配额管理、垃圾回收与存储规划

镜像数据只会膨胀不会缩小，这是存储管理的铁律。Harbor提供两种手段应对：配额管理和垃圾回收。

配额管理在“项目-配置”中设置，可以限制一个项目的最大存储量或最大镜像个数。比如给order-prod项目设置50GB上限，达到上限后，团队需要清理旧的未使用镜像才能继续推送。我见过很多团队因为没设配额，镜像仓库几个月内就吞掉了几TB存储。设置配额还有额外好处：逼着团队建立tag规范——尽量复用固定的发布tag，而不是每次构建都生成一个新tag，实测设置配额后，镜像总量增速能降一半以上。

垃圾回收解决的是“镜像被删但存储没释放”的问题。Docker镜像的原理是分层存储，删除镜像只是删除了manifest引用，数据层还在磁盘里。垃圾回收才是真正清理数据层的手段：

1. 先设置垃圾回收策略，建议选择“每天凌晨2点”。
2. 时间窗口期会停止当前项目的写入操作，所以必须选业务低峰期。
3. 每次垃圾回收执行前可以先查看一下“空间使用”统计，看看哪些项目占用了大量空间但活跃度很低。

执行垃圾回收时会有短暂的I/O峰值，如果底层存储是机械磁盘，期间拉取镜像的延迟会明显上升，这个现象属于正常。

4. 常见问题与排查技巧实录：生产环境踩坑速查表

4.1 安装启动类问题

Harbor启动后页面能打开，但登录后不断跳回登录页

这个问题通常指向数据库会话表失效或者Redis缓存混乱。排查思路按顺序来：先检查Redis容器所有键值对是否过期。再确认PostgreSQL迁移是否完成。Harbor从老版本升级后，数据库结构可能没有完全对齐，这时需要执行一条迁移命令，把旧数据结构升级到当前版本。另一个常见原因是Harbor设置了外部数据库，这种情况下需要在配置中确认DBCMaxIdleConns等参数。

Harbor容器反复重启，报内存不足

查看/var/log/messages或dmesg，如果有Out of memory关键字，说明是宿主机内存不够。Harbor全家桶加起来需要的内存比预想高，尤其是扫描器运行时会额外吃掉1GB左右内存。解决方法是给docker-compose.yml里的每个服务加上mem_limit限制，或者直接升级宿主机内存。优先保障核心服务和Registry不做限制，扫描器可以限制在2GB以内。

4.2 镜像推送拉取类问题

Docker push时报错：unauthorized: authentication required

这个报错信息会误导很多人，以为用户名和密码不对。实际上，这个错误更多时候是登录的目标域名和推送的目标域名不一致。例如你登录了harbor.xxx.internal:443，但推送地址写成了harbor.xxx.internal:80，而80端口是HTTP入口，Docker会认为这是另一个Registry实例，所以要求提供凭证。请检查推送地址是否和登录地址完全一致，包括端口号。

拉取镜像时报错：manifest unknown

这个报错表明目标仓库中确实不存在你指定的镜像标签。优先检查三个点：第一，标签是否打错；第二，项目是否写错；第三，该镜像是否已被垃圾回收。最后一种情况最隐蔽——如果镜像推了半年没人拉取，且项目配额满了，垃圾回收会优先清理未引用的数据层。解决办法就是不要手动删除线上还在用的旧镜像，统一走完整的废弃下线流程。

内网拉取速度极慢，大镜像传了一个小时

先定位瓶颈是网络还是存储。用iperf3在同一网段的两台机器间测带宽，排除物理网络瓶颈。再看Harbor所在宿主机磁盘类型，如果底层是普通SATA机械盘，镜像层文件的大量小I/O操作会明显拖慢整体速度。最佳实践是把Registry的数据卷直接放在NVMe SSD上，大镜像传输速度能提升一个量级。还有一个优化维度：客户端机器的Docker配置里加上max-concurrent-downloads=10，让多个层并行下载，大镜像速度提升非常明显。

4.3 安全扫描和复制任务类问题

扫描任务一直停在“扫描中”状态，迟迟不出结果

先检查扫描器容器内存和CPU占用，Trivy扫描大镜像时耗时会比较长。再检查漏洞库版本日期，如果数据库长时间没更新，扫描器会尝试下载最新漏洞库，而内网环境没有外网权限，下载会挂起。解决办法是提前把漏洞库文件下载好，通过离线方式导入扫描器。扫描器比较吃内存，建议扫描器容器内存不要低于2GB。

复制任务失败，错误信息显示“网络超时”

跨地域复制最常见的问题，就是目标Harbor实例所在区域的防火墙策略阻止了源端访问。复制任务默认走HTTPS端口，如果跨机房专线对443端口做了ACL限制，所有复制任务都会卡住。排查手段是先测试源端到目标端的连通性：

curl -kI https://harbor-prod.xxx.internal

能返回HTTP响应后再去重新执行复制任务。另外，复制账号被误删也会导致任务一直失败，这时错误日志会显示unauthorized，去目标端检查复制账号是否存在、密码是否变更过。

4.4 存储和备份恢复专题

Harbor的备份恢复是一项核心运维能力，很多团队直到丢数据那天才后悔没做。Harbor的数据分两部分：数据库元数据和镜像层文件。恢复时必须两套数据一起恢复，缺一不可。

数据库备份用PostgreSQL的pg_dump。但Harbor的数据库运行在容器里，建议直接用官方脚本备份：

docker exec -it harbor-db pg_dump -U postgres registry > harbor_registry_bak.sql

镜像数据备份更简单粗暴——直接同步整个数据目录。用rsync或者云存储的文件同步服务，把/data目录增量同步到备份存储。这里有一个关键细节：备份前先触发一次垃圾回收，把无效数据清理掉再备份，备份体积能小很多。

恢复流程也别等到出事故才第一次演练。建议每季度做一次恢复演练：在测试服务器上全新安装一套相同版本的Harbor，恢复数据库和镜像数据目录，验证关键镜像能否正常拉取。这一步的成本不高，但能在真正发生灾难时保住整个交付链路。

4.5 升级避坑指南

Harbor的升级是日常维护里容易翻车的操作。很多团队一升级就遇到核心服务起不来的问题。我总结出几条经验：

升级前至少先备份数据库和镜像数据目录。Harbor没有自动回滚机制，一旦中途失败，文件不好恢复的话，整个平台数据就冻住了。

检查升级跨度。Harbor官方支持从相邻大版本直接升级，但不支持跨越两个大版本。比如从2.8升到2.11，需要先升到2.9或2.10，再继续升到2.11。跳版本升级，数据库迁移脚本会直接报错。

升级路径上的另一个坑是prepare阶段。每次升级后都要重新运行prepare来重新生成配置：

sudo ./upgrade.sh

升级脚本运行后会重新编排容器，这个阶段不要中断，也不要另行手动重启容器。我见过有人看到某个容器状态异常，着急手动启动，结果破坏了编排顺序，整个配置错乱。升级是一个完整的事务操作，尽量给它一个完整的维护窗口。

5. 把Harbor嵌入交付链路：从仓库到制品中心

5.1 与CI/CD流水线的深度集成

Harbor配置完成度和生产可用之间，还差一个与CI/CD流水线的集成。这套集成做多了以后，我对它的定位有了一个更准确的认识——Harbor不只是存镜像的仓库，它是整个制品管理和发布策略的中枢。

在CI流水线里，构建完毕后执行docker push到对应项目下，这是基础用法。进一步的做法是利用Harbor的Webhook机制，配置“镜像推送成功”事件，把通知发送到IM群或触发下一阶段任务。比如测试环境镜像推送成功，Webhook自动触发自动化测试环境的更新。这样开发的提交链路就被完整串起来。

生产环境发布流程可以这样演进：开发推送到order-dev项目，测试验证通过后，Harbor复制策略把镜像同步到order-prod项目，生产环境直接从prod项目拉取。对于符合上线标准的镜像，再配合内容签名，确保生产机器只会拉取经过签名的镜像。这个模型完整落地后，生产环境拉错版本的概率基本为零。

部署到Kubernetes环境时，也建议把镜像地址固定指向Harbor的域名。后续换仓库或迁移时，只需改一套地址即可，不用进入每个YAML文件逐条修改，这为基础设施的平滑演进留了余地。

5.2 日常运营管理建议

Harbor上线后，日常运营管理需要一个明确的制度。项目创建必须走审批流程，避免开发者随意建项目导致体系混乱。镜像tag规范要制度化，推荐采用业务标识-版本号-构建序号的格式，比如order-api-1.4.2-b123，这样一眼就能定位版本和构建记录，排查问题时间能缩短不少。

定期巡检建议重点关注：镜像总存储量是否逼近配额线、漏洞扫描任务最近是否产生高危告警、复制任务最近24小时的失败率、垃圾回收是否正常完成。这些巡检项完全可以脚本化，定时把Harbor的API数据拉出来，异常就告警。

最后一条心得要给新装用户：Harbor的控制台功能按钮非常多，但不要为了“全功能”一口气全部打开。比如镜像签名，团队没有Notation工具链就强制开启，只会让整套流程卡壳。合理路径是先跑通基本推拉和项目隔离，再逐步开启扫描、复制、配额，最后根据团队成熟度开签名和自动清理策略。渐进式落地，比一次性堆满功能要稳得多。

我个人在实际操作中的体会是，Harbor的价值曲线在团队规模过二十人后会陡峭上升。前期单独管理还能靠拷贝，到了几十人的协作规模，没有统一镜像中心就会开始出现拉错版本、权限混乱、重复存储等多种问题。把全功能Harbor稳定跑起来，相当于给整个容器化交付体系打了一个扎实可靠的地基。

最后再分享一个小技巧：每次Harbor版本升级前，单独记录一次镜像总量、项目数和复制任务数，升级后做对比，能快速验证升级是否正常完成。镜像总数和项目数变少基本等于数据迁移失败，这些数字是平台健康度的晴雨表，比任何监控告警都直观。