ARM架构下Harbor 2.4.0离线安装全流程与避坑指南

简介：面向ARM架构服务器运维及容器开发人员，提供Harbor v2.4.0离线安装包，解决内网或无外网环境下镜像仓库部署难的问题。整包共6个文件，压缩后约402MB，包含两个Shell脚本（一键安装入口及公共函数）、一份Harbor镜像tar.gz包、一份harbor.yml配置模板、prepare初始化脚本以及开源协议文件，各文件职责清晰，配合使用即可完成安装。需要预先准备Docker与Docker Compose环境，执行install.sh即可自动完成镜像导入、配置生成与服务启动，适合快速搭建私有镜像仓库。已有1576人学习使用，对于需要快速落地ARM架构Harbor服务的团队，可直接基于该包进行二次配置，减少手动编排与容器导入的繁琐步骤。

1. Harbor 2.4.0 离线安装：ARM 架构下最容易翻车的一套镜像仓库

接到一个在某公司内部 ARM 服务器上部署镜像仓库的活，原以为和 x86 一样下载解压、改个 yml 就能跑起来，结果先后栽在离线包缺少组件镜像、docker-compose 版本不兼容这些环节上。最关键的是，2.4.0 这个版本恰好处于 Harbor 从较旧组件结构向新架构过渡的阶段，ARM 架构下的兼容问题比想象中多。配置不当会出现服务起不来、登录返回 502、甚至磁盘被日志塞满等连锁问题，比较典型的就是 Install 脚本在离线环境下默认行为不生效，导致第一步就失败。

如果你正在给 ARM 服务器搭 Harbor，或者准备做离线部署，这篇笔记直接解决两个核心问题：装哪个版本、参数如何配置才能一次跑通。本文围绕 harbor-v2.4.0 离线安装（arm 架构）展开，覆盖从环境准备、离线包组织、harbor.yml 调整、镜像导入到验证的全过程，也会把离线环境特有的坑逐个列出来。

2. 装前准备：版本选择与依赖环境

2.1 为什么选 Harbor 2.4.0，而非更高版本

做离线安装时版本选择比在线更难反悔，因为一旦发现版本不合适需要重下离线包，可能又要浪费数小时下载时间。在我实际对比过多个版本后，选择 2.4.0 主要基于三个理由。

第一，2.4.0 是 2022 年的稳定版本，支持 arm64（aarch64），官方发布页面对应架构的离线安装包齐全。2.5.0 开始对 PostgreSQL 和 Redis 组件做了一定升级，配置复杂度有所上升。第二，Harbor 2.4.0 的镜像仓库功能处于一个比较平衡的位置，既有完整的 RBAC 权限控制、镜像复制、漏洞扫描等能力，又不像 2.6.0 之后的版本那样对 Kubernetes 集成有更重的默认依赖。

第三，ARM 环境下对镜像组件的兼容性要求较高。2.4.0 版本的prepare工具在生成配置时对 ARM 架构的适配已经比较完善，而更早的 2.1.x 版本在部分 ARM 环境上会出现exec format error，因为某些组件镜像没有提供 arm64 版本。如果项目要求必须使用 2.x 版本且要尽量避免镜像格式问题，2.4.0 几乎是 ARM 离线安装的最低安全线。

需要提醒的是，如果你所在的团队对漏洞扫描有强合规需求，2.4.0 的 Trivy 扫描器需要联网更新漏洞数据库，离线环境下需要在构建时额外准备数据库数据。这一点在后面的离线包准备环节会专门说明。

2.2 硬件与操作系统要求

Harbor 2.4.0 官方对硬件的要求比较低调，但从实际运维经验看，低于 2 核 4GB 内存的机器跑起来会比较吃力。特别是在执行镜像推送和页面访问并发较高时，内存容易飙到 3GB 以上。建议 ARM 环境至少准备 2 核 4GB，如果计划支撑较多开发人员日常推送，4 核 8GB 更稳妥。

操作系统层面要注意内核版本。Harbor 本身依赖 Docker 服务，内核过低会导致 Docker 无法正常工作。个人建议使用 4.18 以上内核，对应主流发行版基本不在话下。

磁盘方面，/data目录专门用于存放 Harbor 镜像数据和数据库文件，注意预留足够空间。我曾见过因为/data所在分区只有 20GB，结果推送几个大镜像后导致 Harbor 数据库无法写入而崩溃的情况。规划磁盘时将数据和系统盘分离，能降低后续运维难度。

以下是我在部署前整理的环境对照表，供你按图索骥。

2.3 Docker 与 Docker Compose 的版本选择

离线安装中 Docker 版本不能随便选，因为 Harbor 安装脚本会调用docker-compose和 Docker API。如果你在线环境下安装了 Docker 24.x，又在离线环境装了 Docker 19.03，行为的差异会导致同一个 install.sh 脚本执行结果就完全不同。

ARM 架构下我推荐 Docker 20.10.x 系列。这个版本对 arm64 的容器支持已经稳定，同时兼容 Harbor 2.4.0 使用的 API 版本。Docker Compose 方面，Harbor 2.4.0 自带的是用 docker-compose 命令调用的方式，因此需要独立安装 Compose 插件或二进制文件。

一个容易踩的坑是：如果系统同时存在 python-docker-compose（旧版）和 docker compose 插件（新版），两个命令的格式有差异，Harbor 安装脚本可能调用了不匹配的命令导致服务起不来。在安装前确认命令docker-compose --version的输出是否正常，并避免同时安装两个版本。

在 ARM 环境安装 Docker 时，如果通过离线 rpm 或 deb 包安装，注意一般情况下需要把docker-ce-cli、containerd.io、docker-ce-rootless-extras等几个包一起装齐。缺少containerd.io会导致 Docker 启动后容器无法运行。

3. 离线包准备：下载、校验与目录规划

3.1 从下载到校验的完整流程

Harbor 2.4.0 的离线安装包在官方 GitHub Releases 页面有对应 arm64 版本，文件名形如harbor-offline-installer-v2.4.0.tgz。但在 ARM 机器上要注意下载对应架构的包，因为通常发布页面的下载列表里同时提供了 amd64 和 arm64 两个版本，不少人在下载时不注意就装错架构，解压部署时发现镜像加载报no matching manifest for linux/arm64才意识到问题。

下载完成后先做完整性校验。找到发布页面提供的校验文件（.asc或.sha256），用证书签名校验的方式确认包是官方发布的。以下是我常用的校验流程。

wget https://github.com/goharbor/harbor/releases/download/v2.4.0/harbor-offline-installer-v2.4.0.tgz wget https://github.com/goharbor/harbor/releases/download/v2.4.0/harbor-offline-installer-v2.4.0.tgz.asc gpg --keyserver hkps://keys.openpgp.org --recv-keys 0CB2D2C1F1A2F1A2 gpg --verify harbor-offline-installer-v2.4.0.tgz.asc harbor-offline-installer-v2.4.0.tgz sha256sum harbor-offline-installer-v2.4.0.tgz

gpg 校验是为了确认离线包在传输过程中没有被篡改。如果你使用的网络环境下载速度较慢，注意 sha256 校验值要和官方页面公布的一致，不一致则果断重新下载。不要把校验步骤跳过，离线包内部包含大量镜像文件，一旦其中一个镜像数据损坏，后续docker load阶段会报错，且排错成本很高。

校验通过后将压缩包解压到部署目录，默认我放在/opt/harbor，保证这个目录所在分区至少有 10GB 剩余空间，因为解压后的镜像文件比较大。

sudo mkdir -p /opt/harbor sudo tar -zxvf harbor-offline-installer-v2.4.0.tgz -C /opt/harbor cd /opt/harbor ls -lh

解压后目录下会有一个harbor.yml.tmpl模板文件、一个install.sh脚本和一个common.sh脚本，以及harbor.v2.4.0.tar.gz镜像压缩包。这个镜像压缩包就是离线安装的关键，后续安装脚本会把其中的镜像逐一加载到本地 Docker 中。

3.2 离线包的内容组织与结构说明

解压后的目录结构需要了解清楚，因为后续操作是在这个目录下完成的。

/opt/harbor/ ├── common.sh # 公共函数库 ├── harbor.v2.4.0.tar.gz # 全部组件镜像压缩包 ├── harbor.yml.tmpl # 配置模板 └── install.sh # 安装入口脚本

harbor.v2.4.0.tar.gz压缩包内包含了 Harbor 的核心服务镜像：registry、core、portal、jobservice、postgresql、redis、nginx等，以及可能的trivy扫描器等。执行安装脚本时，脚本会先把这个 tar 包逐个docker load到本地镜像仓库，然后生成配置并启动容器。

如果你需要自定义某些组件的版本，可以在安装前修改common.sh中的镜像参数。但作为离线安装，通常不建议随意修改组件镜像版本，因为 Harbor 对内部组件版本有强依赖关系。修改镜像版本后可能出现 API 接口不兼容，服务能启动但页面报错的情况，排查起来比在线环境更棘手。

有一个细节：离线包里的harbor.yml.tmpl中https配置默认指向的是yourdomain.com，安装前必须修改成你的实际 IP 或域名，否则prepare阶段会生成错误的证书配置，Nginx 启动失败导致页面无法访问。

3.3 在 ARM 机器上修改 Harbor 配置文件

配置文件的修改是整个部署过程中最核心的步骤。先复制模板，再编辑。

cp harbor.yml.tmpl harbor.yml vim harbor.yml

以下是我在一台 ARM 服务器上使用的最终配置片段，你可以参考修改。

hostname: registry.internal.lan http: port: 80 https: port: 443 certificate: /data/cert/server.crt private_key: /data/cert/server.key harbor_admin_password: Harbor12345 database: password: root123 max_idle_conns: 50 max_open_conns: 100 data_volume: /data/harbor trivy: ignore_unfixed: false skip_update: false offline_scan: true jobservice: max_job_workers: 10 notification: webhook_job_max_retry: 6 log: level: info local: rotate_count: 5 rotate_size: 50M location: /var/log/harbor

hostname建议填一个内部域名，而不是纯 IP。纯 IP 作为 hostname 会让部分浏览器识别方式不同，以及后续复制任务配置中可能出现地址拼接错误。如果确实没有内部 DNS，用 IP 也可以跑通，但要注意部分功能会受影响。

https配置中的证书路径必须对应实际存在的文件，证书生成方式在后文说明。如果暂时不想启用 HTTPS，可以注释掉整个https配置块，只使用 HTTP 端口。

harbor_admin_password是管理员密码，默认值Harbor12345建议改成符合复杂度要求的密码。database.password是 Harbor 内部数据库的密码，这里要注意设置足够复杂，同时需要记录好，后续数据库备份还原时会用到。

data_volume是核心数据存储路径，确保该路径所在磁盘空间充足。trivy.offline_scan设置为true，可以避免离线环境下漏洞扫描器频繁尝试联网，否则每次扫描都会卡在等待漏洞数据更新的状态，比较浪费时间。

3.4 证书生成：内网环境自签证书的完整做法

自签证书在 Harbor 的 HTTPS 配置中几乎是必须的。内网部署通常没有公网证书，使用自签证书的方式生成能被 Docker 客户端和浏览器识别的证书文件。以下是在 ARM 服务器上我用 OpenSSL 生成证书的命令。

sudo mkdir -p /data/cert cd /data/cert openssl genrsa -out server.key 2048 openssl req -new -key server.key -out server.csr -subj "/CN=registry.internal.lan" openssl x509 -req -in server.csr -signkey server.key -days 3650 -out server.crt

genrsa生成 2048 位 RSA 私钥，req创建 CSR 证书签名请求，x509 -req用私钥自签名生成证书。注意CN要和harbor.yml中的hostname保持一致，如果后续使用 IP 访问，需要在生成时加上-ext扩展信息把 IP 写入 SAN。

在harbor.yml中配置了证书路径之后，还需要让 Docker 客户端信任该证书，否则在推送镜像时会报x509: certificate signed by unknown authority错误。对于内网环境，更通用的做法是在客户端机器的 Docker 配置中添加 insecure-registries 条目，而不是将证书复制到每台客户端。

在实际运维中建议两种方式结合：服务端配置正规的自签证书，客户端将证书加入系统信任列表。这样既能满足 HTTPS 加密要求，也能避免每台机器配 insecure-registries 带来的安全隐患。

4. 执行安装：install.sh 到服务启动全过程

4.1 加载离线镜像的关键操作

执行安装脚本前，先确认 Docker 服务正常运行，同时检查镜像是否全部加载成功。离线包的镜像文件在harbor.v2.4.0.tar.gz中，安装脚本会自动加载，但为了便于排查问题，我会预先手动加载一次，这样如果加载失败可以第一时间发现。

sudo docker load -i harbor.v2.4.0.tar.gz

这一步会输出大量Loaded image日志，每一行代表一个组件镜像。完整加载过程取决于磁盘性能和镜像大小，通常在 2 到 5 分钟之间。加载完成后可以通过docker images命令检查关键镜像是否存在。

sudo docker images | grep -E "goharbor|redis|postgres"

如果输出为空或缺少关键镜像，说明 tar 包在传输或解压过程中损坏，此时需要用官方 sha256 值重新校验压缩包，而不是继续执行安装脚本。这是我实际踩过的坑，曾在网络不稳定时下载离线包，结果docker load到一半报错archive/tar: invalid tar header，只能重新下载。

4.2 执行 install.sh 与常见参数解读

镜像加载完成后即可执行安装脚本，脚本会调用docker-compose按序启动所有服务。

cd /opt/harbor sudo ./install.sh

执行过程中脚本会调用prepare工具，基于harbor.yml生成 Nginx、Core、Jobservice 等组件的运行配置，这一步会输出大量日志。正常情况下最终会看到✔ ----Harbor has been installed and started successfully----字样。

如果你希望安装时同时启用漏洞扫描功能，可以添加--with-trivy参数，但离线环境下需要提前准备好漏洞数据库。如果要启用 Chartmuseum 或 Notary 组件，也要用对应的参数，例如--with-chartmuseum。

sudo ./install.sh --with-trivy --with-chartmuseum

--with-trivy启用组件要在离线环境下额外准备数据库文件，否则该组件可能无法正常启动。在纯离线环境里建议先不加参数安装核心服务，等确认核心服务稳定后再考虑扩展组件，减小排查范围。

install 脚本跑完后的容器状态检查是一个必要动作。

sudo docker ps

正常情况下可以看到 Nginx、Core、Portal、Registry、PostgreSQL、Redis 等约 8 到 10 个容器处于 Up 状态。如果某个容器状态为 Restarting 或 Exited，需要立即查看该容器的日志定位问题。日志查看的方式我常用以下命令。

sudo docker logs -f <容器名称>

例如nginx容器启动失败时，日志中通常会有502 Bad Gateway或connect() failed字样，指向 Core 容器网络不通。这类问题多数是harbor.yml中配置的 hostname 或端口与容器内部实际监听的端口不一致导致。

4.3 使用 systemd 管理 Harbor 服务的可选方案

install.sh 默认通过 docker-compose 直接启动容器，这意味着如果你重启了机器，Harbor 服务不会自动恢复。在内网服务器环境中，机器重启后手动执行docker-compose up -d虽然可行，但更稳妥的做法是注册为 systemd 服务。以下是我在 ARM 服务器上用的服务文件。

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

将上述服务文件保存为/etc/systemd/system/harbor.service后执行sudo systemctl daemon-reload和sudo systemctl enable harbor，此后重启机器 Harbor 服务会自动恢复。需要说明的是，使用该方案的前提是 docker-compose 命令路径是/usr/local/bin/docker-compose，如果你的环境不同请相应调整。

这种通过 systemd 托管的方式从此解决了机器重启后 Harbor 服务起不来的问题。我在某次机房断电恢复后就深有体会，没有 systemd 的情况下必须手动登录服务器执行命令，极其被动。

4.4 使用 Nginx 或防火墙开放访问端口

Harbor 默认通过 80 和 443 端口对外提供服务。如果你的服务器本身有防火墙或云安全组，需要放行这两个端口。在 CentOS/RHEL 系列上使用 firewalld 时，命令如下。

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

如果你希望使用自定义端口，例如 8080 映射到 Harbor 的 80 端口，可以修改harbor.yml中的http.port配置项。修改后重新执行prepare和install.sh，所有容器会按新端口重建。

确认端口开放后，在浏览器中访问https://registry.internal.lan，如果证书是自签的，浏览器会提示不安全连接，选择继续访问即可。看到 Harbor 的登录页面即表示服务已经可用。

需要注意的是，如果浏览器访问页面加载了部分静态资源失败，大概率是 Nginx 容器内的缓存或路由配置没有正确生成。此时回到服务器删除运行中的容器，重新执行install.sh可以解决。

5. 避坑指南：ARM 环境部署 Harbor 的常见问题与排查

5.1 容器反复重启：原因多为数据目录权限不足

现象：docker ps看到 PostgreSQL 容器每隔几秒就重启一次，日志中持续报Permission denied或could not write to file。

原因：data_volume指定了/data/harbor，但该目录的属主不是容器内运行的 UID 1000 或 999。Harbor 容器内部以非 root 用户运行，数据目录如果权限过大或属主不对，容器启动时数据库初始化无法写入文件。

解决：给数据目录设置正确的属主和权限。

sudo chown -R 1000:1000 /data/harbor sudo chmod -R 755 /data/harbor

重新执行sudo docker-compose down && sudo ./install.sh后容器状态恢复。以后再碰到数据库类容器反复重启，我会先检查数据目录权限，这是最先要排除的常见问题。

5.2 安装脚本卡住：docker-compose 版本不匹配

现象：执行install.sh到Starting Harbor ...步骤长时间无响应，查看进程发现脚本停在一个 docker-compose 命令上。

原因：Harbor 2.4.0 的common.sh内部调用docker-compose（带连字符）命令。如果系统只安装了docker compose插件（带空格），脚本会提示docker-compose: command not found，或者因为命令行为差异导致容器启动参数错误。

解决：安装独立的 docker-compose 二进制文件，并放在PATH中。ARM 架构下使用以下方式安装。

sudo curl -L "https://github.com/docker/compose/releases/download/v2.12.2/docker-compose-linux-aarch64" -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose docker-compose --version

确认输出类似Docker Compose version v2.12.2后，再执行install.sh。注意不要同时保留docker-compose和docker compose两种命令的旧版本，避免脚本调用到错误的命令。

5.3 推送镜像报 x509 证书错误

现象：在客户端机器上执行docker login registry.internal.lan或docker push时，返回x509: certificate signed by unknown authority。

原因：Harbor 使用了自签证书，而 Docker 客户端默认不信任自签证书。客户端机器没有把自签证书加入系统信任列表，也没有配置insecure-registries。

解决：在客户端机器的/etc/docker/daemon.json中添加以下配置。

{ "insecure-registries": ["registry.internal.lan"] }

修改后重启 Docker 服务：

sudo systemctl restart docker

如果你希望严格使用 HTTPS 且信任自签证书，可以把server.crt复制到客户端机器的/etc/docker/certs.d/registry.internal.lan/目录下，然后重启 Docker。两种方式选一种即可，但从安全性角度我更推荐复制证书的方式，因为在 daemon 里配置了 insecure-registries 后，该地址的所有请求都不加密，存在中间人攻击风险。

5.4 ARM 架构下 Trivy 离线扫描失败

现象：启用--with-trivy安装后进入页面执行漏洞扫描，任务长时间处于pending状态，最终显示failed to scan。

原因：Trivy 组件需要联网下载漏洞数据库。离线环境下数据库下载失败，则扫描任务无法完成。Harbor 2.4.0 的 Trivy 集成在设计上默认从 GitHub 等来源拉取数据。

解决：有两种方式处理。一种是在有网环境下准备好漏洞数据库的压缩包，然后在离线环境中设置环境变量或修改配置指定数据库路径。另一种是直接放弃在线扫描，在harbor.yml中设置trivy.skip_update: true与trivy.offline_scan: true，使用手动导入的数据库执行扫描。

如果数据库数据不完整，扫描结果准确度有限。因此对安全要求较高的环境，建议定期在有网环境更新离线数据库，再传输到 ARM 服务器中。

5.5 安装后页面 502 错误：Nginx 与 Core 容器网络不通

现象：打开 Harbor 页面显示 502 Bad Gateway，docker ps显示 Nginx 容器和 Core 容器都在运行，但 Nginx 日志中频繁出现connect() failed (111: Connection refused)，指向 Core 容器的 8080 端口。

原因：多数时候是harbor.yml的hostname配置不当，或者在离线包自带的prepare生成配置时，使用了残留的旧配置文件，导致 Nginx 反代地址错误。

解决：清理旧的容器和配置，重新执行安装。以下是我在遇到该问题时采用的完整操作。

cd /opt/harbor sudo docker-compose down -v sudo rm -rf /opt/harbor/common/config sudo ./install.sh

清理common/config目录是关键，因为该目录由prepare生成，如果存在旧配置，新的prepare步骤可能会跳过部分文件的重新生成，保留错误的 IP 地址或端口映射。删除后重新生成能保证 Nginx 的 upstream 地址与实际容器 IP 一致。

6. 装完怎么验证：从页面登录到镜像推送全链路测试

6.1 验证服务组件状态

安装完成后第一件事是确认所有容器正常运行。我习惯用以下命令做一个状态快照。

sudo docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

所有容器状态应显示为Up，且Ports列能看到端口映射。特别关注 Nginx 容器的80/tcp和443/tcp是否绑定到宿主机的对应端口。如果端口被占用，状态会显示为Up但端口映射失败，访问也必然有问题。

接下来验证核心 API 是否响应。Harbor 提供一个简单的健康检查接口，通过 curl 访问可以确认服务是否正常。

curl -I http://registry.internal.lan/api/v2.0/ping curl -I https://registry.internal.lan/api/v2.0/ping

HTTP 状态码返回 200 表示 API 正常，401 则通常表示需要认证，属于正常范围内。如果连接被拒绝或超时，说明 Nginx 层可能没有正常工作，需要回到第 5 章的排查方法。

6.2 浏览器访问与管理员登录

浏览器里执行 HTTPS 访问，因为是自签证书，浏览器会显示警告，点击继续访问即可。登录页使用admin账号和你在harbor.yml中配置的harbor_admin_password密码。如果密码输入错误多次，账号会被临时锁定，此时需要到服务器上通过数据库解锁，比较麻烦。

登录成功后可以点击页面右上角的「用户」按钮，尝试创建测试用户，验证数据库读写是否正常。创建用户成功则数据库连接正常。同时可以检查「项目」页面，创建一个新项目，例如test-project，为下一步镜像推送做铺垫。

6.3 在客户端执行 Docker Login 与镜像推送

接下来在客户端机器上验证完整的镜像流转链路。首先通过docker login验证认证配置。

docker login registry.internal.lan -u admin -p Harbor12345

登录成功会输出Login Succeeded。如果失败，检查 daemon.json 中insecure-registries配置或证书信任配置是否生效。

然后拉取一个测试镜像，构建后推送到 Harbor。这里以hello-world为例。

docker pull hello-world:latest docker tag hello-world:latest registry.internal.lan/test-project/hello-world:latest docker push registry.internal.lan/test-project/hello-world:latest

推送过程中docker push会输出各层的上传进度，全部显示Pushed后表示推送成功。在 Harbor 页面的test-project仓库中应该能看到该镜像。

6.4 其他可选的单项验证

如果想让部署的可靠性更有保障，还可以把复制规则、垃圾回收等关键功能各验证一遍。在 Harbor 页面中创建一条复制规则，配置一个远端仓库地址，推送一个镜像到本地仓库，然后手动触发复制。虽然离线环境下远端仓库可能不可用，但至少规则创建和页面交互本身能正常工作。

垃圾回收功能需要小心验证，可以使用测试项目中的临时镜像，执行回收后确认未引用的镜像层被清理。注意不要在正在使用的仓库上随意做垃圾回收，因为它可能删除正在被复制任务引用的镜像层，导致复制失败。

另外，如果要验证机器的重启恢复能力，可以执行sudo reboot，重启后登录服务器，运行docker ps查看容器是否全部自动恢复。如果使用了第 4 章中的 systemd 服务，容器会自动恢复；否则你需要手动执行docker-compose up -d。

从那以后，我在每台新部署的 Harbor 服务器上都会强制走一遍完整测试流程：先看容器状态，再 curl 健康检查，最后从客户端推送镜像。整个过程耗时不到 10 分钟，却能把绝大多数部署遗留问题暴露出来。希望这篇基于 ARM 架构的 Harbor 2.4.0 离线部署笔记能帮你少走几个弯路，争取一次装完就能稳定跑起来。

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