企业官网建设流程全解析

简介：面向麒麟V10与ARM64架构环境运维人员、容器平台搭建者的Harbor v2.4.0镜像仓库离线部署资源包。整套方案覆盖从环境准备、配置文件编写、证书生成到docker-compose安装启动的关键环节，适配国产化操作系统与ARM处理器，可帮助用户规避原生x86安装包不兼容、依赖缺失等常见问题，快速落地内网镜像仓库。压缩包共包含8个文件，整体约407.22MB，文件类型以shell脚本（环境检查、安装、证书生成）、离线镜像压缩包、docker-compose YAML配置模板及license等为主，并提供prepare初始化脚本与tmpl模板文件，便于按实际域名、端口调整参数后直接执行，整体结构清晰。目前已有314人学习下载，适合具备Docker、Docker Compose基础、正在为麒麟V10匹配K8s集群镜像源的运维工程师参考。通过该资源可掌握ARM64架构下Harbor离线安装的完整流程、配置模板的调整思路，以及国产化环境中容器镜像仓库的部署要点，便于在生产环境中复用。

1. 麒麟V10+ARM64部署Harbor v2.4.0：离线部署镜像仓库的实战起点

在银河麒麟V10（ARM64架构）服务器上部署Harbor v2.4.0镜像仓库工具，是很多国产化替代项目里的第一个硬骨头。官方默认安装包大多面向amd64，直接拿x86的离线包到飞腾、鲲鹏机器上装，prepare阶段就会报错，甚至镜像加载完成也拉不起容器。而harbor-offline-installer-v2.4.0-aarch64.tgz这个离线包，把Harbor核心镜像、安装脚本、配置模板全打成了aarch64版本，配合麒麟V10 SP3常见环境，一次prepare、install就能把仓库跑起来。这篇文章基于我实际拆包部署的完整过程，从版本核对到推送镜像再到对接k8s拉取，把命令、参数和翻车点写透。适合手里只有ARM64银河麒麟机器、想在纯内网搭镜像仓库的运维和开发。

2. 部署前准备：核对麒麟V10版本、ARM64架构与Docker环境

2.1 为什么必须选aarch64离线包，以及如何核对系统底子

Harbor从v2.x开始，官方在release里同时发布amd64和arm64两种离线安装包。harbor-offline-installer-v2.4.0-aarch64.tgz里的harbor.v2.4.0.tar.gz是已经打好tag的镜像包，内部所有容器镜像都是aarch64架构。如果你在飞腾FT-2000+、鲲鹏920这类ARM64 CPU上强行用amd64包，docker load阶段大概率不会报错，但启动容器时会直接提示“bad linux arm64 image magic”之类的错误，原因就是镜像层平台不匹配，内核不认。

拿到机器后第一步不是解压安装包，而是确认系统、架构和内核版本。常规做法是执行下面三条命令：

cat /etc/os-release uname -m uname -r

命令里各参数的含义：

• cat /etc/os-release：查看是不是Kylin V10以及具体SP版本。我这边是银河麒麟V10 SP3，kernel版本5.4.x。SP1、SP2、SP3在docker和containerd兼容性上差异不大，但SP3默认的yum源里python、openssl版本更高，对Harbor v2.4.0的prepare二进制更友好。
• uname -m：必须显示aarch64，这是ARM64跑起来的前提。如果显示x86_64，说明装的还是amd64系统，那用aarch64包也会出问题。
• uname -r：内核版本，建议4.19以上。我在麒麟V10 SP1上遇到过内核4.19.18的机器，overlayfs和iptables兼容性一般，nginx容器起来后端口映射异常，后来升到5.4问题消失。

这里顺便提一句qemu模拟arm64：如果你手上没有真机，只会在一台x86服务器上用qemu-system-aarch64模拟ARM64环境，我建议别把它当成生产验证环境。qemu模拟的CPU性能很低，Harbor七个容器全部启动可能需要十几分钟，而且模拟环境下docker的overlay2驱动偶尔出现页缓存异常，结论不能代表真实飞腾机器。有条件一定要用真机。

2.2 安装Docker与docker-compose：看清Harbor到底调用哪个命令

麒麟V10自带的yum源里默认没有docker-ce，直接执行yum install docker装出来的是1.13时代的“docker”包，那个跑不起来Harbor v2.4.0。现场有两种路线。

第一种，机器能连外网，直接加docker官方yum源。注意银河麒麟V10兼容CentOS 8，repo路径要用linux/centos/docker-ce.repo，不要用CentOS 9路径：

yum install -y yum-utils yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y docker-ce docker-ce-cli containerd.io

第二种，内网环境没有外网，那就找一台能联网的AMD64机器，把arm64版本的rpm包下载好拷进去，再rpm -ivh。这一步最容易翻车的是误下成x86_64的包，教大家一个快速判断法：

file docker-ce-20.10.9-3.el8.aarch64.rpm

输出里会带ARM aarch64字样。如果是x86_64的rpm，在aarch64机器上安装时yum会直接报“wrong architecture”。

docker-compose方面，Harbor v2.4.0的install.sh内部调用的是docker-compose命令，不是docker compose子命令。compose v2已经变成了docker的子命令，很多教程让你直接装v2，结果install.sh报“command not found”。我一般固定用v1.29.2的aarch64二进制：

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

注意下错版本时的表现：x86_64的compose二进制放在aarch64机器上，执行时会报Exec format error，而不是提示版本不对。这个错误非常容易误判成权限问题。另外，麒麟V10自带yum源里如果已经有老版docker-compose python包，建议先yum remove docker-compose再放二进制，否则which docker-compose会先找到yum装的旧版，导致Harbor觉得版本太老直接拒绝启动。

2.3 初始化数据目录、关闭防火墙与放行端口

Harbor默认监听80和443端口。安装前建议先确认这两个端口没被其他服务占用：

ss -lntp | grep -E ':80|:443'

如果被占用，后面harbor的nginx容器会反复重启。在麒麟V10上常见的是httpd或caddy占着80。占用时有两个选择：改Harbor的http.port，或者停掉占用服务。我习惯把Harbor放在独立服务器上，直接把防火墙关了：

systemctl stop firewalld systemctl disable firewalld setenforce 0

这里有一个很隐蔽的坑：麒麟V10默认selinux状态是enforcing，直接停firewalld不关selinux，Harbor的数据卷data_volume如果正好放在某个带特殊SELinux上下文的位置，nginx容器往里面写缓存文件时会报权限拒绝，而且日志里只显示“permission denied”。所以上面两行是一起执行的。如果公司安全规范强制要求开selinux，那要写好多安全上下文规则，不太划算，内网环境一般直接关。

数据目录也要提前规划好。Harbor离线包解压后大约2GB，镜像加载后占用大约8~10GB，再加上数据库和registry镜像存储，一个初始化的Harbor仓库大概要吃15GB。我一般给/data单独分50GB以上。检查磁盘：

df -h /data

如果/data空间紧张，至少保证:Warning，否则后面docker load -i harbor.v2.4.0.tar.gz一执行，磁盘马上写满，docker daemon进入只读状态，还会连累其他容器。注意确认harbor.yml里的data_volume路径最好也放在这个盘下。

时钟同步也得提前做。Harbor的nginx容器启动时会校验服务端证书有效期，如果机器时钟漂移严重，刚生成的自签证书显示“not yet valid”，所有https请求全部失败。麒麟V10默认带chrony，执行一下：

systemctl enable chronyd systemctl start chronyd chronyc sources -v

chronyc sources -v能看到时钟源是否处于^*状态，一个星号都没有说明没同步成功，这时候生成的证书和后续的docker登录都会踩x509时间坑。这段虽然不起眼，但生产环境里我排查过好几次都是挂在时钟上。

3. 修改harbor.yml与执行install.sh：从自签证书到仓库初始化

3.1 解压离线包并理解它的文件结构

先把aarch64离线包放到目标机器的/tmp或/root目录，然后建一个专门的部署目录：

mkdir -p /opt/harbor_install cd /opt/harbor_install tar -zxvf /tmp/harbor-offline-installer-v2.4.0-aarch64.tgz cd harbor ls -l

解压后的关键文件如下：

这里必须强调的是：别从Windows解压tar再上传文件。tar在Linux下带有软链接和可执行权限位，Windows解压会把这些信息丢掉。我见过有人把整个目录在Windows下解压后用ftp传上去，文件都在，但install.sh无法执行，因为权限位变成了普通文本文件。正确做法是把tar原封不动传到Linux机器上再解压。

解压后先校验一下install.sh和prepare有没有执行权限：

ls -l install.sh prepare

如果-rw-r--r--没有x，执行：

chmod +x install.sh prepare common.sh cert.sh

3.2 修改harbor.yml：hostname、密码、端口与数据目录

官方模板harbor.yml.tmpl不能直接用，必须复制成harbor.yml：

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

列出最关键的配置段并解释每个参数：

hostname: 192.168.209.133 http: port: 80 https: port: 443 certificate: /data/certs/harbor.crt private_key: /data/certs/harbor.key harbor_admin_password: Harbor12345 database: password: HarborDB123 max_idle_conns: 50 max_open_conns: 100 max_lifetime: 10m data_volume: /data/harbor log: level: info rotate_count: 10 rotate_size: 50M quota: per_project_enabled: true

参数说明：

• hostname：必须写内网IP或域名，这是Harbor对外访问的唯一入口。写localhost的话，本机浏览器能打开页面，但docker push会去访问“localhost”，客户端解析的却是自己的回环地址，镜像怎么都推不上去。我推荐直接用IP，省去内网DNS配置。
• http.port、https.port：默认80、443。如果这两口被占，可以改成8080、8443，但要连带改docker客户端的insecure-registries和登录端口。后面推送命令里必须带端口号。
• https.certificate和private_key：证书路径一定要写绝对路径。这里的坑在于，如果你用的相对路径，Harbor的prepare阶段不一定报错，但nginx容器启动时挂载不到证书文件会一直重启。
• harbor_admin_password：admin初始密码，最少8位，必须同时包含大写、小写和数字。这里设置的密码是给web登录和docker login初始用的。
• database.password：Harbor内置postgres数据库的密码，同样要不少于8位且够复杂。强烈建议和管理员密码区分开。
• max_idle_conns、max_open_conns：数据库连接池参数。连接数开太小，多项目并发推送时会出现“database: too many connections”。按你的并发量调，默认值一般够用。
• data_volume：镜像、数据库、缓存的所有存储根目录。生产环境一定要放到独立大分区，并且备份时只需要备份这个目录。
• quota.per_project_enabled：表示是否开启每个项目的配额，开启后可以在web台上按项目限制存储空间。这个配置对多团队共用仓库很重要，默认是true，不用改。

注意yaml里的冒号后面必须有空格，否则Harbor的prepare读取配置时会直接报“Failed to parse yaml file”。改完文件后强烈建议做一次语法检查：

python3 -c "import yaml; print(yaml.safe_load(open('harbor.yml')))"

麒麟V10自带的python3可能没有yaml模块，会报ModuleNotFoundError。这时可以改用：

cat -A harbor.yml | grep -n '\^M'

凡是带^M的行都是Windows换行符，需要整体转换。用sed -i 's/\r$//' harbor.yml清理掉。

3.3 用cert.sh生成自签证书，注意CN与SAN的一致性

如果你的内网没有正式CA，Harbor提供了cert.sh脚本生成自签证书。它的用法：

./cert.sh 192.168.209.133

它会生成私钥harbor.key和证书harbor.crt，放到指定路径。这里有一个非常关键的点：cert.sh生成的证书默认可能不包含SAN扩展。Go 1.15之后的docker客户端在验证证书时，不再只看Common Name，必须检查SAN。如果SAN里没有你的IP或域名，docker login会报：

x509: cannot validate certificate for 192.168.209.133 because it doesn't contain any IP SANs

碰到这个问题，不要急着改docker配置，直接用openssl重新生成：

mkdir -p /data/certs cd /data/certs cat > openssl.cnf <<'EOF' [req] distinguished_name = dn req_extensions = ext prompt = no [dn] CN = 192.168.209.133 [ext] subjectAltName = IP:192.168.209.133 extendedKeyUsage = serverAuth EOF openssl req -newkey rsa:2048 -nodes -keyout harbor.key -x509 -days 3650 -config openssl.cnf

生成后检查：

openssl x509 -in harbor.crt -text -noout | grep -A2 "Subject Alternative Name"

确认输出里有IP Address:192.168.209.133，再更新harbor.yml中的certificate和private_key路径。另外注意到，cert.sh在部分离线包版本里写的证书路径是相对路径，导致prepare时找不到密钥。所以无论用哪个脚本，最终都要确认/data/certs/harbor.crt和/data/certs/harbor.key两个文件存在：

ls -l /data/certs/

3.4 执行prepare和install.sh：分步执行比一把梭更可控

直接执行：

./install.sh

会依次完成四件事：docker load -i harbor.v2.4.0.tar.gz加载镜像、./prepare生成配置文件、docker-compose up -d启动容器、最后做健康检查。第一次执行比较慢，因为镜像文件约1GB，加载需要几分钟。我不想等的时候会先单独加载镜像，再单独跑prepare，能清楚看到是哪一步出的问题：

docker load -i harbor.v2.4.0.tar.gz ./prepare docker-compose up -d

分开执行的好处是：docker load输出的“Loaded image”列表能确认镜像是否包含aarch64架构；./prepare能提前暴露配置语法和目录挂载问题；最后docker-compose up -d才是真正启动容器。如果一步到位install.sh，出现错误时你不容易判断是镜像损坏还是配置问题。

prepare阶段如果成功，会在当前目录生成docker-compose.yml，这就是Harbor真正启动的编排文件。你可以打开看一眼，里面包含了nginx、registry、harbor-core等服务的定义。查看容器状态：

docker ps

标准情况下会有以下容器在运行：

如果某个容器处于Restarting状态，不要立刻重跑install.sh，先看日志：

docker logs harbor-core --tail 100

最常见的错误是：

• failed to connect to database：数据库容器还没起来，或数据库密码不对。
• EOF或connection refused：nginx容器启动慢，等待重试即可。

这里有一个容易被误判的现象：第一次启动时，harbor-core会等harbor-db完成postgres初始化，这个过程在ARM64真机上大约30秒。如果你用qemu模拟ARM64环境，可能要等3-5分钟，期间日志里一直出现“dial tcp ... connection refused”。这不是故障，是初始化还没完成。我的建议是多等一会儿，不要看到失败日志就重装。

3.5 HTTP模式与HTTPS模式的选择：内网部署的最省事路径

如果你不想花时间弄证书，这里有个非常务实的方案：直接关闭HTTPS，只用HTTP跑内网。改harbor.yml时把https段整个注释掉或删除：

hostname: 192.168.209.133 http: port: 8080 # https: # port: 443 # certificate: /data/certs/harbor.crt # private_key: /data/certs/harbor.key

注意：harbor.yml里不能保留空的https:键，prepare阶段会报错“https configuration is empty”。然后把http.port设成非特权端口8080，避免和其他服务冲突。执行./prepare和docker-compose up -d后，所有客户机都要在docker daemon里把这个地址加入insecure-registries：

{ "insecure-registries": ["192.168.209.133:8080"] }

改完daemon.json后必须：

systemctl restart docker

这样docker login、tag、push都要带端口号。内网测试环境这么跑最省事，但要注意，docker客户端访问HTTP仓库时必须显式加端口，否则默认走443，会直接超时。生产环境如果安全要求严格，建议把HTTPS做规范，毕竟Harbor的web页面管理员密码、镜像标签都是明文HTTP传输，有被内网嗅探的风险。

4. Harbor部署避坑：五条会翻车的现场记录与排查

4.1 推送失败：dial tcp IP:端口 connect: connection refused

现象：执行docker push时报：

Get "https://192.168.209.133/v2/": dial tcp 192.168.209.133:443 connect: connection refused

原因：Harbor实际监听的端口和docker客户端访问的端口不一致。比如你配置的是http.port: 8080，但docker登录时写的是docker login 192.168.209.133，没带端口，docker默认走443，当然连不上。还有一种情况是https.port配置了443但证书路径配错，nginx容器起不来，443端口就没有监听。

解决：先看端口：

ss -lntp | grep -E ':80|:443|:8080'

如果Harbor监听的是8080，那docker命令里所有地址都要写192.168.209.133:8080。同时检查daemon.json里的insecure-registries是否也带上了端口。注意insecure-registries里写的端口必须和harbor.yml里http.port一致，少写一个冒号都连不上。这个坑在k8s节点上尤其常见，因为kubelet和containerd各自配置一套，漏掉一个就会出现“镜像拉不到”。

4.2 镜像加载后容器一直重启：看harbor-log而不是harbor-core

现象：docker ps里harbor-log状态为Restarting，或者过几秒钟反复重启。执行docker logs harbor-log时却发现几乎没内容。

原因：Harbor的日志容器负责收集所有容器日志，如果它起不来，通常是因为宿主机上/var/log/harbor目录权限不对，或者日志轮转参数rotate_count、rotate_size设置不合法。我遇到过安全加固过的麒麟V10，把/var/log挂成了只读，harbor-log往里写日志直接失败。

解决：先去看真正的系统日志，而不是harbor-log自己的日志：

docker inspect harbor-log | grep -i mount ls -la /var/log/harbor

确保该目录存在且属主是root、权限755。然后修改harbor.yml里的log段，把rotate_size改小一点再重新prepare。如果还不行，检查磁盘inode是否耗尽：

df -i /var/log

inode满也会导致日志文件创建失败。现场排查时不少新手被“harbor-log重启”误导，疯狂改数据库配置，其实是日志目录的问题。所以先看docker logs没内容，就一定优先查宿主机目录。

4.3 docker login报x509错误：证书信任与daemon配置没有同步

现象：执行docker login时报：

Error response from daemon: Get "https://192.168.209.133/v2/": x509: certificate signed by unknown authority

原因：Harbor用的是自签证书，docker daemon默认不信任它。很多人拿到报错后去改harbor.yml，以为服务端要修，其实问题出在客户端。客户端必须在/etc/docker/daemon.json里把Harbor地址加入insecure-registries，或者把Harbor的ca.crt放到/etc/docker/certs.d/目录下。

解决：两种方式任选其一。第一种跳过证书校验：

{ "insecure-registries": ["192.168.209.133:8080"] }

第二种正规的证书信任方式：

mkdir -p /etc/docker/certs.d/192.168.209.133:8080 cp /data/certs/harbor.crt /etc/docker/certs.d/192.168.209.133:8080/ca.crt systemctl restart docker

注意目录名必须是“IP:端口”的形式，和你在docker login里写的一致。如果端口变了，目录名也要变。另外，如果用的是域名hostname，目录名就是“域名:端口”。我习惯用证书方式，因为insecure-registries会让所有镜像对话都跳过加密，安全审计过不了。改完daemon.json必须重启docker，这个动作很多人漏掉，然后反复纠结证书内容。

4.4 prepare阶段报“Compose version not compatible”

现象：执行./install.sh或./prepare时输出：

ERROR: Docker Compose version is not compatible

原因：Harbor v2.4.0的脚本里对docker-compose版本有下限要求。如果你的compose是v1.9.x这类远古版本，或者装的是v2.x但以docker compose子命令形式存在，都会触发这个错误。更有意思的情况是，机器上同时存在python版compose和二进制版compose，PATH里先找到的是python版。

解决：统一使用v1.29.2的aarch64二进制。先清理旧版本：

yum remove docker-compose -y rm -f /usr/local/bin/docker-compose /usr/bin/docker-compose which docker-compose

然后把下载的aarch64二进制放到/usr/local/bin并验证：

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

确认输出为docker-compose version 1.29.2。这里有个习惯：安装任何软件前先执行which确认没有旧版残留，能省掉后面排查的半小时。

4.5 数据目录或证书相对路径导致nginx容器挂载失败

现象：harbor-nginx容器启动后马上退出。查看日志：

nginx configuration test failed

原因：harbor.yml里data_volume和certificate用的是相对路径，没有用绝对路径。prepare在生成配置文件时把相对路径原样写进了docker-compose.yml，nginx容器挂载时找不到这些目录，直接失败。我遇到过把data_volume: ./data写进配置的，容器起来后所有镜像存储都写到了容器内部，重启后数据全丢。

解决：harbor.yml里所有路径一律用绝对路径。最稳的方式：

mkdir -p /data/harbor mkdir -p /data/certs

然后修改harbor.yml：

data_volume: /data/harbor https: certificate: /data/certs/harbor.crt private_key: /data/certs/harbor.key

修改后别直接docker-compose up -d，先重新执行./prepare，再启动。如果之前已经跑过install.sh，修改路径后要清掉旧的容器层：

docker-compose down -v

-v会删除volumes中的旧数据，所以只有确认旧数据没用时才加。如果你是在部署阶段反复调试，目录搞乱了可以直接删掉重来；如果已经在线运行，必须先把/data/harbor备份好。

4.6 给避坑章的最后提醒

避坑章列到第五条，还想单独强调一点：遇到Harbor出了问题，很多人的第一反应是反复重跑install.sh。其实install.sh是幂等的，重跑不会修复配置错误，反而会掩盖日志里的真实报错。正确做法是，先看docker ps里哪个容器在重启，再去看对应容器的日志：harbor-db对应数据库错误，harbor-core对应API连接错误，nginx对应证书和端口问题。把每条日志都读完整，比盲目重装有价值得多。

5. 验证与进阶：从push/pull到对接K8s与版本升级

5.1 打通第一条基线：登录、建项目、推送、拉取

仓库启动后，先做一条完整的端到端验证。假设是HTTP模式：

docker login 192.168.209.133:8080 -u admin -p Harbor12345 docker tag busybox:latest 192.168.209.133:8080/library/busbox:latest docker push 192.168.209.133:8080/library/busbox:latest docker pull 192.168.209.133:8080/library/busbox:latest

docker tag时写的仓库名要包含项目路径，library是Harbor默认公共项目。推送前最好先执行docker pull busybox确认本地有基础镜像。如果push过程很慢，先检查网络，再考虑是否要调整Harbor的nginx配置。验证通过后，再在另一台机器上执行同样的pull，确认跨主机访问没问题。这一步很关键，很多部署只在服务器本机验证，本机能拉不代表k8s节点能拉。

5.2 对接K8s：imagePullSecret与containerd配置

K8s节点从Harbor拉取私有镜像，需要创建docker-registry类型的Secret：

kubectl create secret docker-registry harbor-secret \ --docker-server=192.168.209.133:8080 \ --docker-username=admin \ --docker-password=Harbor12345 \ --namespace=default

然后在deployment的spec里指定：

spec: imagePullSecrets: - name: harbor-secret

如果k8s节点用的是containerd而非docker，还需要配置/etc/containerd/config.toml。找到[plugins."io.containerd.grpc.v1.cri".registry]区段，加上Harbor的地址和证书目录。这一步最容易漏，漏掉的报错通常是“failed to pull image ... not found”或者“connection refused”。我在k8s集群里排查过一次，deployment一直ImagePullBackOff，结果发现只有三个节点里两个配了containerd，默认没加registry。这个坑在国产化环境特别常见，因为很多k8s集群底层用的是containerd。

5.3 保留镜像数据的版本升级：从v2.4.0到后续版本

Harbor版本升级在ARM64环境里的坑比部署多一些。从v2.4.0升级，先备份数据库和镜像数据：

cp -r /data/harbor /data/harbor_backup_$(date +%F)

然后下载对应新版本的aarch64离线包，解压后用新的harbor.yml覆盖旧配置，但不要无脑覆盖，先对比差异：

diff harbor.yml /opt/harbor_install/harbor/harbor.yml

新版本的参数如果和旧版不兼容，prepare阶段会提示。Harbor的install.sh会自动执行数据库migration，不需要手动升级数据库。我在这里的经验是：升级前必须确认新旧版本之间允许跨版本升级，官方release notes里一般会写升级路径。比如从v2.4.0到v2.6.0要分两步升，不能直接跳到v2.10.0。一旦升级失败，用备份目录回滚，而不是手动改数据库结构。

5.4 我踩过的坑与形成的手感

那次改数据库密码的教训很深。当时只是把admin密码改了一下，以为docker-compose down再up就够了，结果harbor-core一直连不上库，最后发现数据库卷里的postgres密码还是旧值。从那以后，我每次操作数据库密码或admin密码都会强制走一遍“备份→down -v→清data_volume→重新install”的流程。另外，每一次在麒麟V10上装Harbor，我都要先打印uname -m、docker version和docker-compose version三行命令，确认架构与版本无误后再动手。虽然慢一点，但避免了后面几小时的排错。希望这些记录能帮你在同样的ARM64环境里少走弯路。

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