企业官网建设流程全解析

1. 为什么今天还要亲手部署 Harbor？——它不是“过时的私有仓库”，而是生产级镜像治理的底盘

Harbor 这个词，最近在 DevOps 工具链讨论里出现频率没以前高了，很多人第一反应是：“不就是个带 UI 的 Docker Registry 吗？现在云厂商都内置了，K8s 集群也默认配好了镜像拉取策略，还用得着自己装？”——这话听起来很合理，但实际踩过坑的团队都知道：Harbor 不是“能不能用”的问题，而是“敢不敢把核心镜像生命周期交出去”的问题。我参与过三个不同规模的容器化项目迁移，从某高校实验室的轻量级 AI 模型服务集群，到某金融类 SaaS 公司的多租户微服务中台，再到某制造企业边缘计算节点统一镜像分发系统，每一次选型评审会上，当架构师说出“我们用 Harbor 做镜像签名、漏洞扫描、策略审计和跨中心同步”时，会议室里的沉默往往比争论更说明问题——大家心里都清楚：能跑docker pull的地方很多，但能让你半夜接到告警说“生产环境某镜像被篡改，已自动阻断部署”的，目前只有 Harbor 能稳稳托住。

Harbor 的核心价值，从来不在“存储镜像”这个基础动作上，而在于它把镜像从“二进制文件”升级成了“可治理资产”。它强制你思考：这个镜像谁构建的？构建环境是否干净？有没有嵌入已知 CVE 的基础层？是否通过了组织定义的合规基线（比如禁止 root 用户、必须启用非对称签名）？上线前是否经过 QA 环境的灰度验证？这些不是理想主义的流程设计，而是真实发生过的事故倒逼出来的能力。去年某次客户系统升级失败，根因是运维同学误推了一个本地测试镜像到 prod 仓库，而该镜像依赖一个未打补丁的 OpenSSL 版本；如果当时启用了 Harbor 的项目级推送策略（只允许 CI 流水线账号推送）+ 自动扫描 + 扫描结果阻断机制，整个故障就能卡在镜像入库环节，根本不会走到 K8s 调度那一步。

所以，“Harbor 安装和基本使用”这八个字背后，真正要解决的不是“怎么敲几行命令”，而是如何在一个可控、可审计、可回溯的环境中，建立组织级的镜像信任链起点。它适合三类人：一是正在搭建内部 CI/CD 流水线的 DevOps 工程师，你需要一个确定性的镜像落点；二是负责安全合规的平台负责人，你需要对所有容器运行时组件做统一策略管控；三是刚接触容器生态的开发者，你值得从 Harbor 这个“有界面、有日志、有权限、有扫描”的完整体开始理解“镜像到底意味着什么”。接下来的内容，我会完全基于一线实操经验展开——不讲官网文档里抄来的参数列表，只告诉你哪些配置项我调过十次以上、哪些路径必须提前规划、哪些报错信息背后藏着真正的陷阱，以及为什么某些“看起来很酷”的功能，在真实生产环境里反而要主动关掉。

2. 安装方案深度拆解：为什么坚持用离线包+Docker Compose，而不是 Helm 或一键脚本？

2.1 三种主流安装方式的真实落地成本对比

Harbor 官方提供了三种安装路径：离线安装包（harbor-offline-installer）、在线安装包（harbor-online-installer）和 Helm Chart。很多教程一上来就推荐 Helm，理由是“符合云原生范式”“便于 K8s 集成”。但在我经手的六个 Harbor 部署案例中，超过 80% 的首次部署失败，都源于 Helm 方案在非标准网络环境下的不可控性。举个最典型的例子：某制造企业边缘节点部署，内网完全隔离外网，仅能通过 U 盘传递软件包。他们按 Helm 文档下载了 chart 包，却发现 chart 依赖的bitnami/postgresql和bitnami/redis镜像在离线环境下根本无法拉取——Helm 只管编排，不管镜像来源。最后不得不临时搭建一个本地 registry，手动导入所有依赖镜像，再修改 values.yaml 中的 image.repository 字段，折腾了整整两天。

相比之下，离线安装包（harbor-offline-installer）是唯一能真正实现“U 盘即部署”的方案。它的原理非常朴素：把 Harbor 所有组件（core、registry、portal、clair、notary-server 等）的镜像、配置模板、启动脚本全部打包进一个 tar.gz，解压后执行install.sh即可。整个过程不依赖任何外部网络请求，所有镜像直接从本地加载。我统计过某次部署耗时：从解压完成到docker ps看到所有容器 running，平均耗时 4 分 37 秒（含证书生成），且 100% 可重复。

提示：离线包体积较大（v2.10.0 版本约 1.2GB），但它换来的确定性远超空间成本。如果你的服务器磁盘空间紧张，宁可清理/var/lib/docker的 dangling 镜像，也不要为了省几百 MB 而选择在线安装——后者在弱网或代理配置错误时，极大概率卡在pulling harbor-core:latest...这一步，且错误日志极其模糊。

2.2 为什么放弃 Helm？——四个无法绕开的生产现实

注意：这里说的“放弃 Helm”，特指首次部署和中小规模（<50 个项目）场景。如果你的 Harbor 需要管理 200+ 项目、对接多个 K8s 集群、并要求灰度发布 Harbor 自身版本，那么 Helm 的 GitOps 能力确实有价值。但绝大多数团队，起步阶段用 Helm 就像给自行车装 F1 赛车变速箱——结构复杂度远超实际需求。

2.3 硬件与系统准备：那些文档里没写的“隐形门槛”

官方文档写的是“4C8G 起步”，但这是指“空载 Harbor”的理论值。真实场景下，必须预留额外资源给三个“沉默消耗者”：

1. Clair 扫描器的内存暴增：Clair 在执行全量镜像扫描时，会将 CVE 数据库加载进内存。v2.10.0 版本的 clair-db 镜像启动后常驻内存约 1.2GB，但扫描过程中峰值可达 3.5GB。我曾遇到某次扫描触发宿主机 swap，导致 registry 响应延迟飙升至 12 秒，CI 流水线批量超时。

2. Trivy 替代方案的 CPU 占用：Harbor v2.9+ 默认切换为 Trivy 作为扫描引擎（更轻量），但 Trivy 的并发扫描线程数（trivy.max_concurrent_scan）若设为默认值 5，在扫描含 200+ 层的 Java 应用镜像时，单次扫描 CPU 使用率会长时间维持在 300%+（4 核机器）。建议在harbor.yml中显式设置：

   trivy: max_concurrent_scan: 2 # 保守值，平衡速度与负载 skip_update: false # 生产环境务必设为 false，否则用缓存旧数据库

3. 日志轮转的磁盘吞噬：Harbor 默认日志不压缩、不轮转。某次客户环境运行 3 个月后，/var/log/harbor/core.log达到 18GB，/var/log/harbor/jobservice.log达到 12GB。logrotate配置必须在安装前就位，否则后期清理可能引发服务中断。

因此，我的推荐配置是：

• 最小可行配置：4 核 CPU / 16GB 内存 / 100GB SSD（系统盘）+ 500GB HDD（数据盘，挂载/data）
• 生产推荐配置：8 核 CPU / 32GB 内存 / 200GB NVMe（系统+日志）+ 1TB NVMe（数据盘，LVM 逻辑卷管理）

实操心得：/data目录必须独立挂载！Harbor 的 registry 存储、数据库数据、日志归档全部默认写入此目录。如果和系统盘混用，一旦镜像推送量激增（比如 CI 频繁构建），/dev/sda1很快会100%，导致core容器反复 crash。我见过最惨的一次：某团队把/data挂在了 50GB 的系统盘上，第三天就因空间满，所有docker push返回500 Internal Server Error，而docker ps显示所有容器 healthy——问题藏在core.log里一行failed to save manifest: no space left on device，不查日志根本无从定位。

3. 核心配置与初始化：从harbor.yml到第一个可工作的私有仓库

3.1harbor.yml关键字段详解——不是照抄，而是理解每个开关的业务含义

harbor.yml是 Harbor 的心脏配置文件，但官方文档对很多字段的解释过于技术化。下面是我按生产优先级排序的必调字段，并附上真实场景中的取舍逻辑：

# --- 【必须修改】域名与协议 --- hostname: harbor.example.com # 注意：这不是随便填的！它必须和你后续配置的 TLS 证书 Subject Alternative Name (SAN) 完全一致 # 如果填错，浏览器访问会提示 NET::ERR_CERT_COMMON_NAME_INVALID，且 docker login 会失败 # 我的实践：用通配符证书 *.example.com，这样 hostname 可以灵活设为 harbor-prod / harbor-staging http: port: 80 https: port: 443 certificate: /your/cert/path/harbor.crt private_key: /your/cert/path/harbor.key # 强烈建议：生产环境必须启用 HTTPS！HTTP 模式下 docker login 会明文传输密码 # 即使内网，也要防 ARP 欺骗和中间人。Let's Encrypt 免费证书完全够用，用 acme.sh 一键签发 # --- 【必须修改】存储后端 --- data_volume: /data # 再次强调：独立磁盘！不要用 /home 或 /opt # --- 【关键开关】认证模式 --- auth_mode: db_auth # 可选值：db_auth（内置数据库）、ldap_auth、oidc、uaa # 新手务必从 db_auth 开始！LDAP/OIDC 配置稍有偏差就会导致所有用户无法登录 # 我踩过的坑：某次配置 LDAP 时，`ldap_url` 多写了一个斜杠（ldaps://dc.example.com// ），Harbor 启动时不报错，但登录永远返回 "Invalid credentials" # --- 【安全基石】令牌服务 --- token_service: issuer: harbor-token-service # 此值必须和 nginx 配置中的 `iss` claim 一致，否则 Notary 签名会失败 # 默认值即可，除非你有特殊 JWT 集成需求 # --- 【生产必备】邮件通知 --- email: host: smtp.example.com port: 587 username: "harbor-alert@example.com" password: "your-app-password" # 注意：不是邮箱密码，是 SMTP App Password from: "Harbor Admin <harbor-alert@example.com>" ssl: false insecure: false # 邮件用于：用户注册确认、密码重置、扫描报告、配额超限告警 # 关键技巧：测试邮件功能不要等部署完！在 `install.sh` 执行前，先用 telnet 测试 smtp 端口连通性： # telnet smtp.example.com 587

3.2 初始化安装全流程：每一步背后的意图与验证方法

安装不是“解压+执行”两步走，而是包含五个关键验证节点。我把它拆解为可逐项检查的 checklist：

步骤 1：环境预检

# 检查 Docker 版本（Harbor v2.10 要求 Docker 20.10+） docker --version # 检查 Docker Compose（v2.10 要求 Compose v2.15+） docker compose version # 检查 SELinux 状态（CentOS/RHEL 必须 disabled，否则 registry 容器无法写入 /data） getenforce # 应返回 Disabled # 若为 Enforcing，执行：sudo setenforce 0 && sudo sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config # 检查端口占用（80, 443, 5432, 6379） sudo ss -tuln | grep -E ':80|:443|:5432|:6379' # 若被占用，修改 harbor.yml 中对应端口，或杀掉冲突进程

步骤 2：解压与配置

tar -xzf harbor-offline-installer-v2.10.0.tgz cd harbor # 编辑 harbor.yml，重点修改 hostname, https 证书路径, data_volume, email vim harbor.yml

步骤 3：执行安装（带详细日志）

# 关键：加 -l 参数输出详细日志，便于排查 sudo ./install.sh -l # 成功标志（不是看到 "finished" 就完事）： # 1. 控制台最后五行必须包含： # [Step 4]: starting Harbor ... # Creating network "harbor_harbor" with the default driver # Creating harbor-log ... done # Creating harbor-db ... done # Creating registry ... done # 2. `docker ps -a` 显示 8 个容器（harbor-log, harbor-db, registry, redis, harbor-trivy, harbor-portal, harbor-core, harbor-jobservice），状态均为 Up

步骤 4：服务健康验证

# 检查各组件日志是否有 fatal 错误 sudo tail -n 20 /var/log/harbor/core.log | grep -i "fatal\|error\|panic" sudo tail -n 20 /var/log/harbor/registry.log | grep -i "error" # 验证 API 可达性（无需登录） curl -I https://harbor.example.com/api/v2.0/systeminfo # 应返回 HTTP/2 200，且 header 包含 X-Harbor-Version # 验证 Web UI 可访问（浏览器打开 https://harbor.example.com） # 首次访问会跳转到登录页，用户名 admin，密码是 harbor.yml 中的 harbor_admin_password

步骤 5：首个镜像推送实战

# 1. 登录（注意：必须用 https，且 hostname 必须和证书匹配） docker login https://harbor.example.com # 2. 拉取一个测试镜像并重打标签 docker pull hello-world docker tag hello-world harbor.example.com/library/hello-world:v1.0 # 3. 推送（关键验证点：registry 是否正常接收） docker push harbor.example.com/library/hello-world:v1.0 # 4. 验证：登录 Web UI -> 项目 library -> 镜像列表，应看到 hello-world:v1.0 # 同时检查 /data/registry/docker/registry/v2/repositories/library/_manifests/tags/v1.0 下应有 sha256 文件

实操心得：docker push失败的 90% 原因是证书问题。常见错误：

• x509: certificate signed by unknown authority：客户端 Docker daemon 未信任你的 CA 证书。解决：将harbor.crt复制到/etc/docker/certs.d/harbor.example.com:443/ca.crt，重启 docker。
• unauthorized: authentication required：harbor.yml中auth_mode配置错误，或admin密码输错。注意：Web UI 登录密码和docker login密码是同一个。
• denied: requested access to the resource is denied：项目library的推送权限未开放。默认library项目是公开的，但需确认项目设置中 “Public” 开关为 ON。

4. 基本使用进阶：从“能用”到“用好”的四个关键能力

4.1 项目（Project）管理：不只是建个文件夹，而是定义治理边界

Harbor 的“项目”概念，远比 Docker Hub 的“namespace”深刻。它是一个策略执行单元，所有安全、合规、计费相关的规则，都绑定在项目级别。新手常犯的错误是：建一堆项目却不用策略，或者把所有镜像扔进library项目——这等于把银行金库的钥匙交给所有保安。

项目创建后的必做三件事：

1. 设置访问级别（Public vs Private）

   • Public：任何已登录用户都能pull，适合基础镜像（如ubuntu:22.04,nginx:alpine）
   • Private：必须被明确授权才能pull，适合业务应用镜像。强烈建议：新项目默认设为 Private。我在某次安全审计中发现，一个标记为dev-test的 Private 项目，因管理员误操作点成了 Public，导致内部开发框架的构建脚本被外部爬虫抓取，暴露了敏感的 Maven 仓库地址。

2. 配置机器人账号（Robot Account）
   机器人账号是 CI/CD 流水线的“工作身份证”。它和用户账号的核心区别在于：

   • 有独立的 token（而非密码），可随时禁用而不影响人工账号
   • 可精确控制权限（如只允许pull某项目，或只允许push到ci-builds项目）
   • Token 支持设置过期时间（建议 90 天）
     创建路径：Web UI → 项目 →library→Robot Accounts→+ New Robot Account

   实操技巧：为 Jenkins 流水线创建机器人账号时，权限勾选Pull和Push，但不要勾选Admin。曾经有团队给 Jenkins 账号开了 Admin 权限，结果一个误操作脚本执行了DELETE /api/v2.0/projects/1，整个项目被清空。

3. 启用内容信任（Content Trust）
   这是 Harbor 最被低估的安全能力。开启后，项目内所有镜像必须经过 Notary 签名才能pull。配置路径：项目 →Configuration→Content Trust→Enable content trust。
   效果：当用户执行docker pull harbor.example.com/library/nginx:1.21时，如果该镜像未签名，命令会失败并提示no trust data available。

   注意：启用前必须确保所有 CI 流水线已集成notary客户端，并在docker build后执行notary sign。否则会立刻阻断所有部署。建议先在测试项目启用，验证流程后再推广。

4.2 镜像扫描：不止是“扫出 CVE”，而是建立可信基线

Harbor 集成的 Trivy 扫描，默认只做“发现”，不做“决策”。要让它真正发挥作用，必须配置扫描策略（Scan All）和阻断策略（Policy-based Blocking）。

扫描策略配置：

• Web UI →Administration→Configuration→Vulnerability Prevention
• 勾选Enable vulnerability prevention
• 设置Severity level to block：建议从High开始（Critical 会过于严格，Low 无实际意义）
• 关键：Block images that fail scanning必须勾选，否则只是“看热闹”

效果验证：
推送一个已知含高危漏洞的镜像（如alpine:3.12，含 CVE-2021-36159）：

docker pull alpine:3.12 docker tag alpine:3.12 harbor.example.com/library/alpine-bad:3.12 docker push harbor.example.com/library/alpine-bad:3.12

预期结果：推送成功，但 Web UI 中该镜像状态显示Blocked，且docker pull会返回Error response from daemon: unauthorized: authentication required（因为策略拒绝未通过扫描的镜像被拉取）。

实操心得：扫描不是越严越好。某次客户将阻断级别设为Critical，结果所有基于golang:1.19构建的镜像都被拦住（因基础层含一个未修复的 Critical CVE），导致整个研发流程停摆。我的建议是：

• 开发环境：High级别阻断 + 扫描报告邮件通知
• 预发环境：Critical级别阻断 + 扫描失败自动触发 Jenkins 构建失败
• 生产环境：Critical阻断 + 扫描报告必须由安全团队人工复核签字

4.3 用户与权限体系：用好“项目成员”比搞懂 LDAP 更重要

Harbor 的权限模型是三层结构：系统管理员 → 项目管理员 → 项目成员。90% 的权限问题，都源于混淆了“项目管理员”和“系统管理员”。

• 系统管理员（System Admin）：全局最高权限，可管理所有项目、用户、系统配置。账号名固定为admin，密码在harbor.yml中设置。
• 项目管理员（Project Admin）：仅对该特定项目有完全控制权（包括删除项目、管理成员、配置策略）。这是最应该被广泛授予的角色。
• 项目成员（Developer / Guest）：Developer可push/pull，Guest只可pull。

权限分配黄金法则：

1. 永远不要给普通开发者System Admin权限（哪怕只是临时）
2. 每个项目至少配置 2 名Project Admin（防止单点故障）
3. Guest角色应只授予需要pull基础镜像的团队（如前端组只需要nginx镜像）

典型场景配置：

• 场景：某微服务团队 A 开发user-service，需要push到prod-user项目，pullbase-java项目
• 正确做法：
  • 将 A 团队负责人设为prod-user项目的Project Admin
  • 将 A 团队所有成员设为prod-user项目的Developer
  • 将 A 团队所有成员设为base-java项目的Guest
• 错误做法：把 A 团队所有成员都设为System Admin（过度授权）或都设为Guest（无法push）

4.4 日志与审计：当出问题时，你靠什么还原真相？

Harbor 的审计日志（/var/log/harbor/audit.log）是事故复盘的唯一依据。但默认配置下，它只记录login、logout、push、pull四类事件，且不记录 IP 地址和 User-Agent。

必须修改的审计配置（harbor.yml）：

audit_log: location: /var/log/harbor/audit.log max_size: 50 # 单个日志文件最大 50MB max_backup: 10 # 保留 10 个备份文件 # 关键：启用详细审计 level: debug # 默认 info，debug 级别才记录完整请求头

审计日志关键字段解读：

2023-10-05T08:23:41Z [INFO] [/server/middleware/log/log.go:30]: {"client_ip":"10.10.20.15","user":"admin","req_id":"2b3e8f1a-9c7d-4e2a-8b1f-0a1b2c3d4e5f","req_method":"POST","req_path":"/api/v2.0/projects","req_query":"","req_headers":{"User-Agent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36","Authorization":"Bearer eyJhb..."},"resp_status":"201","resp_bytes":"124","resp_duration":"123ms"}

• client_ip：发起请求的真实 IP（非代理 IP，需确保 nginx 配置了X-Real-IP透传）
• user：操作用户名
• req_method+req_path：具体操作（如POST /api/v2.0/projects= 创建项目）
• req_headers.Authorization：JWT token 前缀，可用于关联用户会话

实操技巧：用awk快速分析审计日志：

• 查找某用户所有操作：awk '/"user":"alice"/ {print}' /var/log/harbor/audit.log
• 统计每日push次数：awk '$5 ~ /"POST.*\/api\/v2\.0\/repositories.*\/artifacts"/ {count++} END {print count}' /var/log/harbor/audit.log
• 发现异常高频请求（疑似暴力破解）：awk '{print $3}' /var/log/harbor/audit.log | sort | uniq -c | sort -nr | head -20

5. 常见问题与硬核排查：那些让老手也皱眉的“幽灵错误”

5.1 “502 Bad Gateway” —— 表面是 Nginx，根因在 Core 服务

现象：浏览器访问https://harbor.example.com显示502 Bad Gateway，但docker ps显示所有容器Up。

排查路径：

1. 检查harbor-portal容器日志：docker logs harbor-portal | tail -20
   • 若出现connect() failed (111: Connection refused) while connecting to upstream，说明 portal 无法连接 core
2. 检查harbor-core容器日志：docker logs harbor-core | tail -20
   • 最常见原因：core.log中出现failed to initialize database: pq: password authentication failed for user "harbor"
   • 根因：harbor-db容器重启后，core容器未正确读取新密码。Harbor 的密码同步机制有时失效。
   • 解决：进入harbor-db容器，重置密码：

     docker exec -it harbor-db psql -U postgres \password harbor # 输入新密码（需和 harbor.yml 中的 database.password 一致） \q

   • 然后重启 core：docker restart harbor-core

注意：不要直接docker restart harbor！这会重启所有容器，可能导致 registry 数据不一致。精准重启harbor-core即可。

5.2 “no basic auth credentials” —— Docker 客户端的信任链断裂

现象：docker login https://harbor.example.com成功，但docker push时返回no basic auth credentials。

根因分析：
Docker 客户端的~/.docker/config.json中，auths字段的 key 必须和docker push的 registry 域名完全一致。例如：

• 如果harbor.yml中hostname: harbor.example.com，则 config.json 中必须是"harbor.example.com": {...}
• 如果你docker push时用了https://harbor.example.com:443，但 config.json 中是"harbor.example.com"，就会失败！

解决方案：

1. 检查 config.json：cat ~/.docker/config.json | jq '.auths'
2. 确保 key 是纯域名（无端口、无协议）："harbor.example.com"
3. 如果错误，手动编辑 config.json，或重新docker login harbor.example.com（注意：不要带https://）

5.3 扫描一直 “Pending” —— Trivy 的静默超时

现象：镜像上传后，Web UI 中扫描状态长期显示Pending，harbor-trivy容器日志无报错。

真相：Trivy 默认扫描超时时间为 60 分钟，但某些超大镜像（如含完整 CUDA 工具链的nvidia/cuda:11.8.0-devel-ubuntu22.04）扫描时间可能超过 70 分钟，Trivy 进程会被 Harbor 主动 kill，但状态未更新。

验证：

# 查看 trivy 容器日志最后 50 行 docker logs harbor-trivy | tail -50 # 若看到 "context deadline exceeded"，即超时

解决：修改harbor.yml中的trivy配置：

trivy: timeout: 120m # 扫描超时设为 120 分钟 ignore_unfixed: false skip_update: false insecure: false

然后执行：

sudo ./prepare # 重新生成配置 sudo docker-compose down sudo docker-compose up -d

5.4 项目删除后镜像仍存在 —— Registry 的垃圾回收机制

现象：在 Web UI 中删除了一个项目，但/data/registry目录下对应的镜像文件夹依然存在，磁盘空间未释放。

原理：Harbor 的“删除项目”只是移除了数据库中的元数据，Registry 存储的 blob 文件仍保留，需手动触发垃圾回收（GC）。

执行 GC：

# 进入 harbor-core 容器 docker exec -it harbor-core /bin/bash # 执行 GC（-m 参数表示只清理未被引用的 blob） ./garbage_collection.sh -m # 退出后，检查磁盘空间 df -h /data

提示：GC 过程会短暂阻塞 registry 服务（通常 < 2 分钟），建议在低峰期执行。可配置定时任务：
0 2 * * 0 /usr/bin/docker exec harbor-core /harbor/garbage_collection.sh -m >> /var/log/harbor/gc.log 2>&1
（每周日凌晨 2 点执行）

6. 性能优化与生产加固：让 Harbor 在高并发下依然呼吸顺畅

6.1 Registry 存储优化：从 ext4 到 XFS 的必要升级

Harbor 的 registry 组件底层使用 Docker Distribution，其性能对文件系统极为敏感。默认的 ext4 文件系统在大量小文件（镜像 layer）场景下，fsync延迟高、inode 分配慢。

实测数据（相同硬件，1000 个 50MB 镜像并发 push）：

迁移到 XFS 的步骤：

1. 备份/data：rsync -av /data /backup/data-$(date +%F)
2. 卸载原分区：umount /data
3. 格式化为 XFS：mkfs.xfs -f -i size=512 /dev/sdb1（-i size=512增加 inode 大小，适应小文件）
4. 挂载并恢复：mount /dev/sdb1 /data && rsync -av /backup/data-xxx/ /data/
5. 重启 Harbor：docker-compose down && docker-compose up -d

注意：XFS 不支持在线 resize，扩容需先卸载。生产环境建议初始分配足够空间（如 2TB），避免频繁维护。

6.2 数据库调优：PostgreSQL 的三个救命参数

Harbor 默认的 PostgreSQL（harbor-db）配置是通用型，面对高并发 API 请求（如 CI 频繁查询镜像列表）极易成为瓶颈。

必须调整的postgresql.conf参数（位于/var/lib/docker/volumes/harbor-db/_data/postgresql.conf）：

# 增加