简介：本资源为面向银河麒麟 V10 SP1 Server 用户的 Docker 安装操作手册，适合需要在国产化服务器环境中部署容器服务的运维工程师与技术人员，解决官方源无 Docker Server 软件包、依赖组件兼容性受限等实际部署难点。文档为 Word 格式，共 1 个文件，包体约 17KB，内容紧凑、步骤清晰。手册完整展示了配置 YUM 源（含阿里第三方源与麒麟官方源）到通过 YUM 安装 Docker CE、启动服务并验证版本的全程操作，并给出经环境验证可行的固定版本 18.09.7；同时详细记录了最新版因 container-selinux 依赖缺失而安装失败的报错与排错思路，可帮助读者规避同类坑点。资源已有 7000 余人浏览学习，对正在基于国产化平台搭建容器环境的开发者有直接参考价值。
1. 在银河麒麟上装 Docker：先看到 “nothing provides container-selinux” 这个坎
银河麒麟v10 sp1 server上安装 docker 这件事，很多第一次接触国产系统的同事都栽在同一句报错上：nothing provides container-selinux >= 2:2.74 needed by docker-ce-3:20.10.17-3.el7.aarch64。按网上 CentOS 教程一步步走，明明源也配了、缓存也清了，yum 就是不让你装，换好几个版本都在这句话上打转。这个坎不解决，后面所有容器化工作都推不动。这篇笔记就围绕这一句报错展开：先说清它背后的依赖规则和麒麟的仓库差异，再给你一套能照着落地的固定版本安装流程，最后把安装过程中最常见的几种报错一次性讲透，适合正在信创服务器上部署 Docker 环境的开发、运维和实施同学，照着做能绕开大多数“玄学”挫折。
2. 为什么通用 CentOS 教程会在麒麟上翻车：依赖、源与架构三层因素
2.1 银河麒麟 v10 的软件源生态：能用 el7 仓库，但不等价
如果你和我一样，第一反应用 CentOS 7 的 Docker 安装经验去套银河麒麟 v10 sp1 server，多半会走到同一条死路上。这套系统的 rpm 包和仓库布局让很多工具链能直接兼容 el7 时代的二进制，所以第三方 Docker CE 仓库里的linux/centos/7路径能正常服务，$basearch在 ARM 服务器上会解析成aarch64，yum 会去读/centos/7/aarch64/stable/目录。目录里确实有包，但这不代表系统源里所有底层依赖也都跟上来了。
最常见的误解是“能用 el7 仓库 = 和 CentOS 7 完全一样”。这个判断会害死人。因为 yum 安装一个 rpm 包时，除了下载这个包本身，还要在当前所有 enabled 仓库里解析它的 Requires 依赖。Docker CE 的 rpm 依赖的可不只是 docker-ce-cli，还有一堆和容器安全、容器网络相关的组件，而这些组件并不在 Docker 自己的仓库里，要靠系统自带源提供。如果系统源提供不了预期版本，yum 的依赖解析就失败，最终报错落在某个具体包上。
我在项目里遇到的那台服务器，uname -m输出是aarch64，打开/etc/yum.repos.d/能看到系统自带的kylin_aarch64.repo这类文件。很多教程只让你加 Docker 源，没人提醒你系统源必须保持可用；我见过有人为了“干净”把系统源全禁掉，结果被缺失依赖报错卡了整整一下午。
如果你的服务器是x86_64架构，同样的容器源里对应目录是centos/7/x86_64/stable，镜像仓库维护 x86 包的频率通常比 ARM 高，所以最新版 docker-ce 在 x86 上依赖更容易被满足。ARM 包数量少、依赖断层更明显，这也就是为什么银河麒麟这类 aarch64 服务器更容易碰到container-selinux版本不足的问题。拿到机器先别急着装，花两分钟确认架构和现有源，后面能省很多事。
2.2 报错拆解：best candidate、nobest 与 container-selinux 版本门槛
回到开头那条报错，信息其实分三段。Last metadata expiration check只是告诉你 yum 的元数据刚才刷新过，这一段不是错误本身。Problem: cannot install the best candidate for the job是 yum 对本次安装请求的结论性描述，意思是它找不到一个满足全部依赖约束的“最优候选包”。真正有诊断价值的在最后一句：nothing provides container-selinux >= 2:2.74 needed by docker-ce-3:20.10.17-3.el7.aarch64。
RPM 依赖机制里有一个“provides”概念：一个包不一定叫 container-selinux 才能满足依赖，只要它Provides: container-selinux并且版本号大于等于 2:2.74 就行。yum 在系统源里找了一圈，没找到能达到这个版本门槛的包，于是判定 docker-ce 20.10.17 这个候选不可安装。注意版本格式2:2.74，前面的2:是 epoch，RPM 比较版本时 epoch 优先，哪怕上游版本号看着是 2.74，如果 epoch 是其它值，比较结果可能和你预期完全相反。
这里的 container-selinux 是干嘛的？它主要负责给 Docker 创建的容器目录打 selinux 标签，让容器进程只能访问该访问的资源。银河麒麟这种对安全策略有自定义裁剪的系统，源里这个包的版本往往会滞后于 Docker CE 最新版的依赖要求。常见情况就是：Docker 侧要求 2.74，系统侧停在旧版，两边对不上。
报错末尾括号里给的两个建议，--skip-broken和--nobest，我建议你在弄懂原理前不要贸然使用。--nobest的意思是“不要执念于最高版本，允许 yum 选一个次优候选”，听起来很适合用来绕过这个报错，但实际上如果你的仓库里根本没有候选能满足依赖，降级选出来的下一个版本照样断依赖。--skip-broken更危险，它让 yum 把解析失败的包直接跳过，表面装完了，docker 命令可能根本起不来，属于给自己埋雷。这两条是 yum 给的逃生通道，不是治疗药方。
2.3 为什么旧版 18.09.7 能装，而新版本装不上
既然系统源里没有 container-selinux 2.74，那问题就变成：找一个依赖约束没这么苛刻的 Docker 版本。Docker CE 18.09.7 是 el7 时代比较早的构建，它的 Requires 列表里没有硬性要求 container-selinux >= 2:2.74，底层依赖基本是老一套内核、iptables、device-mapper 相关包，这些在麒麟系统源里都能找到。于是锁定旧版本就成了一个能落地的解。
选版本之前，先看看源里到底有哪些候选。执行：
yum list docker-ce --showduplicates--showduplicates是关键参数，它让 yum 把仓库里的重复版本也显示出来，否则默认只显示每个包的最新版。你会看到类似这样的输出，docker-ce.aarch64下有几个版本，其中 18.09.7 和 20.10.17 都在同一行。版本越全，越方便你锁定具体目标。注意如果docker-ce-cli和docker-ce的版本不一致，yum 会自动尝试找一个互相匹配的组合，但手动锁定是最不依赖运气的做法。
这不是唯一解，但绝对是最省事的解。后来新系统源的依赖条件可能被补齐，到时候你自然可以装新版；但在那个时间点的服务器上，与其去折腾 container-selinux 的手动安装，不如直接用仓库里现成的旧版本。生产环境求稳，18.09.7 跑常规容器完全够用，等哪天真的需要 20.10 的新功能，再回头补依赖也不迟。
3. 照着手动安装一遍：锁定 docker-ce-18.09.7 的完整流程
3.1 配置 yum 源：第三方 Docker CE 仓库 + 系统依赖源，缺一不可
先把目录切到/etc/yum.repos.d/，找个地方备份现有配置：
cd /etc/yum.repos.d mkdir ../kylin-repo-bak cp * ../kylin-repo-bak/备份目录放在/etc/yum.repos.d的上一级，是因为 yum 会自动加载目录里所有以.repo结尾的文件。如果备份文件也放在原目录里还带.repo后缀，反过来会把你的配置环境搞乱。备份的意义很简单：后面改坏了还能一键还原，别不信，改 repo 改到系统源失效是新手高频事故。
新建docker-ce.repo，内容如下：
cat > /etc/yum.repos.d/docker-ce.repo <<'EOF' [docker-ce-stable] name=Docker CE Stable - 7 baseurl=https://mirrors.example.local/docker-ce/linux/centos/7/$basearch/stable enabled=1 gpgcheck=1 gpgkey=https://mirrors.example.local/docker-ce/linux/centos/gpg EOF注意mirrors.example.local只是占位符，实际部署时把这个地址换成你环境里能访问的 Docker CE 镜像仓库。$basearch是 yum 的自动变量，ARM 机器上会展开成aarch64，所以仓库路径最后落在centos/7/aarch64/stable，这正是银河麒麟 v10 sp1 server 需要的目录。gpgcheck=1表示安装时校验 RPM 签名，gpgkey指向的 GPG 公钥地址也必须能访问，否则后面会报公钥缺失。
接着确认系统自带的依赖源。原手册里会打开kylin_aarch64.repo来检查，这里你直接用命令看：
cat /etc/yum.repos.d/kylin_aarch64.repo yum repolist enabledrepolist enabled的输出里必须同时看到docker-ce-stable和系统自己的仓库。如果系统源文件被改名成了.repo.bak，或enabled=0，yum 就找不到那些提供底层依赖的包，安装同样会失败。系统源地址用文件里已有的配置就行，不要手动改成网上搜来的地址，每个环境的镜像站同步范围不一样，乱改反而制造新问题。
然后刷新元数据：
yum clean all yum makecache这两个命令通常连着跑。clean all清掉本地缓存的仓库元数据，makecache重新拉取所有已启用仓库的索引。如果makecache在某个仓库上报超时，说明它的 baseurl 地址不通，先修网络再继续，不要跳过这步硬装，否则 yum 可能还在用旧缓存重复之前的错误判断。
3.2 先装 cli 再装 ce：版本精确对齐
配置好源之后，正式开始安装。网上很多教程会让你直接yum install docker-ce，但在银河麒麟这里，这样装默认会拉最新稳定版 20.10.x，然后命中第 2 章里那条 container-selinux 报错。所以这里必须把版本号写全：
yum install docker-ce-cli-18.09.7-3.el7先装 cli 的原因，是让 yum 先把命令客户端固定在 18.09.7 这个版本。后面安装 docker-ce 本体时，yum 的依赖解析会去找和它配套的服务端版本，不会自作主张升到 20.10。如果你不指定后缀只写docker-ce-cli，yum 会挑最新的 cli 版本，再跟旧版服务端组合时，很可能出现命令版本和服务端版本不匹配的怪现象。
装完 cli 后再装服务端：
yum install docker-ce-18.09.7-3.el7这里的18.09.7是 Docker 上游版本号，3.el7是 RPM 的 release 标识，说明它是按 el7 体系打的包。少写一个段或用通配符，都有可能让 yum 匹配到别的版本。如果过程中 yum 提示缺少 containerd.io 或其他组件，不要慌，先把缺少的包名记下来，用同样“包名-版本号”的方式在源里查一遍有没有对应版本可装。18.09.7 在 aarch64 上一般不会要求太新的 containerd，但具体以你源里的实际版本为准。
装完先别急着启动，看一眼安装结果：
rpm -qa | grep docker理论上应该看到docker-ce、docker-ce-cli两个包都列出来，版本号都停在 18.09.7。如果只有一个包出现，回到上一步补装，不要带着半套环境往下走。
3.3 启动 Docker 并确认版本回显
依赖没问题后启动服务：
systemctl start docker systemctl enable dockerstart拉起 Docker 守护进程，enable把它加入开机自启。这两个命令返回 0 不等于一切正常，更稳的验证是：
systemctl status docker --no-pager docker --version正常情况下docker --version会输出Docker version 18.09.7, build 2d0083d。这个 build 号是 18.09.7 这个版本在对应发布渠道里的实际构建标识，只要版本主干是 18.09.7 就说明安装成功。再往深处验证 daemon 到底就绪没有：
docker info docker psdocker info能看到内核、存储驱动、镜像数量等运行时信息，只要不报Cannot connect to the Docker daemon，就说明服务端真的起来了。这里提醒一句：如果你的服务器不连外网，别急着用docker run hello-world验证，那一步要拉镜像，拉不下来不是安装的锅，反而会把问题引向错误方向。内网环境用docker version看 Client 和 Server 两段都正常，就可以确认安装没问题。
3.4 为什么不推荐官方一键脚本和直接 rpm 安装
你在网上能看到很多一键脚本，比如从 Docker 官网拉下来的安装脚本。这类脚本的逻辑是“装当前最新稳定版”，它会把源切换到最新目录，然后执行等效于yum install docker-ce的操作，结果就是在银河麒麟上重新踩一次 container-selinux 的坑。更麻烦的是脚本执行过程是黑盒，中途失败留下的缓存和源配置，反而干扰你自己手动排错。
还有人图省事，直接从 centos 仓库把docker-ce-20.10.17-3.el7.aarch64.rpm下载下来，用rpm -ivh硬装。rpm 工具不会帮你自动解析依赖，缺一个包就报一个错，缺到第 4 个依赖时你会发现这个方案比 yum 还费时间。在 yum 可用的情况下，正确姿势永远是让 yum 从源里解析依赖，锁版本是给 yum 一个明确指令，而不是绕过它。
4. 安装 Docker 常见问题排查：从依赖到服务的踩坑记录
4.1 “nothing provides container-selinux >= 2:2.74”：别用 --nobest 硬闯
现象：配好源后直接yum install docker-ce，报cannot install the best candidate，错误行定位到 container-selinux 版本不满足。
原因：最新 Docker 的 rpm 依赖高于系统源现有版本的 container-selinux，yum 在已启用仓库里找不到满足依赖的包。这不代表源断了，只代表依赖版本差。很多人这时候去搜“解决 container-selinux”，搜到一堆让加第三方源的教程，但这些源的签名和系统策略未必兼容，装了容易崩。
解决：改用旧版本docker-ce-cli-18.09.7-3.el7和docker-ce-18.09.7-3.el7安装。如果你确实需要新版，先看系统源中 container-selinux 的实际版本，执行yum info container-selinux，确认它和2:2.74差多少，再决定是升级系统源还是手动补装 RPM。不要在没搞清依赖前加--nobest，它只改选择策略，不改依赖事实。
4.2 “Last metadata expiration check” 与找不到仓库
现象：执行 install 时提示Last metadata expiration check: 0:00:51 ago ...，随后报No match for argument或直接说找不到 docker-ce 包。
原因：这个提示本身只是元数据刷新时间，真正的坑在后面。找不到包基本都是仓库路径没生效：docker-ce.repo文件权限不对、baseurl里的$basearch解析失败、或者仓库根本没被enabled=1。
解决：先执行yum repolist enabled确认仓库存在，再执行yum list docker-ce --showduplicates看源里到底有没有你能装的版本。如果列表里一个版本都不显示，用curl -I试一下 baseurl 地址能否返回目录页面，能返回再回 yum 重试。这步跳过的话，后面所有安装命令都在跟一个不存在的仓库对话。
注意：
Last metadata expiration check后面跟的时间只是缓存刷新时间，不是报错时间。很多人会把它误读成“系统时间不同步”，越查越偏。
4.3 GPG key 校验失败
现象：安装时提示Public key for ... is not installed或The GPG key ... has an unsupported type。
原因：gpgcheck=1时，yum 必须能从gpgkey指到的 URL 下载公钥并完成签名校验。内网环境如果没放行这个地址，或者 gpgkey 写成了本机不存在的文件路径，校验就会失败。
解决：确认gpgkey地址可达。如果所在网络访问不了外网，把公钥文件下载后放到本机，再把配置改成gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-docker。最后一招才是把gpgcheck改成 0 绕过，这只适合临时内网环境，生产环境别这么干，等于放弃 rpm 完整性校验，装到被篡改的包都没人知道。
4.4 启动失败：cannot connect to the Docker daemon
现象：yum 装完包，执行docker ps却报Cannot connect to the Docker daemon at unix:///var/run/docker.sock。
原因：最直接的是守护进程没起来。注意systemctl start docker成功不等于 daemon 一直健康，很多时候是启动即崩，systemctl 返回失败时才显示具体错误。另一个常见原因是/etc/docker/daemon.json配置了错误的参数，比如 registry-mirrors 写成不可达地址，daemon 起不来。
解决：按顺序查。先systemctl status docker看服务状态，再journalctl -u docker --no-pager -n 50看 daemon 日志，最后ls -l /var/run/docker.sock看 socket 是否存在。日志里常出现存储驱动或网络配置问题，18.09.7 在 ARM 环境一般用默认的 overlay2 或 vfs 即可，不要在没有把握时随便改--storage-driver。如果 daemon.json 是刚写的，检查它的 JSON 格式有没有逗号或引号错误，一个格式错就能让整个配置文件不生效。
4.5 已经装过其他容器运行时导致命令冲突
现象：安装完 docker 后执行docker --version，显示的却是另一个运行时，或者 systemctl 里有多个容器服务争抢。
原因：银河麒麟这类系统可能预装了 moby-engine、podman 等容器组件，它们和 Docker CE 共用 containerd，/usr/bin/docker这个命令可能被软链或覆盖。我遇到过一台机器，装了 docker 后docker --version报的是别家的版本号，一开始还以为自己装失败了。
解决：安装前先执行rpm -qa | grep -E 'docker|podman|moby'看看有谁在。确认没有业务依赖后，把冲突的包卸载干净再重新安装 Docker CE。卸载前记得备份/etc/docker下的已有配置，避免你刚配好的 daemon.json 被一起清掉。这个动作虽然多一步，但能避免后面大量“启动异常”的假故障。
5. 下次遇到依赖类报错，半小时内定位的排查方法
以后无论在哪台国产系统上装 Docker，遇到 yum 层面的报错，按固定顺序走：先确认架构，再确认源，最后看依赖版本。这个顺序能筛掉六成“源没配好”的坑，剩下的才轮到版本对齐问题。
uname -m # 1. 架构确认 yum repolist enabled # 2. 仓库确认 yum list docker-ce --showduplicates # 3. 可用版本清单 yum deplist docker-ce # 4. 当前版本要哪些依赖 yum info container-selinux # 5. 系统源能提供什么版本最后两步是定位根因最有效的组合。yum deplist docker-ce会列出安装这个包需要的全部依赖和版本约束，yum info container-selinux告诉你系统源里实际版本是多少，两边一比对，就知道该升级依赖还是换 Docker 版本。那次在银河麒麟上排错，就是靠这两条命令把根因从“yum 玄学”变成了“版本差距”。如果deplist输出的某个依赖你根本不知道是谁提供的，再用yum provides 'container-selinux'搜一下，看哪个包在提供这个能力，搜索范围一下就缩小了。
从那以后，我每次拿到新系统，第一件事不再是直接敲安装命令，而是先花五分钟看架构、看源、看版本清单。装 Docker 也一样，先把候选版本和依赖约束列清楚再动手，省下的是后面半天来回折腾。希望帮到你。
本文还有配套的精品资源，点击获取
