arm64 openEuler下Docker与docker-compose离线安装配置指南-北京尧图网络

简介面向 arm64 架构服务器与 openEuler 环境的运维及开发人员这套离线安装包聚焦内网、无外网或网络受限场景下的容器环境快速落地省去逐项寻找依赖与适配版本的麻烦。zip 压缩包共 4 个文件约 54.41MB包含 Docker 离线安装包、systemd 服务配置、一键安装脚本以及 docker-compose 可执行文件分别对应运行时部署、开机服务管理、自动化安装与编排工具配置结构精简且用途明确。已在 openEuler 下完成验证已有 646 人学习下载。对于需要在内网服务器批量部署容器运行环境、排查 arm64 版本兼容问题或补齐 docker-compose 编排能力的读者可借助这套材料减少联网安装受阻、依赖缺失和版本不匹配等困扰获得可复用的离线部署参考。1. 离线装 Docker为什么 x86 那份包拷到 arm64 上一跑就废第一次在 arm64 机器上装 Docker 的人多半栽在同一个地方把笔记本上那份跑得好好的离线包原样拷过去文件传完、权限给足、脚本一跑终端甩回来一句cannot execute binary file: Exec format error。arm64 平台下 Docker 与 docker-compose 的离线安装难点从来不在 Docker 本身而在“这份包到底是谁编译的”。openEuler 在服务器侧的装机量这两年涨得很快鲲鹏、飞腾这类 aarch64 机器出厂常常没有外网dnf 源也指不到离线安装几乎成了唯一选项。装不好会怎样轻则 dnf 卡在依赖循环里转圈重则 docker 服务根本起不来、容器网络全断上面跑的业务跟着停摆而重启之后才发现日志里那句 error 早就写在那儿了。这篇笔记面向手上有一台 arm64 机器、一份离线包、但没有外网的开发者与运维从环境核对一路走到脚本执行、daemon.json 调参和装完自检每一步都落到能抄的命令上。2. 环境核对aarch64、openEuler 版本与 cgroup 三件事先钉死在解压任何压缩包之前我一般会先花三分钟把机器的底细摸清楚。原因很实在离线安装不像联网安装装错了没有回退余地包里少一个依赖就得重新拷一遍 U 盘。这三分钟能省掉的返工比后面所有步骤加起来都多。2.1 三条命令确认架构、发行版与内核# 1) CPU 架构期望输出 aarch64不是 arm64也不是 x86_64 uname -m # 2) 发行版版本期望 openEuler release 22.03 (LTS-SPx) 或 24.03 (LTS) cat /etc/openEuler-release # 3) 内核主版本22.03 一般是 5.10.x24.03 是 6.6.x uname -r第一条命令的返回值会被很多人误读。Docker 官方给 arm64 架构的包命名是aarch64而uname -m在 64 位 ARM 上也输出aarch64如果你在脚本里写成判断 arm64它永远不成立脚本会直接退出或者更糟——跳过校验继续往下装。类似的坑还有dpkg --print-architecture在 Debian 系输出arm64、在 RPM 系根本没有这条命令跨发行版脚本里最好只认uname -m。第二条命令的输出格式要留意大小写和括号openEuler 22.03 的完整字符串通常是openEuler release 22.03 (LTS-SP3)这种形态。做版本判断时用grep -oE 2[24]\.[0-9]抓数字比字符串全等匹配稳因为 SP 补丁号会变。第三条命令决定了后面 daemon.json 里几个参数怎么写。内核 5.10 的 openEuler 22.03 默认走 cgroup v124.03 默认切到 cgroup v2两者的 Docker 配置项并不完全一样。顺手再确认一下# 返回 cgroup2fs 表示 v2 已启用tmpfs 表示还是 v1 stat -fc %T /sys/fs/cgroup # 确认内核模块overlay2 存储驱动依赖 overlay lsmod | grep -E overlay|br_netfilteroverlay和br_netfilter这两个模块缺一个都会让后续步骤难受。RPM 包的 %post 脚本一般会写/etc/modules-load.d/静态二进制安装则完全没有这一步需要手动补cat /etc/modules-load.d/docker.conf EOF overlay br_netfilter EOF modprobe overlay modprobe br_netfilterbr_netfilter的作用是让桥接流量经过 iptables 规则容器跨主机通信时缺了它会出现“同一个宿主机能通、跨机器就是不通”的玄学现象排查起来能耗掉半天。2.2 离线包里到底该有哪些文件拿到一份打包好的离线资源先别急着执行。列一下文件清单对照下表确认完整性比装到一半报错再去翻压缩包高效得多。文件/目录用途是否必需rpms/docker-ce-*.aarch64.rpmDocker 引擎主体RPM 包名带 aarch64 后缀RPM 路线必需rpms/containerd.io-*.aarch64.rpm容器运行时被 docker-ce 强依赖RPM 路线必需rpms/docker-ce-cli-*.aarch64.rpmdocker 命令行客户端必需rpms/docker-buildx-plugin / compose-pluginCLI 插件装完直接有docker compose建议保留binary/docker-*.tgz静态编译的二进制合集解压即用二进制路线必需binary/docker-compose-linux-aarch64compose v2 单文件二进制必需install.sh一键安装脚本必需images/*.tardocker save出来的业务镜像按需这里最容易出问题的是 RPM 的命名。x86 包叫x86_64.rpmarm 包叫aarch64.rpm两个后缀只差几个字符肉眼扫一遍很容易漏。更稳妥的做法是用file命令直接看包里的 ELF 头# 看 RPM 包内二进制架构输出含 aarch64 才对 rpm2cpio rpms/docker-ce-*.aarch64.rpm | cpio -itv 2/dev/null | head # 看 tgz 里的二进制架构期望 ELF 64-bit LSB ... ARM aarch64 tar -xzf binary/docker-*.tgz -O docker/dockerd | file -第二条命令我几乎每次都会敲一遍。Exec format error这种报错事后看文件名就能发现但当场没查就得来回折腾。另外openEuler 22.03 的 glibc 版本对应 RHEL 8 一档官方给 el8 编的 RPM 包通常能直接装如果包名里写的是 el9先别装rpm -qpR看一眼依赖大概率要libc.so.6(GLIBC_2.34)而系统提供不了。2.3 openEuler 自带 podman 的共存问题全新装的 openEuler 大概率已经带着 podman 和 buildah。这不是坏事但它和 Docker 会抢几样东西/etc/containers/、CNI 的网桥名、以及 iptables 里的规则链。两者同时跑常见表现是 docker 起来之后宿主机访问外网正常、容器出不去或者docker0网卡建不出来。我的处理方式是先卸干净再装# 先看装了哪些确认没有业务依赖 podman 再动手 rpm -qa | grep -E ^(podman|buildah|containers-common|skopeo) # 停服务、禁用、卸载--nodeps 只在确认无依赖时使用 systemctl disable --now podman.socket podman.service 2/dev/null || true dnf remove -y podman buildah如果现场确实有 podman 在跑业务那就不要卸改为在 daemon.json 里把 Docker 的网段和网桥名都错开具体参数放在第 4 章讲。两条路选一条最怕的是“先装着看看”结果两套容器网络互相覆盖规则出一堆谁都解释不清的连通性问题。3. 安装 Docker 引擎rpm 离线包和静态二进制两条路的取舍包齐了、环境清了才轮到真正动手装。Docker 在 arm64 Linux 上有两条正规路线RPM 包安装和静态二进制解压。选哪条不是个人喜好问题得看现场还有没有 dnf 能用的本地源、以及后续要不要走 systemd 管理。3.1 路线一dnf localinstall 装 RPM 包RPM 路线的好处是依赖被记录在数据库里rpm -q docker-ce能查到版本后续升级卸载都干净代价是必须把依赖一起备齐。# 解压离线包到固定目录后面脚本里也复用它 mkdir -p /opt/docker-offline tar -xzf docker-arm64-offline.tar.gz -C /opt/docker-offline cd /opt/docker-offline # 关键--disablerepo* 断掉所有外部源避免 dnf 卡在超时上 dnf localinstall -y --disablerepo* --nogpgcheck ./rpms/*.rpm--disablerepo*这个参数在离线环境里几乎是必须的。不写它dnf 会先尝试刷新openEuler.repo里那几个 baseurl每个源等几十秒超时最后才处理本地包一批包装下来十几分钟就没了。--nogpgcheck则是因为离线包通常没有导入 GPG key不关掉会因为验签失败整批回滚。依赖的安装顺序由 dnf 自己解但包本身必须覆盖这几层container-selinux提供 SELinux 策略即使 SELinux 关闭它也常被写成硬依赖、libseccomp、iptables、libcgroup、containerd.io、docker-ce-cli、docker-ce。少一个dnf 会打印一串 “Error: Package: docker-ce-xx requires ...” 然后退出这时候不用猜把缺的包名复制出来回打包机上补进 rpms 目录就行。装完确认一下rpm -qa | grep -E docker|containerd # 期望看到 containerd.io-1.6.x、docker-ce-24.0.x、docker-ce-cli-24.0.x 齐整3.2 路线二静态二进制解压到 /usr/bin某些加固过的镜像连 dnf 都被裁掉了或者系统里残留着半装的旧版本卸不干净这时候静态二进制是最省事的方案。它把 dockerd、docker、containerd、runc、ctr、docker-proxy、docker-init 全打在一个 tgz 里。cd /opt/docker-offline # 解压后目录结构是 docker/ 下平铺所有二进制 tar -xzvf binary/docker-24.0.7.tgz # install 同时做两件事复制设权限比 cp 再 chmod 少一步 install -m 0755 docker/* /usr/bin/ # 验证三条命令都应打印出版本号 dockerd --version containerd --version runc --versioninstall -m 0755比cp chmod好在它是原子的中途失败不会留下一个没有执行权限的 dockerd。这个细节在脚本里很重要——权限没给对的 dockerdsystemd 启动时报的是status203/EXEC看起来像“文件不存在”实际是权限问题能排查很久。二进制路线需要手动补的东西比 RPM 多systemd 单元文件、/etc/docker目录、docker 用户组、/var/run/docker.sock的权限。用户组和目录这两样漏了docker 服务能起来但普通用户永远连不上。# 手动补 systemd 单元内容见 3.4 cat /etc/systemd/system/docker.service EOF [Unit] DescriptionDocker Application Container Engine Afternetwork-online.target firewalld.service Wantsnetwork-online.target [Service] Typenotify ExecStart/usr/bin/dockerd ExecReload/bin/kill -s HUP $MAINPID LimitNOFILE1048576 LimitNPROC1048576 TimeoutStartSec0 Delegateyes KillModeprocess Restarton-failure StartLimitBurst3 StartLimitInterval60s [Install] WantedBymulti-user.target EOF groupadd -f docker mkdir -p /etc/dockerTypenotify表示 dockerd 启动完成后会主动通知 systemd这比Typesimple准确得多——simple 模式下 systemd 认为进程一起来就算成功而 dockerd 完全可能起来两秒后退出。Delegateyes是给容器内的 cgroup 操作放权不加的话某些需要调整自身 cgroup 的容器会报 permission denied。3.3 一键安装脚本里到底做了什么离线包里那个install.sh不是黑匣子值得逐段读一遍再执行。它通常做七件事架构校验、备份旧配置、清理冲突包、安装、写 daemon.json、启服务、自检。下面是我自己维护的版本逻辑和市面上常见的脚本大同小异#!/usr/bin/env bash # install-docker-arm64.sh —— openEuler arm64 离线安装 set -euo pipefail PKG_DIR$(cd $(dirname ${BASH_SOURCE[0]}) pwd) DATA_ROOT${DATA_ROOT:-/data/docker} TS$(date %Y%m%d%H%M%S) # 1) 架构硬校验不匹配立刻退出不留半装状态 if [[ $(uname -m) ! aarch64 ]]; then echo [FAIL] 当前架构 $(uname -m)本包仅支持 aarch64 2 exit 1 fi # 2) 幂等重复执行时先备份已有配置 if [[ -f /etc/docker/daemon.json ]]; then cp -a /etc/docker/daemon.json /etc/docker/daemon.json.bak.${TS} fi # 3) 清理会抢网桥和 iptables 链的包 dnf remove -y podman buildah /dev/null 21 || true # 4) 本地源安装断外网源 dnf localinstall -y --disablerepo* --nogpgcheck ${PKG_DIR}/rpms/*.rpm # 5) 数据目录挪出根分区并写最小配置 mkdir -p ${DATA_ROOT} [[ -f /etc/docker/daemon.json ]] || \ printf {\n data-root: %s\n}\n ${DATA_ROOT} /etc/docker/daemon.json # 6) 重新加载并开机自启 systemctl daemon-reload systemctl enable --now docker # 7) 自检Server 版本非空即视为通过 docker version --format {{.Server.Version}}几个参数值得单独说。set -euo pipefail是三个开关的合集-e让任意命令非零退出就终止脚本避免在 dnf 失败之后还傻乎乎去systemctl start-u让引用未定义变量时报错${DATA_ROOT:-...}这种写法就是配合它用的-o pipefail让管道里任何一个环节失败都算失败grep | head这种组合不加它会吞掉错误。DATA_ROOT做成环境变量而不是写死是因为不同机器的磁盘布局差别太大。有的机器根分区 50G、数据盘 2T有的反过来。写成DATA_ROOT/data/docker ./install.sh就能在首次执行时指定不用装完再改。第 5 步的[[ -f ... ]] ||是个幂等保护配置文件已存在时不覆盖。这条很关键运维二次执行脚本是常态把人家调好的 daemon.json 覆盖成一行>systemctl status docker --no-pager systemctl is-enabled docker # 期望输出 enabled journalctl -u docker -n 50 --no-pageris-enabled输出enabled才算真的开机自启光start过的服务重启就没了。这个检查在交付前必须走一遍我见过不止一次“装完能用、机器一重启全没了”的现场。句柄上限是 arm64 大内存机器上容易被忽略的一项。Docker 默认的LimitNOFILE往往不够跑几十个容器的场景表现是容器跑一阵子报too many open files。改法不是动/etc/security/limits.conf——那份文件对 systemd 管理的服务无效得用 drop-inmkdir -p /etc/systemd/system/docker.service.d cat /etc/systemd/system/docker.service.d/override.conf EOF [Service] LimitNOFILE1048576 LimitNPROC1048576 EOF systemctl daemon-reload systemctl restart docker systemctl show docker --propertyLimitNOFILE最后一条命令输出LimitNOFILE1048576才算生效。limits.conf那条路之所以走不通是因为 systemd 服务不经过 PAM 会话pam_limits 根本没机会插手只有单元文件里的Limit*系列指令才管用。这个坑在调优文章里被抄来抄去实际照做基本无效。4. 配置收尾docker-compose 插件位置与 daemon.json 四个必改参数引擎装完、服务能起来此时离“能干活”还有一段距离。compose 没装、数据目录还在根分区、日志没限大小这三件事只要有一件没处理跑上一两个月就会出事。4.1 compose v2 插件放对目录才算装好docker-compose 现在有两条并行的产品线v1 是独立的docker-compose二进制最后一版停在 1.29.2已经不再演进v2 是 Go 重写的 CLI 插件调用方式是docker compose中间是空格不是横杠。新装环境没有理由再选 v1除非现场有跑了好几年的脚本硬编码了docker-compose up -d。v2 的安装本质就是放对位置# 系统级路径rpm 装的 docker-ce-cli 默认扫这里 mkdir -p /usr/libexec/docker/cli-plugins install -m 0755 binary/docker-compose-linux-aarch64 \ /usr/libexec/docker/cli-plugins/docker-compose # 验证注意 compose 后面是空格 docker compose version三个候选目录的优先级要搞清楚$HOME/.docker/cli-plugins用户级最高、/usr/local/lib/docker/cli-plugins、/usr/libexec/docker/cli-plugins。放在用户级目录只有那个用户能用放在/usr/local/lib对二进制安装和 rpm 安装都通用放在/usr/libexec则是 RPM 包自己的约定。搞混了的表现是docker compose version报docker: compose is not a docker command而文件明明躺在磁盘上。需要兼容老脚本的话再补一条软链让docker-compose这个命令也能用ln -sf /usr/libexec/docker/cli-plugins/docker-compose /usr/local/bin/docker-compose docker-compose version软链比复制好升级时只改一处。另外 v2 对 compose 文件里的version:字段态度比 v1 宽松写着version: 3.8也能跑但会打印一行 deprecated 警告不影响功能交付时别被这行警告吓到。4.2 daemon.json 里我必改的四个参数/etc/docker/daemon.json是 Docker 的核心配置文件改错一个字段服务就起不来。离线环境里下面四项我基本都会配{ data-root: /data/docker, log-driver: json-file, log-opts: { max-size: 100m, max-file: 5 }, insecure-registries: [registry.internal:5000], default-address-pool: [ { base: 10.201.0.0/16, size: 24 } ], live-restore: true }># 先校验 JSON 语法格式错会导致服务起不来 python3 -m json.tool /etc/docker/daemon.json /dev/null echo JSON OK # 大部分字段走 reloaddata-root 变更必须 restart systemctl reload docker || systemctl restart docker docker info --format {{.DockerRootDir}} {{.LoggingDriver}}最后那条docker info是验证配置真的生效了DockerRootDir应该打印/data/docker。只改文件不验证是配置类问题最常见的来源。注意daemon.json 是严格 JSON不能写注释不能有尾逗号。粘贴配置时把行尾的逗号多看了一眼能省掉一次服务起不来的排查。4.3 用户组、目录权限与普通用户的使用装完的 Docker 默认只有 root 能用。业务侧通常不希望用 root 跑发布脚本标准做法是把用户加进 docker 组# rpm 安装会自动建 docker 组二进制安装需要手动补 getent group docker || groupadd docker usermod -aG docker deploy # 当前会话立即生效不用重新登录 newgrp dockerusermod -aG里的-a不能省。漏了它-G是覆盖语义用户原有的附加组会被全部清掉权限瞬间出问题而且这种故障现场很难联想到是加组操作导致的。组加对了但docker ps还是报permission denied while trying to connect to the Docker daemon socket八成是 socket 权限不对ls -l /var/run/docker.sock # 期望 srw-rw---- 1 root docker权限是srw-rw----、属组是 docker 才算正常。二进制安装漏了 udev 规则或者 systemd 单元里没写ExecStartPostsocket 可能变成srw-------那就只有 root 能用。docker组等价于 root 权限这点必须跟团队讲清楚——组里的任何用户都能docker run -v /:/host挂载宿主机根目录。生产环境更稳的做法是配 sudo 白名单只放开固定的几条 docker 命令而不是无脑加组。5. 排查清单离线装完起不来的五种典型翻车离线安装的排查比联网安装难因为不能顺手dnf install补包、不能拉镜像验证。下面五条是我在不同机器上真真切切遇到过的按“现象 → 原因 → 解决”记下来。5.1 现象执行 dockerd 报 Exec format error原因基本只有一个包里装的是 x86_64 的二进制被拷到了 aarch64 机器上。文件名可能是docker-24.0.7.tgz压根没带架构后缀打包时拿错了目录肉眼完全看不出来。解决分两步。先确认用file docker/dockerd看 ELF 头输出里是x86-64就实锤了。再回打包机重新取 aarch64 版本。已经装上去的残骸清理干净dnf remove -y docker-ce docker-ce-cli containerd.io 2/dev/null || true rm -f /usr/bin/dockerd /usr/bin/docker /usr/bin/containerd /usr/bin/runc systemctl daemon-reload/usr/bin/dockerd这类文件如果被install覆盖过dnf 卸载时未必清得掉手动删一遍更保险。5.2 现象Cannot connect to the Docker daemon at unix:///var/run/docker.sock服务没起来或者起来就退出了。这时候不要去猜配置先看日志systemctl status docker --no-pager -l journalctl -u docker -n 80 --no-pager日志里出现unable to configure the Docker daemon with file /etc/docker/daemon.json: invalid character就是 JSON 写坏了出现failed to start daemon: pid file found是上次异常退出留下的/var/run/docker.pid删掉重启出现Error starting daemon: layer does not exist往往是>iptables --version # 输出含 (nf_tables) 表示 nft 后端(legacy) 表示老后端处理办法有两条。省事的做法是切到 legacyupdate-alternatives --set iptables /usr/sbin/iptables-legacy 2/dev/null || \ alternatives --set iptables /usr/sbin/iptables-legacy systemctl restart docker更彻底的做法是把 Docker 升到 23.0 之后的版本对 nft 的支持完善很多。离线环境升级麻烦的话前一条就够用。另外net.ipv4.ip_forward必须是 1这个值被安全加固脚本改成 0 的情况也不少sysctl -w net.ipv4.ip_forward1 echo net.ipv4.ip_forward1 /etc/sysctl.d/99-docker.conf5.4 现象跑一段时间后容器全部异常docker ps报 read-only file system根分区写满了。df -h /var/lib/docker一看 100%而du -sh /var/lib/docker/*里overlay2和containers各占一半。前者是镜像层后者多半是没限大小的 json-file 日志。急救先清日志别直接rm -rf /var/lib/docker# 找最大的几个日志文件 du -sh /var/lib/docker/containers/*/*-json.log | sort -rh | head -5 # 截断而不是删除删除会让 dockerd 拿着已释放的 fd 继续写 truncate -s 0 /var/lib/docker/containers/id/id-json.log # 清理无用镜像和构建缓存 docker image prune -af docker builder prune -af根治靠 4.2 节的log-opts加># 离线镜像导入注意 -i 后面接 tar 文件不是目录 docker load -i /opt/docker-offline/images/app-base.tar # 用导入的镜像起一个最小容器验证运行时 docker run --rm app-base:latest /bin/sh -c echo runtime-ok # compose 层面的验证写一个最小 compose 文件跑通再删 cat /tmp/smoke-compose.yaml EOF services: smoke: image: app-base:latest command: [/bin/sh, -c, echo compose-ok] EOF docker compose -f /tmp/smoke-compose.yaml up docker compose -f /tmp/smoke-compose.yaml down -vdocker load的输出会打印Loaded image: app-base:latest看到这行才算导入成功。如果报open images/app.tar: no such file检查路径里有没有笔误报invalid tar header说明这个 tar 是用docker export导出的容器快照不是docker save的镜像两者不能混用。compose 那个 smoke 文件里刻意不写version:字段v2 已经不需要它了写了只是多一行警告。down -v带上-v是顺手清掉匿名卷避免自检留下一堆垃圾。还有一项容易被跳过但值得做把机器重启一次等两分钟再跑第 1、3、7 步。很多配置问题是在重启后才暴露的——比如 daemon.json 只在 reload 时生效但重启后又被别的文件覆盖、比如 drop-in 目录权限不对导致 systemd 忽略配置。重启验证过一遍交付时才踏实。从那以后我每次做离线交付都会在最后留一份install.log和docker info的输出截图机器上跑的是哪个版本、数据目录在哪、存储驱动是什么白纸黑字写着。半年后有人接手不用再猜这套环境当初是怎么装的。希望帮到你。本文还有配套的精品资源点击获取

arm64 openEuler下Docker与docker-compose离线安装配置指南

相关推荐

改进人工势场法MATLAB程序：解决路径规划震荡与角度问题

C# GDI+交互式绘图：坐标系、重绘与鼠标事件深度解析

MATLAB语音降噪实战：频谱减法全流程源码解析

更多资讯

夸克网盘挂载AList失败排查：凭证、网络、配置与版本问题全解析

C语言实现离散事件模拟：银行排队算法与事件驱动设计

Java Web请求全链路拆解：从Cookie会话到Servlet与数据库分页

Spring Cloud Gateway局部过滤器实战：用GatewayFilterFactory实现灵活权限校验

Kubernetes 1.18.8 源码包构建与调试实战指南

Kubernetes 1.18.8源码包深度解析与kubelet编译实战

今日更新

Verilog实现FPGA密码锁：矩阵键盘与状态机设计实战

数据服务监控运维实战：从指标体系到告警治理与故障排查

FreeRTOS任务通知实战详解：内核原理、API与避坑指南

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？