鸿蒙PC融合开发引擎openEuler安装Docker排障实录

鸿蒙专家

测试环境与结论
鸿蒙 PC 的融合开发引擎内置 openEuler 环境，能否在其中安装 Docker 跑开发服务？本次实测在融合开发引擎的 openEuler 终端完成，不是鸿蒙原生终端。结论是：可以运行。实际安装的是 Moby 25.0.3，成功拉取并运行 ARM64 版 hello-world 容器，后续补齐 Docker Compose v5.5.0 插件。但直接 dnf install docker 不会一次成功，中间遇到旧引擎与 cgroup v2 不兼容、Docker Hub 访问超时、Compose 插件缺失和重启后 SELinux 标签异常等问题。本文针对本次环境，不代表所有融合开发引擎版本和容器应用都已验证兼容。

第一处坑：docker-engine 启动失败，根因是 cgroup v2
最初通过系统软件源安装：

2. sudo dnf install -y docker
3. sudo systemctl enable --now docker

复制代码

安装事务成功，但得到 docker-engine 18.09.0-354.oe2403sp3，服务启动失败。查看日志：

2. sudo journalctl -u docker.service -b -n 120 --no-pager -o cat

复制代码

关键错误：

2. Error starting daemon: Devices cgroup isn't mounted

复制代码

继续检查 /sys/fs/cgroup：

2. stat -fc %T /sys/fs/cgroup
3. findmnt -t cgroup,cgroup2
4. cat /sys/fs/cgroup/cgroup.controllers

复制代码

结果类型为 cgroup2fs，系统只有 cgroup v2 挂载。cgroup v2 的 cgroup.controllers 不列出 devices 是正常现象，不应通过手动创建目录解决。真正问题是已安装的旧引擎在寻找 cgroup v1 的 devices 挂载点。Docker 上游从 20.10 开始支持 cgroup v2，本次旧分支未适配。

改用 openEuler 仓库中的 Moby 25.0.3
不修改内核启动参数，也不混用 CentOS 源，选择同一 openEuler 仓库提供的 Moby 25.0.3。Moby 是 Docker Engine 开源上游，安装后仍使用 docker 命令。先预览替换计划：

2. sudo dnf info moby moby-engine moby-client
3. sudo dnf install moby --allowerasing --assumeno

复制代码

预览显示安装 Moby、containerd、runc 等 10 个包，只移除旧 docker-engine。确认后执行：

2. sudo dnf install moby --allowerasing
3. sudo systemctl daemon-reload
4. sudo systemctl enable --now docker
5. sudo docker version
6. sudo docker info

复制代码

最终能看到 25.0.3 的 Client 和 Server，并显示：

2. Cgroup Driver: systemd
3. Cgroup Version: 2

复制代码

已有容器业务的机器应先备份配置和业务数据，再评估迁移，不要直接照搬卸载操作，也不要删除 /var/lib/docker。全新环境可优先查询并安装 moby。过程中还出现过独立 containerd.service 启动失败，但 Docker 服务端仍能响应，后续容器也能运行；该异常尚未单独定位，不应描述成已修复，也不要盲目反复启动或停用。

第二处坑：Docker Hub 超时与镜像加速配置
引擎启动后运行：

2. sudo docker run --rm hello-world

复制代码

出现访问 https://registry-1.docker.io/v2/ 超时。此时应排查镜像仓库网络，而不是重装 Docker。本次按用户选择，将 https://docker.1panel.live 加入 /etc/docker/daemon.json 的 registry-mirrors。已有配置先备份，并在原 JSON 对象中合并该字段，不能覆盖其他设置。若文件不存在或为空，可写：

2. {
3.   "registry-mirrors": ["https://docker.1panel.live"]
4. }

复制代码

保存后校验、重启并确认：

2. sudo dockerd --validate --config-file=/etc/docker/daemon.json &&
3. sudo systemctl restart docker
4. sudo docker info --format '{{json .RegistryConfig.Mirrors}}'
5. sudo docker run --rm hello-world

复制代码

本次成功拉取并输出：

2. Hello from Docker!
3. This message shows that your installation appears to be working correctly.

复制代码

这说明客户端通信、镜像下载、容器创建和程序执行的基本链路已跑通。该地址是第三方服务，本次可用不代表长期可用或适合生产，使用前应评估可信度。

补齐 Docker Compose：引擎可用不等于插件已装
运行 sudo docker compose up -d 时出现：

2. unknown shorthand flag: 'd' in -d
3. docker: 'compose' is not a docker command.

复制代码

这说明当前 Docker CLI 没有识别到 Compose 插件，不是 -d 写错，也不是需要重装引擎。docker compose 是 CLI 插件用法，与带横线的 docker-compose 不能简单等同。
dnf search compose 能查到 docker-compose.noarch，但仅凭包名不能确认版本及是否提供 CLI 插件，本次没有安装该包，而是采用官方发布的 Linux ARM64 Compose 插件，实测 v5.5.0。先确认下载依赖：

2. curl --version
3. rpm -q ca-certificates

复制代码

缺少依赖时再通过 sudo dnf install curl ca-certificates 安装并检查事务清单。本次安装依赖时，DNF 同时升级了 curl、libcurl 和 ca-certificates，说明安装命令也可能更新已安装包，不能当成纯检查命令。
下载 ARM64 文件时，文件名是 docker-compose-linux-aarch64，不是 x86_64。建议使用固定缓存目录，便于断点续传：

2. mkdir -p "$HOME/.cache/docker-compose/v5.5.0"
3. curl -fL -C - --connect-timeout 30 "https://github.com/docker/compose/releases/download/v5.5.0/docker-compose-linux-aarch64" -o "$HOME/.cache/docker-compose/v5.5.0/docker-compose"

复制代码

-f 使 HTTP 错误返回失败，-L 跟随重定向，-C - 尝试断点续传。不要设置总下载时长。镜像加速地址不会加速 GitHub 二进制文件下载。
本次最初设置 --max-time 600，文件约 44.3 MiB，下载到约 16.2 MiB 时触发十分钟总时限：

2. curl: (28) Operation timed out after 599354 milliseconds
3. with 17068712 out of 46470638 bytes received

复制代码

这不是终端断线，也不意味着必须从头下载。保留部分文件，去掉总时限，用 curl -C - 可尝试续传。实测还发生过路径错误：把 /tmp/tmp.ABC123/docker-compose 这类示例路径直接复制进命令，导致：

2. curl: (23) Failure writing output to destination

复制代码

该错误表示输出路径不可写或不存在，不是远端文件损坏。示例路径不能当实际路径，部分文件也不能仅因出现下载错误就当完整文件安装。
确认 curl 正常退出、下载达到 100% 后，安装到系统级目录：

2. sudo install -d -m 0755 /usr/local/lib/docker/cli-plugins &&
3. sudo install -m 0755 "$HOME/.cache/docker-compose/v5.5.0/docker-compose" /usr/local/lib/docker/cli-plugins/docker-compose &&
4. sudo docker compose version

复制代码

选择 /usr/local/lib/docker/cli-plugins 是为了系统级安装，避免仅装在普通用户 ~/.docker/cli-plugins 后 sudo docker 找不到插件。安装 CLI 插件不需要重启 Docker。本次输出：

2. Docker Compose version v5.5.0

复制代码

手动安装的插件不会随 DNF 软件包更新自动升级，需要自行维护。本次未另行记录发布文件校验和核验，因此不能宣称已完成供应链完整性验证；正式环境应按官方发布校验信息验证。
后续进入实际包含 compose.yaml 或 docker-compose.yml 的项目目录，可执行：

2. sudo docker compose config --quiet &&
3. sudo docker compose up -d
4. sudo docker compose ps
5. sudo docker compose logs --tail=50

复制代码

config --quiet 用于检查配置，up -d 会创建或更新并启动服务。没有 Compose 配置文件时，不要直接在用户主目录执行。若出现 API 版本不兼容，应根据错误选用匹配的 Compose 或引擎版本，而不是把版本命令成功当成完整兼容性验证。

重启后的 SELinux 标签异常与临时恢复思路
后续重启验证发现，系统处于 SELinux Enforcing 模式时，部分文件标签与策略不匹配，导致 systemctl 异常、Docker 查询超时。定点修复后 Docker API 恢复响应；再次重启时，/、/etc、/usr 和 /etc/ld.so.cache 的修复标签保留，但 /dev/null 又变成了 xserver_misc_device_t，而本机策略期望 null_device_t。
原文给出一个仅适用于该融合开发引擎 openEuler 环境的 recover-docker.sh。它不是通用修复脚本，也不是永久修复。脚本会调整明确列出的五个路径的 SELinux 标签，并提交 Docker 启动请求，不是只读检查。运行方式是在文件所在目录执行：

2. sh recover-docker.sh

复制代码

无需先设置执行权限，脚本需要时会请求 sudo。不要添加递归参数 -R 或 -r，也不要在鸿蒙原生终端运行。脚本核心动作包括：

2. restorecon -v / /etc /usr /dev/null /etc/ld.so.cache
3. timeout 15s systemctl reset-failed docker.service
4. timeout 15s systemctl start --no-block docker.service
5. docker --host unix:///var/run/docker.sock info

复制代码

脚本最多检查 12 次 Docker API 是否就绪。若出现“Docker 本地 API 已恢复响应”且退出码为 0，说明本地引擎能响应查询，不代表业务健康，也不代表重启标签问题已永久解决。脚本不操作指定容器，但 Docker 启动时可能根据已有容器的 restart 策略自动启动容器；它不会关闭 SELinux、递归重标记系统、安装软件或删除数据。中途失败不会自动撤销此前已成功的标签修复或启动请求。如果服务查询仍无输出，需检查 SELinux 拒绝日志，不能把“没有输出”视为成功。标签复发的启动层原因仍未定位。

跑通之后还要注意什么
优先选择 ARM64 镜像。本次运行的是 arm64v8 版本，不能假设所有仅支持 AMD64 的应用都能直接运行。留意存储驱动，本次实际使用 vfs，基本功能可用，但通常更占磁盘、效率较低；能否使用 overlay2，需要检查内核和文件系统，不能直接改配置了事。容器端口不等于鸿蒙本机端口，-p 8080:80 首先映射到 openEuler 环境，鸿蒙侧或局域网能否访问，还取决于融合开发引擎的网络与转发配置，本次尚未验证。

结论
这次实测证明，鸿蒙 PC 可以借助融合开发引擎内的 openEuler 运行 Docker 容器。关键不是反复重装，而是先从日志确认失败点：旧引擎遇到 cgroup v2，就换用适配的 Moby；镜像拉取超时，就处理仓库网络。最终 hello-world 已成功运行，Compose v5.5.0 插件也已安装并通过版本命令验证。此次补充排查还解决了插件缺失、GitHub 下载超时和续传路径填写错误的问题。准确结论是：Docker 基本运行链路已跑通，Compose 插件已补齐，但重启稳定性、系统策略适配和业务健康不能视为全部通过。上述恢复脚本只是当前环境的临时恢复工具。

参考：
Docker 官方 Linux Compose 插件安装说明：https://docs.docker.com/compose/install/linux/
Docker Compose v5.5.0 发布页：https://github.com/docker/compose/releases/tag/v5.5.0
Docker 官方 cgroup 说明：https://docs.docker.com/articles/runmetrics
openEuler 社区 Moby 安装记录：https://forum.openeuler.org/t/topic/19434

热心网友4

感谢楼主分享，这篇排障实录很实用。最大的收获是遇到 docker-engine 启动失败时，先去查 cgroup 版本和日志，确认旧引擎在找 cgroup v1 的 devices 挂载点，而不是乱改内核参数或混用其他源；后面改用同一 openEuler 仓库里的 Moby 25.0.3，并且看到 Cgroup Driver 和 Cgroup Version 都正常，这个思路很稳。 Docker Hub 超时那段也很有帮助，先排查镜像仓库网络，再考虑在 daemon.json 里合并 registry-mirrors，而且强调先备份、不要覆盖其他配置，这些细节对实际环境很重要。第三方镜像地址的可用性和生产适用性确实得自己评估。 Compose 部分把“unknown shorthand flag”和“compose is not a docker command”定位成 CLI 插件缺失，而不是 -d 写错或重装引擎，这点很清楚。ARM64 要取 aarch64 版本、安装依赖时 DNF 可能顺带升级 curl 和 ca-certificates，也都是容易踩的坑。 另外你提醒已有容器业务要先备份配置和业务数据，不要直接照搬卸载，也不要删 /var/lib/docker，这个非常关键。独立 containerd.service 启动失败但 Docker 服务端仍能响应这个异常暂时没

热心网友4

感谢分享，这篇排障记录很实用。把环境限定在融合开发引擎的 openEuler 终端，不写成鸿蒙原生终端，这点很严谨。旧 docker-engine 在 cgroup v2 下报 Devices cgroup isn't mounted，确实容易让人误判；换成同仓库 Moby 25.0.3 后确认 Cgroup Driver 是 systemd、Cgroup Version 是 2，思路很清楚。已有业务先备份配置和数据、不删 /var/lib/docker 的提醒也很及时。 Docker Hub 超时那段，先查镜像仓库网络而不是重装 Docker，我比较认同；daemon.json 先备份再合并字段、校验后重启，步骤也完整。Compose 插件缺失和 docker-compose 不是一回事、ARM64 文件名不能写成 x86_64，这些细节很有帮助。第三方镜像地址只适合临时验证，是否长期可用和生产使用前都要评估。期待后续 SELinux 标签异常和 Compose 安装细节。

热心网友4

感谢分享，这篇排障记录对想在鸿蒙 PC 融合开发引擎里折腾 openEuler 容器环境的人很有帮助。几个关键点总结得很清楚：先确认是在融合开发引擎的 openEuler 终端里做，不是鸿蒙原生终端；旧 docker-engine 在 cgroup v2 下报 Devices cgroup isn't mounted，根因是旧分支没适配 cgroup v2，而不是手动去补 devices 目录；换同一 openEuler 仓库的 Moby 25.0.3 后 Cgroup Driver 是 systemd、Cgroup Version 是 2，链路能跑通。Docker Hub 超时那段也很实用，先查镜像仓库网络，配置 registry-mirrors 前备份并合并原 JSON，别覆盖已有设置。Compose 部分把 docker compose 插件和 docker-compose 包区分开，这个容易混淆。已有容器先备份、别直接删 /var/lib/docker、第三方镜像源要评估可信度、独立 containerd.service 异常先保留观察，这些提醒都很稳。后面 SELinux 标签异常和 Compose 插件安装如果继续更新，应该会更有参考价值。