查看: 99|回复: 0

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

[复制链接]
发表于 1 小时前 | 显示全部楼层 |阅读模式
测试环境与结论
鸿蒙 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
最初通过系统软件源安装:
  1. sudo dnf install -y docker
  2. sudo systemctl enable --now docker
复制代码
安装事务成功,但得到 docker-engine 18.09.0-354.oe2403sp3,服务启动失败。查看日志:
  1. sudo journalctl -u docker.service -b -n 120 --no-pager -o cat
复制代码
关键错误:
  1. Error starting daemon: Devices cgroup isn't mounted
复制代码
继续检查 /sys/fs/cgroup:
  1. stat -fc %T /sys/fs/cgroup
  2. findmnt -t cgroup,cgroup2
  3. 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 命令。先预览替换计划:
  1. sudo dnf info moby moby-engine moby-client
  2. sudo dnf install moby --allowerasing --assumeno
复制代码
预览显示安装 Moby、containerd、runc 等 10 个包,只移除旧 docker-engine。确认后执行:
  1. sudo dnf install moby --allowerasing
  2. sudo systemctl daemon-reload
  3. sudo systemctl enable --now docker
  4. sudo docker version
  5. sudo docker info
复制代码
最终能看到 25.0.3 的 Client 和 Server,并显示:
  1. Cgroup Driver: systemd
  2. Cgroup Version: 2
复制代码
已有容器业务的机器应先备份配置和业务数据,再评估迁移,不要直接照搬卸载操作,也不要删除 /var/lib/docker。全新环境可优先查询并安装 moby。过程中还出现过独立 containerd.service 启动失败,但 Docker 服务端仍能响应,后续容器也能运行;该异常尚未单独定位,不应描述成已修复,也不要盲目反复启动或停用。

第二处坑:Docker Hub 超时与镜像加速配置
引擎启动后运行:
  1. sudo docker run --rm hello-world
复制代码
出现访问 https://registry-1.docker.io/v2/ 超时。此时应排查镜像仓库网络,而不是重装 Docker。本次按用户选择,将 https://docker.1panel.live 加入 /etc/docker/daemon.json 的 registry-mirrors。已有配置先备份,并在原 JSON 对象中合并该字段,不能覆盖其他设置。若文件不存在或为空,可写:
  1. {
  2.   "registry-mirrors": ["https://docker.1panel.live"]
  3. }
复制代码
保存后校验、重启并确认:
  1. sudo dockerd --validate --config-file=/etc/docker/daemon.json &&
  2. sudo systemctl restart docker
  3. sudo docker info --format '{{json .RegistryConfig.Mirrors}}'
  4. sudo docker run --rm hello-world
复制代码
本次成功拉取并输出:
  1. Hello from Docker!
  2. This message shows that your installation appears to be working correctly.
复制代码
这说明客户端通信、镜像下载、容器创建和程序执行的基本链路已跑通。该地址是第三方服务,本次可用不代表长期可用或适合生产,使用前应评估可信度。

补齐 Docker Compose:引擎可用不等于插件已装
运行 sudo docker compose up -d 时出现:
  1. unknown shorthand flag: 'd' in -d
  2. 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。先确认下载依赖:
  1. curl --version
  2. rpm -q ca-certificates
复制代码
缺少依赖时再通过 sudo dnf install curl ca-certificates 安装并检查事务清单。本次安装依赖时,DNF 同时升级了 curl、libcurl 和 ca-certificates,说明安装命令也可能更新已安装包,不能当成纯检查命令。
下载 ARM64 文件时,文件名是 docker-compose-linux-aarch64,不是 x86_64。建议使用固定缓存目录,便于断点续传:
  1. mkdir -p "$HOME/.cache/docker-compose/v5.5.0"
  2. 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 时触发十分钟总时限:
  1. curl: (28) Operation timed out after 599354 milliseconds
  2. with 17068712 out of 46470638 bytes received
复制代码
这不是终端断线,也不意味着必须从头下载。保留部分文件,去掉总时限,用 curl -C - 可尝试续传。实测还发生过路径错误:把 /tmp/tmp.ABC123/docker-compose 这类示例路径直接复制进命令,导致:
  1. curl: (23) Failure writing output to destination
复制代码
该错误表示输出路径不可写或不存在,不是远端文件损坏。示例路径不能当实际路径,部分文件也不能仅因出现下载错误就当完整文件安装。
确认 curl 正常退出、下载达到 100% 后,安装到系统级目录:
  1. sudo install -d -m 0755 /usr/local/lib/docker/cli-plugins &&
  2. sudo install -m 0755 "$HOME/.cache/docker-compose/v5.5.0/docker-compose" /usr/local/lib/docker/cli-plugins/docker-compose &&
  3. sudo docker compose version
复制代码
选择 /usr/local/lib/docker/cli-plugins 是为了系统级安装,避免仅装在普通用户 ~/.docker/cli-plugins 后 sudo docker 找不到插件。安装 CLI 插件不需要重启 Docker。本次输出:
  1. Docker Compose version v5.5.0
复制代码
手动安装的插件不会随 DNF 软件包更新自动升级,需要自行维护。本次未另行记录发布文件校验和核验,因此不能宣称已完成供应链完整性验证;正式环境应按官方发布校验信息验证。
后续进入实际包含 compose.yaml 或 docker-compose.yml 的项目目录,可执行:
  1. sudo docker compose config --quiet &&
  2. sudo docker compose up -d
  3. sudo docker compose ps
  4. 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 启动请求,不是只读检查。运行方式是在文件所在目录执行:
  1. sh recover-docker.sh
复制代码
无需先设置执行权限,脚本需要时会请求 sudo。不要添加递归参数 -R 或 -r,也不要在鸿蒙原生终端运行。脚本核心动作包括:
  1. restorecon -v / /etc /usr /dev/null /etc/ld.so.cache
  2. timeout 15s systemctl reset-failed docker.service
  3. timeout 15s systemctl start --no-block docker.service
  4. 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
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

指导单位

江苏省公安厅

江苏省通信管理局

浙江省台州刑侦支队

DEFCON GROUP 86025

Hacking Group 021A

旗下站点

态势感知中心

应急响应中心

红盟安全

联系我们

官方QQ群:112851260

官方邮箱:security#ihonker.org(#改成@)

官方核心成员

关注微信公众号

Archiver|手机版|小黑屋| ( 沪ICP备2021026908号 )

GMT+8, 2026-9-16 13:09 , Processed in 0.021520 second(s), 18 queries , Gzip On, Redis On.

Powered by ihonker.com

Copyright © 2015-现在.

  • 返回顶部