最近在龙芯 3B6000 平台上基于 AnolisOS 23.4 部署 Docker 环境时遇到了一个典型问题通过系统默认仓库安装 Docker 后服务能正常启动但在尝试创建或运行容器时却频繁遭遇失败。这个问题在国产化平台迁移和容器化实践中具有一定普遍性其背后往往涉及架构兼容性、内核模块、存储驱动等多个层面的因素。本文将系统性地拆解这一问题的完整排查与解决流程从环境准备、问题复现、根因分析到最终修复提供一套可复现的实战指南。无论你是正在将业务向龙芯平台迁移的运维工程师还是对 LoongArch 架构下容器技术感兴趣的开发者都能从中获得直接的帮助。1. 背景与核心概念在深入问题之前我们有必要厘清几个关键概念这有助于理解后续的排查逻辑。龙芯 3B6000 与 LoongArch 架构龙芯 3B6000 是龙芯中科推出的新一代通用处理器采用完全自主设计的 LoongArch 指令集架构。这意味着其二进制指令与常见的 x86_64 或 ARM 架构不同所有软件包括操作系统内核、系统工具和应用程序都需要针对 LoongArch 进行编译或提供对应的版本。AnolisOS 23.4Anolis OS 是由 OpenAnolis 社区推出的开源、中立的企业级 Linux 发行版旨在为多样化的计算场景提供稳定、高性能的操作系统。AnolisOS 23.4 是其一个重要版本提供了对 LoongArch 等新兴架构的良好支持并集成了较新的软件包。Docker 与容器Docker 是一种容器化平台它允许开发者将应用及其依赖打包到一个轻量级、可移植的容器中。容器共享宿主机的操作系统内核但拥有独立的用户空间从而实现快速部署和一致性运行。在 LoongArch 架构上运行 Docker意味着我们需要 LoongArch 版本的 Docker 引擎、相关工具以及兼容的容器镜像。问题的本质在 x86_64 架构上yum install docker或apt install docker.io通常能获得一个开箱即用的环境。但在龙芯平台上情况更为复杂。默认仓库提供的 Docker 包可能并非为 LoongArch 架构最优构建或者其依赖的内核模块、底层库如containerd、runc存在版本不匹配或兼容性问题导致容器运行时runc无法正确创建容器所需的隔离环境如命名空间、控制组等。因此“安装成功但无法创建容器”是一个典型的运行时兼容性问题。2. 环境准备与版本说明为了准确复现和解决问题首先需要明确我们的基础环境。以下版本信息基于实际测试你的环境可能略有差异但排查思路是通用的。硬件平台龙芯 3B6000 处理器操作系统AnolisOS 23.4 (LoongArch 64)内核版本5.10.0-26.an23.loongarch64可通过uname -r命令查看安装方式通过 AnolisOS 23.4 默认的dnf仓库安装 Docker。首先我们验证系统架构和初始状态# 查看系统架构 uname -m # 预期输出loongarch64 # 查看内核版本 uname -r # 预期输出类似5.10.0-26.an23.loongarch64 # 检查 Docker 是否已安装初始状态应未安装 docker --version # 如果已安装旧版本建议先彻底卸载3. 问题复现默认仓库安装与容器创建失败让我们按照“常规”流程操作重现问题。3.1 通过默认仓库安装 Docker在 AnolisOS 中我们使用dnf包管理器。# 1. 更新软件包索引 sudo dnf makecache # 2. 安装 Docker 引擎及相关工具 sudo dnf install docker docker-compose # 3. 启动 Docker 服务并设置开机自启 sudo systemctl start docker sudo systemctl enable docker # 4. 验证 Docker 服务状态 sudo systemctl status docker如果安装和启动成功status命令应显示active (running)。3.2 尝试运行容器并遭遇失败安装完成后我们尝试运行一个最简单的容器进行测试例如官方的hello-world镜像。但请注意Docker Hub 上官方镜像大多为linux/amd64或linux/arm64没有linux/loongarch64。因此我们需要一个针对 LoongArch 编译的镜像。这里以busybox为例假设有 LoongArch 版本或者直接测试容器创建过程。# 尝试运行一个交互式 busybox 容器此命令很可能失败 sudo docker run -it --rm busybox /bin/sh或者更直接地测试容器运行时# 拉取一个已知支持多架构包含loongarch64的镜像例如来自第三方仓库的镜像 # 这里假设我们有一个可用的镜像地址实际操作中可能需要先配置镜像仓库 # sudo docker pull cr.loongnix.cn/library/busybox:latest # 运行测试 # sudo docker run -it --rm cr.loongnix.cn/library/busybox:latest echo “Hello LoongArch”在问题环境中你很可能会遇到如下几种典型的错误信息docker: Error response from daemon: failed to create shim task: OCI runtime create failed: ...这是最常见的一类错误指向 OCI开放容器标准运行时通常是runc创建失败。docker: Error response from daemon: failed to start shim: fork/exec /usr/bin/containerd-shim-runc-v2: no such file or directory这表明 containerd 的 shim 可执行文件路径有问题或文件缺失。docker: Error response from daemon: failed to create shim: could not find an OCI runtime configuration file指向 OCI 运行时配置文件缺失。权限错误虽然使用了sudo但仍可能遇到与cgroup、AppArmor、SELinux或用户组相关的权限问题。4. 根因分析与深度排查当容器创建失败时我们需要像侦探一样从 Docker 引擎日志、容器运行时日志以及系统层面逐层排查。4.1 查看 Docker 引擎日志Docker 服务的详细日志是首要的排查入口。# 使用 journalctl 查看 Docker 服务的日志 sudo journalctl -u docker.service --since “1 hour ago” -f # 或者查看 Docker 守护进程的日志文件如果配置了 # sudo tail -f /var/log/docker.log在日志中寻找ERROR、failed等关键词。重点关注与runc、containerd、cgroup、iptables、seccomp相关的错误信息。4.2 检查容器运行时状态Docker 默认使用containerd作为容器运行时。# 检查 containerd 服务状态 sudo systemctl status containerd # 查看 containerd 的配置 sudo cat /etc/containerd/config.toml确保containerd服务正在运行并且其配置中指定的runc路径通常是/usr/bin/runc或/usr/sbin/runc是存在的、可执行的 LoongArch 版本。4.3 验证 runc 与内核模块runc是实际创建容器的工具它依赖于 Linux 内核的命名空间和 cgroup 功能。# 1. 检查 runc 的版本和路径 which runc runc --version # 确认输出的是 LoongArch 版本且版本与 Docker/containerd 兼容。 # 2. 检查必需的内核模块是否加载 lsmod | grep -E “overlay|br_netfilter|ip_tables|iptable_filter|iptable_nat” # 关键模块overlay存储驱动、br_netfilter、ip_tables网络 # 如果未加载使用 sudo modprobe 模块名 加载。 # 3. 检查 cgroup 文件系统支持 ls /sys/fs/cgroup/ # 确认有 cgroup2 或 cgroup 目录。现代 Docker 更推荐使用 cgroup v2。 grep cgroup /proc/filesystems # 查看内核支持的文件系统类型。4.4 分析存储驱动Docker 使用存储驱动来管理镜像和容器的分层文件系统。在龙芯平台上overlay2是最常用且推荐的驱动。# 查看 Docker 当前的存储驱动配置 sudo docker info | grep “Storage Driver\|Backing Filesystem”如果输出不是overlay2或者Backing Filesystem不被支持如xfs需要ftype1就需要调整。4.5 检查用户组与权限虽然使用了sudo但 Docker 守护进程本身以及runc执行时对某些资源的访问权限可能仍有问题。# 将当前用户加入 docker 组避免每次都使用 sudo操作后需重新登录 sudo usermod -aG docker $USER # 检查 /var/run/docker.sock 的权限 ls -l /var/run/docker.sock # 应属于 docker 组且组用户有读写权限。5. 解决方案修复容器创建失败根据上述排查我们针对龙芯 3B6000 AnolisOS 23.4 的常见问题提供一套组合解决方案。5.1 方案一彻底卸载并安装社区验证版本默认仓库的 Docker 包可能不是最佳选择。我们可以卸载后采用龙芯社区或 Anolis 社区验证过的软件源进行安装。# 1. 彻底卸载现有 Docker sudo dnf remove docker docker-client docker-client-latest docker-common docker-latest docker-latest-logrotate docker-logrotate docker-engine docker-compose sudo rm -rf /var/lib/docker sudo rm -rf /var/lib/containerd # 2. 添加龙芯开源软件仓库Loongnix 或 OpenAnolis 的扩展仓库 # 例如添加 Anolis 的 extras 仓库请根据 AnolisOS 23.4 实际文档操作 # 通常仓库配置文件在 /etc/yum.repos.d/ 下 # 这里以可能存在的社区源为例实际操作需确认可用性 # sudo curl -o /etc/yum.repos.d/anolis-extras.repo https://some-mirror.anolisos.com/repo/anolis-extras.repo # 3. 重新安装 Docker # 在配置好合适的仓库后再次安装 sudo dnf makecache sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 4. 配置 Docker 使用 systemd 作为 cgroup 驱动重要 sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -‘EOF’ { “exec-opts”: [“native.cgroupdriversystemd”], “log-driver”: “json-file”, “log-opts”: { “max-size”: “100m” }, “storage-driver”: “overlay2”, “registry-mirrors”: [“https://cr.loongnix.cn”] # 使用龙芯镜像加速 } EOF # 5. 重启服务 sudo systemctl daemon-reload sudo systemctl restart docker5.2 方案二手动配置 containerd 和 runc如果安装后containerd或runc仍有问题可以尝试手动检查和配置。# 1. 确认 containerd 和 runc 的二进制文件 ls -lh /usr/bin/containerd* /usr/bin/runc* /usr/sbin/runc* # 2. 如果 runc 缺失或版本不对可以从可靠来源安装 # 例如从龙芯的软件包中提取或从源码编译复杂 # 假设已有正确的 runc 二进制包 # sudo dnf install runc-version.loongarch64.rpm # 3. 生成 containerd 的默认配置 sudo containerd config default | sudo tee /etc/containerd/config.toml # 4. 在 config.toml 中确保 runc 的路径正确 # 使用 sed 修改或手动编辑 sudo sed -i ‘s#SystemdCgroup false#SystemdCgroup true#’ /etc/containerd/config.toml # 5. 重启 containerd 和 docker sudo systemctl restart containerd sudo systemctl restart docker5.3 方案三内核参数与模块调整确保内核支持容器运行所需的所有功能。# 1. 加载必要的内核模块 sudo modprobe overlay sudo modprobe br_netfilter # 2. 设置系统启动时自动加载模块 echo “overlay” | sudo tee -a /etc/modules-load.d/containerd.conf echo “br_netfilter” | sudo tee -a /etc/modules-load.d/containerd.conf # 3. 配置网络桥接的 iptables 处理 cat EOF | sudo tee /etc/sysctl.d/99-docker.conf net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF sudo sysctl --system5.4 方案四使用特定 LoongArch 镜像测试在修复环境后使用已知良好的 LoongArch 镜像进行测试。龙芯社区维护了一个镜像仓库。# 配置 Docker 镜像加速器如果上一步的 daemon.json 已配置可跳过 # 拉取 LoongArch 架构的 busybox 镜像进行测试 sudo docker pull cr.loongnix.cn/library/busybox:latest # 查看镜像架构 sudo docker inspect cr.loongnix.cn/library/busybox:latest | grep Architecture # 运行测试容器 sudo docker run -it --rm cr.loongnix.cn/library/busybox:latest echo “Hello from LoongArch Container!”如果这一步成功恭喜你Docker 环境已经基本正常。6. 常见问题与排查思路即使按照上述步骤操作仍可能遇到一些“坑”。下表汇总了常见问题现象及其解决思路问题现象可能原因排查与解决思路OCI runtime create failed: unable to retrieve OCI runtime error1.runc版本不兼容或损坏。2. 内核不支持某些特性如 cgroup v2。3.containerd配置错误。1. 检查runc --version尝试安装/更新runc。2. 检查内核版本和cgroup类型 (mount -t cgroup2)。3. 检查/etc/containerd/config.toml中的runc配置路径。failed to start shim: fork/exec ... no such file or directorycontainerd-shim-runc-v2二进制文件缺失或路径错误。1. 查找文件find / -name “containerd-shim-runc-v2”。2. 如果缺失重新安装containerd或从正常机器拷贝。3. 在config.toml中核对shim路径。docker run挂起无响应1. 镜像拉取失败网络问题。2. 存储驱动问题如overlay2与文件系统不兼容。3. 资源不足内存、磁盘。1. 配置镜像加速器使用docker pull单独拉取镜像测试。2. 检查docker info中的存储驱动和文件系统。3. 检查dmesg和系统资源使用情况。权限错误即使使用 sudo1./var/run/docker.sock权限问题。2. SELinux/AppArmor 策略限制。3. 用户未加入docker组。1.ls -l /var/run/docker.sock确保docker组有权限。2. 临时禁用 SELinux (setenforce 0) 测试或配置正确策略。3. 将用户加入docker组并重新登录。无法拉取镜像no matching manifest镜像仓库中没有linux/loongarch64架构的镜像。1. 使用支持 LoongArch 的镜像仓库如cr.loongnix.cn。2. 在拉取时指定平台如果镜像支持多架构--platform linux/loongarch64。3. 自己构建 LoongArch 架构的镜像。7. 最佳实践与工程建议在龙芯等国产化平台上稳定运行 Docker除了解决问题更需要建立规范。源的选择与管理优先使用经过验证的软件源如 OpenAnolis 社区为 AnolisOS 提供的扩展仓库、龙芯的官方或社区仓库。避免混用来源不明的 RPM/DEB 包。固定版本在生产环境中固定 Docker、containerd、runc 的版本避免因自动升级引入不兼容问题。镜像构建与迁移多架构构建如果你的应用需要跨平台部署使用docker buildx进行多架构镜像构建包括linux/loongarch64。基础镜像选择优先选择基于 AnolisOS、Loongnix 或 Alpine Linux已支持 LoongArch 等发行版构建的基础镜像以获得更好的兼容性。镜像仓库搭建私有镜像仓库并主动同步或构建 LoongArch 架构的常用基础镜像减少对公网不可控仓库的依赖。配置标准化统一daemon.json将cgroupdriver、storage-driver、registry-mirrors、log-opts等关键配置在/etc/docker/daemon.json中标准化。内核参数调优将容器相关的内核参数如net.ipv4.ip_forward,vm.max_map_count等写入/etc/sysctl.d/下的配置文件并确保系统启动时加载。监控与日志启用 Docker 日志轮转在daemon.json中配置log-driver和log-opts防止日志占满磁盘。监控容器资源使用cadvisor、node-exporter等工具监控龙芯主机上容器的 CPU、内存、IO 使用情况观察是否有架构特定的性能特征。安全考虑非 Root 用户运行考虑使用rootless模式运行 Docker尽管在 LoongArch 上可能需要更多测试但这是提升安全性的重要方向。最小权限原则容器内应用以非 root 用户运行避免使用--privileged特权模式。SELinux/AppArmor在理解策略的基础上为容器配置适当的 SELinux 上下文或 AppArmor 配置文件而不是简单粗暴地禁用。备份与恢复定期备份/etc/docker和/var/lib/docker在服务停止时目录下的关键配置和镜像数据。记录最终可用的软件包版本组合docker-ce,containerd.io,runc形成环境配置清单。在龙芯 3B6000 的 AnolisOS 23.4 系统上部署 Docker核心挑战在于软件生态的完整性与兼容性。通过本文的步骤——从通过默认仓库安装复现问题到层层深入分析日志、检查运行时和内核模块最终通过切换软件源、调整配置、加载内核模块等组合方案解决问题——我们不仅解决了一个具体的技术障碍更梳理出了一套在非 x86 架构上部署容器环境的通用排查方法论。关键收获在于不能简单照搬 x86 环境的经验。在龙芯平台上每一个组件内核、Docker 引擎、containerd、runc、基础镜像的架构兼容性都必须得到确认。优先采用社区验证过的软件源和镜像仔细核对配置文件并充分利用系统日志进行排查是成功的关键。下一步你可以探索如何在龙芯平台上利用 Docker Compose 编排多容器应用或者结合 Kubernetes 进行容器集群的管理。同时关注 OpenAnolis 社区和龙芯生态的最新动态获取更优的软件包和更稳定的镜像将使你的国产化容器之旅更加顺畅。