企业官网建设流程全解析

在龙芯 3B6000 平台上运行 AnolisOS 23.4，通过系统默认仓库安装 Docker 后，遇到容器无法创建的问题，是一个典型的国产化平台软件生态适配过程中的实战挑战。这个问题并非简单的命令错误，其背后往往涉及内核模块支持、软件包版本兼容性、架构特定的依赖关系以及容器运行时配置等多个层面。对于需要在龙芯平台上进行应用容器化部署的开发者或运维人员来说，理解并解决这个问题是打通从硬件到应用部署的关键一步。本文将带你从零开始，在龙芯 3B6000 + AnolisOS 23.4 的环境下，完成 Docker 的安装、配置，并系统性地排查和解决容器创建失败的问题，最终实现一个可稳定运行的容器环境。

1. 理解龙芯平台与 Docker 的兼容性挑战

在 x86/ARM 架构上安装 Docker 通常是一条命令的事，但在龙芯（LoongArch）架构上，情况会复杂许多。龙芯 3B6000 处理器采用 LoongArch 指令集，这是一个完全自主设计的指令集架构。Docker 的核心依赖于 Linux 内核的容器化功能（如 cgroups、namespaces）以及特定的运行时（如 runc）。虽然 Docker 官方提供了对多种架构的支持，但 LoongArch 作为较新的架构，其软件生态，特别是预编译的二进制包和主流发行版的官方仓库支持，仍在不断完善中。

AnolisOS 23.4 作为一款兼容 CentOS/RHEL 生态的国产操作系统，其默认仓库中的软件包是针对 LoongArch 架构编译的。这既是优势也是挑战。优势在于，通过yum/dnf安装的软件理论上与系统其他组件兼容性更好。挑战在于，仓库中 Docker 相关包的版本、依赖关系以及内核模块的适配程度，可能无法直接满足 Docker 运行时的所有要求，尤其是与容器创建直接相关的containerd和runc组件。

容器无法创建的典型现象是，执行docker run hello-world后，命令长时间挂起，最终报错退出，错误信息可能涉及failed to create shim task、OCI runtime create failed或failed to start container等。其根本原因通常可以追溯到以下几个层面：

1. 内核模块未启用或版本不匹配：Docker 需要内核开启overlay、bridge、iptables等模块支持。
2. containerd或runc版本/配置问题：它们是 Docker 创建容器的实际执行者，其 LoongArch 版本的二进制文件可能存在 bug 或配置不当。
3. SELinux/AppArmor 安全策略限制：安全模块可能阻止了容器进程的某些操作。
4. 系统资源限制：如cgroup配置、用户进程数限制等。
5. 架构特定的依赖库缺失：某些动态链接库在 LoongArch 环境下可能缺失或路径不正确。

2. 环境准备与系统基础检查

在进行任何安装操作之前，必须确保系统处于一个干净、一致的状态，并完成必要的基础配置。

2.1 系统信息确认

首先，登录你的龙芯 3B6000 服务器，通过以下命令确认系统版本和架构：

cat /etc/os-release uname -a lsb_release -a # 如果已安装 lsb_release 命令

预期输出应明确显示AnolisOS 23.4和loongarch64架构。记录下完整的内核版本号，例如5.10.xxx。

2.2 更新系统并安装基础工具

确保系统所有包更新到最新状态，并安装后续排查可能需要的工具。

sudo dnf update -y sudo dnf install -y vim wget curl net-tools lsof pciutils elfutils-libelf-devel

2.3 检查并加载必需的内核模块

Docker 依赖的内核功能需要对应的模块处于加载状态。运行以下命令检查：

lsmod | grep -E “overlay|bridge|nf_nat|veth|iptable|ip6table”

如果这些模块没有显示，可能需要手动加载或确认内核编译时已包含。对于 AnolisOS，通常这些模块都已内置或可加载。可以尝试手动加载关键模块：

sudo modprobe overlay sudo modprobe br_netfilter

为了让这些模块在系统启动时自动加载，需要创建配置文件：

sudo tee /etc/modules-load.d/docker.conf <<EOF overlay br_netfilter EOF

此外，还需要配置系统参数以启用网络过滤和桥接：

sudo tee /etc/sysctl.d/docker.conf <<EOF net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF sudo sysctl --system # 应用配置

3. 通过 AnolisOS 默认仓库安装 Docker

这是最直接的方式，但也是问题可能出现的起点。

3.1 安装 Docker 引擎及相关组件

执行以下命令从 AnolisOS 默认仓库安装：

sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

注意：在 LoongArch 架构的 AnolisOS 23.4 上，docker-ce这个包名可能不存在于默认仓库。更常见的情况是，仓库中提供的包名是docker或moby-engine。因此，首先应该搜索可用的 Docker 相关包：

sudo dnf search docker sudo dnf search moby

假设搜索结果显示包名为docker和docker-client，那么安装命令应改为：

sudo dnf install -y docker docker-client containerd

安装完成后，验证安装的版本：

docker --version containerd --version runc --version # 如果 runc 作为独立包安装

记录下这些版本号，对于后续排查至关重要。

3.2 启动 Docker 服务并设置开机自启

sudo systemctl start docker sudo systemctl enable docker

检查服务状态，确保其处于active (running)状态：

sudo systemctl status docker

如果服务启动失败，使用journalctl -u docker --since “1 hour ago”查看详细日志。

3.3 配置 Docker 守护进程（可选但推荐）

编辑 Docker 守护进程配置文件/etc/docker/daemon.json。如果文件不存在，则创建它。一个适用于基础环境的配置示例如下：

{ “exec-opts”: [“native.cgroupdriver=systemd”], “log-driver”: “json-file”, “log-opts”: { “max-size”: “100m” }, “storage-driver”: “overlay2”, “storage-opts”: [ “overlay2.override_kernel_check=true” ] }

这个配置做了几件事：使用systemd作为 cgroup 驱动（与 AnolisOS 默认一致），配置日志轮转，并明确使用overlay2存储驱动。保存后，重启 Docker 服务使配置生效：

sudo systemctl daemon-reload sudo systemctl restart docker

4. 首次运行测试与问题现象复现

完成安装和基础配置后，进行最简单的容器运行测试。

4.1 运行 Hello-World 容器

sudo docker run hello-world

如果一切正常，你将看到来自 Docker 的欢迎信息。然而，在龙芯 3B6000 + AnolisOS 23.4 环境下，你更可能遇到以下情况之一：

1. 命令长时间挂起，无任何输出，最终超时或需要Ctrl+C中断。
2. 快速返回一个错误，例如：

   docker: Error response from daemon: failed to create shim: OCI runtime create failed: unable to retrieve OCI runtime error (open /run/containerd/io.containerd.runtime.v2.task/moby//log.json: no such file or directory): runc did not terminate successfully: unknown.

3. 提示镜像拉取失败，但错误信息可能指向更深层的运行时问题。

4.2 收集诊断信息

当容器创建失败时，不要盲目重试。首先收集全面的诊断信息：

# 1. 检查 Docker 服务状态和最近日志 sudo systemctl status docker -l sudo journalctl -u docker --since “-5min” --no-pager # 2. 检查 containerd 服务状态和日志（如果它作为独立服务运行） sudo systemctl status containerd -l 2>/dev/null || echo “containerd not running as separate service” journalctl -u containerd --since “-5min” --no-pager 2>/dev/null # 3. 检查 Docker 系统信息 sudo docker info # 4. 检查 runc 二进制文件是否存在且可执行 which runc runc --version ls -la $(which runc) # 5. 查看内核消息，可能有关键错误 sudo dmesg | tail -50

将上述命令的输出保存到文件中，这是分析问题的起点。

5. 系统性排查与解决容器创建失败问题

根据收集到的日志和信息，我们可以按照以下路径进行系统性排查。

5.1 排查路径一：Containerd 与 Runc 运行时问题

这是 LoongArch 架构下最常见的问题根源。Docker 默认使用containerd作为容器运行时，而containerd调用runc来实际创建容器。如果runc的 LoongArch 版本存在 bug 或与当前内核不兼容，就会导致创建失败。

检查与解决步骤：

1. 确认 runc 版本和路径：docker info输出中会显示Runtimes和Default Runtime信息。确保runc可执行文件存在于系统中，并且其版本与containerd兼容。
2. 升级或替换 runc：AnolisOS 仓库中的runc可能版本较旧。可以尝试从更上游的源（如 openEuler 的 LoongArch 仓库或龙芯社区）寻找更新的runc包进行安装。注意：直接替换runc二进制文件有风险，建议先备份。

   # 备份原有 runc sudo cp $(which runc) $(which runc).bak # 假设你下载了新的 runc 二进制到 /tmp/runc.new sudo install -m 755 /tmp/runc.new $(which runc)

3. 切换容器运行时：如果runc问题无法快速解决，可以尝试使用crun（一个用 C 语言编写的 OCI 运行时，有时在非 x86 架构上兼容性更好）或者旧版的docker-runc。但这需要重新配置containerd或 Docker，较为复杂。
4. 检查 containerd 配置：查看/etc/containerd/config.toml文件。确保[plugins.”io.containerd.grpc.v1.cri”.containerd.runtimes.runc]部分的runtime_type和binary_name设置正确。有时需要显式指定runc的路径。

5.2 排查路径二：内核与存储驱动问题

龙芯内核可能对 OverlayFS 的某些特性支持有差异。

检查与解决步骤：

1. 验证 overlay2 支持：运行sudo docker info | grep -i storage。确保Storage Driver是overlay2，并且Backing Filesystem是xfs或extfs（推荐 XFS 或 EXT4）。
2. 检查文件系统特性：对于overlay2，需要底层文件系统（如/var/lib/docker所在分区）支持d_type（目录条目类型）。使用以下命令检查：

   sudo df -T /var/lib/docker # 假设挂载点是 /dev/root sudo xfs_info /dev/root 2>/dev/null | grep ftype # 对于 XFS，ftype 应为 1 # 或者 sudo tune2fs -l /dev/root 2>/dev/null | grep features # 对于 EXT4，应包含 `dir_index` 和 `filetype`

   如果d_type不支持，docker info会显示警告。解决方案是使用支持d_type的文件系统（如格式化时指定-n ftype=1对于 XFS）。
3. 尝试其他存储驱动：作为临时测试，可以尝试使用vfs存储驱动。vfs性能很差且不适用于生产，但兼容性最高，可以用于判断问题是否出在存储驱动上。在/etc/docker/daemon.json中添加“storage-driver”: “vfs”，重启 Docker 后再次测试docker run hello-world。如果成功，则问题很可能与overlay2和内核的交互有关。

5.3 排查路径三：安全模块与权限问题

SELinux 或 AppArmor 可能会阻止容器进程执行某些操作。

检查与解决步骤：

1. 检查 SELinux 状态：getenforce。如果结果是Enforcing，可以尝试临时设置为Permissive进行测试：

   sudo setenforce 0

   再次尝试运行容器。如果成功，则说明是 SELinux 策略问题。你需要为 Docker 容器制定或调整 SELinux 策略，或者在生产环境中评估是否可以将 SELinux 设置为Permissive（不推荐）或Disabled（在/etc/selinux/config中修改并重启）。
2. 检查用户命名空间：虽然不常见，但用户命名空间映射问题也可能导致故障。确保/etc/subuid和/etc/subgid文件存在并为运行 Docker 守护进程的用户（通常是root）或其所属的docker组配置了映射。

5.4 排查路径四：资源与 Cgroups 问题

确保 Cgroups 被正确挂载且 Docker 可以访问。

检查与解决步骤：

1. 检查 cgroups 挂载：运行mount | grep cgroup。应该看到cgroup2或cgroup文件系统挂载在/sys/fs/cgroup。Docker 需要 cgroups 来管理容器资源。
2. 检查 cgroup 驱动：在docker info输出中查看Cgroup Driver。它应该与系统使用的 init 系统匹配（AnolisOS 23.4 通常使用systemd）。这已在之前的daemon.json配置中设置。
3. 检查系统资源限制：使用ulimit -a查看当前用户的资源限制。确保max user processes和open files等限制不是过低。可以在/etc/security/limits.conf或 systemd service 文件中为 Docker 服务调整限制。

6. 一个经过验证的解决方案示例

假设经过排查，你发现问题是 AnolisOS 23.4 默认仓库中的runc版本（例如 1.1.7）与当前内核存在兼容性问题。以下是一个可行的解决步骤：

1. 停止 Docker 服务：

   sudo systemctl stop docker sudo systemctl stop containerd # 如果独立运行

2. 备份并移除有问题的 runc：

   sudo mv $(which runc) $(which runc).bak.orig

3. 从兼容的源安装新版 runc。例如，从 openEuler 的 LoongArch 仓库下载。注意：你需要根据你的系统版本（这里是 AnolisOS 23.4，对应 openEuler 22.03 LTS SP2 可能更接近）和架构（loongarch64）寻找合适的 RPM 包。

   # 示例：下载一个已知在龙芯3B6000上可用的 runc 包（请替换为实际可用的URL） wget https://repo.openeuler.org/openEuler-22.03-LTS-SP2/loongarch64/Packages/runc-1.1.9-1.oe2203sp2.loongarch64.rpm # 安装 sudo rpm -ivh --force runc-1.1.9-1.oe2203sp2.loongarch64.rpm # 或者使用 dnf localinstall sudo dnf localinstall -y runc-1.1.9-1.oe2203sp2.loongarch64.rpm

   如果找不到直接可用的 RPM，也可以尝试从源码编译，但这需要完整的 Go 开发环境。

4. 验证新 runc 版本：

   runc --version

5. 重启 Docker 服务：

   sudo systemctl start containerd # 如果独立运行 sudo systemctl start docker

6. 再次运行测试容器：

   sudo docker run --rm hello-world

如果成功，你将看到经典的 “Hello from Docker!” 消息。

7. 最佳实践与后续步骤

成功运行第一个容器只是开始。为了在龙芯平台上获得稳定的容器化体验，请遵循以下实践：

1. 镜像兼容性：确保你拉取的镜像有loongarch64标签。许多官方镜像（如nginx:alpine,redis:alpine）现在都提供多架构支持，Docker 会自动拉取匹配的架构版本。对于自定义镜像，你需要在龙芯机器上使用Dockerfile重新构建。

2. 监控与日志：配置 Docker 的日志驱动和日志轮转策略（如前文daemon.json所示）。使用docker logs <container_id>查看容器日志。对于系统级监控，可以将 Docker 守护进程日志接入journald或 ELK 等系统。

3. 网络配置：龙芯平台的网络性能需要特别关注。如果遇到容器网络性能问题，可以尝试调整 Docker 的网络驱动（如使用macvlan获得原生性能），或者优化宿主机的网络参数。

4. 生产环境考量：

   • 存储：为/var/lib/docker挂载独立的高性能磁盘（如 SSD），并使用 XFS 文件系统（ftype=1）。
   • 安全：在解决 SELinux 问题后，应重新启用并配置正确的策略。定期更新 Docker、containerd 和 runc 到已知稳定的版本。
   • 资源管理：使用docker run的--memory,--cpus等参数限制容器资源，避免单个容器影响宿主机。
   • 编排：考虑使用 Docker Compose 管理多容器应用。对于集群，可以调研 Kubernetes 对 LoongArch 架构的支持情况，目前已有社区版本开始提供支持。

5. 社区资源：龙芯和 AnolisOS 的生态发展迅速，遇到问题时，优先查阅：

   • 龙芯开源社区
   • AnolisOS 官方文档和邮件列表
   • openEuler LoongArch SIG 这些社区通常有更针对性的问题讨论和解决方案。

通过以上步骤，你不仅解决了“容器无法创建”这个具体问题，更掌握了在国产化平台上部署和调试容器基础设施的方法论。从内核模块、运行时版本到安全策略，每一步的排查都加深了对容器技术栈的理解。在龙芯这样的新兴架构上实践，要求开发者具备更强的底层问题定位能力，而这正是从“使用者”向“专家”迈进的关键。