简介:本资源为 Harbor 最新 v2.13.1 的 ARM64 架构离线安装包,面向在 ARM64 服务器或 Kubernetes 集群上部署私有镜像仓库的运维与开发人员,解决国产化平台、信创环境及边缘节点无法直接拉取官方 x86 安装包的问题。压缩包共 6 个文件,以 shell 安装脚本、配置文件模板、镜像归档及许可证说明为主,整体约 679MB,其中镜像归档承载核心组件,脚本与模板负责初始化与参数定制,可在无外网环境下完成一键部署。目前已有 528 人学习下载,适合需要快速搭建 ARM64 私有仓库、研究 Harbor 离线安装机制或进行版本升级的读者参考。资源持续跟进官方最新版本,便于对照官方文档完成配置调优与故障排查。
1. 从一次内网部署翻车说起:为什么我盯上了 Harbor v2.13.1 的 ARM64 离线包
上个月帮一个做边缘计算的朋友救火,他们机房清一色 ARM64 服务器,想在内网搭一套镜像仓库给 Kubernetes 集群用。结果从官方渠道拉镜像,要么架构不对跑不起来,要么依赖一堆外网地址,内网根本拉不动。折腾两天,最后靠一份 Harbor v2.13.1 的 ARM64 离线安装包才把局面稳住。这件事让我意识到,ARM64 场景下的镜像管理,和 x86 那套经验真不是一回事。
Harbor 本身是 CNCF 毕业的容器镜像仓库项目,做的是镜像存储、权限控制、漏洞扫描、镜像复制这些事。而这份资源的核心价值就三点:版本是 v2.13.1、架构是 ARM64、形态是离线安装包。翻译成人话就是——你不需要在目标机器上联网拉一堆镜像,解压、改配置、跑脚本,一套内网镜像仓库就起来了。适合谁?在 ARM64 服务器或国产化平台上跑 Kubernetes、又要求镜像不出内网的运维和平台工程师。如果你手上是 x86 机器,这份包不是给你准备的,别下错了。
2. 离线包拆开看:ARM64 架构下 Harbor 的组件构成与选型逻辑
2.1 离线安装包到底装了什么
先把包解开看结构,这是判断一份离线包靠不靠谱的第一步。Harbor 的离线包本质是一个自包含的部署套件,核心目录大致长这样:
tar -xzf harbor-offline-installer-v2.13.1-arm64.tgz cd harbor ls -la你会看到几个关键文件:harbor.v2.13.1.tar.gz是全部组件镜像的打包,harbor.yml.tmpl是配置模板,install.sh是安装入口,prepare负责生成 docker-compose 编排文件。注意那个harbor.v2.13.1.tar.gz,它才是离线能力的来源——里面塞了 registry、portal、core、jobservice、db、redis、trivy 等一堆镜像,安装时用docker load一次性灌进本地。
为什么 ARM64 要单独出包?因为镜像里的二进制是编译好的,x86 的镜像层在 ARM64 上根本执行不了。很多人以为 Docker 镜像跨架构通用,这是最大的误解。镜像 manifest 里带着架构信息,docker pull时如果本地是 ARM64 而仓库只有 amd64,要么报no matching manifest,要么拉下来跑就exec format error。所以这份 ARM64 离线包的价值,就在于所有组件镜像都是原生 ARM64 构建的,省掉了你自己交叉编译或找替代镜像的麻烦。
2.2 组件清单与资源占用预估
在动手前,先对这套东西吃多少资源有个数,不然装到一半磁盘满了很尴尬。下面是 v2.13.1 默认部署下的主要组件和大致占用:
| 组件 | 作用 | 镜像大小量级 | 内存占用 |
|---|---|---|---|
| harbor-core | 核心 API 与业务逻辑 | 百 MB 级 | 中等 |
| harbor-portal | Web 前端 | 较小 | 低 |
| harbor-registry | 镜像存储后端 | 中等 | 中等 |
| harbor-jobservice | 复制、扫描等异步任务 | 中等 | 中等 |
| harbor-db | PostgreSQL 元数据库 | 中等 | 中等 |
| redis | 缓存与会话 | 小 | 低 |
| trivy | 漏洞扫描 | 较大 | 较高 |
磁盘上,光镜像包解压加加载后,建议预留至少 40GB 起步,因为后续你还要往里推镜像。内存方面,2GB 能跑起来但会紧,4GB 以上比较舒服,8GB 可以开扫描。CPU 核心数不是瓶颈,ARM64 平台常见的是 4 核或 8 核,够用。
提示:如果你的 ARM64 机器是那种内存只有 2GB 的轻量实例,装之前先把 trivy 扫描关掉,否则 jobservice 容易因为内存不足反复重启。
2.3 为什么选离线而不是在线安装
在线安装脚本会去 Docker Hub 或指定 registry 拉镜像,内网环境直接卡死。离线包把这一步前置了,安装过程只跟本地 Docker daemon 打交道。对于 Kubernetes 集群的镜像仓库来说,这还有个额外好处:整个部署过程可重复、可审计,不会因为某天外网镜像 tag 变了导致重装失败。我一般给内网项目做交付,优先选离线包,图的就是确定性。
3. 从解压到登录:ARM64 离线部署的完整操作链路
3.1 前置检查:Docker 与 docker-compose 的版本底线
Harbor v2.13.1 对运行环境有要求,ARM64 上尤其要注意 Docker 版本别太老。先确认:
docker version --format '{{.Server.Version}}' docker compose versionDocker 建议 20.10 以上,docker compose 用 v2 插件形式(docker compose而不是docker-compose)。v2.13.1 的 install.sh 已经适配 compose v2,如果你系统里只有老的 python 版 docker-compose,可能报命令找不到。ARM64 的 Docker 安装包现在主流发行版都有,装完记得把当前用户加进 docker 组,不然 install.sh 里一堆 sudo 很烦。
sudo usermod -aG docker $USER newgrp docker这一步不做,后面docker load会提示权限拒绝,属于新手最常见的翻车点。
3.2 配置 harbor.yml:ARM64 场景下必须改的几个参数
复制模板再改,别直接改 tmpl:
cp harbor.yml.tmpl harbor.yml vim harbor.yml重点看这几处。hostname填你机器的实际 IP 或内网域名,别用 localhost,否则 Kubernetes 节点拉镜像时解析不到。http.port默认 80,如果被占用改成别的。harbor_admin_password设一个强密码,默认的 Harbor12345 上线就是安全隐患。data_volume指向一个大盘路径,别放系统盘。database.password和redis相关如果没特殊需求保持默认即可。
如果要开 HTTPS,把https段取消注释并配好证书路径;内网自签也行,但记得把 CA 分发给所有 Kubernetes 节点,否则 kubelet 拉镜像会报证书错误。ARM64 平台上的证书和 x86 没区别,别被架构吓到。
hostname: 192.168.1.100 http: port: 80 harbor_admin_password: YourStrongPass data_volume: /data/harbor改完保存。这里有个血泪经验:harbor.yml里缩进是空格,别用 Tab,YAML 解析器对 Tab 零容忍,报错信息还特别含糊。
3.3 执行安装:install.sh 背后发生了什么
sudo ./install.sh --with-trivy不带参数就装基础组件,加--with-trivy会启用漏洞扫描。脚本执行时依次做几件事:先调prepare读取 harbor.yml 生成docker-compose.yml,然后docker load把harbor.v2.13.1.tar.gz里的镜像逐个加载,最后docker compose up -d拉起所有容器。整个过程不需要外网,这就是离线包的意义。
安装完用docker compose ps看状态,所有服务应该是 Up 或 healthy。如果某个容器反复重启,先docker compose logs <服务名>看日志。ARM64 上最常见的是 db 初始化慢导致 core 起不来,等一两分钟再刷新通常就好了。
3.4 验证与首次推送镜像
浏览器打开http://你的hostname,用 admin 和你设的密码登录。能进 dashboard 说明核心链路通了。接着验证推送:
docker login 192.168.1.100 docker tag nginx:latest 192.168.1.100/library/nginx:arm64 docker push 192.168.1.100/library/nginx:arm64注意,Harbor 默认要求先创建项目(project),library是默认存在的公共项目。推之前确认你的 nginx 镜像是 ARM64 的,用docker inspect看 Architecture 字段。推一个 amd64 镜像进去,Kubernetes 节点拉下来照样跑不起来,这个坑我在第 4 章细说。
4. 避坑与排查:ARM64 离线部署里最容易翻车的五件事
4.1 镜像加载后容器起不来,报 exec format error
现象:docker compose up后容器秒退,日志里出现exec format error或standard_init_linux.go相关报错。
原因:加载进来的镜像架构和宿主机不匹配。虽然这份包号称 ARM64,但如果你之前本地 Docker 里残留了同名 amd64 镜像,docker load可能没覆盖干净,或者你误用了 x86 的包。
解决:先docker image inspect <镜像> | grep Architecture确认是 arm64。如果是 amd64,docker rmi清掉再重新docker load。另外确认uname -m输出是aarch64或arm64,别在 x86 机器上装 ARM64 包,方向反了。
4.2 Kubernetes 节点拉镜像报证书或解析错误
现象:Pod 一直 ImagePullBackOff,describe 看到x509: certificate signed by unknown authority或no such host。
原因:Harbor 用了自签 HTTPS 证书,节点不信任;或者 hostname 配的是 localhost,节点解析不到。
解决:把 Harbor 的 CA 证书放到每个节点的/etc/docker/certs.d/你的hostname/ca.crt,然后重启 docker。hostname 必须用节点能访问到的 IP 或域名。如果图省事用 HTTP,需要在每个节点的 docker daemon 配置里把该地址加进insecure-registries,但生产环境不建议这么干。
4.3 磁盘写满导致 registry 拒绝推送
现象:推送镜像推到一半报no space left on device,或者 registry 容器 unhealthy。
原因:data_volume指向的分区满了。Harbor 的镜像存储、数据库、日志都吃这个盘,镜像一多涨得很快。
解决:df -h确认分区,把data_volume迁到大盘。迁移时先docker compose down,改 harbor.yml 里的路径,再install.sh重跑。日常可以配镜像保留策略,在 Web 界面里设置按 tag 数量或天数清理,别等满了才救火。
4.4 漏洞扫描一直卡在 pending
现象:镜像推上去了,扫描任务永远排队,trivy 容器 CPU 或内存飙高。
原因:ARM64 上 trivy 的漏洞库更新和扫描比较吃资源,内存不足时任务会卡死。
解决:给机器加内存,或者关掉自动扫描改为手动触发。也可以在 harbor.yml 里调 jobservice 的并发数,降低同时扫描的任务量。轻量 ARM64 实例上,扫描功能属于奢侈品,量力而行。
4.5 升级或重装后数据丢失
现象:重跑 install.sh 后,之前推的镜像和用户全没了。
原因:docker compose down时如果带了-v,或者手动删了数据卷,数据库和镜像存储就一起没了。Harbor 的数据默认存在data_volume和 Docker volume 里,重装脚本本身不会主动删,但操作顺序错了就会丢。
解决:升级前先备份data_volume整个目录和数据库。重装时用docker compose down不带-v,保留卷。养成习惯:动 Harbor 之前先docker compose down停服务,备份,再操作。后悔药这东西,Harbor 不卖。
5. 进阶技巧:把 Harbor 接进 Kubernetes 与镜像保留策略
5.1 在 Kubernetes 里创建 imagePullSecret
Harbor 跑起来只是第一步,让 Kubernetes 集群能用它才是目的。私有项目需要认证,先在 Harbor 里建一个机器人账号(robot account),拿到 token,然后在集群里建 secret:
kubectl create secret docker-registry harbor-cred \ --docker-server=192.168.1.100 \ --docker-username='robot$yourproject' \ --docker-password='生成的token' \ --namespace=default建完在 Deployment 的spec.imagePullSecrets里引用harbor-cred。机器人账号的好处是权限可控、可轮换,比直接用 admin 强得多。ARM64 集群里所有节点都要能访问 Harbor 地址,网络策略别拦了。
5.2 用保留策略控制镜像膨胀
镜像仓库不管,半年就能撑爆盘。Harbor 的 tag 保留策略在项目设置里配,规则可以按「保留最近推送的 N 个」或「保留最近 N 天」。我一般给生产项目配「保留最近 10 个 tag + 保留最近 30 天」,两条规则取并集。配完先点「模拟运行」看会删哪些,确认无误再启用。这个功能救过我好几次,尤其是 CI 频繁推镜像的场景。
5.3 验证离线包完整性的一个习惯
最后说个我自己的习惯。每次拿到离线包,先校验再解压:
sha256sum harbor-offline-installer-v2.13.1-arm64.tgz和来源提供的校验值对一下。传输过程损坏的包,解压时可能不报错,但docker load到一半失败,排查起来很费劲。从那以后我每次部署前都强制走一遍校验,宁可多花两分钟,也不想到机房现场才发现包是坏的。希望帮到你。
本文还有配套的精品资源,点击获取