企业官网建设流程全解析

简介：本资源为面向国产化ARM架构环境的Harbor 2.10.2离线安装包，适合在信创服务器、麒麟或统信等国产操作系统上部署私有镜像仓库的运维与DevOps人员使用。包内共6个文件，以Shell安装脚本、配置模板、离线镜像压缩包及许可证文件为主，涵盖安装入口、环境准备、参数配置与镜像导入等环节，压缩包整体约650.11MB，可满足无外网环境下的一站式部署需求。目前已有98人学习下载。借助该离线包，读者可省去逐层拉取依赖的繁琐过程，直接完成Harbor核心服务的安装与初始化，并依据配置模板调整端口、存储路径与访问协议等关键参数，快速搭建可用的企业级镜像仓库，为后续容器镜像的推送、拉取与权限管理提供基础支撑。

1. 从 harbor-offline-installer-aarch64-v2.10.2.tgz 说起：ARM 内网部署 Harbor 到底难在哪

如果你手里正好有一个harbor-offline-installer-aarch64-v2.10.2.tgz，又恰好面对的是鲲鹏、飞腾这类 aarch64 服务器，还要求全程纯内网、不能连外网拉镜像，那你大概率已经踩过或即将踩到一个坑：x86 上那套「下载 online installer、改改 harbor.yml、跑 install.sh」的顺滑流程，在 ARM 上会因为架构不匹配、基础镜像缺失、依赖组件版本错位而处处卡壳。这个离线包的价值就在于，它把 Harbor 运行所需的全部容器镜像和组件都预先打进了压缩包，专门针对 aarch64 架构，省去了在内网逐层拉取镜像的麻烦。这篇文章面向的是需要在国产化 ARM 服务器上落地私有镜像仓库的运维和平台工程师，我会把从环境准备、解压配置、安装启动到排错验证的完整路径讲清楚，让你拿到这个包就能照着复现，而不是对着报错日志干瞪眼。

2. 动手之前：aarch64 纯内网环境的三项硬性准备

2.1 确认 CPU 架构与操作系统版本匹配

很多人拿到离线包第一件事就是解压，结果install.sh跑到一半报exec format error，回头一查发现服务器是 x86_64。aarch64 的离线包只能在 ARM 架构上运行，这是最基础也最容易被忽略的前提。先在目标机器上执行确认：

uname -m # 期望输出：aarch64 # 如果输出 x86_64，说明你拿错包了 cat /etc/os-release # 关注 NAME 和 VERSION_ID # 常见组合：CentOS 7.9 aarch64、银河麒麟高级服务器 V10（鲲鹏/飞腾）

逻辑说明：uname -m返回的是内核视角的硬件架构，aarch64 就是 ARM 64 位。/etc/os-release用来确认发行版和版本，因为 Harbor 的安装脚本对 systemd、docker 版本有隐式依赖，CentOS 7.9 和麒麟 V10 在包管理层面有差异，后续装 Docker 时命令会不同。

参数说明：如果你的环境是银河麒麟 V10，它的底层包管理仍然兼容 yum，但部分仓库地址需要替换为内网源。CentOS 7.9 aarch64 的 yum 源在纯内网下需要提前配置好本地镜像源，否则装 Docker 时会因为找不到 aarch64 的 rpm 包而失败。

2.2 离线安装 Docker 与 Docker Compose

Harbor v2.10.2 的离线安装器依赖 Docker Engine 和 Docker Compose。纯内网环境下，你需要提前准备好 aarch64 架构的 Docker 离线 rpm 包或二进制包。常见做法是从同架构的机器上导出，或者使用内网 yum 源安装。

# 方式一：内网 yum 源安装（推荐，依赖自动解决） yum install -y docker-ce docker-ce-cli containerd.io systemctl enable docker && systemctl start docker # 方式二：二进制离线安装（无 yum 源时） # 将 docker-<version>.tgz 和 docker-compose-linux-aarch64 上传到服务器 tar -xzvf docker-<version>.tgz cp docker/* /usr/bin/ # 手动编写 systemd unit 文件后启动

逻辑说明：优先用 yum 是因为它能自动处理 containerd、runc 等依赖的版本匹配。二进制方式虽然灵活，但需要自己写/etc/systemd/system/docker.service，容易漏掉--exec-opt native.cgroupdriver=systemd这类参数，导致后续 Harbor 容器启动异常。

参数说明：Docker 版本建议不低于 20.10，Compose 版本不低于 v2.20。Harbor v2.10.2 的docker-compose.yml使用了较新的 compose 语法，老版本 compose 会报unsupported config option。

# 验证 docker version docker compose version # 注意：Harbor 2.10 使用 docker compose（v2 插件形式），不是 docker-compose（v1）

2.3 内核参数与防火墙预调

Harbor 的多个组件（PostgreSQL、Redis、Nginx）会监听大量端口，纯内网环境下防火墙策略往往比较严格。提前调整内核参数和防火墙规则，能避免安装后服务起不来却找不到原因。

# 关闭 SELinux（或设为 permissive） setenforce 0 sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config # 调整内核参数 cat >> /etc/sysctl.conf <<EOF net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 vm.max_map_count = 262144 EOF sysctl -p # 开放必要端口（或直接关闭 firewalld 测试） firewall-cmd --permanent --add-port=80/tcp firewall-cmd --permanent --add-port=443/tcp firewall-cmd --reload

逻辑说明：vm.max_map_count是 Elasticsearch 类组件的硬性要求，Harbor 的镜像扫描组件依赖它。net.bridge参数确保容器网络能正常转发。SELinux 在 enforcing 模式下会阻止容器挂载宿主机目录，这是 Harbor 启动失败的常见原因之一。

参数说明：如果你的环境不允许关闭 SELinux，需要为 Harbor 的数据目录单独打标签，操作更复杂，建议测试阶段先用 permissive 模式跑通。

3. 解压与配置：harbor.yml 里必须改的五个参数

3.1 解压离线包与目录结构说明

拿到harbor-offline-installer-aarch64-v2.10.2.tgz后，解压到一个有足够磁盘空间的分区。Harbor 运行后镜像数据会持续增长，建议数据目录单独挂盘。

tar -xzvf harbor-offline-installer-aarch64-v2.10.2.tgz -C /opt/ cd /opt/harbor ls -lh # 关键文件： # harbor.yml 主配置文件 # install.sh 安装脚本 # prepare 预处理脚本 # harbor.v2.10.2.tar.gz 离线镜像包（aarch64） # common.sh 公共函数库

逻辑说明：harbor.v2.10.2.tar.gz是离线安装的核心，里面包含了 Harbor 所有组件的 aarch64 镜像。install.sh会先调用prepare生成 docker-compose 配置，然后加载镜像并启动容器。

参数说明：解压后的目录不要随意移动，install.sh内部使用相对路径引用harbor.v2.10.2.tar.gz。如果磁盘空间不足，可以只解压必要文件，但镜像包必须完整。

3.2 harbor.yml 五个必改参数

复制一份配置模板再修改，保留原始文件方便回滚：

cp harbor.yml harbor.yml.bak vim harbor.yml

需要修改的关键参数如下表：

# harbor.yml 关键片段 hostname: 192.168.1.100 http: port: 80 # https: # port: 443 # certificate: /your/certificate/path # private_key: /your/private/key/path harbor_admin_password: YourStrongPass123 data_volume: /data/harbor database: password: root123 max_idle_conns: 100 max_open_conns: 900

逻辑说明：hostname决定了 Harbor 生成的 token 服务和 registry 地址，如果填错，docker login 会报no such host或证书不匹配。data_volume建议指向独立数据盘，避免系统盘被镜像撑满。

参数说明：database.password是内部 PostgreSQL 密码，不是管理员密码，但也不要用默认值。max_open_conns在高并发推送场景下可以调大，但要注意 PostgreSQL 的max_connections限制。

3.3 执行安装与验证容器状态

配置改完后，执行安装脚本。这个过程会加载镜像、生成配置、启动容器，耗时取决于磁盘 IO 性能。

./install.sh # 安装完成后检查容器状态 docker compose ps # 期望看到：harbor-core、harbor-db、harbor-jobservice、 # harbor-portal、harbor-registry、harbor-redis、 # harbor-trivy、nginx、registryctl 均为 running

逻辑说明：install.sh内部先执行prepare生成docker-compose.yml，然后docker load加载离线镜像，最后docker compose up -d启动。如果某一步失败，脚本会中断并输出错误信息。

参数说明：如果docker compose ps中有容器处于restarting或exited状态，用docker compose logs <service>查看具体日志。常见的是harbor-db初始化慢导致harbor-core反复重启，等待一两分钟通常会自行恢复。

4. 避坑排查：aarch64 离线安装 Harbor 的五个血泪教训

4.1 坑一：install.sh 报 exec format error

现象：执行./install.sh后立即报cannot execute binary file: Exec format error。

原因：离线包中的某些二进制文件（如prepare）是 aarch64 架构的，但当前机器是 x86_64，或者反过来。也有可能是下载的包在传输过程中损坏。

解决：先用uname -m确认架构，再用file prepare查看二进制文件的目标架构。如果架构不匹配，换正确的包。如果架构匹配但仍报错，检查文件是否完整，重新解压。

4.2 坑二：docker load 卡住或报 no space left on device

现象：安装过程中docker load进度条长时间不动，或者直接报磁盘空间不足。

原因：harbor.v2.10.2.tar.gz解压后的镜像层占用空间远大于压缩包本身，通常需要 10GB 以上的可用空间。另外 Docker 的默认数据目录/var/lib/docker可能在小分区上。

解决：安装前用df -h确认/var/lib/docker和/data所在分区有足够空间。如果 Docker 数据目录需要迁移，修改/etc/docker/daemon.json中的># 查看 Docker 当前数据目录 docker info | grep "Docker Root Dir" # 迁移示例 systemctl stop docker mv /var/lib/docker /data/docker ln -s /data/docker /var/lib/docker systemctl start docker

4.3 坑三：harbor-core 启动后不断重启

现象：docker compose ps显示harbor-core状态为restarting，日志中报数据库连接失败。

原因：harbor-db容器初始化需要时间，harbor-core启动时数据库还没准备好。另外，如果database.password中包含了特殊字符（如#、$），YAML 解析可能出错。

解决：先等 2-3 分钟，让harbor-db完成初始化。如果仍然重启，检查harbor.yml中database.password是否被正确解析，避免使用 YAML 保留字符。查看harbor-db日志确认是否有权限问题。

docker compose logs harbor-db | tail -50 docker compose logs harbor-core | tail -50

4.4 坑四：docker login 报 x509 证书错误

现象：在客户端执行docker login 192.168.1.100时报x509: certificate signed by unknown authority。

原因：Harbor 默认使用自签名证书或未配置 HTTPS，而 Docker 客户端默认要求 HTTPS。纯内网环境下如果harbor.yml中注释了 https 段，Harbor 只监听 HTTP，但 Docker 客户端仍然尝试 HTTPS。

解决：在客户端的 Docker 配置中声明该仓库为不安全仓库。修改/etc/docker/daemon.json：

{ "insecure-registries": ["192.168.1.100"] }

然后重启 Docker。注意：这是内网测试环境的做法，生产环境应配置受信任的证书。

4.5 坑五：推送镜像时 aarch64 镜像 manifest 不匹配

现象：从 x86 机器构建的镜像推送到 ARM Harbor 后，在 ARM 节点上拉取运行时报exec format error。

原因：Harbor 本身不限制镜像架构，但如果你推送的是 x86 镜像，在 ARM 节点上自然无法运行。这不是 Harbor 的问题，而是镜像构建架构的问题。

解决：在 ARM 机器上构建镜像，或使用docker buildx构建多架构镜像。验证方法：docker manifest inspect <image>查看镜像支持的架构列表。

5. 进阶技巧：用 skopeo 在纯内网同步镜像与验证 Harbor 健康状态

5.1 用 skopeo 做离线镜像搬运

纯内网环境经常遇到一个场景：外网机器上拉取了镜像，需要搬到内网 Harbor。用docker save/docker load的方式在 aarch64 上容易因为架构问题翻车。更稳的做法是用skopeo copy，它直接操作 registry API，不依赖本地 Docker daemon。

# 在外网机器上（需支持 aarch64 镜像） skopeo copy \ --all \ docker://registry.example.com/app:v1.0 \ dir:/tmp/app-image # 将 /tmp/app-image 目录打包拷贝到内网机器 tar -czvf app-image.tar.gz -C /tmp app-image # 在内网机器上推送到 Harbor skopeo copy \ --dest-tls-verify=false \ dir:/tmp/app-image \ docker://192.168.1.100/library/app:v1.0

逻辑说明：--all参数确保同步所有架构的 manifest，这样 x86 和 ARM 节点都能拉取到对应架构的镜像。dir:格式将镜像保存为文件系统目录，方便跨网搬运。--dest-tls-verify=false用于自签名证书场景。

参数说明：如果内网 Harbor 配置了 HTTPS 且证书受信任，去掉--dest-tls-verify=false。skopeo需要单独安装，aarch64 版本可以从发行版仓库获取或自行编译。

5.2 Harbor 健康检查与日常巡检命令

安装完成后，建议把几个健康检查命令固化成日常巡检脚本。Harbor 提供了 API 接口，可以直接查询组件状态。

# 检查 Harbor 整体健康状态 curl -s http://192.168.1.100/api/v2.0/health | python3 -m json.tool # 检查各容器资源占用 docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}" # 检查镜像存储使用量 du -sh /data/harbor/registry/docker/registry/v2/ # 检查数据库连接数 docker exec harbor-db psql -U postgres -c "SELECT count(*) FROM pg_stat_activity;"

逻辑说明：/api/v2.0/health返回各组件状态，正常时所有组件均为healthy。docker stats用于发现异常资源占用，比如harbor-trivy在扫描大量镜像时内存会飙升。du命令用于容量规划，镜像存储增长过快时需要清理策略。

参数说明：API 健康检查默认不需要认证，但如果 Harbor 配置了外部认证，可能需要先获取 token。docker exec进入数据库的命令需要harbor.yml中配置的数据库密码。

5.3 一个我踩过的坑：时间同步导致 token 失效

最后说一个很隐蔽的问题。Harbor 的 token 服务依赖系统时间，如果 Harbor 服务器和客户端时间偏差超过几分钟，docker push会报token expired或unauthorized。纯内网环境如果没有配置 NTP，服务器重启后时间可能漂移。

# 检查时间同步状态 timedatectl status # 确保 System clock synchronized: yes # 如果没有 NTP，手动同步或配置内网 NTP 源 chronyc sources -v

我现在拿到任何一台新服务器，第一件事就是确认时间同步，这个习惯帮我省掉了至少三次「莫名其妙」的认证失败排查。希望帮到你。

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