龙芯3B6000平台AnolisOS 23.4部署Docker容器失败排查与修复指南

最近在龙芯 3B6000 平台上基于 AnolisOS 23.4 部署 Docker 环境时，遇到了一个典型问题：通过系统默认仓库安装 Docker 后，服务能正常启动，但在尝试创建或运行容器时，却频繁遭遇失败。这个问题在国产化平台迁移和容器化实践中具有一定普遍性，其背后往往涉及架构兼容性、内核模块、存储驱动等多个层面的因素。本文将系统性地拆解这一问题的完整排查与解决流程，从环境准备、问题复现、根因分析到最终修复，提供一套可复现的实战指南。无论你是正在将业务向龙芯平台迁移的运维工程师，还是对 LoongArch 架构下容器技术感兴趣的开发者，都能从中获得直接的帮助。

1. 背景与核心概念

在深入问题之前，我们有必要厘清几个关键概念，这有助于理解后续的排查逻辑。

龙芯 3B6000 与 LoongArch 架构：龙芯 3B6000 是龙芯中科推出的新一代通用处理器，采用完全自主设计的 LoongArch 指令集架构。这意味着其二进制指令与常见的 x86_64 或 ARM 架构不同，所有软件，包括操作系统内核、系统工具和应用程序，都需要针对 LoongArch 进行编译或提供对应的版本。

AnolisOS 23.4：Anolis 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”

在问题环境中，你很可能会遇到如下几种典型的错误信息：

1. docker: Error response from daemon: failed to create shim task: OCI runtime create failed: ...这是最常见的一类错误，指向 OCI（开放容器标准）运行时（通常是runc）创建失败。
2. docker: Error response from daemon: failed to start shim: fork/exec /usr/bin/containerd-shim-runc-v2: no such file or directory这表明 containerd 的 shim 可执行文件路径有问题或文件缺失。
3. docker: Error response from daemon: failed to create shim: could not find an OCI runtime configuration file指向 OCI 运行时配置文件缺失。
4. 权限错误：虽然使用了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需要ftype=1），就需要调整。

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.cgroupdriver=systemd”], “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 docker

5.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 docker

5.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 --system

5.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. 常见问题与排查思路

即使按照上述步骤操作，仍可能遇到一些“坑”。下表汇总了常见问题现象及其解决思路：

7. 最佳实践与工程建议

在龙芯等国产化平台上稳定运行 Docker，除了解决问题，更需要建立规范。

1. 源的选择与管理：

   • 优先使用经过验证的软件源：如 OpenAnolis 社区为 AnolisOS 提供的扩展仓库、龙芯的官方或社区仓库。避免混用来源不明的 RPM/DEB 包。
   • 固定版本：在生产环境中，固定 Docker、containerd、runc 的版本，避免因自动升级引入不兼容问题。

2. 镜像构建与迁移：

   • 多架构构建：如果你的应用需要跨平台部署，使用docker buildx进行多架构镜像构建（包括linux/loongarch64）。
   • 基础镜像选择：优先选择基于 AnolisOS、Loongnix 或 Alpine Linux（已支持 LoongArch） 等发行版构建的基础镜像，以获得更好的兼容性。
   • 镜像仓库：搭建私有镜像仓库，并主动同步或构建 LoongArch 架构的常用基础镜像，减少对公网不可控仓库的依赖。

3. 配置标准化：

   • 统一daemon.json：将cgroupdriver、storage-driver、registry-mirrors、log-opts等关键配置在/etc/docker/daemon.json中标准化。
   • 内核参数调优：将容器相关的内核参数（如net.ipv4.ip_forward,vm.max_map_count等）写入/etc/sysctl.d/下的配置文件，并确保系统启动时加载。

4. 监控与日志：

   • 启用 Docker 日志轮转：在daemon.json中配置log-driver和log-opts，防止日志占满磁盘。
   • 监控容器资源：使用cadvisor、node-exporter等工具监控龙芯主机上容器的 CPU、内存、IO 使用情况，观察是否有架构特定的性能特征。

5. 安全考虑：

   • 非 Root 用户运行：考虑使用rootless模式运行 Docker，尽管在 LoongArch 上可能需要更多测试，但这是提升安全性的重要方向。
   • 最小权限原则：容器内应用以非 root 用户运行，避免使用--privileged特权模式。
   • SELinux/AppArmor：在理解策略的基础上，为容器配置适当的 SELinux 上下文或 AppArmor 配置文件，而不是简单粗暴地禁用。

6. 备份与恢复：

   • 定期备份/etc/docker和/var/lib/docker（在服务停止时）目录下的关键配置和镜像数据。
   • 记录最终可用的软件包版本组合（docker-ce,containerd.io,runc），形成环境配置清单。

在龙芯 3B6000 的 AnolisOS 23.4 系统上部署 Docker，核心挑战在于软件生态的完整性与兼容性。通过本文的步骤——从通过默认仓库安装复现问题，到层层深入分析日志、检查运行时和内核模块，最终通过切换软件源、调整配置、加载内核模块等组合方案解决问题——我们不仅解决了一个具体的技术障碍，更梳理出了一套在非 x86 架构上部署容器环境的通用排查方法论。

关键收获在于，不能简单照搬 x86 环境的经验。在龙芯平台上，每一个组件（内核、Docker 引擎、containerd、runc、基础镜像）的架构兼容性都必须得到确认。优先采用社区验证过的软件源和镜像，仔细核对配置文件，并充分利用系统日志进行排查，是成功的关键。

下一步，你可以探索如何在龙芯平台上利用 Docker Compose 编排多容器应用，或者结合 Kubernetes 进行容器集群的管理。同时，关注 OpenAnolis 社区和龙芯生态的最新动态，获取更优的软件包和更稳定的镜像，将使你的国产化容器之旅更加顺畅。