企业官网建设流程全解析

简介：面向 ARM 架构的 Harbor v2.9.0 离线安装包，专为内网环境或无法访问外网镜像仓库的 ARM64 服务器设计，帮助运维工程师快速部署企业级私有镜像仓库。安装前需具备 Docker 和 Docker Compose 环境，资源内含一键安装脚本，执行该脚本即可自动完成部署，无需在线拉取任何镜像组件。安装包共含 6 个文件，包括 shell 安装脚本、离线镜像包、许可说明、初始化脚本及配置模板等，各文件职责清晰，压缩包整体约 722.35MB，可完整支撑离线安装与后期配置调整，适配多种生产环境。该资源目前已有 962 人学习下载，适合具备基础 Linux 操作能力的运维人员、DevOps 工程师或需要在 ARM 环境中搭建镜像仓库的技术人员。通过本包可一次性获得全套离线依赖，规避因网络受限导致的部署中断，同时保留配置模板便于按需修改，显著提升部署效率，尤其适合离线机房或内网 CI/CD 场景下的快速交付。

1. 先认清这条命令行背后的需求：ARM 服务器上的 Harbor 离线包为什么难装

公司内网里扔着一台 ARM 架构的服务器，系统是银河麒麟这类 Linux，开发环境全在内网，外网完全不通。要在这台机器上跑一个镜像仓库供团队 push 和 pull 镜像，很多人第一反应就是找 Harbor 的离线安装包，结果一执行install.sh就各种报错。原因不复杂：Harbor 本身的离线包是一回事，ARM 架构下的 Docker、Compose 和镜像架构是另一回事，三者只要有一个选错，整个安装就得推倒重来。这篇文章不是把官方文档抄一遍，而是把 ARM 架构离线装 Harbor v2.9.0 从依赖准备到验证交付的整条链路拆开，把最容易翻车的地方先讲清楚。适合要给内网 ARM 服务器交付 Harbor 的运维、项目交付和正在搭私有仓库的团队参考。

2. 先把原理摆正：Harbor v2.9.0 离线包、ARM 架构与安装链路

2.1 Harbor v2.9.0 离线包里到底装了些什么

离线安装包和在线安装包最大的区别，是把 Harbor 运行所需的全部组件镜像提前打包放好，安装时不需要访问任何外部镜像源。Harbor 本身不是单个进程，它由一组容器组成：core负责 API 和认证，portal是 Web 前端，registry负责镜像存取，jobservice做复制和清理任务，还有nginx、db、redis这些基础设施组件。离线包把这些组件的镜像统一打成 tar 然后放进image目录，install.sh做的事本质上是三步：检查环境、把镜像docker load进本地、用docker-compose把容器拉起来。

所以你会看到，所谓离线安装并不需要你手动去拉镜像，难点全在 install.sh 执行之前的准备阶段。v2.9.0 这个版本在功能上覆盖了内网交付常见的需求：项目隔离、镜像复制、机器人账号、按需漏洞扫描，同时这个版本的官方发布包对 ARM64 的适配已经比较成熟。如果你的环境同时还在用旧版本的 Docker，2.9.0 的安装脚本对 Docker 20.10.x 的兼容性也比更早的版本好，这也是我为什么推荐它作为 ARM 内网环境首选版本。

2.2 ARM 和 x86 的差别：选错一次包就得重来

Docker 镜像是带架构标识的。同一个 Harbor 组件，推送到镜像仓库里可以同时存在linux/amd64和linux/arm64两个版本。在线环境下，Docker 会根据当前机器的架构自动拉取对应的那个；但离线环境没有外网，所有东西都是提前拷进去的，不存在自动选择这回事。你拷进去的是 x86 的镜像，在 ARM 机器上docker load能成功，但容器一启动就直接exec format error，因为 CPU 根本执行不了另一套指令集。

这一点和离线装其他软件是同一个逻辑。比如很多人给 arm64 机器离线装 Nginx 时下的也是 aarch64 的包，ARM 环境下没有“通用二进制”这种说法。具体到安装 Harbor，有三个东西必须保证是 ARM 架构：Docker 的二进制文件、Docker Compose 的二进制文件、Harbor 离线包里的组件镜像。任何一个不对，后面的安装就是白费功夫。很多跑 Harbor 的 ARM 服务器装的是银河麒麟这类国产 Linux 发行版，包管理习惯和 CentOS 7 很接近，所以网上那些 CentOS 7 离线装 Docker 20.10.24 的步骤可以直接平移过来用，但所有下载源必须换成 aarch64 的。

2.3 安装前的检查：先把机器底子摸清楚

拿到一台服务器，别着急解压 Harbor，先把底子摸清楚。我一般会先跑下面这一组命令。

uname -m cat /etc/os-release free -h df -h / /data nproc

uname -m输出aarch64，说明是 ARM 64 位，可以继续；如果输出x86_64，直接停，你手里的离线包很可能选错了。cat /etc/os-release看发行版信息，银河麒麟、统信这类系统会直接显示名称和版本号，这决定了后面要不要额外装一些依赖。free -h看内存，Harbor 跑起来是一组容器，内存低于 4G 会非常吃力，甚至 compose 阶段直接 OOM。df -h / /data这一步很多人会忽略——Harbor 占的空间不是离线包那一个压缩包的大小，还要算上 Docker 镜像存储目录和 Harbor 数据卷。我的经验值是：系统盘和数据盘至少预留 30G 以上，否则后面docker load会卡在中间报磁盘不足。

3. 离线安装实操：从准备依赖到跑通 install.sh

3.1 先装 Docker 和 Docker Compose：ARM 二进制从哪里来

Harbor 的安装脚本依赖 Docker 和 Docker Compose，这两个在离线环境下没有安装包可以碰运气，必须提前准备好。常见做法是在一台能上网的机器上，下载对应 aarch64 架构的 Docker 静态二进制包，想办法拷贝进内网。ARM 场景下我习惯用 Docker 20.10.24 这个版本，它在银河麒麟、CentOS 7 这类内网环境的兼容性验证过很多次，不那么挑内核。

静态包解压后是docker/目录，把里面的二进制统一放到/usr/bin/即可。

tar -xzf docker-20.10.24.tgz cp docker/* /usr/bin/ mkdir -p /etc/docker cat > /etc/docker/daemon.json <<'EOF' { "data-root": "/data/docker" } EOF

cp docker/* /usr/bin/把dockerd、docker、containerd等全套二进制都拷进去。这里重点看daemon.json：把 Docker 的数据根目录指到/data/docker，因为镜像仓库日积月累占用很大，系统盘一般放不下，这个习惯建议一开始就养成。

Docker 的静态包不带 systemd 管理文件，需要自己写一个 service unit，否则无法开机自启。

cat > /etc/systemd/system/docker.service <<'EOF' [Unit] Description=Docker After=network-online.target [Service] Type=notify ExecStart=/usr/bin/dockerd ExecReload=/bin/kill -s HUP $MAINPID LimitNOFILE=1048576 TimeoutStartSec=0 Restart=on-failure [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl enable --now docker

Type=notify让 systemd 等dockerd真正起来之后再确认启动成功，而不是只看到进程被拉起就完事。LimitNOFILE=1048576提高文件描述符上限，镜像多了以后不会莫名报too many open files。执行完systemctl enable --now docker，接着docker version确认服务正常。

接下来是 Docker Compose。离线环境里它也是一个独立二进制，ARM 架构对应的文件名通常带aarch64。把它放到/usr/local/bin并加上执行权限。

cp docker-compose-linux-aarch64 /usr/local/bin/docker-compose chmod +x /usr/local/bin/docker-compose docker-compose version

注意，Harbor 的install.sh脚本调用的是docker-compose这个命令，不是docker compose插件。哪怕你机器上已经装了新版 Docker 自带 compose 插件，也必须保证docker-compose这个命令存在。最省事的做法就是上面这样放一个独立二进制，或者给docker compose做一个软链，避免后面 install.sh 半路退出。

3.2 解压 Harbor 离线包并按内网环境改 harbor.yml

Docker 和 Compose 就绪后，把 Harbor 离线包拷进内网并解压。离线包的文件名可能带arm64后缀也可能不带，以实际拿到的为准。

tar -xzf harbor-offline-installer-v2.9.0.tgz cd harbor cp harbor.yml.tmpl harbor.yml vi harbor.yml

harbor.yml.tmpl是官方提供的配置模板，里面带了很多注释。我的做法是复制成harbor.yml再改，保留模板作为备份。修改的关键点如下面的 YAML 片段。

hostname: 192.168.10.20 http: port: 80 harbor_admin_password: Admin@12345 data_volume: /data/harbor log: level: info database: password: root123

模板默认把https段开着、http段注释掉，内网没有正式证书的话，把https段整个注释，打开http段让 install.sh 直接走 HTTP。hostname是第一个必改项，它决定客户端 push 和 pull 时用的地址，内网环境直接写这台机器的 IP 最稳妥，写域名反而容易踩坑。harbor_admin_password是管理员密码，要求至少 8 位且包含大小写字母和数字。data_volume指向/data/harbor，和上面 Docker 的>sudo ./install.sh

脚本开始后主要做几件事：先做环境检查，确认 Docker 和 Docker Compose 存在且版本满足要求；然后把image目录下的组件镜像逐个docker load进本地；最后基于harbor.yml生成正式的docker-compose.yml并用它把容器拉起来。整个过程少则几分钟，多则十几分钟，取决于机器磁盘速度和离线包大小。

很多人执行完后只看最后的安装成功横幅，但我更建议盯着前 30 秒的输出。这段时间最容易暴露环境问题：docker-compose: command not found是 Compose 没装好；exec format error是架构选错了；no space left on device是磁盘预留不足。这些错误越早看到，越容易收场。如果失败，不要反复执行install.sh，先把报错日志看清楚再动手。

全部启动后进到 Harbor 解压目录，跑一下docker compose ps，确认core、portal、registry、db、jobservice、nginx这些关键容器都是Up状态。有容器Exited的话，直接docker logs看对应容器日志，按下一章的排查思路处理。

4. 避坑汇总：ARM 离线安装最常见的 5 个翻车点

4.1 架构选错：包不对，怎么调都是白搭

现象：dockerd启动直接报exec format error，或者 Harbor 镜像docker load阶段一切正常，但容器一启动就Exited，日志里同样是exec format error。

原因：ARM 服务器上用了 x86 的二进制或镜像。Docker 二进制、Docker Compose 二进制、Harbor 组件镜像，这三者里只要有一个是 x86 架构，就会在启动时被 CPU 直接拒绝执行。

解决：装之前uname -m确认是aarch64；拷进来的文件用file命令验证一下，输出里带ARM aarch64才是对的。镜像架构可以在docker load之后用docker image inspect看Architecture字段。这个检查花不了两分钟，能避免整个安装流程白跑一遍。

4.2 Docker Compose 缺失或版本太老，install.sh 半路退出

现象：执行./install.sh时出现docker-compose: command not found，或者环境检查阶段直接退出，提示 Compose 版本不满足要求。

原因：离线环境里压根没装过 Docker Compose；还有一种情况是机器上装了新版 Docker，自带docker compose插件，但 Harbor 的 install.sh 脚本调用的还是老命令docker-compose。

解决：提前把docker-compose-linux-aarch64这个独立二进制放到/usr/local/bin/并chmod +x，执行docker-compose version确认能输出版本。如果只装了插件，就做一个符号链接：ln -s /usr/bin/docker-compose /usr/local/bin/docker-compose，保证 install.sh 能找到命令就行。

4.3 磁盘空间算少了，docker load 卡在中间

现象：install.sh 在docker load阶段卡住不动，最后报no space left on device；或者某个镜像加载成功但下一个失败，再次执行时各种残留状态。

原因：空间被低估了。离线包本身几个 GB，解压后又是一份，docker load进/var/lib/docker又是一份，再加上 Harbor 的数据卷，实际占用的总空间远大于离线包的文件大小。

解决：安装前df -h确认 Docker 根目录所在分区至少 30G 以上；通过daemon.json的>hostname: 192.168.10.20 http: port: 80 harbor_admin_password: Admin@12345 data_volume: /data/harbor log: level: info database: password: 生成一个强密码

重点说一下hostname。如果你所在的内网有内部域名，也可以填域名，但前提是所有客户端都能解析到这个 IP。实际情况是很多内网里只有 IP 能通，域名没人解析，填域名只会让所有人登录时报错。我的原则是：没有统一 DNS 的环境一律写 IP，写域名只会让人踩坑。

5.2 用自建 CA 代替 insecure-registries：TLS 的一劳永逸做法

测试环境可以开insecure-registries，但生产环境建议还是上自建 CA。这个方案的好处是客户端只要信任 CA，就不需要在每台机器上开不安全的免认证配置。证书生成在 Harbor 服务器上完成，下面这段是 IP 访问场景的完整命令。

mkdir -p /data/certs && cd /data/certs openssl genrsa -out ca.key 4096 openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj "/CN=Harbor-CA" openssl genrsa -out server.key 2048 openssl req -new -key server.key -out server.csr -subj "/CN=192.168.10.20" 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")

这段命令先创建一个 CA，再用这个 CA 给 Harbor 服务器签发证书，证书里通过subjectAltName绑定了 IP。注意-days 825这个值，大约是两年多，写多了在合规审计上会有问题，写少了要频繁轮换，825 是平衡后的选择。各处出现的192.168.10.20要替换成实际的服务器 IP。之后在harbor.yml里取消https段的注释，把certificate和private_key指到server.crt和server.key，重新执行./install.sh --enable-tls或者重跑 prepare 和重启服务。

客户端的做法是将ca.crt复制到节点的信任目录，比如/etc/docker/certs.d/192.168.10.20:80/ca.crt，或者加入 CentOS 系的/etc/pki/ca-trust/source/anchors/后执行update-ca-trust。这样docker login就不会再报证书错误，也不需要任何不安全配置。用 IP 访问的场景，subjectAltName是必须的，少了它会报证书校验失败，这是最容易踩的坑。

5.3 数据卷与备份策略：Harbor 的后悔药

Harbor 装完之后，data_volume目录下会分成database、redis、storage、secret等几个子目录，核心业务数据都在里面。备份的本质就是把整个data_volume打包带出去，出了问题直接恢复。我习惯的备份命令是这样的。

cd /data/install/harbor docker compose down tar -czf /data/backup/harbor-backup-$(date +%F).tar.gz /data/harbor docker compose up -d

备份前先docker compose down停止服务，保证数据文件不会在写入过程中被拷贝，得到的是一个一致性的快照。备份完成后docker compose up -d拉回服务。恢复时注意一点：备份时的hostname和数据库密码，恢复时必须一致，否则 Harbor 的 secret 和数据库关联会对不上，容器起来也登录不了。所以在交付的时候，我一般会额外把当时的harbor.yml和生成的docker-compose.yml也存一份，这两个文件在重装时能省去大量重新配置的时间。

6. 验证一遍才敢交付：健康检查、API 测试与常用排错命令

装完只是第一步，交付前我会按固定的顺序把这台 Harbor 过一遍，确认是活的、能用、能推拉。先看容器状态和服务健康检查。

docker compose ps curl -sk https://192.168.10.20/api/v2.0/ping curl -sk https://192.168.10.20/api/v2.0/health

docker compose ps确认所有关键容器都是Up；/api/v2.0/ping返回一个简单的响应，说明 API 服务活着；/api/v2.0/health返回各组件健康状态。如果第 3 章配置时用的是 HTTP，把命令里的https换成http即可。

然后是完整的推拉测试，这一步能验证客户端侧所有配置是否到位。

docker login 192.168.10.20:80 -u admin docker tag nginx:1.21 192.168.10.20:80/library/nginx:v1 docker push 192.168.10.20:80/library/nginx:v1 docker pull 192.168.10.20:80/library/nginx:v1

登录成功后打一个 tag，推上去再拉下来，全流程能走通，这台 Harbor 才算真正可交付。如果用 IP 加端口登录失败，八成是证书信任或hostname的问题，回头按第 4 章排查。

交付后日常排障时，日志入口主要有两个：容器日志和文件日志。核心服务看harbor-core，镜像存取看harbor-registry。

docker logs harbor-core --tail 100 docker logs harbor-registry --tail 100 tail -f /var/log/harbor/*.log

容器日志适合看某个容器自身的问题，文件日志适合跨模块追踪一次完整的请求链路。我现在的习惯是：每次在 ARM 环境交付完 Harbor，都把uname -m、docker-compose --version、docker compose ps这三样输出存进交付文档。因为后续不管是谁接手，出问题时先对照这三样，能过滤掉一半以上的环境类故障，剩下的才是真正的应用问题。这台机器上架构对不对、Compose 全不全、容器活没活，一眼就清楚。整个离线安装链路没有玄学，把架构、Compose、磁盘空间这三件前置条件钉死，后面就是一条命令的事。希望这篇东西能帮你在内网里少折腾几趟。

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