企业官网建设流程全解析

简介：面向ARM64架构（如树莓派、ARM服务器）的Docker与Docker Compose离线安装包，为开发者、运维人员提供免编译的容器运行环境交付方案，解决手动下载依赖、逐项配置易出错的问题。压缩包共5个文件，包含一键安装脚本、Docker 19.03.9稳定版tgz压缩包、docker-compose可执行文件、systemd服务文件及日志配置脚本，整体61.54MB。已有4174人学习下载，尤其适合无法访问外网的内网环境，或需要在多台ARM设备上批量部署容器的项目。安装脚本自动完成依赖检查、二进制安装、服务注册与开机自启，并适配ARM64平台特有的权限与兼容性细节；借助docker-compose，可通过YAML定义多容器服务，实现微服务或边缘应用的一次配置、快速启动。日志配置脚本还能帮助调整容器日志策略，便于后期排查与维护，让树莓派等低功耗设备上的容器化部署更省心。 最近后台收到不少私信，都在问“arm64 docker安装包”到底怎么下、怎么装。原因我也理解：苹果 M 系列芯片普及之后，Windows 笔记本也出了骁龙 X 系列这种 ARM 架构的机器，再加上树莓派、各类国产 ARM 开发板玩家越来越多，大家突然发现 Docker 不是随便下一个安装包就能跑起来的。我当年第一次在 ARM 板子上装 Docker，随手下了个 x86 的安装包，装完一运行直接报 Exec format error，当场傻眼。

这篇就把 arm64 装 Docker 的完整链路捋一遍：怎么判断自己机器的架构、各平台安装包怎么选、Docker Desktop 安装报错怎么排查、镜像下载慢怎么解决，最后再用 MySQL 8.0 和 Redis 主从两个例子带你把容器跑起来。想认真玩 Docker 的，无论你是新手还是从 x86 转过来的老手，这篇都能帮你少踩几个坑。

1. 装之前先把架构搞明白：arm64 和 amd64 到底差在哪

1.1 一条命令识别当前架构

先别急着下载安装包，第一步一定是确认你机器的 CPU 架构。我自己排查问题的时候发现，很多人根本分不清uname -m和arch输出代表什么，结果装错了包还以为是软件的问题。

macOS 和 Linux 终端里跑这条命令：

uname -m

输出结果常见两种：

• x86_64或amd64：Intel 或 AMD 的 64 位处理器，最普及的桌面和服务器架构。
• aarch64或arm64：64 位 ARM 处理器，苹果 M 系列、高通骁龙笔记本芯片、树莓派 4B/5 都是这类。

Windows 上不用终端也行，直接在 PowerShell 里敲：

echo $env:PROCESSOR_ARCHITECTURE

输出AMD64就是 x86 架构，输出ARM64就是 ARM 架构。

简单类比：amd64 和 arm64 的关系就像汽油车和电动车，虽然都是车，但加油口和充电口完全不一样。Docker 安装包和容器镜像也一样，每种架构各有各的二进制文件，混着用是跑不起来的。

1.2 为什么安装包必须区分架构

Docker 本身是 Go 语言编译的，Go 在编译时会针对不同 CPU 架构生成对应的机器码，所以官方需要分别发布 amd64 和 arm64 的安装包。这个区别不仅体现在安装包上，容器镜像同样有架构之分。

你在 Docker Hub 上拉镜像时，Docker 会根据当前主机的架构自动选择对应平台的镜像层。比如mysql:8.0官方镜像就是一个多架构镜像（multi-arch），在 x86 机器上拉取的是 amd64 版本，在 ARM 机器上拉取的是 arm64 版本。这也是为什么很多软件下载页面会同时提供Windows x86_64和Windows ARM64两个安装包，包括热词里提到的download for windows amd64和download for windows arm64的区别，本质就是二进制指令集不同。

顺带说一句，安卓手机装软件时常见的arm64-v8a包也是同一个逻辑——手机处理器基本都是 ARM 架构，所以安卓安装包基本都是 arm64 的。理解了这套命名规则，以后看到任何带架构后缀的软件包都不会选错。

1.3 一个容易误判的场景

有些朋友在 Windows 设置里看到系统类型写的是“基于 x64 的处理器”，就误以为自己的机器是 amd64。但要注意，如果电脑是骁龙 X Elite 芯片，系统信息里会明确写“基于 ARM 的处理器”，此时哪怕你用的是 Windows 11，Docker 也必须装 arm64 版本。

还有一种特殊情况：x86 电脑上的虚拟机里跑 ARM 系统，或者反过来 ARM 电脑上用模拟器运行 x86 环境。这种场景下该装哪个安装包，要看 Docker 最终运行在哪个平台上，也就是看虚拟机里系统报告的架构，而不是物理机的架构。说实话这种嵌套场景不太适合新手折腾，后面遇到容器跑不起来的时候，优先检查架构匹配度就对了。

2. 主流平台 arm64 Docker 安装包怎么选

2.1 Windows on ARM：认准 arm64 安装包

Windows on ARM 设备这两年越来越多了，装 Docker 首选是 Docker Desktop。在 Docker 官方的 Release Notes 页面，每个版本都会同时提供Docker Desktop Installer-amd64.exe和Docker Desktop Installer-arm64.exe两个安装包，下载的时候务必选arm64那个。

安装前提有三条，缺一不可：

• 系统必须是 Windows 11（Windows 10 对 ARM 虚拟化的支持太差，官方也基本放弃了）。
• 必须启用 WSL2，Docker Desktop 在 Windows 上的默认后端就是 WSL2。
• BIOS 里必须开启虚拟化技术（Intel VT-x 或 AMD-V，ARM 芯片对应的是虚拟化扩展）。

我在骁龙 X Elite 的笔记本上实测过，装好 arm64 版 Docker Desktop 后跑常用容器问题不大，MySQL、Redis、Nginx 都没遇到坑。但如果你下载时手滑选成了 amd64 版，安装过程可能不会立刻报错，启动 Docker Engine 时就会卡住。

2.2 Linux 各发行版：不需要单独下安装包

Linux 下装 Docker 其实最省心，因为发行版的软件源会自动匹配当前架构。Ubuntu、Debian 系的 ARM 设备（树莓派、瑞芯微开发板等）直接：

sudo apt update sudo apt install docker.io -y sudo systemctl enable --now docker

CentOS、Fedora 系用dnf install docker-ce或者yum install docker，同样由软件源自动处理架构问题。如果你非要装 Docker 官方源，按照官网的 apt 仓库配置步骤操作，安装时同样会自动匹配 arm64 包，不需要手动指定。

需要提醒的是，开发板上的系统如果太老，软件源里可能没有 docker.io，或者版本比较旧。建议先把系统更新到较新的 LTS 版本再装。

2.3 macOS Apple Silicon：选 Apple Silicon 版本

macOS 上装 Docker 相对简单，Docker Desktop 官网会根据你的 Mac 芯片自动推荐下载版本。M 系列芯片下载 Apple Silicon 版，Intel Mac 下载 Intel 版，两个安装包的 download 文件在官网顶部就能区分。

有个容易踩的坑：有时候你在搜索引擎找下载链接，搜出来的可能是 Intel 版安装包。M 系列 Mac 强行装 Intel 版也能装上，但 Docker 会通过 Rosetta 转译运行，性能和稳定性都会打折扣。打开安装包之前先看一眼文件名，Apple Silicon 版通常标注了-arm64后缀，Intel 版标注-amd64。

2.4 离线安装包的下载与校验

内网环境或者网络条件差的场景，需要提前下载好离线安装包。去 Docker 官方 Release Notes 页面找对应平台的安装包时，先确认文件名里的架构标识，再确认版本号，别拿旧版本的安装包去配新系统。

下载完成后建议校验一下文件哈希，防止下载损坏。Linux 下用 sha256sum：

sha256sum Docker-Desktop-Installer-arm64.exe

然后和官网公布的 SHA256 值比对，一致再安装。我在树莓派上下载过几次安装包，网络一抖就会出现文件损坏，安装时莫名其妙报错，排查到最后发现是哈希对不上。

3. Windows 上安装 Docker Desktop 的完整实操与报错排查

3.1 安装前准备：开启虚拟化和 WSL2

Windows 装 Docker Desktop 最容易卡住的就是环境准备。打开任务管理器，切到“性能”标签，点击“CPU”，看右下角“虚拟化”是否显示“已启用”。如果显示“已禁用”，需要重启进 BIOS 开启虚拟化技术。

虚拟化开好之后，以管理员身份打开 PowerShell 启用 WSL 功能：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

然后重启电脑，再执行：

wsl --update wsl --set-default-version 2

以上两步都完成之后，再双击 arm64 版 Docker Desktop 安装包。安装时按默认选项走，但注意安装界面有一个“Use WSL 2 instead of Hyper-V”的勾选，保持勾选状态。

3.2 安装过程演示和首次启动验证

安装完成后第一次启动 Docker Desktop，系统可能会弹出 WSL 内核更新的提示，按提示装完、重启 Docker Desktop 就行。首次启动需要等一会儿，右下角鲸鱼图标会从“Docker Desktop is starting”变成“Engine running”。

启动完成后开 PowerShell 验证：

docker version docker info

docker version能看到 Client 和 Server 两部分版本信息，注意 Server 部分不能为空。docker info里查看Architecture一栏，arm64 机器上应该显示aarch64。看到这个输出就说明 Docker 已经正常工作了。

3.3 高频报错：virtualisation support wasn't detected

很多人在这一步翻车，启动 Docker Desktop 直接弹窗报错：Docker Desktop failed to start because virtualisation support wasn't detected。我帮朋友排查过几次，原因大概有这几种：

• BIOS 里虚拟化没开或者被关了，这是最常见的原因。
• Windows 的“虚拟机平台”可选功能没启用。
• 系统版本过旧，部分 Win10 的 WSL2 支持不完整。
• 已安装的 Hyper-V 和 WSL2 冲突。

排查顺序建议是：先回任务管理器确认虚拟化已启用；再跑一遍上面提到的两条 dism 命令，重启；然后执行wsl --status确认 WSL2 是默认版本。最后一个容易忽略的点是 Windows 安全中心里的“内核隔离”和“基于虚拟化的安全”有时会干扰 Docker 的虚拟化检测，可以暂时关闭再试一次。

我自己在 Surface Pro X 上遇到过一次，折腾到最后发现是 Windows 预览版的一个已知 bug，后来更新系统之后就好了。所以如果你所有配置都正确还是报这个错，先更新 Windows 到最新版本。

4. arm64 镜像下载慢的解决办法：镜像源配置实操

4.1 现象：拉到一半卡住、超时

Docker 装好了，但要拉镜像时又遇到新问题——默认的 Docker Hub 镜像源在国内网络环境下经常超时。这不是 arm64 独有的问题，amd64 也一样，但 ARM 设备很多是开发板，网络环境本来就一般，症状会更明显。

docker pull命令执行半天，进度条卡在某个百分比不动，最后报net/http: TLS handshake timeout。解决办法是给 Docker 配置镜像加速器，原理就是让 Docker 从一个访问更快的镜像仓库拉取镜像层。

4.2 配置 daemon.json 加速器

Linux 下编辑 Docker 配置文件：

sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com", "https://docker.nju.edu.cn" ] } EOF sudo systemctl daemon-reload sudo systemctl restart docker

Windows Docker Desktop 上不用手动改文件，打开 Settings -> Docker Engine，在 JSON 配置里加同样的registry-mirrors字段，点 Apply & Restart 让 Docker 重启即可。

配置完后用docker info查看Registry Mirrors一栏，能看到列表就说明生效了。然后再重新拉镜像，速度会明显改善。需要说明的是：加速器只会加速配置列表中的镜像仓库下载，拉取原始 Docker Hub 直连地址的超时问题，加速器能缓解但无法保证 100% 覆盖所有情况。我实际使用下来，拉最常见的mysql、redis、nginx这些官方镜像基本没问题。

4.3 拉取前先确认镜像架构

配置好加速器之后，还要留个心眼确认拉取的是不是 arm64 镜像。大多数官方镜像都是多架构的，Docker 会自动适配；但有些第三方镜像只发布了 amd64 版本，在 ARM 机器上拉下来虽然能下载成功，但运行时会直接报exec format error。

拉取前可以用docker manifest inspect查看镜像支持的架构：

docker manifest inspect mysql:8.0

输出中会有一个platform列表，能看到architecture: "arm64"和architecture: "amd64"。只有一个架构的话，就要检查一下是否符合你的设备。如果确实需要用某个只有 amd64 版的镜像，可以在拉取时显式指定架构，但运行性能会有损耗，而且不支持所有镜像：

docker pull --platform linux/amd64 镜像名:tag

这个命令在 ARM 主机上会通过仿真运行 amd64 容器，像 MySQL 这种重负载场景用起来能跑，但性能损失明显，不建议生产环境这么干。

5. 装完就练手：arm64 环境跑 MySQL 8.0 和 Redis 主从

5.1 MySQL 8.0 容器部署

Docker 跑 MySQL 8.0 是最经典的练手场景。先拉镜像：

docker pull mysql:8.0

然后运行容器：

docker run -d \ --name mysql-test \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=root123 \ -v mysql-data:/var/lib/mysql \ mysql:8.0

简单说明一下参数含义：-d是后台运行，--name指定容器名，-p 3306:3306把宿主机 3306 端口映射到容器的 3306，-e设置环境变量（这里设置 root 密码），-v mysql-data:/var/lib/mysql是数据卷挂载，作用是把 MySQL 数据存到宿主机上，容器删除后数据依然保留。

验证是否启动成功：

docker ps docker exec -it mysql-test mysql -uroot -proot123

能进入 MySQL 命令行就说明部署成功。arm64 机器上跑 MySQL 8.0 官方镜像非常稳定，我在树莓派 4B 上测过，小规模数据读写完全没问题。

5.2 Redis 主从搭建

Redis 主从是理解读写分离的入门案例。先启动主节点：

docker run -d --name redis-master -p 6379:6379 redis:7

再启动从节点，通过--slaveof参数指定主节点地址（容器网络里直接用容器名访问）：

docker run -d --name redis-slave -p 6380:6379 --link redis-master redis:7 redis-server --slaveof redis-master 6379

验证主从关系：

docker exec -it redis-slave redis-cli info replication

看到role:slave以及master_link_status:up，说明主从已经同步成功。在主节点写入数据，从节点能查询到，基本就理解了 Redis 主从的工作方式。

5.3 实操提醒：数据卷和端口冲突

跑 MySQL 和 Redis 时有两个注意事项。第一是容器删除前先想想数据卷要不要保留，docker run时挂载了数据卷还好说，没挂载的话容器一删数据就没了，我踩过这个坑，删容器之前还确认过数据，结果没想到连容器一起删掉了。第二是端口冲突，宿主机上已经跑了 MySQL 或 Redis 时，-p 3306:3306会启动失败，报port is already allocated，换个宿主机端口映射即可，比如-p 3307:3306。

6. 常见问题速查与我的避坑心得

6.1 问题速查表

6.2 我实测下来的几个心得

最后分享几条我在 arm64 设备上折腾 Docker 的真实感受。

第一条，能用官方镜像就别用第三方镜像。官方镜像基本都是多架构自动适配，第三方镜像很多只构建了 amd64。我需要在 ARM 设备上跑某个工具时，经常发现只有 amd64 版本，要么用--platform硬跑模拟，要么自己写 Dockerfile 构建。有这功夫，直接找官方镜像或者带 arm64 标签的替代品更快。

第二条，ARMac 设备的内存通常不大，开发板普遍 4G 到 8G，跑几个容器内存就吃紧了。如果发现容器莫名其妙被 kill，大概率是 OOM。建议运行容器时加上资源限制：

docker run -d --memory=512m --cpus=2 镜像名:tag

或者干脆用docker compose管理，在 compose 文件里配置deploy.resources.limits。

第三条，热词里提到的青龙面板这类国产项目，在 ARM 设备上安装时经常遇到依赖缺失问题。原因是基础镜像只包含最小运行环境，缺少 Python、Node 等运行时依赖。这时候先别急着在 Dockerfile 里折腾，直接docker exec -it 容器名 bash进容器手动补依赖，确认哪些依赖缺失再固化到 Dockerfile 里，效率高很多。

最后再分享一个小技巧：容器命令一长串记不住，尤其是带了一堆参数的时候。我后来习惯把常用的容器定义写成一个docker-compose.yml文件，启动时直接docker compose up -d，比每次敲一串docker run参数好维护多了。ARM 设备上玩 Docker 最怕的就是“起了服务但不知道怎么管理”，写好 compose 文件之后，删容器重建都是秒级的事情，还能保证每次配置一致。

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