简介：这份资源面向在ARM64架构Linux设备上部署容器环境的开发者与运维人员，提供Docker与Docker Compose的一键安装方案，解决树莓派、ARM服务器等平台手动编译安装繁琐、版本适配困难的问题。压缩包共5个文件，约61.54MB，包含sh安装脚本、tgz二进制包、docker-compose-linux-aarch64可执行文件及service服务单元，覆盖依赖安装、二进制部署、服务注册与开机自启等环节，安装脚本会自动完成下载、解压、权限设置与版本验证。资源选用Docker 19.03.9稳定版本，兼容ARM64架构，配合Compose可声明式管理多容器应用。目前已有4191人学习下载，适合希望快速搭建容器运行环境、减少重复配置工作的读者参考使用。
1. arm64 docker安装包：为什么x86的包在ARM机器上装不上
如果你手里有一台 ARM 架构的服务器或开发板，兴冲冲地照着 x86 教程敲下apt install docker-ce，结果大概率会看到一行Unable to locate package或者装完之后docker info直接报架构不匹配。这不是玄学，是 arm64 docker安装包 这件事本身就和 x86 走的不是同一条路。ARM 平台上跑 Docker，安装包来源、仓库地址、依赖链、甚至内核模块的加载方式都和 x86 有差异，照搬教程翻车是常态。这篇笔记面向的是手里有 ARM 设备、想在上面把 Docker 跑起来并且长期稳定用的工程师，从安装包怎么选、仓库怎么配、离线包怎么导，一路讲到踩过的坑和验证方法。读完你应该能在一台干净的 arm64 机器上，不依赖任何图形界面，把 Docker 装好、跑通容器、并且知道出问题时先看哪里。
2. arm64 docker安装包从哪来：三条主流获取路径的取舍
2.1 官方仓库、系统源、离线包，先搞清楚区别
在 arm64 上拿 Docker 安装包，常见做法有三条路。第一条是走 Docker 官方提供的 apt/yum 仓库，这条路的包是官方构建的，版本新、更新及时，但需要机器能访问外网仓库地址，而且不同发行版的仓库路径不一样。第二条是用系统自带源里的 docker.io 包，比如 Ubuntu 的 universe 源、Debian 的默认源，优点是省事、依赖自动解决，缺点是版本往往偏旧，某些新特性用不上。第三条是离线安装包，把 deb 或 rpm 包下载好再拷到目标机器上dpkg -i或rpm -ivh，适合内网机器或者网络受限的环境。
选哪条路，取决于你的机器能不能联网、对版本有没有要求、以及要不要长期维护。我一般会先确认三件事：uname -m输出是不是aarch64，cat /etc/os-release看发行版和版本号，apt-cache policy docker-ce看当前源里有没有可用的包。这三条命令跑完，基本就能判断该走哪条路。
# 确认架构，aarch64 就是 arm64 uname -m # 确认发行版和版本，决定后面仓库地址怎么写 cat /etc/os-release # 看当前源里 docker 相关包的候选版本 apt-cache policy docker-ce docker.io containerd.io逻辑说明：uname -m在 ARM 服务器上通常返回aarch64，在 32 位 ARM 上返回armv7l，这两个对应的安装包完全不同，不能混用。/etc/os-release里的VERSION_CODENAME字段决定了 apt 仓库地址里的发行版代号，写错了就会 404。apt-cache policy是装之前先摸底，避免装完才发现版本不对再卸载重来。
参数说明：如果你用的是 yum 系发行版，把apt-cache policy换成yum list available docker-ce，仓库配置文件放在/etc/yum.repos.d/下。离线包场景下，dpkg -i不会自动解决依赖，需要配合apt-get install -f补依赖，或者提前把所有依赖包一起下载好。
2.2 用官方仓库在 arm64 上装 Docker 的完整命令
确认走官方仓库之后，步骤其实不复杂，但每一步的顺序不能乱。先装基础依赖，再加 GPG 密钥，再写仓库地址，最后才 install。顺序错了，最常见的结果是apt update报签名验证失败。
# 1. 装基础依赖，arm64 上 ca-certificates 和 curl 基本是必须的 sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg # 2. 建密钥目录并下载官方 GPG 密钥 sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \ sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg # 3. 写入 arm64 对应的仓库地址，注意 $(dpkg --print-architecture) 会输出 arm64 echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \ https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo $VERSION_CODENAME) stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 4. 更新源并安装 sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin逻辑说明：第 2 步的gpg --dearmor是把 ASCII 格式的密钥转成二进制格式，apt 新版本要求密钥放在/etc/apt/keyrings下并且权限可读。第 3 步里$(dpkg --print-architecture)在 arm64 机器上会展开成arm64，这是让 apt 只拉对应架构包的关键，写死成amd64就会拉错包。VERSION_CODENAME从/etc/os-release里读，避免手写代号写错。
参数说明：docker-buildx-plugin和docker-compose-plugin是可选但强烈建议装的，前者用于多架构镜像构建，后者提供docker compose子命令。如果你的发行版是 Debian，把仓库地址里的ubuntu换成debian，其余不变。安装完成后用docker version看 Server 段的Arch字段，确认是arm64才算装对。
2.3 离线场景：把 arm64 安装包完整搬到目标机器
内网机器或者网络受限的环境，只能走离线包。离线安装的难点不在装，在于依赖链要凑齐。我的做法是在一台同版本同架构的联网机器上，用apt-get install --download-only把包和依赖全部下下来，再整体拷过去。
# 在联网的同架构机器上，只下载不安装，包会落在 /var/cache/apt/archives/ sudo apt-get install --download-only -y \ docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 把下载好的 deb 包打包带走 sudo tar -czvf docker-arm64-offline.tar.gz -C /var/cache/apt/archives/ . # 在目标机器上解压后安装 sudo mkdir -p /tmp/docker-offline sudo tar -xzvf docker-arm64-offline.tar.gz -C /tmp/docker-offline sudo dpkg -i /tmp/docker-offline/*.deb # 如果 dpkg 报依赖缺失，用下面这条补齐 sudo apt-get install -f -y逻辑说明：--download-only只下载不安装，保证依赖包也一起进缓存目录。打包时用-C切到缓存目录再打包，避免把绝对路径带进压缩包。目标机器上先dpkg -i再apt-get install -f，是因为 dpkg 本身不解决依赖，-f会尝试从本地缓存或已配置源里补齐缺失的依赖。
参数说明：如果目标机器完全没有 apt 源可用，apt-get install -f也会失败，这时候需要手动把缺失的依赖 deb 包也放进同一个目录再dpkg -i。离线包方案的一个硬约束是：下载机和目标机的发行版版本、架构必须完全一致，否则依赖版本对不上，装完可能起不来。
3. 装完之后跑不起来：arm64 上 Docker 服务的启动与验证
3.1 systemd 服务起不来先看这三处日志
装完包不等于 Docker 就能跑。arm64 上最常见的是systemctl start docker卡住或者直接 failed。这时候别急着重装，先按顺序看三处：systemctl status docker看服务状态和最近几行日志，journalctl -u docker --no-pager -n 50看完整启动日志，dmesg | tail -30看内核层面有没有报错。
# 看服务状态，failed 时这里会给出退出码 sudo systemctl status docker --no-pager # 看最近 50 行服务日志，定位具体报错 sudo journalctl -u docker --no-pager -n 50 # 看内核日志，排查 cgroup、iptables、overlay 相关问题 sudo dmesg | tail -30逻辑说明：systemctl status给的是概览，真正有用的报错在journalctl里。dmesg用来排查内核模块层面的问题，比如 overlay2 存储驱动加载失败、cgroup v2 没挂载、iptables 规则链缺失，这些在服务日志里可能只体现为一句笼统的启动失败。
参数说明：--no-pager是防止日志被分页器截断，方便直接复制。-n 50控制行数，机器日志多的时候可以调到 100。如果journalctl里看到failed to start daemon: error initializing graphdriver，基本就是存储驱动问题，往下看 3.2。
3.2 存储驱动和 cgroup 版本：arm64 上最容易翻车的两个点
arm64 机器上内核版本差异大，有的发行版默认 cgroup v2，有的还是 v1，Docker 对两者的支持行为不一样。存储驱动方面，overlay2 是首选，但某些 ARM 板子的内核没编 overlay 模块，就会回退到 vfs，性能差很多。
# 看当前 Docker 用的存储驱动和 cgroup 版本 docker info | grep -E "Storage Driver|Cgroup" # 看内核是否支持 overlay grep overlay /proc/filesystems # 看 cgroup 挂载情况 mount | grep cgroup逻辑说明：docker info里的Storage Driver如果是vfs，说明 overlay2 没启用成功，需要检查内核模块。Cgroup Version显示2时，某些老版本 Docker 需要额外配置。/proc/filesystems里有overlay才说明内核支持，没有的话要么换内核，要么接受 vfs 的性能损失。
参数说明：如果确认内核支持 overlay 但 Docker 没用上，可以在/etc/docker/daemon.json里显式指定{"storage-driver": "overlay2"}，然后systemctl restart docker。cgroup v2 环境下如果遇到容器资源限制不生效，检查daemon.json里有没有"exec-opts": ["native.cgroupdriver=systemd"]，这个配置在 arm64 上尤其重要。
3.3 跑一个 arm64 容器验证整条链路
服务起来之后，别急着上业务镜像，先用一个确定支持 arm64 的基础镜像验证。hello-world是多架构的，alpine也有 arm64 版本，用这两个做冒烟测试最稳。
# 拉取并运行 hello-world，验证 Docker 基本功能 docker run --rm hello-world # 跑一个 arm64 的 alpine，确认架构匹配 docker run --rm alpine uname -m # 看本地镜像的架构信息 docker image inspect alpine --format '{{.Architecture}}'逻辑说明：hello-world验证的是 Docker 守护进程、镜像拉取、容器运行这条链路通不通。alpine uname -m在容器里输出aarch64才说明拉到的确实是 arm64 镜像。docker image inspect的Architecture字段是最直接的确认方式，输出arm64就对了。
参数说明：--rm是容器退出后自动删除，冒烟测试用这个避免留一堆停止的容器。如果docker run报exec format error，说明拉到的是 x86 镜像，需要检查镜像标签或者用--platform linux/arm64显式指定。
4. arm64 docker安装包避坑：五条血泪经验
4.1 坑一：仓库地址里架构写死成 amd64
现象：apt update成功，但apt install docker-ce报找不到包，或者装完docker version里 Server 段架构显示 amd64。
原因：仓库地址里arch=后面写死了amd64，apt 在 arm64 机器上按这个架构去找包，自然找不到匹配的。
解决：把arch=后面的值改成$(dpkg --print-architecture)让它动态展开，或者直接写arm64。改完apt update再装。
4.2 坑二：离线包跨发行版版本混用
现象：dpkg -i装完没有报错，但systemctl start docker直接 failed，日志里报依赖库版本不匹配。
原因：下载离线包的机器和目标机器的发行版版本不一致，比如一个是 22.04 一个是 24.04，依赖的 libc 或 libssl 版本不同。
解决：离线包必须在同发行版同版本的机器上下载。已经装错的，先dpkg -r卸载，清理/var/lib/docker残留，再重新用匹配版本的包安装。
4.3 坑三：cgroup v2 下资源限制不生效
现象：容器里跑stress压满 CPU，但docker stats显示的限制值没起作用，或者--memory限制被忽略。
原因：Docker 的 cgroup driver 和系统实际的 cgroup 版本不匹配，arm64 新内核默认 cgroup v2，但 Docker 可能还在用 cgroupfs。
解决：在/etc/docker/daemon.json里加"exec-opts": ["native.cgroupdriver=systemd"]，重启 Docker 服务，再用docker info确认Cgroup Driver显示systemd。
4.4 坑四：overlay2 没启用导致磁盘爆满
现象：跑几个容器之后磁盘占用飙升，docker system df显示镜像层占用异常大。
原因：存储驱动回退到了 vfs，vfs 不做层共享，每个容器都复制完整文件系统，磁盘消耗成倍增加。
解决：确认内核支持 overlay 后，在daemon.json里显式指定"storage-driver": "overlay2"，重启 Docker。注意切换存储驱动会导致已有镜像和容器不可用，需要提前备份或重建。
4.5 坑五：镜像拉取慢或超时，误以为是安装包问题
现象：Docker 装好了，docker pull卡住或者超时，误判成安装包不完整。
原因：镜像仓库的网络连通性问题，和安装包本身无关。arm64 镜像在部分仓库里的层可能和 x86 不共享，拉取量更大。
解决：先docker pull hello-world验证基础连通性，再试目标镜像。如果基础镜像也拉不动，检查 DNS 配置和防火墙规则，别在安装包上浪费时间。
5. 进阶：用 buildx 构建 arm64 镜像并验证安装包完整性
装好 Docker 只是第一步，arm64 上真正高频的需求是构建和运行 arm64 镜像。docker buildx是多架构构建的核心工具，装docker-buildx-plugin之后就能用。下面这个流程是我常用的：建 builder、构建 arm64 镜像、导出并验证。
# 1. 创建一个 buildx builder，支持多架构 docker buildx create --name armbuilder --use # 2. 启动 builder 并查看支持的平台 docker buildx inspect --bootstrap # 3. 构建一个 arm64 镜像并加载到本地 docker buildx build --platform linux/arm64 -t myapp:arm64 --load . # 4. 验证镜像架构 docker image inspect myapp:arm64 --format '{{.Architecture}}'逻辑说明：buildx create建的是一个独立的构建环境，--use表示后续命令默认用它。inspect --bootstrap会启动 builder 并列出支持的平台，确认列表里有linux/arm64。--load是把构建结果加载到本地 Docker 镜像列表，不加这个参数构建完的镜像只在 builder 缓存里。最后用inspect确认架构字段。
参数说明：--platform linux/arm64指定目标平台，如果要同时构建多个架构可以写成linux/amd64,linux/arm64，但多架构同时构建时不能用--load，需要推到仓库或者用--output导出。构建缓存方面，arm64 上首次构建会比较慢，后续增量构建会快很多。
验证安装包完整性还有一个实用技巧：用dpkg -V docker-ce检查已安装包的文件校验和，输出为空说明文件完整。如果输出有行，说明对应文件被改动或损坏，可以考虑重装。
# 检查已安装的 docker-ce 包文件完整性 dpkg -V docker-ce # 看包的实际安装信息和版本 dpkg -l | grep docker # 看包安装了哪些文件 dpkg -L docker-ce | head -20逻辑说明：dpkg -V做的是文件校验和比对，输出为空是正常。dpkg -l看版本和状态，ii表示正常安装。dpkg -L列出包内文件，用来确认关键二进制比如dockerd在不在预期路径。
我自己在 arm64 上装 Docker 的习惯是：装完先跑hello-world，再跑alpine uname -m，两个都过了才往上面放业务。这个习惯帮我省过好几次「装是装上了但架构不对」的后悔药。另外离线包场景下，我一般会在下载机上也跑一遍完整安装验证，确认包本身没问题再打包带走，比到了目标机器上再排查省事得多。希望帮到你。
本文还有配套的精品资源，点击获取
