当自托管栈慢慢变成"十几个服务，各自从镜像仓库拉 Docker 镜像"时，你会撞上一个不起眼却真实的痛点：所有东西都从公共镜像源（Docker Hub 或它的镜像站）拉，一来速度看别人脸色、二来你怕哪天某个镜像下架或被投毒、三来你想把自己打好的镜像也存起来统一管理。Harbor 就是为这类需求服务的：一套开源的、企业级的私有容器镜像仓库，它把"存镜像 + 权限控制 + 漏洞扫描 + 镜像复制"收拢到一套自托管服务里。这篇讲清 Harbor 能解决什么、怎么装、你怎么把 Docker/Kubernetes 接上去、以及漏洞扫描和复制这两个进阶能力怎么用。
一、为什么要私有镜像仓库：Harbor 存在的三个理由
即使只有一个 VPS，自建私有仓库也有实在的价值。其一是稳定与可达：公共仓库在大陆访问常常时断时续或限速，你私有的仓库放在自己的 VPS 上，拉镜像的速度和稳定性都由自己把控。其二是可控与安全：企业/团队内谁可以拉谁可以推，可以精确到项目级权限；镜像是被扫过漏洞还是被打过标签，也能在入口把住。其三是"内容主权"：你精心构建的基础镜像、以及需要".版本"对齐的内部镜像，放进自己仓库就不怕一夜之间从公共源消失。
它和"本地一堆 tar 文件"相对照，最大的提升是"注册中心（registry）"这个抽象：镜像是用标准的 `docker pull/push` 走 HTTP 协议推拉，带版本标签、带清单校验，还能被 Kubernetes 这类编排系统无缝读取。建立起"一个统一、可信、可审计的镜像来源"，是自托管从"手动拷 tar 包"升级到"工程化交付"的一步。
二、最小安装：用官方方式把 Harbor 拉起来
Harbor 以发布一个 docker-compose 风格的安装包为常态，安装分两步：先准备足够的内存和磁盘（建议至少 2-4GB 内存、镜像数据盘要留够），再用官方脚本一键部署。核心是它的 config 文件，你至少要把 hostname 和访问口令改对：
# 下载 Harbor 官方离线安装包并解压后，主要配置在 harbor.yml
hostname: registry.example.com # 对外访问的地址
http:
port: 80
https:
port: 443
certificate: /your/path/tls.crt # 给自己的仓库配证书（或用 Caddy 反代 + 自动证书）
private_key: /your/path/tls.key
harbor_admin_password: 改成一个强口令
# 配置好后执行安装脚本
sudo ./install.sh装完访问 `hostname` 就是一个带 Web UI 的仓库后台，默认管理员是 admin。Http 部署时你若想用标准的 443/自动证书，两个选择：直接在 harbor.yml 里配好证书文件，或者（更省心）用前面讲的 Caddy 之类反代在端口层接管并自动申请证书，Harbor 只监听内部 http。别让仓库 UI 和推送接口裸奔到公网，更别用它的默认弱口令。
三、把 Docker 和 Kubernetes 接上去：登录与命名空间
私有仓库接入的姿势几乎一样：对 Docker 用 `docker login`，对 Kubernetes 需要一个 imagePullSecret。Harbor 用"项目（project）"组织镜像并做权限隔离，用"机器人账号（robot account）"给 CI 指一个受限的凭据。先看 Docker 和 K8s 两个接入示例：
# Docker：登录后就能 push/pull 私有镜像
docker login registry.example.com
docker tag my-app:v1 registry.example.com/library/my-app:v1
docker push registry.example.com/library/my-app:v1
# Kubernetes：把登录凭据做成 imagePullSecret，供 Pod 拉取私有镜像
kubectl create secret docker-registry harbor-pull \
--docker-server=registry.example.com \
--docker-username=admin --docker-password=你的口令
# 在 Pod spec 里加 imagePullSecrets:
# imagePullSecrets: [ { name: harbor-pull } ]
给 K8s 配私有仓库，大多数人的坑是漏掉 `imagePullSecrets` 这一行——API 不会提醒你，Pod 会一直卡在 ImagePullBackOff。另一个建议：给 CI/CD 用"机器人账号"而不是管理员直连，机器人受限在指定项目、还能设有效期，比在脚本里塞管理员口令安全得多。
四、漏洞扫描：把"镜像安不安全"在入口把住
Harbor 最该被用起来的能力之一，是内置的漏洞扫描（它用 Trivy 作为扫描器）。你可以要求"每个推送的镜像都做一次漏洞扫描"，扫描结果会列出每个已知 CVE、对应版本与受影响组件，并可以按严重程度设阻断策略——比如"高危以上的漏洞不允许被拉取到生产"。对自托管来说，这个能力把"我该不该担心这个镜像"从主观猜测变成了可查的清单。
# 手动触发扫描（也可以通过 Harbor 的 Web UI 或策略自动扫描）
# 扫描器引擎默认用 Trivy；
# 也可以配置"扫描前必须先推送"等安全策略。
# 命令行/脚本方式可用 Harbor 的 REST API trigger 扫描
不过要对扫描保持现实预期：Trivy 扫的是"已知漏洞数据库里的条目"，它给的是"这个镜像包含哪些已知 CVE"，不等于"绝对安全"，也不能替代"只拉可信来源的镜像、定期重建镜像"。把它当作入口的一道检查关卡，和前面的反代、防火墙、最小权限一起构成防护，而不是"扫了就当安全"的免死金牌。
五、多机房/多节点：镜像复制（Replication）
如果你有两个 VPS 或在跨地备份镜像，Harbor 的"复制（replication）"是把镜像从一个仓库同步到另一个仓库（甚至可以跨 Harbor、或同步到公共仓库用于分发）的能力。它基于"在源上配置到目标的复制规则"，可以按项目、按标签选择镜像，定期或事件触发同步。对自托管最常见的使用：把关键镜像在另一个机房的实例上留一份，故障切换时本地全局不用去公共源再拉。
# 复制配置要点（在 Harbor Web UI 里建）：
# 1. 目标端点：另一个 Harbor 或仓库的地址 + 凭据
# 2. 选择范围：要复制哪些项目/镜像/标签
# 3. 触发方式：手动 / 定时（cron）/ 事件（推送时立即复制）
用它的时候有几个清醒点：复制的镜像大小和数据吞吐可能不小，跨地复制前想清楚带宽成本；复制是"拉取后写入目标"，源和目标都要能互相访问；复制不代表"灾难恢复整体方案"，它只管镜像，必要的数据库/配置备份还是要另做。把复制当作"让镜像在地理上多一份"的便捷手段，而不是"给所有数据做备份"的替代品。
结语
Harbor 的价值，是把"从公共源拉镜像 + 自己拷 tar 包"升级成"一个统一、可信、可审计的镜像来源"。落地要点：用一个 hostname + 足够内存磁盘装起来，用项目 + 机器人账号管好权限；Docker 用 login、Kubernetes 用 imagePullSecret 接入；把漏洞扫描开起来在入口把关；需要时用复制在跨节点/机房留镜像副本。记得它的边界——它管"镜像"，不管"应用数据备份"，也扫不出"完全安全"。当你的自托管服务多到"该有个家"时，Harbor 就是你给这些容器镜像安排的、可以住得整齐又巡查到位的那个家。
