简介：这份文档面向在国产化服务器环境中部署容器平台的运维工程师与信创适配人员，聚焦银河麒麟 v10 SP1 Server 上 Docker 的落地安装问题。由于官方源缺少 docker server 软件包，文档给出阿里云 docker-ce 源与麒麟官方依赖源的配置方法，并说明为何只能安装 18.09.7 版本、无法直接升级到最新版。资源为 1 个 docx 文件，压缩包约 17KB，体量轻便，适合离线查阅或随环境交付存档。内容按「配置 yum 源—安装 docker-ce-cli 与 docker-ce—启动服务—查看版本」的顺序组织，附有完整 repo 文件内容、可复制的命令与真实报错信息，读者可据此快速复现安装流程，并借助其中的 container-selinux 依赖报错分析掌握排查思路。该文档已有 7220 人学习下载，对需要在麒麟系统上搭建容器运行环境的初、中级用户具有直接参考价值。

1. 从一台 aarch64 服务器说起：麒麟上装 Docker 为什么先降版本

第一次在银河麒麟 v10 SP1 Server 上敲yum install docker-ce，多数人以为十分钟能收工，结果终端甩回一行nothing provides container-selinux >= 2:2.74。机器是 aarch64 架构，系统自带源里压根没有 docker server 包，第三方源里最新版的依赖又跟麒麟的 selinux 策略包对不上，装到一半就卡死。这类机器在国产化改造的场景里太常见了，docker 银河麒麟这个组合踩的坑，九成都集中在「版本对不上」和「源没配对」两件事上。下面按我实际装过的那套流程走一遍：先核对架构和版本，再配双源，然后按 cli → engine 的顺序钉死 18.09.7，最后给一套能自查的验收命令。手上正卡在依赖报错、或者装完 docker 起不来的开发者，可以照着复现。

2. 装前把底子摸清：麒麟 v10 SP1 的架构、内核与版本取舍

动手改源之前先花三分钟做体检。这一步偷懒的人最多，后面翻车的也最多——源地址里的$basearch填错、把 x86_64 的包往 aarch64 机器上怼、内核太老撑不起 overlay2，都是在这个环节埋下的雷。

2.1 三条命令确认系统版本、内核与 CPU 架构

# 麒麟自己的发行版标识，确认是不是 v10 SP1 cat /etc/kylin-release # 通用发行版信息，重点看 ID 和 VERSION_ID cat /etc/os-release # CPU 架构：aarch64 还是 x86_64，直接决定源地址里 $basearch 展开成什么 uname -m # 内核版本：4.19 及以上对 overlay2、cgroup v2 的支持才比较稳 uname -r

/etc/kylin-release是麒麟特有的文件，CentOS 上没有，用它确认小版本号最直接，SP1 和 SP2 的源路径不一样，抄错一个字整段源就废。/etc/os-release里的ID字段一般会写成kylin，有的镜像版本写成centos，这会影响后面 yum 变量展开的行为，装之前心里要有数。

uname -m是关键中的关键。飞腾、鲲鹏这类机器输出aarch64，海光、兆芯输出x86_64。同一个 Docker CE 源里，两个架构的包是分目录放的，$basearch写对了 yum 才会去对应目录取包。我见过有人把 x86_64 机器的 repo 文件整体拷到 aarch64 机器上，$basearch虽然会展开，但如果写成了硬编码的x86_64，yum 就会报「没有可用软件包」，而且报错信息完全不提架构的事，特别迷惑。

内核版本决定存储驱动。麒麟 v10 SP1 常见内核在 4.19 一带，overlay2 能用；如果碰上更老的 4.4 内核，就得退回devicemapper，性能和稳定性都差一截。先看清楚，省得装完再折腾。

2.2 版本选择：18.09.7-3.el7 与 20.10 的取舍

Docker CE 在 EL 系仓库里同时维护 el7 和 el8 两个包线，aarch64 的构建产物主要挂在centos/7/aarch64/stable下面。麒麟 v10 SP1 的 glibc 和 systemd 版本其实更接近 EL8 时代，但 el7 的 docker 包依赖少、自带组件多，反而更容易在这套系统上落地。

真正卡住的是新版。20.10 系列的 rpm 包在 spec 里硬性声明了container-selinux >= 2:2.74，而麒麟 v10 SP1 自带源里的 container-selinux 版本低于这个门槛，第三方源又不提供 aarch64 的 container-selinux，于是依赖链在第一步就断了。yum 给出的建议是加--skip-broken或--nobest，这两个参数看着像救命稻草，实际上--skip-broken会把 docker-ce 本身也跳过，--nobest则会降级去挑一个更老的候选包，结果往往装上一个版本号更乱的残件。

所以这份环境里我固定用18.09.7-3.el7。它不算新，但 Docker 的 API 版本兼容性一向做得好，日常的镜像构建、容器编排、私有仓库对接都不受影响。真要上新版，得先自己编译 container-selinux 或者从别的源里找 aarch64 的包手动装，那是另一个工作量级的事，不适合在业务机器上折腾。

2.3 装前清场：卸掉残留 docker 与冲突包

很多麒麟机器出厂自带 podman 或者装过旧版 docker，直接覆盖装会出现二进制打架、/etc/docker目录残留配置覆盖新配置的问题。装之前先清一遍。

# 卸掉历史遗留的 docker 相关包，不存在也不会报错 yum remove -y docker docker-client docker-client-latest docker-common \ docker-latest docker-latest-logrotate docker-logrotate docker-engine # 看看有没有 podman / buildah / containerd / runc 占着底层依赖 rpm -qa | grep -E 'podman|buildah|containerd|runc' # 残留的运行时目录，确认没在用再删 ls -ld /var/lib/docker /etc/docker /run/docker.sock 2>/dev/null

第一条命令里的包名是从 EL 系历史沿革下来的，麒麟上大部分不存在，yum remove对不存在的包会静默跳过，不会有副作用。第二条命令是重点：podman 和 docker 都依赖 containerd、runc 这些底层组件，但版本要求不一样，如果系统里已经装了 podman 自带的一套 runc，docker 装上去可能跑的是不兼容的 runc 版本，表现是容器起来了但秒退，日志里报OCI runtime create failed。这种情况要么卸 podman，要么用yum install时观察 runc 是否被升级。

/var/lib/docker目录如果存在且里面还有旧数据，新装的 docker 会直接接管，镜像层格式不兼容时会出现「镜像列表里有但起不来」的怪现象。确认没数据就rm -rf，有数据先备份。这一步做完，环境才算干净。

3. 配置 yum 源：docker-ce 源加麒麟官方源的组合打法

麒麟官方源里查不到 docker server 的包，这是前提事实，所以必须引第三方源。但只加第三方源又不够——docker 运行还需要libcgroup、iptables、container-selinux这类系统级依赖，它们得从麒麟自己的源里来。两个源各管一段，缺一个都装不完整。

3.1 写 docker-ce.repo：$basearch与 gpgcheck 两个关键参数

先备份现有源，出事能整段回滚，这是血泪经验。

# 备份现有 repo 文件到 /root 下，出问题直接拷回来 mkdir -p /root/repo-backup cp -a /etc/yum.repos.d/*.repo /root/repo-backup/ # 新建 docker-ce 源文件 vi /etc/yum.repos.d/docker-ce.repo

文件内容如下：

[docker-ce-stable] name=Docker CE Stable - 7 baseurl=https://<镜像站域名>/docker-ce/linux/centos/7/$basearch/stable enabled=1 gpgcheck=1 gpgkey=https://<镜像站域名>/docker-ce/linux/centos/gpg

baseurl里的<镜像站域名>换成你环境里能访问的 Docker CE 镜像站域名，内网有同步源就填内网地址，比走公网稳。路径里的centos/7不是指操作系统必须是 CentOS 7，而是 Docker 官方对 EL7 包线的目录约定，aarch64 的构建产物就在centos/7/aarch64/stable下面。$basearch是 yum 的内置变量，在 aarch64 机器上自动展开成aarch64，在 x86_64 上展开成x86_64，所以这一行在两个架构上都能用，不要手写成固定值。

gpgcheck=1配合gpgkey做包签名校验，安全上应该开。但如果内网镜像站是自建的、没有同步 gpg 文件，校验会失败并报GPG key retrieval failed，这时候要么把 gpgkey 指向内网可达的地址，要么临时设gpgcheck=0——后者是妥协，装完记得改回来。

enabled=1表示默认启用。如果同一个 repo 文件里想禁用某个仓库，单独写enabled=0即可，不用删文件。

3.2 补一份麒麟官方源：依赖包从这里来

麒麟的源文件通常已经在/etc/yum.repos.d/下了，文件名类似kylin_aarch64.repo。先看现有的：

# 列出所有 repo 文件 ls -l /etc/yum.repos.d/ # 看现有源里都配了哪些 baseurl，抄一个能用的 grep -rh "baseurl" /etc/yum.repos.d/*.repo

如果现有的源被禁用了或者地址失效，需要补一份。内容参照这个结构：

[ks10-os-media] name = Kylin Linux Advanced Server 10 - Os baseurl = http://<麒麟官方源域名>/yum/v10/sp1-openstack-q/aarch64/os/ gpgcheck = 0 enabled = 1

baseurl里的路径要跟你的系统版本严格对应，v10 和 v10 SP1 的目录名不同，sp1 后面还带-openstack-q这类仓库标识，抄错就 404。最稳的办法是从机器上已有的源文件里复制一行过来改，不要凭记忆手敲。

gpgcheck = 0在这里是常见做法。麒麟官方源的 gpg key 分发不一定完整，开了校验经常拉不下来元数据，导致整个源不可用。这个源只用来装系统依赖包，风险可控；但对安全要求高的环境，还是应该把 key 导进去再开校验。

3.3 刷新缓存并确认两个源都生效

源文件写完不等于生效，yum 有元数据缓存，不清就是旧的。

# 清掉所有缓存，包括元数据和包 yum clean all # 重建缓存，这一步会去两个源拉元数据，耗时看网络 yum makecache # 列出所有启用的仓库，确认 docker-ce-stable 和麒麟源都在 yum repolist # 看 docker-ce 有哪些可用版本，重点确认 18.09.7-3.el7 在列表里 yum --showduplicates list docker-ce

yum repolist的输出里，每个仓库后面会跟一个包数量，如果某个源显示0或者状态是repodata is over 2 weeks old，说明元数据没拉到，先解决源连通性再往下走。--showduplicates list会把同一个包的所有可用版本列出来，aarch64 的 18.09.7 应该出现在 docker-ce-stable 那一列，没出现就是$basearch或者路径写错了。

麒麟 v10 上yum其实是dnf的软链接，两条命令等价，但dnf的报错信息更详细，排查依赖问题时用dnf往往能多看到一层原因。

4. 用 yum 装 docker-ce 18.09.7：先 cli 再 engine 的顺序不能反

源配好之后，安装本身只有两条命令，但顺序和版本号的写法有讲究。docker-ce这个包依赖docker-ce-cli的精确版本，一次性装会让 yum 自己去解析依赖，解析结果不一定是你要的那个版本。

4.1 先装 docker-ce-cli：把版本号钉死

# 显式指定完整版本号，连 release 号一起写 yum install -y docker-ce-cli-18.09.7-3.el7

版本号必须写全18.09.7-3.el7，只写18.09.7会让 yum 去匹配所有 release，可能挑到el7之外的构建。-y是免交互确认，脚本化部署时必带。

为什么先装 cli？docker-ce的 rpm 里声明了Requires: docker-ce-cli = 18.09.7-3.el7这样的精确依赖。如果直接yum install docker-ce-18.09.7-3.el7，yum 会顺带解析出 cli 的依赖，理论上也能装上。但实际情况是，仓库里同时存在 20.10 的 cli，yum 的依赖解析器在遇到多版本候选时可能挑最新的那个，装完就变成 cli 是 20.10、engine 是 18.09.7，docker version里 Client 和 Server 版本对不上，某些 API 调用直接报client version too new。

先把 cli 钉死，engine 安装时的依赖解析就只剩一层，冲突概率大幅下降。这是我在几台机器上反复验证过的顺序，不按这个来也能成，但失败的次数明显更多。

4.2 再装 docker-ce：engine 与 cli 版本对齐

# 同样写全版本号 yum install -y docker-ce-18.09.7-3.el7

装完立刻核对 rpm 层面的一致性：

# 两个包的版本号应该完全一致 rpm -qa | grep docker-ce

正常输出是两行，docker-ce-18.09.7-3.el7.aarch64和docker-ce-cli-18.09.7-3.el7.aarch64，架构后缀也必须是 aarch64。如果看到x86_64或者只有一行，说明依赖解析出了问题，yum remove重来。

有个参数值得提一句：--setopt=obsoletes=0。某些第三方源里会把 docker-ce 标记为废弃某个旧包，加上obsoletes=0能阻止 yum 顺带删掉你不想删的东西。一般用不上，但在源比较杂的环境里是道保险。

4.3 启动、开机自启与版本验证

# 启动服务 systemctl start docker # 设开机自启，服务器重启后容器要能自己回来 systemctl enable docker # 看服务状态，--no-pager 避免输出被分页截断 systemctl status docker --no-pager # 只看客户端版本 docker --version # 客户端和服务端版本都看，这个才是完整信息 docker version

docker --version只打印一行Docker version 18.09.7, build 2d0083d，那是客户端版本，服务端起没起来它完全不管。很多人执行完这条看到版本号就以为装好了，实际 dockerd 可能根本没跑。docker version会分成 Client 和 Server 两段输出，Server 段能打出来才说明守护进程活着。这是验收环节最容易糊弄过去的一步。

systemctl status的输出里如果看到Active: active (running)就正常，如果是failed，往下翻几行会有具体的错误原因，配合journalctl -u docker -n 50 --no-pager能看到更详细的启动日志。

4.4 配 daemon.json：data-root、日志与 cgroup driver

装完能跑只是及格线，配置文件不改，跑一阵子会出问题。/etc/docker/daemon.json是守护进程的主配置，改完要systemctl daemon-reload && systemctl restart docker。

{ "data-root": "/data/docker", "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "3" }, "exec-opts": ["native.cgroupdriver=systemd"], "storage-driver": "overlay2" }

># 有网的机器上导出，busybox 镜像只有几 MB docker save -o busybox.tar busybox:latest # 拷到目标机器后导入 docker load -i busybox.tar # 用导入的镜像做冒烟测试，能看到输出就说明运行时链路完整 docker run --rm busybox:latest echo "docker ok"

--rm让容器退出后自动清理，不留垃圾。这条命令打出来docker ok，说明镜像加载、容器创建、runc 调用、网络命名空间初始化整条链路都是通的，比单纯看版本号有说服力得多。如果这一步报网络相关的错，再加--network none试一次，能跑就说明是网络配置的问题，不是 docker 本身。

docker info里还有个容易被忽略的字段是Cgroup Driver，配了 systemd 的话这里应该显示systemd，显示cgroupfs说明exec-opts没生效。另外docker network ls应该能看到bridge、host、none三个默认网络，少一个就说明 dockerd 初始化时出了问题，去journalctl -u docker里翻。

从那以后我每次装完麒麟的 docker，都强制走一遍docker version的双端对齐检查，再跑一条离线镜像的冒烟命令，两步都过了才往生产环境推。这套流程不复杂，但能挡掉八成「装完了但跑不起来」的返工。希望帮到你。

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