麒麟V10安装Docker：container-selinux依赖避坑

简介：面向在国产化服务器环境中部署容器运行时的运维人员与开发者的实操型手册，聚焦银河麒麟 V10 SP1 Server 无法直接获取 docker server 软件包这一常见障碍，给出可行的版本选择与落地路径。压缩包内共 1 个 docx 文档，约 17KB，篇幅精炼，按配置 yum 源、通过 yum 安装 docker 两大模块编排，并附目录，便于快速定位章节。文档给出了阿里第三方源与麒麟官方源两份 repo 配置写法，并以 docker-ce-cli 18.09.7、docker-ce 18.09.7 的具体安装命令为主线，串起服务启动与版本核验环节；同时专门记录最新版 docker 因 container-selinux 依赖无法满足而安装失败的报错原文与成因分析，帮助读者避开同类问题。目前已有 7220 人学习下载，适合需要一份可直接照做的国产系统 docker 部署参照的中级用户。

1. 麒麟上装 docker：卡在nothing provides container-selinux >= 2:2.74的那三天

在银河麒麟 V10 SP1 Server 上装 docker，最常见的失败方式，是yum install docker-ce敲下去，系统回你一句Error: Problem: cannot install the best candidate for the job - nothing provides container-selinux >= 2:2.74 needed by docker-ce-3:20.10.17-3.el7.aarch64。搜「docker 银河麒麟」出来的帖子十有八九停在这一步：有人加了--skip-broken看着不报错了，回头docker --version还是没有命令；有人一路--nogpgcheck硬装上去，容器起不来、镜像拉不动。这类故障折腾人的地方在于，报错只告诉你缺一个包，不告诉你缺的是哪个源、哪个版本门槛，该退回哪一版。下面把这份安装手册里的实际路径拆开，从源配置写到版本选择，适合第一次在麒麟服务器上落地容器环境、又不想把系统搞成半残的人。

2. 配源这一步：docker-ce.repo 少一个斜杠都装不上

装不上 docker，九成的原因不在 docker 本身，在仓库。麒麟服务器默认只挂了自家源，yum search docker出来的东西和你想要的不是一回事，yum install docker-ce自然也找不到可用的包。所以第一条命令永远是确认仓库，而不是直接装。

2.1 麒麟官方源里为什么搜不到 docker-ce

麒麟 V10 SP1 Server 的官方仓库（ks10-os-media这类）里，容器相关提供的是 podman、skopeo、buildah 这一套，docker-ce 不在其中。这不是配置错了，是发布策略如此。于是很多人yum search docker之后选了名字里带 docker 的那个包装上去，docker命令确实有了，docker version输出却和文档对不上，docker info里 Server 段要么是 podman 的兼容实现，要么干脆报Cannot connect to the Docker daemon。这种“装了个假 docker”的坑，比直接报错还费时间。

正确做法是两条腿走路：docker-ce 本体和它的同族包（docker-ce-cli、docker-ce-rootless-extras）从 docker 官方的 CentOS 7 仓库拿，因为 docker 的 el7 包同时提供 x86_64 和 aarch64 两种架构，麒麟的 aarch64 机器能直接用；而 container-selinux、libcgroup、libseccomp 这些底层依赖，docker 自己的仓库里没有，得回到麒麟官方源里解析。两个源同时启用，缺一个就会在yum install阶段报依赖缺失。

先清理一遍旧缓存，很多人改完 repo 文件不makecache，看到的还是上一轮的元数据，改了半天“没生效”：

# 清掉旧元数据，避免改完 repo 后仍命中旧缓存 yum clean all # 重新拉取所有启用仓库的元数据 yum makecache # 看当前生效的仓库列表，确认新加的两个都 enabled yum repolist

yum clean all会清掉/var/cache/yum下的元数据和包缓存，第一次配置源时必做；yum makecache是把各仓库的repomd.xml和 primary 数据拉回本地，后面yum list、yum install都基于它；yum repolist输出里如果某个仓库显示0个包，说明 baseurl 或者网络有问题，别急着往下装，先把这个仓库修好。

2.2 docker-ce.repo 五个字段里最容易写错的是哪个

仓库文件放在/etc/yum.repos.d/下，文件名随意，习惯叫docker-ce.repo。内容按手册给的最小集写：

[docker-ce-stable] name=Docker CE Stable - 7 # 注意：这里写死 centos/7，不要用 $releasever baseurl=https://mirrors.aliyun.com/docker-ce/linux/centos/7/$basearch/stable enabled=1 gpgcheck=1 gpgkey=https://mirrors.aliyun.com/docker-ce/linux/centos/gpg

逐字段说清楚，因为每个字段都有对应的一种翻车方式。[docker-ce-stable]是仓库 ID，后面--enablerepo、--disablerepo都靠这个名字，改名之后脚本里的参数要同步改。baseurl里的$basearch由 yum 在运行时替换成机器架构，aarch64 机器替换成aarch64，x86_64 替换成x86_64，所以同一份文件在两种机器上都能用，不用手改。

真正容易出问题的是路径里的那个7。麒麟 V10 的VERSION_ID是 10，如果写成$releasever，yum 会拼出.../linux/centos/10/aarch64/stable，这个目录在镜像站上不存在，直接 404，报错是Failed to download metadata for repo 'docker-ce-stable'或者Cannot download repomd.xml，看起来像网络问题，实际是路径拼错了。这也是手册里写死7的原因。同理，baseurl结尾的斜杠别丢，某些 yum 版本在拼接repodata/repomd.xml时不做补斜杠处理，少了就变成stable/repodata之外的怪路径。

gpgcheck=1配合gpgkey是校验包签名用的，保证装上的 rpm 没被篡改。gpgkey指向的是 docker 仓库的 GPG 公钥，yum 首次安装时会自动下载并导入。这一项如果出问题，报错长这样：Public key for docker-ce-18.09.7-3.el7.aarch64.rpm is not installed，处理办法在后面的避坑章里展开。

配完之后先别装，用一条只读命令确认仓库里到底有哪些版本可装：

# 列出所有可见的 docker-ce 版本，倒序排列让新版本在上 yum list docker-ce --showduplicates | sort -r

--showduplicates是关键参数，不加它 yum 只显示每个包的最高版本，你会误以为仓库里只有一个 20.10，从而以为“只能装最新版”。加上它，18.09.7-3.el7、19.03.x、20.10.x 会全部列出来，后面的版本选型就有了依据。sort -r只是让输出顺序更符合直觉，不影响结果。

2.3 麒麟源为什么必须单独加，gpgcheck=0 能不能忍

只用 docker-ce 仓库装不下去，因为container-selinux这类包 docker 仓库不提供。麒麟官方源要单独加一个文件，按手册的写法：

[ks10-os-media] name = Kylin Linux Advanced Server 10 - Os baseurl = http://archive.kylinos.cn/yum/v10/sp1-openstack-q/aarch64/os/ gpgcheck = 0 enabled = 1

写入/etc/yum.repos.d/kylin_aarch64.repo。手册原文这里路径写成了/etc/yum.repos./kylin_aarch64.repo，少了个d，照着敲的话系统会提示目录不存在，或者更坏的情况——你以为写进去了，其实文件落在别处，yum repolist里根本没有这个仓库。这是纯手误，但确实有人卡在这一步很久。

baseurl里的aarch64是写死的，x86_64 的机器要换成x86_64，这个路径不认$basearch。gpgcheck = 0意味着不校验这个源的包签名，属于妥协做法：内网或归档源经常没有正确部署 GPG 公钥，开校验会直接卡住依赖安装。判断标准很简单——这个源是你信任的、走内网或官方归档的，可以关；来源不明的第三方源，别为了装上去就关校验。关校验的风险是没有完整性保护，属于“能跑但不该长期这样”的状态。

两个源都就位后，再跑一次yum repolist，应该能看到docker-ce-stable和ks10-os-media都在列表里，并且包数量不为 0。这一步看着琐碎，但它把后面 80% 的报错挡在了门外。

3. 报错拆解：nothing provides container-selinux >= 2:2.74到底缺什么

3.1 依赖链条：docker-ce 不是一个人在战斗

yum install docker-ce解析出来的依赖不是一条线，是一个小图。docker-ce 依赖 containerd.io（容器运行时）、docker-ce-cli（命令行）、container-selinux（SELinux 策略模块）、libcgroup、libseccomp、iptables、device-mapper-libs 等等。其中 containerd.io 和 docker-ce-cli 由 docker 仓库自己提供，版本能对上；container-selinux、libcgroup、iptables 这些由发行版仓库提供，也就是麒麟源。

报错里的>= 2:2.74是版本约束，2:是 epoch（可以理解成版本号的最高优先级字段），2.74是版本主体。这句话翻译过来是：docker-ce 20.10.17 这个包要求系统里有一个 epoch 为 2、版本不低于 2.74 的 container-selinux，而当前启用的所有仓库加起来，没有任何一个包能满足这个条件。注意是“没有任何一个包”，不是“版本低了装不上”——如果麒麟源里有 2.60，yum 的报错会变成requires container-selinux >= 2:2.74, but 2:2.60 is available之类的形式。所以看到nothing provides，第一反应应该是“这个包名在当前仓库里根本不存在”，而不是“版本差一点”。

验证方法就一条命令：

# 看麒麟源里到底有没有 container-selinux，以及它提供的版本 yum info container-selinux # 如果上面查不到，再确认是不是包名不同或被合并进了别的包 yum provides 'container-selinux' 2>/dev/null yum search selinux | grep -i container

yum info能查到就说明包在，重点看Version和Epoch两行；查不到就是彻底没有，这种情况在麒麟的精简版仓库里不罕见，有些镜像干脆把 SELinux 相关包裁掉了。yum provides是按文件反查包，参数给包名本身意义不大，但配合2>/dev/null可以快速排掉噪音，看有没有同名不同源的候选。

3.2--nobest和--skip-broken为什么救不了这个错

报错末尾那句(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)是 dnf 后端自动附带的建议，它坑过不少人。先说清楚，麒麟 V10 的yum实际是 dnf 的兼容前端，所以输出是Last metadata expiration check这种 dnf 风格，这也解释了为什么yum会提示 dnf 的参数。

--skip-broken的语义是“遇到装不上的包就跳过，把能装的装上”。用在这里，docker-ce 正是装不上的那个，于是它被跳过，yum 退出码是 0，看起来成功了。你回头docker --version提示命令不存在，或者只装了 docker-ce-cli 没有 daemon。这不是解决问题，这是把问题藏起来，属于典型的自欺欺人。

--nobest的语义是“不要只挑最优（最新）版本，允许退而求其次”。这个参数方向是对的，但它有个前提：仓库里必须存在一个依赖能被满足的版本。如果仓库里最老的 docker-ce 是 19.03，而 19.03 同样要求 container-selinux >= 2:2.74，那--nobest一样失败，只是报错信息变长。所以--nobest是“可能有用”，不是“一定有用”，能不能成得看仓库里有哪些版本。

真正有效的做法是反过来：先看有哪些版本，再逐个确认依赖，最后指定版本装。这里有个很实用的技巧是“试运行”，只解析不落盘：

# --assumeno 会在解析完依赖后自动回答 no，只输出计划，不真的安装 yum install --assumeno docker-ce-18.09.7-3.el7

--assumeno会让 yum 把所有需要安装、升级、替换的包列出来，然后停下。如果依赖不满足，报错在这一步就出现了，系统不会被改动。比起真装一次再卸载，这个命令安全得多，也快得多。把候选版本挨个试一遍，哪个能过依赖解析，就装哪个。

3.3 为什么最终选 18.09.7-3.el7 而不是 20.10

手册的结论很明确：docker-ce装最新版会失败，因为最新版的依赖组件在麒麟系统上无法满足，暂时没有找到解决办法，所以退回18.09.7-3.el7。这个版本能装上的核心原因是它的依赖门槛更低——老版本对 container-selinux 的最低要求比 20.10 宽松，麒麟源里现有的包能过线。

选版本时有几个判断依据，不只是“能装上就行”。第一是内核兼容性，docker 18.09 对内核版本的要求比 20.10 低，麒麟 V10 SP1 自带的内核如果是 4.19 系列，18.09 跑起来更稳，overlay2 存储驱动和 cgroup 的支持不会踩到新版才引入的特性。第二是 CLI 与 daemon 的版本必须一致，docker-ce 和 docker-ce-cli 要装同一个版本号，混装会出现client version 18.09.7 is too old或者 API 版本不匹配的报错，所以两条命令里的版本号要成对改。第三是后续升级路径，18.09 是比较老的版本，如果业务侧要求 compose v2、buildx 这些新特性，迟早要面对升级问题，这时候的正确做法是先解决 container-selinux 的来源问题（比如从更高版本的发行版仓库里找兼容包，或者关掉 SELinux 后不装这个包），再升 docker，而不是硬升。

一个务实的判断顺序：先yum list docker-ce --showduplicates | sort -r看有哪些版本，从高到低用--assumeno试依赖，第一个能过的版本就是你的天花板。这个结论要记下来，因为下一次换机器、换麒麟小版本，天花板可能变，方法不变。

4. 按版本装：先 cli 后 ce，这个顺序不是玄学

4.1 为什么手册坚持先装 docker-ce-cli 再装 docker-ce

两条命令分开敲，看似只是排版习惯，实际解决的是“报错信息混在一起看不清”的问题。如果一条命令装两个包，yum 会把两个包的依赖合并解析，一旦失败，你看到的是长长一串Problem:，里面既有 cli 的依赖也有 daemon 的依赖，很难判断到底是哪个环节断了。

分开装之后，yum install docker-ce-cli-18.09.7-3.el7这一步只解析 cli 的依赖，它依赖的是比较底层的库（libc、libseccomp 之类），通常能顺利通过；通过之后再装docker-ce，如果这一步报错，你就很确定问题出在 daemon 的依赖上，范围一下缩小一半。这不是玄学，是把排查变量控制住。尤其是第一次在这台机器上装，不确定源配得对不对，分开装能最快告诉你“源没问题，是版本门槛的问题”。

先装 cli 的另一个好处是版本号能先锁死。docker-ce-cli-18.09.7-3.el7装完之后，rpm -q docker-ce-cli能看到确切版本，后面装 daemon 时照着这个版本号写，不会出现“cli 是 18.09、daemon 是 19.03”这种低级的版本错配。

4.2 两条安装命令的完整写法和验证动作

# 第一步：先装命令行客户端，锁死版本号 yum install docker-ce-cli-18.09.7-3.el7 # 第二步：再装 daemon 本体，版本号必须和上面一致 yum install docker-ce-18.09.7-3.el7 # 确认两个包的版本完全对齐 rpm -q docker-ce docker-ce-cli containerd.io

命令里的18.09.7-3.el7是完整的 NEVRA 里的版本段，格式是主版本.次版本.修订号-打包号.el7，.el7表示这是给 RHEL 7 系打的包，麒麟 V10 兼容这个 ABI，所以能装。版本号写全的好处是 yum 不会自作主张挑最新版，装出来的东西和你验过的完全一致，可复现。生产环境建议一直这么写，别用yum install docker-ce这种不带版本的形式，否则哪天仓库更新了，同一份脚本在不同时间跑出不同结果。

rpm -q那一条是验证动作，输出三行，版本应该都是18.09.7-3.el7（containerd.io 的版本号体系不一样，不用强求一致）。如果docker-ce-cli显示not installed，说明第一步没成，或者被第二步的某个obsoletes换掉了，这时候别急着往下走，回头查。

装完之后还有一个容易漏的动作：确认 SELinux 状态。如果系统开了 enforcing，而 container-selinux 版本又刚好卡在边缘，容器启动时会报permission denied却看不出原因。查一下：

getenforce # 输出 Enforcing 表示强制模式，Permissive 表示只记录不拦截

这一步不是让你马上去关 SELinux，而是留个记录：如果后面容器起不来且日志里全是avc: denied，那就是它。关掉是应急手段，正确的做法是装对应的策略模块，但麒麟环境下这个包不好弄，很多团队的做法是把 SELinux 调成 permissive 并记进变更单。取舍自己判断。

4.3 启动、自启和第一次拉镜像

# 启动服务 systemctl start docker # 设为开机自启，服务器重启后容器能自己回来 systemctl enable docker # 看守护进程状态，Active: active (running) 才算成功 systemctl status docker --no-pager # 验证版本 docker --version # 期望输出：Docker version 18.09.7, build 2d0083d

systemctl start docker如果失败，systemctl status只会给你一句Job for docker.service failed because the control process exited with error code，真正的信息在 journal 里：

# 看 docker 服务最近 50 行日志，定位启动失败原因 journalctl -u docker -n 50 --no-pager

-u docker限定单元，-n 50只取最近 50 行，--no-pager避免输出被分页卡住。常见的失败原因有三类：/etc/docker/daemon.json的 JSON 语法错误（少个逗号、多个逗号，最常见）、存储驱动不支持（overlay2需要内核支持，日志里会说failed to mount overlay）、cgroup 挂载异常。

服务起来之后，docker --version只是客户端版本，真正要看的是docker info：

# 看 Server 段是否正常，重点看 Storage Driver 和 Cgroup Driver docker info 2>/dev/null | grep -Ei 'server version|storage driver|cgroup driver'

输出里Server Version: 18.09.7说明 daemon 正常，Storage Driver: overlay2是最理想的，如果是devicemapper或者vfs，说明没走对驱动，性能和磁盘占用都会难看。Cgroup Driver是cgroupfs还是systemd也要留意，后面如果要在这个节点上跑编排系统，cgroup driver 不一致会导致节点注册失败，这是个经典问题。

最后拉一个镜像验证网络：

docker pull hello-world docker run --rm hello-world

拉不动是另一个话题，net/http: TLS handshake timeout或dial tcp ... i/o timeout属于镜像源和网络层的问题，处理办法在下一章第五个坑里。

5. 避坑：六个反复翻车的点

这一章把我自己踩过和帮别人排查过的六种情况写下来，每条按现象、原因、解决三步走。看到对应报错直接抄解决那栏就行。

5.1 repo 文件路径写成/etc/yum.repos./

现象：按手册原文敲vim /etc/yum.repos./kylin_aarch64.repo，vim 提示E212: Can't open file for writing，或者更隐蔽的情况——你用的是cat >重定向，文件写进了一个新建的不存在的目录（如果权限允许），然后yum repolist里怎么都看不到这个源。

原因：路径少了d，/etc/yum.repos.d/才是仓库目录。手册排版时丢字符，是纯粹的文档错误，但新手照着敲会一头雾水。

解决：改成/etc/yum.repos.d/kylin_aarch64.repo。养成个习惯，配完源立刻ls /etc/yum.repos.d/确认文件名，再yum repolist确认仓库加载成功，两步都不花时间，能挡掉后面一堆“为什么源不生效”的疑问。

5.2 baseurl 用了$releasever，报Failed to download metadata for repo

现象：yum makecache或yum install时报Failed to download metadata for repo 'docker-ce-stable'、Cannot download repomd.xml、Status code: 404，有时还伴随长时间的等待。

原因：docker-ce 的 CentOS 仓库路径里有一段固定是centos/7，而麒麟 V10 的$releasever解析成10，拼出来的地址.../linux/centos/10/aarch64/stable根本不存在。另外%24basearch拼错、结尾少斜杠，也会造成类似问题。

解决：baseurl里写死7，架构段保留$basearch让它自动替换。改完yum clean all && yum makecache，再yum repolist看有没有报错。以后配任何第三方 el7 仓库，在麒麟上都要先想一遍“这个地址里的版本段会不会被自动替换成 10”。

5.3yum install docker-ce直接装，nothing provides container-selinux

现象：Error: Problem: cannot install the best candidate for the job - nothing provides container-selinux >= 2:2.74 needed by docker-ce-3:20.10.17-3.el7.aarch64。

原因：不带版本号的yum install会挑仓库里最新的 docker-ce，最新版对 container-selinux 的要求超出麒麟源能提供的范围。

解决：yum list docker-ce --showduplicates | sort -r看全部版本，从高到低用yum install --assumeno docker-ce-<版本>试依赖，第一个能过的就装它，并且docker-ce-cli用同一版本号。不要用--skip-broken掩盖问题。

5.4 安装正常但systemctl start docker失败

现象：Job for docker.service failed because the control process exited with error code.，systemctl status docker看不出有用信息。

原因：大致三类。/etc/docker/daemon.json有 JSON 语法错误（多一个逗号、少一个引号）；存储驱动不被内核支持；cgroup 或 iptables 在工作环境里有冲突。

解决：journalctl -u docker -n 50 --no-pager看真实报错。如果是 JSON 问题，用python3 -m json.tool /etc/docker/daemon.json校验一遍格式，比肉眼找逗号靠谱。如果是failed to mount overlay，换成"storage-driver": "vfs"先让服务起来（性能差但能跑），再回头解决内核模块。改完daemon.json一律systemctl daemon-reload && systemctl restart docker，别只 restart。

5.5 镜像拉不下来，TLS handshake timeout

现象：docker pull hello-world卡住很久，最终报net/http: TLS handshake timeout或dial tcp ...: i/o timeout。

原因：默认镜像仓库在公网上，访问不稳定或者被限速，DNS 解析慢也会加剧这个问题。装 docker 成功和拉镜像是两个独立环节，前者只验证了包管理，后者才验证网络。

解决：配镜像加速地址，写进/etc/docker/daemon.json：

{ "registry-mirrors": ["https://你的加速地址"], "exec-opts": ["native.cgroupdriver=systemd"], "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "3" } }

registry-mirrors是加速地址列表，按可达性排序；native.cgroupdriver=systemd让 cgroup 驱动和系统保持一致，避免以后接入编排系统时踩坑；后面两行是日志轮转，不加的话/var/lib/docker/containers/*/*-json.log会把磁盘吃满，这个坑通常在跑了一两个月之后才炸。改完systemctl daemon-reload && systemctl restart docker，用docker info看Registry Mirrors段有没有生效。

5.6 装完docker: command not found，或者装成了 podman 兼容包

现象：yum install docker执行成功，docker version提示command not found，或者有输出但 Server 段是 podman。

原因：麒麟源里docker这个名字可能指向 podman-docker 之类的兼容包，它提供/usr/bin/docker的软链，实际调用 podman；另一种情况是只装了 docker-ce 没装 cli，二进制不在 PATH 里。

解决：rpm -qa | grep -Ei 'docker|podman'看清楚到底装了什么。如果发现 podman-docker，先yum remove podman-docker再按版本装 docker-ce-cli 和 docker-ce。装完which docker应该指向/usr/bin/docker，docker version的 Client 和 Server 段版本号要一致。

6. 快速定位：三条命令分清是源问题、依赖问题还是版本问题

装不上的时候别急着换源、换版本、重装系统，先花三十秒做分类。我的习惯是三步，顺序固定。

第一步，确认仓库在不在：

yum repolist | grep -E 'docker-ce|ks10'

两个仓库都应该出现，包数量不为 0。只有 docker-ce 没有麒麟源，说明依赖解析注定失败；一个都没有，说明 repo 文件没生效，回头查文件名和路径。

第二步，确认版本有哪些：

yum list docker-ce docker-ce-cli --showduplicates | sort -r

如果只列出一两个版本，说明仓库元数据没更新或者 baseurl 指错了；如果列出一长串但全都装不上，说明是依赖门槛问题，不是版本缺失。

第三步，用试运行定位到底缺哪一环：

yum install --assumeno docker-ce-18.09.7-3.el7

报错里出现nothing provides就是依赖包在源里不存在，出现but X is available就是版本低了。这两句话的处置方向完全不同：前者要补源或者换版本，后者只能换版本。

把常见报错和根因对照成一张表，遇到不认识的报错先在这张表里找最像的：

验证环节也有个固定的收尾动作，装完必跑三条：docker --version看客户端，docker info看 Server 和 Storage Driver，docker run --rm hello-world看端到端通不通。三条都过，才算这台机器真的能跑容器，而不是“装上了”。

血泪教训是，我早期在这类国产化系统上装东西，总想着“先把包装上再说”，结果每次都在依赖上反复，一周能修三四台同款机器。后来改成固定顺序：先 repolist 确认仓库、再 showduplicates 确认版本、再 assumeno 确认依赖，最后才动手装。从那以后我每次在新机器上装 docker，不管是不是麒麟，都强制把这三条命令走一遍，宁可多花两分钟，也不要在--skip-broken的假成功里浪费半天。这份手册的价值也在这里——它把“能装上”的那条路径固定下来了：源怎么配、版本选哪个、装完怎么验，照着走一遍就有结果。希望帮到你。

本文还有配套的精品资源，点击获取