企业官网建设流程全解析

简介：基于麒麟V10与ARM64架构的Harbor v2.4.0离线部署包，面向需要在内网或国产化服务器上搭建镜像仓库的运维与开发工程师，重点解决ARM平台兼容性、离线安装以及与Docker Compose、Kubernetes集成等实际痛点。资源共8个文件，以shell脚本、配置模板、离线镜像压缩包和许可文件为主，覆盖安装初始化、服务参数配置、证书生成与镜像离线分发等完整环节，整体约407MB，解压后目录结构清晰，便于按需取用。目前已有314人学习下载，尤其适合刚接触Harbor或正在推进国产化环境改造的团队。下载后可参照离线安装包与配套脚本，在麒麟V10上完成从环境准备、参数调整、TLS证书生成到Harbor服务启动的完整部署；模板文件亦为后续调整存储、对接Kubernetes提供清晰参照，能有效缩短镜像仓库落地周期。

1. 麒麟V10+ARM64 上部署 Harbor v2.4.0：和 x86 服务器的差别到底在哪

在一台 x86_64 的 Ubuntu 服务器上部署 Harbor v2.4.0，下载离线包、改两行配置、跑 install.sh，基本二十分钟收工。换成麒麟V10 + ARM64 之后，同样一套流程会先给你一个 prepare 执行失败，然后是镜像标签不匹配、容器反复重启、docker push 时连接拒绝，每一步都像在拆盲盒。差别不在于 Harbor 本身，而在于这个国产 Linux 发行版的软件源、内核版本和周边工具链，和 Harbor 官方发布包的默认假设并不一致。这篇笔记按我实际部署走过的路径，把架构确认、离线包准备、harbor.yml 参数、HTTPS 证书、五个高发坑一次讲完，适合要在国产化 ARM 服务器上搭内网镜像仓库的运维和开发，也适合想把已有 x86 仓库迁到 ARM 平台的人先做一轮预期管理。

2. 架构与依赖：ARM64 的 Harbor 组件集和麒麟V10 环境检查

2.1 用 uname 和 docker info 把架构坐实，别信“看起来是 ARM”

很多刚接触国产化机器的同事会直接看 CPU 型号，发现是 Phytium 或者 Kunpeng 就默认“反正是 ARM”。但实际部署前必须确认两件事：内核看到的 CPU 架构，以及 userland 是不是 64 位。麒麟V10 也有 32 位 userland 的版本，如果用户态跑在 armv7l 上，Harbor 官方 aarch64 镜像一个都起不来。

登录机器后先把这三条命令跑一遍：

uname -m cat /etc/os-release docker info | grep -Ei 'architecture|ostype|server version'

• uname -m输出aarch64才是 64 位 ARM；如果输出armv7l，说明当前内核跑在 32 位兼容模式，Harbor 的 arm64 镜像无法直接运行。
• /etc/os-release能看到 Kylin 的版本号，常见的是 V10 SP1、SP2 或 SP3。SP3 的软件源里 docker-ce 版本更新，遇到的兼容问题相对少。
• docker info里Architecture一栏对应 Docker daemon 运行时的架构，这决定了 Docker 会优先匹配哪个平台的镜像。

注意一个细节：即使 uname 返回 aarch64，如果 Docker 是旧版 18.09 或 19.03，拉取多架构镜像时不一定能正确识别 arm64 的 manifest。所以依赖检查要放到 Docker 版本确认之后，不要先急着 tar 解包。

麒麟V10 常见是基于 Ubuntu 的软件生态，但也有 Kylin 自维护的 rpm 系版本。部署前先确认你手里是 deb 系还是 rpm 系，后面所有安装源的写法、证书信任目录都会不一样。我遇到过最典型的情况是：deb 系麒麟用/etc/pki/ca-trust也能工作，但默认只有/etc/ssl/certs路径，二者不能混着配。

2.2 Harbor 2.4.0 的组件镜像与架构匹配逻辑

Harbor v2.4.0 不是一个单体服务，它是一组 docker-compose 编排的容器集合，核心组件包括 nginx、harbor-portal、harbor-core、harbor-jobservice、harbor-registry（就是 Docker Distribution）、harbor-db（PostgreSQL）、redis，以及可选的 trivy、notary、chartmuseum。

判断“这套组件能不能在 ARM64 上跑”，不是看 Harbor 主程序支持不支持，而是看每个镜像的基础层是否也有 arm64 版本。nginx、postgres、redis 这些上游都有官方 aarch64 构建；harbor-core、harbor-jobservice、harbor-registry 这些 Go 和静态编译产物，官方同样发布了 arm64 版本。所以只要拿到正确的镜像标签，整个编排跑起来不存在架构层面的硬障碍。

真正的翻车点通常在镜像导入环节。有人在 x86 机器上先docker save出 tar 包，再传到麒麟 ARM 服务器上docker load，然后 docker images 里确实能看到镜像，但容器一起就报exec format error。这是因为 load 只是解包，Docker 并不会在你 load 时提醒你这个镜像的 platform 与当前机器不符。

建议导入后用下面命令检查每个关键镜像的架构字段：

docker image inspect goharbor/harbor-core:latest \ --format '{{.Architecture}} {{.Os}}'

如果输出是amd64 linux，说明当前这个 tag 指向的是 x86 镜像；想要在麒麟V10+ARM64 上跑，要找到对应arm64的后缀标签重新打 tag，或者从官方源直接拉 arm64 版本。还有一点容易被忽略：镜像的Architecture和实际包含的二进制架构可能不一致，稳妥的办法是直接把镜像跑起来验证，而不是只看 inspect 输出。

2.3 麒麟V10 上 Dockerd、compose 和 openssl 的版本边界

Harbor v2.4.0 官方对 Docker 版本的要求并不激进，但实际部署中我会至少用 Docker 20.10.x。太老的版本在拉取 multi-arch manifest 时选择不到 arm64 平台，或者对 registry API 的兼容处理有问题，表现为镜像能列出来但 push 时 400 错误。

docker-compose 是另一个容易漏的依赖。Harbor 安装脚本在 v2.4 时代默认调docker-compose命令，而麒麟V10 上不少环境只装了 Docker 自带的 compose v2 插件。先确认两个命令都在：

docker-compose version docker compose version

如果只有docker compose而没有docker-compose，可以做一个软链接指向 Compose v2 的二进制，常见位置是/usr/libexec/docker/cli-plugins/docker-compose。软链接只是让旧脚本能找到命令，不需要重装任何东西。

openssl 的版本影响的是后面证书环节。麒麟V10 SP3 上 openssl 3.x 已经比较常见，生成证书时默认签名算法如果太弱，新版 Docker 客户端校验 HTTPS 证书时可能直接拒绝。后文第 4 章的所有 openssl 命令我都显式指定了-sha256，这是避免踩坑的关键，不要偷懒省略。

3. 部署 Harbor v2.4.0 的手把手操作：离线包、harbor.yml 与启动验证

3.1 解压离线包并确认 prepare 工具架构

Harbor 离线包解压之后，里面的prepare是一个独立可执行文件，负责根据 harbor.yml 生成 docker-compose 所需的配置。它本身是编译后的二进制，有架构之分。这一步经常被忽略，导致在 ARM 机器上./prepare直接报 Exec format error，很多人误以为是 Harbor 不支持 ARM。

先做一个快速检查：

mkdir -p /opt/harbor-install tar -xzf harbor-offline-installer-v2.4.0.tgz -C /opt/harbor-install cd /opt/harbor-install/harbor file prepare

file输出里如果包含x86-64，说明这个离线包里的 prepare 是为 x86 编译的，不能直接在你当前机器上执行；输出aarch64则可以继续走官方安装脚本。国内不少镜像源提供的离线包其实是 x86 的，放到 ARM 上跑 install.sh 会因为 prepare 失败而中断。

如果 prepare 是 x86 的，不需要非得在 ARM 机器上重编译，可以用官方 prepare 镜像以容器方式运行。先把离线包里的镜像全部导入：

docker load -i harbor.v2.4.0.tar.gz docker images | grep goharbor/prepare

查看输出的标签，如果只有 amd64 的 prepare 镜像，要么从能访问的仓库拉取 arm64 版本的 prepare 镜像，要么在有 arm64 支持的其他节点上导出镜像再导入。确认 arm64 的 prepare 镜像存在后，重新打一个本地 tag，避免 compose 配置里引用不到：

docker tag goharbor/prepare:v2.4.0-arm64 goharbor/prepare:v2.4.0

然后再手动以容器方式执行 prepare：

docker run --rm \ -v "$PWD":/harbor \ -v /var/run/docker.sock:/var/run/docker.sock \ goharbor/prepare:v2.4.0 prepare

这段命令把当前 Harbor 目录挂载进容器，同时挂载 docker.sock 让 prepare 能读取本地 Docker 环境信息。--rm表示执行完成后删除临时容器，避免留下残留。如果你确认准备环境没问题，也可以跳过容器方式，直接./prepare走官方路径。

3.2 harbor.yml 中必改的 5 个参数

离线包解压后会有一个harbor.yml.tmpl模板，先复制成正式配置再改：

cp harbor.yml.tmpl harbor.yml

用 vim 打开后，五个参数是每次部署必改的：

hostname: 192.168.10.20 http: port: 80 harbor_admin_password: 'Admin@2024' data_volume: /data/harbor

• hostname：建议直接写成 Harbor 所在服务器的内网 IP，而不是机器名。企业内部 DNS 记录未必可靠，客户端 push 镜像时是拿这个 hostname 拼 registry 地址的；写 IP 最直观，也少一层 DNS 故障。
• http.port：如果暂时不配 HTTPS，这里保持 80；后面第 4 章切 HTTPS 时，再开 https 段。
• harbor_admin_password：初始化管理员密码。Harbor 默认要求至少 8 位且包含大小写和数字，弱密码会在安装阶段被直接拒绝。YAML 里如果密码包含#、@等符号，用单引号包住，避免被解析成注释。
• data_volume：所有镜像、数据库、证书都会落到这个目录。强烈建议放到独立数据分区，不要放在根目录/下，否则镜像体积增长后很容易把系统盘塞满。

如果后面想启用漏洞扫描或 Chart 仓库，需要在执行安装脚本时加--with-trivy或--with-chartmuseum。但在 ARM64 麒麟上我一般先不加，特别是 trivy 首次漏洞库下载依赖外部网络，内网环境很容易卡住。先把基础仓库跑通，再加功能不迟。

3.3 用 compose 拉起全部容器：三种启动方式对比

Harbor 启动容器有三种常见方式，顺序上也对应不同的排查阶段：

第一种，官方脚本方式：

./install.sh

install.sh 内部会自动调用 prepare，然后执行 docker-compose up。前提是 prepare 可执行文件能在当前架构上运行。

第二种，容器 prepare 加 compose 方式，适合 prepare 架构不匹配的场景。配置改完后：

docker run --rm \ -v "$PWD":/harbor \ -v /var/run/docker.sock:/var/run/docker.sock \ goharbor/prepare:v2.4.0 prepare docker-compose up -d

容器方式 prepare 生成的配置和官方脚本完全一致，之后再用docker-compose up -d启动。第一次启动会创建 nginx、core、jobservice 等容器，-d参数让它们在后台运行。

第三种，分步排查方式。如果前面两种起不来，就手动拆开执行，把输出全部打出来：

./prepare 2>&1 | tee /tmp/harbor-prepare.log docker-compose config 2>&1 | tee /tmp/harbor-compose-config.log docker-compose up -d 2>&1 | tee /tmp/harbor-up.log

docker-compose config会验证生成的 compose 文件语法是否合法，这步报错通常能直接定位到 harbor.yml 里的字段拼写错误。日志一定要留着，后面排查容器反复重启时会用到。

3.4 启动后的健康检查清单

容器都起来之后，不要急着去看网页。先跑一遍下面的检查：

docker-compose ps curl -k -I http://192.168.10.20/v2/ docker logs harbor-core --tail 200 2>&1 | grep -i error

docker-compose ps应该看到 8 个左右容器处于 Up 状态，端口映射与 harbor.yml 一致。curl /v2/是 Docker Registry API 的根路径，返回 200 或 401 都说明 nginx 和 registry 通了，返回 connection refused 则说明端口未监听或有防火墙。harbor-core的日志里如果连续出现 database 相关错误，直接跳到第 5 章第 3 节排查。

注意：Harbor 的 Web 页面首次访问会加载不少静态资源，如果看到页面出来了但接口 502，大概率是 harbor-core 还在等数据库就绪，等一两分钟再刷新即可。不要一看到 502 就立刻重启容器，给它一个初始化时间。

4. 给 Harbor v2.4.0 配自签名 HTTPS：证书生成、签发与双向信任配置

4.1 openssl 生成 CA 和服务端证书：SAN 扩展不能省

内网仓库用自签名证书很正常，但很多人生成证书省了 SAN 扩展，结果 Docker 客户端始终报 x509 校验失败。新版 Docker 和 Go 客户端在校验证书时只认subjectAltName，不再自动把 CN 当成主机名。所以服务端证书里必须包含 Harbor 的 IP 或域名。

下面是我在麒麟V10 上常用的一组生成命令：

mkdir -p /data/cert && cd /data/cert # 生成 CA 私钥，4096 位，用于签发服务端证书 openssl genrsa -out ca.key 4096 # CA 自签名根证书，有效期给 3650 天，内网自用不用频繁续 openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \ -subj "/C=CN/ST=Beijing/L=Beijing/O=Demo/OU=Infra/CN=Harbor-CA" \ -out ca.crt # 服务端私钥，2048 位足够 openssl genrsa -out server.key 2048 # 生成证书请求，CN 直接写 Harbor 的内网 IP openssl req -new -key server.key \ -subj "/C=CN/ST=Beijing/L=Beijing/O=Demo/OU=Infra/CN=192.168.10.20" \ -out server.csr # 用 SAN 扩展签发服务端证书，IP 和 DNS 按实际 hostname 调整 openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -out server.crt -days 825 -sha256 \ -extfile <(printf "subjectAltName=IP:192.168.10.20,DNS:harbor.local")

这段命令的核心是最后一个extfile参数，它把 SAN 写进证书扩展。IP:192.168.10.20必须和你 harbor.yml 里的 hostname 保持一致；如果 hostname 配的是域名，这里就写DNS:域名。-days 825是故意选一个少于 825 天的有效期，避免部分客户端对超长有效期证书的兼容问题。

生成后用下面命令验证证书里的 SAN 是否真的写进去：

openssl x509 -in server.crt -noout -text | grep -A1 "Subject Alternative Name"

输出里必须能看到IP Address:192.168.10.20。看不到就回到上一步重新签发，这一步不通过，后面 Docker 怎么配证书都没有用。

4.2 改 harbor.yml 启用 https 并重建容器

得到 server.crt 和 server.key 后，回到 Harbor 目录修改 harbor.yml，加入 https 段落：

hostname: 192.168.10.20 http: port: 80 https: port: 443 certificate: /data/cert/server.crt private_key: /data/cert/server.key

certificate和private_key写绝对路径。Harbor 的 prepare 会把这些路径映射到容器内部并挂载，不需要把证书复制到 Harbor 目录里。

接着重新执行 prepare 和容器重建。注意，不是简单的 restart 就能生效，因为 nginx 配置是在 prepare 阶段生成的：

docker-compose down ./prepare docker-compose up -d

down会停止并删除旧容器，但不会删除数据卷，镜像和数据库都还在。prepare 会重新生成 nginx 配置，把 443 端口挂进去。如果 prepare 仍然有架构问题，还是用第 3 章的容器方式执行。

重启后检查端口监听：

ss -lntp | grep -E ':80|:443'

正常应该看到 80 和 443 都有监听。此时浏览器访问https://192.168.10.20，因为证书是自签的，浏览器会提示风险，直接点继续即可。

4.3 让麒麟V10 和 Docker daemon 同时信任新 CA

浏览器能访问只是第一步，更关键的是让 Docker daemon 信任这个 CA，否则 docker login 和 docker push 会一直报证书错误。

麒麟V10 是基于 Debian/Ubuntu 生态的系统，信任根证书用update-ca-trust：

cp /data/cert/ca.crt /etc/pki/ca-trust/source/anchors/harbor-ca.crt update-ca-trust extract

有些最小化安装的麒麟V10 没有/etc/pki/ca-trust目录，需要先创建。如果系统里是update-ca-certificates风格，对应把证书放到/usr/local/share/ca-certificates/再执行 update-ca-certificates。两种方式效果一样，只是路径不同。

Docker daemon 的信任是单独管理的，不能依赖系统证书库。要让 docker 客户端在访问192.168.10.20时信任 Harbor 的 CA，需要把 CA 放到 Docker 的证书目录：

mkdir -p /etc/docker/certs.d/192.168.10.20 cp /data/cert/ca.crt /etc/docker/certs.d/192.168.10.20/ca.crt systemctl restart docker

/etc/docker/certs.d/<hostname>/ca.crt是 Docker daemon 的固定校验路径，目录名必须和 Harbor 的 hostname 完全一致。如果 hostname 是域名，目录就要叫域名。一定要在重启 Docker 之后再做后续 login 和 push 测试，证书是 daemon 启动时加载的，不重启不会生效。

配置完成后验证：

docker login 192.168.10.20 -u admin -p 'Admin@2024'

如果 login 成功，说明证书信任链和 Harbor 的 https 服务都正常。此时再看第五章第 1 条里那类推送失败，通常就不会出现了。

5. 麒麟V10 ARM64 部署 Harbor 的 5 个高发坑：现象、原因与解决办法

5.1 推送失败：dial tcp 连接拒绝背后的协议与端口问题

现象：docker push 192.168.10.20/library/demo:v1报错，日志里出现Get "https://192.168.10.20/v2/": dial tcp 192.168.10.20:443: connect: connection refused。

原因：docker 客户端默认优先走 HTTPS，而当前 Harbor 还只开了 HTTP 80 端口，443 没有监听。还有另一种情况是网卡到 Harbor 之间被防火墙拦了，但防火墙拦通常是 timeout 而不是 connection refused，据此可以区分。

解决：先确认 Harbor 监听端口，执行ss -lntp | grep -E ':80|:443'。如果只有 80，说明协议没对上。在/etc/docker/daemon.json里给这个仓库配置 insecure-registries：

{ "insecure-registries": ["http://192.168.10.20:80"] }

注意这里写了完整的http://和端口，明确告诉 Docker 用 HTTP。只写192.168.10.20在某些版本上仍然会先试 HTTPS。改完systemctl restart docker。如果已按第 4 章配好 HTTPS，则不需要这个配置，直接用证书信任即可。

防火墙场景下，麒麟V10 如果开了 firewalld，开放端口：

firewall-cmd --permanent --add-port=80/tcp --add-port=443/tcp firewall-cmd --reload

5.2 容器起不来或 exec format error：架构错位的典型表现

现象：从离线 tar 包 load 镜像后，执行 docker-compose up，容器一直Restarting，docker logs 里反复出现exec format error。有些场景下，如果在 qemu 或 boot 工具里检测镜像内核段，还会看到类似bad linux arm64 image magic的提示，本质上都是同一个问题：目标二进制或镜像的平台不是 ARM64。

原因：离线包里的镜像是从 x86 机器打包的，或者镜像 tag 选择的是 amd64 版本。Docker load 阶段不校验平台，只有真正 exec 容器进程时才暴露。

解决：回到第 2.2 节，逐个 inspect 关键镜像的 Architecture。如果确认是 amd64，不要试图在 ARM 机器上“硬跑”，老老实实拉 arm64 版本的镜像重新打 tag。对需要多架构发布的场景，在构建阶段就用 buildx 同时出 amd64 和 arm64：

docker buildx build --platform linux/arm64 \ -t 192.168.10.20/library/app:v1 --push .

这句话的意思是让 buildx 以 arm64 平台构建并直接推到 Harbor。用--push会先登录目标仓库，否则需要先docker buildx build --load再手动 push。

5.3 core 容器反复重启：数据库就绪与数据盘性能

现象：Harbor 页面 502，docker-compose ps里 harbor-core 显示 Restarting，查看日志：

docker logs harbor-core --tail 100

里面出现failed to ping database或dial tcp 127.0.0.1:5432 connect: connection refused。

原因：Harbor 容器编排里 postgres 与 core 几乎同时启动，core 在数据库未就绪时连续重试失败。如果数据卷放在 NFS、CephFS 这类网络存储上，postgres 初始化速度会明显变慢，core 更容易判定启动失败。

解决：把 data_volume 放到本地物理盘或本地 RAID 上，这是最根治的办法。如果数据目录必须放在共享存储，至少给 core 容器加一个等待脚本或手动重启：

docker-compose restart harbor-core

重启前先确认docker-compose ps里 harbor-db 已经是 Up 状态，并且docker logs harbor-db里能看到database system is ready to accept connections。数据库没有 ready 就直接重启 core，只会再翻车一次。

5.4 重启后 Harbor 全没了：systemd 与服务自启动

现象：麒麟V10 重启后，docker ps 里一个 Harbor 容器都看不到，80 和 443 端口无监听，需要手动进目录执行 docker-compose up 才能恢复。

原因：Harbor 容器本身没有注册成 systemd 服务。docker daemon 开机启动了，但 docker-compose 不会自动把容器拉起来。如果服务器意外断电，即使容器有 restart 策略，也可能因为 Docker 未启动而没机会恢复。

解决：把 Harbor 包装成 systemd 服务。创建/etc/systemd/system/harbor.service：

[Unit] Description=Harbor Container Service Requires=docker.service After=docker.service [Service] Type=oneshot RemainAfterExit=yes WorkingDirectory=/opt/harbor-install/harbor ExecStart=/usr/bin/docker-compose up -d ExecStop=/usr/bin/docker-compose down [Install] WantedBy=multi-user.target

WorkingDirectory要改成你实际的 Harbor 目录。RemainAfterExit=yes表示 up 命令执行完就算服务成功，不会因为命令退出而把服务标记为失败。这段 unit 的 ExecStart 里用了 docker-compose 的绝对路径，避免 systemd 环境里 PATH 不完整导致找不到命令。

启用并立即验证：

systemctl enable harbor.service systemctl daemon-reload systemctl restart harbor.service systemctl status harbor.service

之后重启机器，Harbor 会自动跟着 docker 一起起来。如果你不想写 systemd，也可以把 docker-compose up 写到 rc.local，但 systemd 的可观测性和排错体验好得多。

5.5 日志和镜像占满磁盘：Harbor 与 Docker 的磁盘清理

现象：某天 docker push 镜像时报no space left on device，Harbor Web 页面也开始报 500。登录服务器一看，df -h显示根分区或 /var/lib/docker 所在分区已满，排队最多的往往不是镜像本身，而是容器日志。

原因：Harbor 组件多，nginx、core、jobservice 都会写日志，默认不限制日志文件大小，运行一两个月单容器日志可能到几十 GB。麒麟V10 系统自身的 journald 日志同样会占用 /var/log，两者叠加很容易把系统盘塞满。

解决：先看占用：

cd /var/lib/docker/containers && du -sh $(ls -t | head -20) | sort -h

再对 Docker daemon 做全局日志上限。修改/etc/docker/daemon.json：

{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }

max-size=10m限制单个日志文件不超过 10MB，max-file=3保留最多 3 个轮转文件。这是一个全局配置，会对之后新建的所有容器生效，旧的容器仍需要重建日志驱动才能应用，所以改完后对 Harbor 执行一次docker-compose up -d重建即可。注意不要在生产数据没备份的情况下直接docker system prune -a --volumes，那会把镜像缓存和历史容器全清掉，虽然是回收空间最快的方法，但“后悔药”是真的没有。

6. 部署只是开始：客户端推送配置与跨仓库镜像同步的两个落地技巧

6.1 在客户端配置证书信任后推送镜像

Harbor 部署完成后，不能只在自己机器上访问，还要让其他内网服务器能推拉镜像。把所有客户端的 Docker 证书配置统一，比每个客户端都配 insecure-registries 更安全，也不要混用。客户端机器上执行：

mkdir -p /etc/docker/certs.d/192.168.10.20 cp /data/cert/ca.crt /etc/docker/certs.d/192.168.10.20/ca.crt systemctl restart docker

注意/data/cert/ca.crt是 Harbor 服务器的 CA 文件，需要先拷贝到当前客户端。没有证书文件时，可以用scp从 Harbor 服务器拉下来，但传输过程中最好校验一下文件内容是否完整。客户端配置完成后的推送流程如下：

docker login 192.168.10.20 -u admin -p 'Admin@2024' docker tag busybox:latest 192.168.10.20/library/busybox:v1 docker push 192.168.10.20/library/busybox:v1

docker tag的格式是仓库地址/项目名/镜像名:标签，项目名必须是 Harbor 里已经存在的项目，否则 push 会被拒绝。默认有一个 library 项目，也可以先在页面上建好项目再推。

6.2 用 Harbor 复制任务在不同 ARM64 仓库间同步镜像

如果在多个 ARM64 节点上还要各自部署一套 Harbor，手动逐个推镜像太原始。Harbor 自带的复制功能可以直接做仓库间同步。在 Harbor 页面进入“系统管理”下的“仓库管理”，新建一个远端目标，填另一套 Harbor 的地址、协议和访问凭证。这个目标不需要对公网开放，内网可达即可，ARM64 仓库之间同步保持架构一致。

随后在“复制管理”里新建规则，关键参数是源资源过滤器、触发方式和覆盖策略。标签过滤写arm64或aarch64可以有效避免把 x86 镜像同步过来；触发方式选“手动”先跑一遍试错，确认无误后改成“定时”或“事件驱动”。

我最开始的习惯是每次部署都手动 push，后来发现一旦镜像数量上百，漏 push 一个 tag 就会导致后续环境回滚困难。现在我会给每套 ARM64 仓库建一条复制规则，把基础镜像从主仓库同步过去。希望这篇笔记能让你在麒麟V10 上部署 Harbor v2.4.0 时少走几趟弯路，也少几个半夜被 push 失败叫醒的晚上。

本文还有配套的精品资源，点击获取