简介本资源为 Harbor 最新 v2.13.1 的 ARM64 架构离线安装包面向在 ARM64 服务器或 Kubernetes 集群上部署私有镜像仓库的运维与开发人员可解决国产化平台、信创环境及边缘节点无法直接拉取官方 x86 镜像的部署难题。压缩包共 6 个文件以 sh 安装脚本、gz 镜像归档、prepare 预处理程序、tmpl 配置模板及 license 授权文件为主整体约 679.05MB离线包内已内置核心镜像无需联网即可完成安装。目前已有 528 人学习下载适合具备一定 Docker 与容器编排基础的中高级用户参考。借助该包可快速搭建 Harbor 私有仓库完成镜像存储、权限管理与漏洞扫描等能力落地同时便于对照配置模板理解各服务组件的参数含义为后续升级与排错提供依据。1. Harbor v2.13.1 ARM64 离线安装包为什么值得你花一个下午搞定如果你手里有一台 ARM64 架构的服务器——鲲鹏、飞腾、Ampere 或者树莓派集群——又想在内网里跑一套完整的容器镜像仓库那你大概率绕不开 Harbor。而 Harbor v2.13.1 的 ARM64 离线安装包解决的就是一个很具体的场景没有外网、没有 x86 机器、不想从源码编译直接解压就能把仓库跑起来。这件事的价值在于很多团队的 CI/CD 流水线卡在“镜像没地方存”这一步尤其是信创环境或者边缘机房网络隔离是硬性要求。离线安装包把 Harbor 的核心组件、依赖镜像、数据库初始化脚本全部打包好了你只需要一台 ARM64 机器、一个 Docker 和 Docker Compose剩下的就是改配置、执行安装脚本。适合谁适合运维工程师、平台搭建者以及那些被“内网无法拉取镜像”折磨过的后端开发。接下来我会把整个流程拆开从包结构到参数调优再到我踩过的坑一步步讲清楚。2. 离线包结构拆解与 ARM64 环境预检拿到一个 Harbor 离线安装包别急着解压就跑。先搞清楚里面有什么再确认你的机器能不能扛住。这一章解决的是“装之前心里有数”的问题。2.1 离线包里到底装了哪些东西Harbor 的离线安装包本质上是一个自包含的压缩包解压后你会看到几个关键目录和文件。以 v2.13.1 的 ARM64 版本为例典型结构是这样的harbor/ ├── harbor.yml.tmpl # 配置文件模板需要复制成 harbor.yml ├── install.sh # 主安装脚本 ├── prepare # 预处理脚本负责加载镜像和准备环境 ├── common.sh # 公共函数库install.sh 会调用 ├── docker-compose.yml # 容器编排定义一般不需要手动改 └── harbor.v2.13.1.tar.gz # 所有组件镜像的离线包这是核心那个harbor.v2.13.1.tar.gz是重中之重里面打包了 Harbor 运行所需的全部 Docker 镜像包括 core、portal、registry、postgresql、redis、trivy 等。安装时prepare脚本会把这些镜像docker load到本地然后docker-compose根据docker-compose.yml启动服务。注意不同来源的离线包可能把镜像包放在images/子目录下或者直接内嵌在prepare脚本的加载逻辑里。解压后先ls -lh看一眼文件大小镜像包通常有几个 GB如果只有几百 KB那大概率是空壳。2.2 ARM64 环境预检别等装到一半才发现缺东西ARM64 和 x64 在 Harbor 安装上的最大区别不是 Harbor 本身而是底层依赖的镜像架构必须匹配。如果你在 ARM64 机器上误用了 x64 的离线包docker load能成功但docker-compose up时会报exec format error因为镜像里的二进制是 x86 指令集。预检清单如下检查项命令期望结果CPU 架构uname -maarch64或arm64Docker 版本docker version --format {{.Server.Version}}20.10 以上Docker Composedocker compose versionv2 以上内存free -h建议 4GB 以上磁盘df -h /data至少 40GB 可用端口占用ss -tlnp | grep -E 80|443|5432|6379无输出内存和磁盘这两项经常被忽略。Harbor 的 Trivy 扫描组件在 ARM64 上内存占用比 x64 略高2GB 内存的机器跑起来会频繁 OOM。磁盘方面镜像存储目录默认在/data如果你把 Harbor 装到系统盘后期镜像多了容易把根分区撑爆。# 快速检查内核是否支持 overlay2 存储驱动 docker info | grep -i storage driver # 期望输出Storage Driver: overlay2如果存储驱动是vfs性能会差很多建议先调整 Docker 配置。ARM64 平台上 overlay2 的支持已经比较成熟主流发行版的内核都能满足。3. 从零跑通 Harbor v2.13.1 ARM64 离线安装这一章是核心操作部分。我会按实际执行顺序把每一步的命令、参数含义和验证方法都写出来。你照着做大概率能一次跑通。3.1 解压与配置文件的最小改动先把离线包传到目标机器上然后解压。假设包名是harbor-offline-installer-v2.13.1-arm64.tar.gz# 创建安装目录并解压 mkdir -p /opt/harbor tar -zxvf harbor-offline-installer-v2.13.1-arm64.tar.gz -C /opt/harbor cd /opt/harbor/harbor # 复制配置模板 cp harbor.yml.tmpl harbor.yml接下来编辑harbor.yml这是整个安装过程中唯一需要你手动改的文件。最小改动集只有三处# harbor.yml 关键片段 hostname: harbor.internal.example.com # 改成你的实际域名或 IP http: port: 80 # 如果 80 被占用改成其他端口 harbor_admin_password: Harbor12345 # 首次登录密码装完后可以改 data_volume: /data # 镜像和数据库的存储路径 # 如果不需要 HTTPS把 https 整段注释掉 # https: # port: 443 # certificate: /your/certificate/path # private_key: /your/private/key/pathhostname这一项很关键。如果你用 IP 访问就填 IP如果用域名确保内网 DNS 能解析。填错了会导致 portal 页面能打开但镜像推拉失败因为 Harbor 的 token 服务会校验 hostname。data_volume建议指向独立的数据盘。我见过不少案例是装完后镜像越堆越多最后把/撑满Docker 和 Harbor 一起挂掉。3.2 执行安装脚本与镜像加载过程配置文件改好后执行安装脚本# 赋予执行权限并运行 chmod x install.sh prepare common.sh ./install.sh这个脚本会依次做几件事调用prepare加载镜像、生成docker-compose.yml的最终版本、启动容器。加载镜像的过程在 ARM64 上可能比较慢因为镜像包大解压和docker load都是 IO 密集型操作。如果卡在Loading images超过十分钟先别急着 CtrlC用另一个终端看看docker images是不是在陆续出现。# 另开终端观察镜像加载进度 watch -n 2 docker images | grep -c goharbor正常情况下你会看到goharbor/harbor-core、goharbor/harbor-portal、goharbor/registry-photon等镜像逐个出现。全部加载完后脚本会输出[Step 5]: starting Harbor ... Creating network harbor_harbor with the default driver Creating harbor-log ... done Creating harbor-db ... done Creating redis ... done Creating harbor-core ... done ... ✔ ----Harbor has been installed and started successfully.----看到这行字基本就成了。但别急着庆祝先做一轮健康检查。3.3 安装后的验证别只看容器状态docker compose ps显示所有容器Up不代表 Harbor 真的可用。有些容器会反复重启状态在Up和Restarting之间跳。用下面的命令做一轮完整验证# 检查容器健康状态 docker compose ps --format table {{.Name}}\t{{.Status}} # 检查核心 API 是否响应 curl -s http://harbor.internal.example.com/api/v2.0/health | jq . # 检查 portal 页面 curl -s -o /dev/null -w %{http_code} http://harbor.internal.example.com/api/v2.0/health返回的 JSON 里每个组件的status都应该是healthy。如果有unhealthy去看对应容器的日志# 查看 harbor-core 日志 docker compose logs --tail100 harbor-core # 查看 harbor-db 日志 docker compose logs --tail100 harbor-db最常见的失败是harbor-db初始化失败日志里会出现initdb: could not create directory或者permission denied。这通常是因为data_volume目录的权限不对PostgreSQL 容器里的用户没有写权限。# 修复数据目录权限 chmod -R 777 /data # 然后重新执行安装 docker compose down -v ./install.sh注意docker compose down -v会删除数据卷如果之前已经推过镜像数据会丢。生产环境慎用测试环境无所谓。4. ARM64 离线安装的避坑与排查记录这一章记录的是我在 ARM64 环境里实际踩过的坑。有些坑在 x64 上根本不会遇到但 ARM64 的生态差异会让它们冒出来。4.1 镜像架构不匹配导致容器反复重启现象docker compose ps显示容器状态是Restarting日志里报exec /usr/bin/xxx: exec format error。原因离线包里的镜像虽然是 ARM64 的但某些基础镜像层可能混入了 x64 的二进制。这种情况在非官方渠道获取的离线包里比较常见尤其是有人用docker save从 x64 机器上导出后再重新打标签的。解决用docker inspect检查镜像架构docker inspect goharbor/harbor-core:v2.13.1 --format {{.Architecture}} # 期望输出arm64如果输出是amd64说明镜像不对需要重新获取正确的 ARM64 离线包。另一个办法是在 ARM64 机器上开启 QEMU 模拟但这会带来性能损耗不推荐在生产环境用。4.2 端口冲突导致 portal 无法访问现象安装脚本执行成功容器全部Up但浏览器打不开 Harbor 页面curl返回Connection refused。原因harbor.yml里配置的http.port被其他服务占用了。常见的是机器上已经跑了 Nginx 或者 Apache占着 80 端口。解决先确认端口占用情况ss -tlnp | grep :80如果被占用改harbor.yml里的端口然后重新生成配置# 修改 harbor.yml 中的 http.port 为 8080 ./prepare docker compose up -d./prepare会根据新的harbor.yml重新生成docker-compose.yml和配置文件不需要重新加载镜像。4.3 磁盘空间不足导致镜像推送失败现象Harbor 页面能打开登录也正常但docker push时报no space left on device。原因data_volume指向的分区满了。Harbor 的 registry 组件会把镜像层存储在/data/registry下如果这个目录所在分区只有 20GB推几个大镜像就满了。解决把data_volume迁移到更大的分区。操作步骤# 停止 Harbor docker compose down # 迁移数据 mv /data /new-disk/harbor-data # 修改 harbor.yml 中的 data_volume # data_volume: /new-disk/harbor-data # 重新生成配置并启动 ./prepare docker compose up -d迁移前记得用du -sh /data确认实际占用留出至少两倍空间。4.4 ARM64 上 Trivy 扫描组件启动超时现象harbor-trivy容器一直处于starting状态日志里报failed to download vulnerability database。原因Trivy 需要下载漏洞数据库但离线环境没有外网。Harbor 的离线包理论上应该包含 Trivy 的数据库但某些版本里这个数据库是单独下载的。解决如果不需要镜像扫描功能可以在harbor.yml里关掉 Trivytrivy: ignore_unfixed: false skip_update: true # 跳过数据库更新 offline_scan: true # 离线扫描模式如果确实需要扫描得手动把 Trivy 数据库文件放到指定目录。这个操作比较绕建议先确认业务是否真的需要。4.5 升级时旧版本数据卷不兼容现象从 v2.12 升级到 v2.13.1 后Harbor 启动失败日志报数据库迁移错误。原因Harbor 的数据库 schema 在版本间可能有变化直接覆盖安装会导致迁移脚本执行失败。解决升级前先备份数据库和配置文件# 备份数据库 docker exec harbor-db pg_dump -U postgres registry /backup/registry-$(date %Y%m%d).sql # 备份配置文件 cp harbor.yml /backup/harbor.yml.bak然后按照官方升级路径先停旧版本再解压新版本用旧版本的harbor.yml覆盖新版本的模板执行./prepare和docker compose up -d。如果数据库迁移失败用备份恢复后回退到旧版本。5. 让 Harbor ARM64 离线部署更稳的几个进阶习惯装完只是开始真正让这套东西在生产环境跑得住靠的是一些不起眼的习惯。这一章不讲大道理只说几个我反复验证过的具体做法。5.1 用 systemd 托管 Harbor 的启停docker compose up -d启动的容器在机器重启后不会自动恢复。写一个 systemd unit 文件是最省心的办法# /etc/systemd/system/harbor.service [Unit] DescriptionHarbor Container Registry Requiresdocker.service Afterdocker.service [Service] Typeoneshot RemainAfterExityes WorkingDirectory/opt/harbor/harbor ExecStart/usr/bin/docker compose up -d ExecStop/usr/bin/docker compose down TimeoutStartSec300 [Install] WantedBymulti-user.targetsystemctl daemon-reload systemctl enable harbor systemctl start harborTimeoutStartSec300是给 ARM64 机器留足启动时间。我在飞腾机器上见过 Harbor 启动花了将近两分钟默认的 90 秒不够用。5.2 定期清理旧镜像释放空间Harbor 自带垃圾回收功能但默认不会自动执行。可以配一个 cron 任务# 每周日凌晨 2 点执行垃圾回收 0 2 * * 0 docker exec harbor-core /harbor/harbor_core garbage-collect --delete-untaggedtrue--delete-untaggedtrue会删除没有被任何标签引用的镜像层。执行前建议先跑一次不带--delete-untagged的命令看看会删多少心里有数再动手。5.3 验证离线包完整性的一个笨办法离线包在传输过程中可能损坏尤其是几个 GB 的文件。解压前先校验# 计算 sha256 sha256sum harbor-offline-installer-v2.13.1-arm64.tar.gz # 解压后检查镜像包是否完整 tar -tzf harbor.v2.13.1.tar.gz | head -20如果tar -tzf报错说明镜像包损坏重新传一遍。这个步骤花不了两分钟但能避免装到一半发现镜像加载失败的尴尬。我自己现在拿到任何离线包第一件事就是sha256sum加tar -tzf双验证。这个习惯帮我省过好几次重装的时间。希望帮到你。本文还有配套的精品资源点击获取