简介：面向需要在离线或内网环境部署GPU容器服务的运维工程师、AI平台管理员及在受限网络下搭建容器环境的开发人员，这份资源专门解决CentOS 7.6无外网条件下安装docker-ce 19.03与nvidia-docker2.4的难题，省去从零下载依赖的繁琐过程。压缩包整齐收纳了30个文件，其中20个rpm包覆盖docker核心组件与nvidia容器运行时依赖链，3个gz和3个bz2文件提供额外库、源码或元数据，另有json配置文件、xml仓库数据与txt安装说明，整体体积约91.98MB，目录结构清晰。目前该资源已有3312人学习下载，在真实生产与实验环境中得到了较多验证。内容上，它既包含docker-ce、docker-ce-cli、containerd.io等主程序包，也集齐nvidia-container-toolkit、libnvidia-container等GPU支持组件，并附上可直接修改的daemon.json配置模板与文字版操作指引。按包内步骤依次执行rpm安装、启动服务和替换配置即可完成整套部署，无需联网等待，适合批量推送、离线容灾备份及内网环境快速排错参考。

1. 为什么要离线装 docker-ce 19.03 + nvidia-docker2：内网 GPU 机器的真实处境

CentOS 7.6 的服务器放在机房内网，要装 docker-ce 19.03 和 nvidia-docker2，外网却不通——这是不少 GPU 服务器交付现场的常态。从标题的字面就能看出两件事：一不能用yum install直接连仓库，只能把 rpm 包提前拷进去；二是要让容器能调用宿主的 NVIDIA 驱动，光装 docker 还不够，需要 nvidia 的 container runtime 配合。这篇文章适合拿到一台没有公网权限的 CentOS 7.6、又必须把 GPU 容器跑起来的同事。离线安装的难度不在装的那一下，而在离线包准备、依赖补齐和 daemon.json 配置这三处，后面几章都围绕这三件事展开。

2. 离线包从哪来：在中转机上把依赖一次拉齐

2.1 docker-ce 19.03 与 nvidia-docker2 的依赖树

离线安装的第一步是先搞清楚要准备哪些 rpm。docker-ce 19.03 在 CentOS 7 上不是一个单包，它拆成了 docker-ce、docker-ce-cli 和 containerd.io 三部分，其中 containerd.io 是容器运行时的具体实现，docker-ce-cli 里面是 docker 命令行工具。CentOS 7 的 SELinux 策略还需要 container-selinux 这个包，否则 docker 启动时会因为标签缺失直接报错。下面表格里的内容基本就是一套能跑起来的最小集合。

nvidia-docker2 自己有另外一串依赖：主包 nvidia-docker2 依赖 nvidia-container-runtime，runtime 又依赖 libnvidia-container1 和 libnvidia-container-tools。这一串包的作用是在 docker 创建容器时插入一个 NVIDIA 设备 prestart hook，把宿主机的 /dev/nvidia* 设备节点和驱动库映射进容器。这里有一个容易踩的点：nvidia-docker2 的 rpm 里写得是依赖 docker-engine，而 docker-ce 在 EL 7 上恰好通过 Provides 提供了 docker-engine 这个虚拟包，所以两边是兼容的。只懂看包名的同事看到“找不到 docker-engine”不用慌，包就在你准备的本地仓库里。

中转机准备离线包时，我建议选一台与目标机同样是 CentOS 7.6 的机器。版本太新可能会有 libseccomp、iptables 等基础库差异，版本太老则可能缺少 docker 运行需要的内核特性。目标机内核最好是 3.10.0-957 系列，这对应 CentOS 7.6 的默认内核，属于 docker 19.03 支持范围内的基线。

2.2 用 yumdownloader 拉 rpm：参数 --resolve 的正确用法

中转机需要先装 yum-utils 和 createrepo，yum-utils 提供 yumdownloader，createrepo 用来生成本地仓库元数据。命令如下：

yum install -y yum-utils createrepo mkdir -p /tmp/docker-offline/rpms cd /tmp/docker-offline/rpms # 配置 docker-ce 与 nvidia-docker 的 yum 仓库，baseurl 指向你内网能访问的镜像源 yumdownloader --resolve --destdir=./ \ docker-ce-19.03.15 \ docker-ce-cli \ containerd.io \ container-selinux \ nvidia-docker2

这里关键参数是--resolve，它的含义是“把命令行指定包的依赖也一并下载”。注意它基于中转机当前已安装的 rpm 状态来做依赖判断：如果中转机已经装过 docker 和 nvidia-docker2，yum 会认为 containerd 已满足而跳过下载，结果一起打包装到目标机上才发现缺包。所以中转机最好是一台干净的机器，或者先把本机已安装的 docker、nvidia 相关包yum remove掉再执行。

我一般不用yum install --downloadonly做这件事，原因是 yumdownloader 对单包定位更清晰，依赖展开时的报错也会直接点出是哪个包找不到。如果拉取过程中提示某个依赖找不到，先看是不是 yum 仓库里没有对应包，比如 container-selinux 不在 docker-ce 仓库里，而在 CentOS 的 extras 仓库，中转机必须同时启用 base、extras 和 docker-ce、nvidia-docker 这几组仓库。

命令里列出的 docker-ce-19.03.15 是我这边实际拉到过的小版本，具体版本号以你yum list --showduplicates看到的为准。查看命令也很简单：

yum list docker-ce --showduplicates | head -30 yum list nvidia-docker2 --showduplicates

参数说明：--showduplicates会让 yum 列出仓库里所有可用版本，因为默认只显示最新版本；看到输出后挑一个 19.03 系列的版本。注意 docker-ce 的 rpm 小版本依赖 docker-ce-cli 的完全同版本，所以二者要一起锁定。

2.3 校验 rpm 依赖与生成本地仓库

下载完成后，先看一眼目录里有多少个 rpm。正常情况应该在 7 到 10 个之间，包多了不用惊讶，说明把依赖也叫出来了。下一步是验证依赖链是否完整。这一步能帮你提前发现“装了 nvidia-docker2 却缺 nvidia-container-runtime”这类问题：

cd /tmp/docker-offline/rpms ls -1 *.rpm # 查看某个 rpm 的全部依赖，例如 nvidia-docker2 rpm -qpR nvidia-docker2-*.rpm

rpm -qpR不会安装包，只打印该 rpm 的 Requires 列表。看到docker-engine不用紧张，docker-ce 会 provide 它；看到nvidia-container-runtime、libnvidia-container1这类名字，就要确认目录里对应的 rpm 文件存在。检查通过后执行 createrepo：

createrepo ./ # 查看是否生成 repodata 目录 ls -l ./repodata/repomd.xml # 打包转移到目标机 cd /tmp/docker-offline tar -czf docker-offline.tar.gz rpms scp docker-offline.tar.gz root@目标机IP:/root/

createrepo 命令没有其他多余参数，它扫描当前目录下所有 rpm，在子目录 repodata 里生成 repomd.xml 和主元数据文件。yum 加载本地仓库时就只认这个 repomd.xml。注意，createrepo 是“一次性快照”：之后如果你又往目录里放了新 rpm，必须重新执行一次 createrepo，否则 yum 会提示“元数据不匹配”或找不到包。这也是离线安装里很常见的低级错误。

tar 打包时结构是docker-offline.tar.gz解压出来是rpms/这个目录。目标机上解压到 /root/ 下，仓库路径就是/root/rpms。你如果想放到 /opt、/data 这类目录，后续 local.repo 里的 baseurl 得跟着改。

提示：tar 之前先df -h看一下中转机剩余空间。docker-ce 加 nvidia 依赖这堆 rpm 通常只有几十 MB，但中转机 yum 缓存可能很大，tar 目录别和缓存放一起。

3. 在目标 CentOS 7.6 上装 docker-ce 19.03：两条安装路线

3.1 先关掉等不到响应的外网 repo：禁 repo 的三种写法

离线目标机上通常还有 CentOS-Base.repo 等系统自带的源，这些源指向公网，在没外网的环境里 yum 命令会卡在连接超时上，时长能到几分钟，看起来就像死机。所以在做任何操作前要把它们隔离掉。常见做法是这几个方式取一即可：

# 方式一：把现有 repo 全部移走备份 cd /etc/yum.repos.d mkdir -p /etc/yum.repos.d/backup mv *.repo backup/ 2>/dev/null # 方式二：只禁用不删除 # sed -i 's/^enabled=.*/enabled=0/' /etc/yum.repos.d/CentOS-*.repo # 方式三：命令行临时禁用（不修改文件） # yum --disablerepo='*' --enablerepo=local install ...

方式一最干净，yum 不会扫描 backup 子目录，所以移进去后就等于停用。方式二适合你之后还想用系统源的情形，但离线环境下没必要保留。方式三适合只想临时搭一次本地安装、不想动 repo 文件的情况。

随后写一个只指向本地目录的 repo 文件，名字随意，后缀必须是 .repo：

cat > /etc/yum.repos.d/local.repo <<'EOF' [local-docker] name=Local Docker Offline Repo baseurl=file:///root/rpms enabled=1 gpgcheck=0 EOF yum clean all yum repolist

baseurl 用file://前缀指向目标机本地目录。gpgcheck=0 是离线仓库的正常处理，因为包已经从中转机带过来，中转机当时在镜像站已经完成过一次校验；如果你手头有镜像站的 GPG 公钥，也可以把 key 导入 rpm 数据库后开 gpgcheck=1，这里为了少出幺蛾子就关掉。

yum repolist输出里如果只有 local-docker 一项，说明仓库已经生效。如果输出还出现其他仓库，多半是刚才移走的文件名带.repo在 backup 子目录里，yum 不会扫描子目录，若有则可能是另外的 epel 或自定义 repo 没被移走。

3.2 方案一：rpm 批量安装（最直接）

rpm 安装的好处是不依赖 repo 文件，解压 tar 后就可以装：

cd /root/rpms rpm -Uvh container-selinux-*.rpm containerd.io-*.rpm docker-ce-cli-*.rpm docker-ce-19.03*.rpm

这里要说明一下顺序与通配符写法。rpm 命令展开*.rpm时按文件名排序；我用docker-ce-19.03*.rpm而不是docker-ce-*.rpm，是因为后者会把 docker-ce-cli 的文件也一起展开，导致命令里多一个匹配，虽然 rpm 能处理，但看日志时容易混。顺序上，container-selinux 和 docker 包之间没有硬依赖，但 container-selinux 应该在前，因为 docker 安装包的脚本可能在 post 阶段调用 SELinux 相关的命令；containerd.io 必须在 docker-ce 之前安装，docker-ce 的 rpm 要求在安装时能解析到 containerd.io。

rpm 批量安装的本质是“在这一次调用里把所有包的依赖都看作候选”，依赖关系由 rpm 数据库统一解析。如果缺依赖，命令会立刻失败并列出缺的包名，不会半装半坏。所以看到失败信息不要慌，照着缺失包名去中转机补包即可。这里要特别提醒：不要执行rpm -Uvh *.rpm，因为里面还包括 libnvidia-container 和 nvidia-docker2，而你现在只装 docker，两个 nvidia 包会因为没有 daemon.json 等前置条件而失败。

装完后立刻查看服务状态：

systemctl enable --now docker systemctl status docker --no-pager

--now让 systemctl 同时完成 enable 和 start，少打一条命令。如果服务没有起来，看journalctl -u docker最后几十行，大部分问题会直接写在日志里，比如网络冲突、存储驱动不支持、SELinux 策略缺失。

3.3 方案二：本地 yum 仓库安装（更省心）

如果离线 tar 里已经带了 repodata，也可以直接走 yum：

yum install -y --disablerepo='*' --enablerepo=local docker-ce docker-ce-cli containerd.io

用--disablerepo='*'可以完全屏蔽系统里其他 repo，同时--enablerepo=local只开放刚才写的 local-docker 这个仓库。这样即使你前面没有移走 yum 自带的 repo，也不会因为外网仓库超时中断安装。yum 这条路线的优势是它会按依赖自动选 rpm，补齐我们没意识到的版本要求。缺点是如果 createrepo 元数据没更新，yum 装出的包就会缺漏，报错“没有任何匹配”。所以两条路线取决于你手里的状态：同目录已经生成 repodata 用 yum，只有散 rpm 用 rpm 批量装。

3.4 装完检查 Server Version 与存储驱动

无论哪条路线装完，都要做一个完整性检查，确认 docker 服务已经在跑、版本是 19.03、存储驱动是 overlay2。命令如下：

docker version docker info | grep -E "Server Version|Storage Driver|Cgroup Driver|Runtimes"

第一行docker version会同时输出 Client 和 Server 两段，如果只看到 Client 看不到 Server，说明 daemon 没起来。docker info里的 Server Version 原则上应该等于 19.03.x，Storage Driver 应当是 overlay2 或 overlay，Runtimes 这一行现在应该只有 runc，因为 nvidia-docker2 还没装。看到这几个指标后，docker-ce 本体这步就算收工了。

4. 安装 nvidia-docker2：runtime 配置与 daemon.json 关键坑

4.1 nvidia-docker2 想干什么：一个 hook 和一个 runtime

nvidia-docker2 有点像一个“开关盒”：它本身不包含 GPU 驱动，也不包含 CUDA 库，它做的事情是把 NVIDIA 的设备挂载逻辑接入到 docker 运行容器的那条链路上。docker 启动容器时，调用的是 runc；nvidia-docker2 提供的 nvidia-container-runtime 在 runc 之前插入一个 prestart hook，这个 hook 检查容器的 NVIDIA_VISIBLE_DEVICES 环境变量，决定把宿主的哪些 /dev/nvidia* 设备节点、驱动库和二进制文件映射进容器。

没有这个 runtime 时，就算你在 docker 命令里加--gpus all，Docker 19.03 也只是个“看起来有这个参数”的状态：因为缺少 hook，容器里的 nvidia-smi 仍然找不到设备。这就是标题把 docker-ce 19.03 和 nvidia-docker2 写在一起的原因。docker-ce 19.03 首次在 CLI 里引入了--gpus参数，但底层执行还是交给 nvidia container runtime 的 hook，所以这两个软件版本其实是一套组合。

这里顺带说一句，nvidia-docker2 是旧方案，NVIDIA 后来把它改名成 nvidia-container-toolkit。但很多存量 CentOS 7.6 环境里，容器平台依赖的还是 nvidia-docker2 的包名和默认配置写法，所以标题里的方案在今天仍然有大量复现价值。

4.2 安装 nvidia-docker2 的最小命令与依赖解决

安装前先看一眼 /etc/docker/daemon.json 是否存在。如果之前没动过 docker 配置，这个文件很可能不存在；如果存在，务必先备份：

ls -l /etc/docker/daemon.json 2>/dev/null cp /etc/docker/daemon.json /etc/docker/daemon.json.bak 2>/dev/null || true cd /root/rpms rpm -Uvh libnvidia-container-*.rpm nvidia-container-runtime-*.rpm nvidia-docker2-*.rpm

依赖顺序是：先装 libnvidia-container 的两个底层库，再装 nvidia-container-runtime 这个运行时，最后装 nvidia-docker2。如果目录里 rpm 版本与这些通配不匹配，就先ls看一下实际文件名再改命令。rpm 安装过程中的一个坑是：nvidia-docker2 的 postinstall 脚本会写 /etc/docker/daemon.json。如果该文件原先已有内容，脚本会用自带模板覆盖或尝试合并，不同小版本行为不一样。先备份，等于给自己买了后悔药。

安装完成后重启 docker：

systemctl restart docker sleep 2 docker info | grep -A5 Runtimes

输出里如果看到Runtimes: nvidia runc，说明 runtime 已经被 daemon 识别。如果还是只有 runc，去 /etc/docker/daemon.json 看 runtime 段是否还在。

4.3 daemon.json 配置：Runtimes 段与 default-runtime

nvidia-docker2 安装脚本写出的 daemon.json 通常长这样：

{ "default-runtime": "nvidia", "runtimes": { "nvidia": { "path": "nvidia-container-runtime", "runtimeArgs": [] } } }

这里的path指的是 nvidia-container-runtime 这个可执行文件，它会被 dockerd 以 PATH 查找。先执行which nvidia-container-runtime确认它在 /usr/bin 或 /usr/sbin，如果不在，daemon 启动后会报找不到 runtime，那时候 docker info 的 Runtimes 就只剩 runc。

default-runtime设为 nvidia 的效果是：所有容器默认都走 nvidia runtime，不需要每条命令额外写--runtime=nvidia。对 GPU 服务器来说这是常见配置。如果你不希望普通容器也挂 GPU 设备，可以把这一行删掉，保留 runtimes 段，然后用docker run --runtime=nvidia显式指定。我遇到过的失败案例里，最常见的就是runtimeArgs里写成了 Docker 19.03 不认识的参数，或者 path 写成了 hook 的绝对路径再加了一串参数，结果 daemon 直接起不来。

daemon.json 是严格 JSON，注释和尾逗号都会导致解析失败。改完后先做一步校验再重启：

python -m json.tool /etc/docker/daemon.json systemctl daemon-reload systemctl restart docker

python -m json.tool是检查 JSON 格式最快的方式，能解析就返回原内容，不能解析就定位到哪一行。注意，systemctl daemon-reload对 docker 这种传统 init 脚本服务作用有限，但对某些版本里 systemd unit 文件变化是必要的，反正无害，顺手执行。

5. 离线安装常见问题与排查：五个我踩过的坑

5.1 Ubuntu 的 docker-ce 仓库抄进 CentOS：元数据直接报错

现象：目标机上写好了 docker-ce.repo，执行yum repolist时终端弹出一长串错误，其中能看到类似e: 仓库 “https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/ubuntu bionic” ... repomd.xml 下载失败的提示。这里 e: 开头的其实是详细错误日志里一个条目标签，碰到它基本可以确认 baseurl 路径写错了。

原因：镜像站的 docker-ce 目录下同时存在linux/ubuntu和linux/centos两套结构。Ubuntu 路径下是 dists/bionic 这种 deb 源结构，CentOS 的 yum 解析不了这个目录，因为 yum 只认 repodata/repomd.xml，而 bionic 下的结构完全不一样。这个错误的本质是“抄配置时没分发行版”。

解决：把 baseurl 改回linux/centos/7/x86_64/stable，检查/etc/yum.repos.d/docker-ce.repo里的 URL 层级，然后yum clean all && yum repolist重试。其实把标题里的 centos7.6 先看清楚，再从镜像站选对应分发段的目录，就不会翻车。

5.2 rpm 提示缺少依赖但不是没下载，是本仓库没建好

现象：在目标机上执行yum install docker-ce，报错内容大概是这样——“没有与 docker-ce 匹配的包”或“包 containerd.io 需要被依赖，但没有可以被安装的候选”。此时离线包里明明有 containerd.io 的 rpm。

原因：这是典型的 createrepo 元数据过期。如果你先把 rpm 拷进目录、执行了 createrepo，后来又从别处补了几个 rpm，补完后没有再执行 createrepo，yum 读取的元数据里就没有这些新包，也不认识新增版本。另一种可能是用rpm -Uvh时通配符没匹配全，把 docker-ce-cli 当成 docker-ce 的依赖漏掉了。

解决：补完 rpm 后重新执行createrepo ./，再yum clean all。如果走 rpm 路线，用ls *.rpm列出全部包名，手动按依赖顺序写在一条 rpm 命令里，不要让 rpm 自己“猜”。

5.3 dockerd 启动失败：iptables 规则被清掉

现象：systemctl start docker失败，journalctl -u docker里出现iptables failed: iptables --wait -t nat -A DOCKER，或者提示链不存在。有些机器重启后 docker 起不来，执行iptables -L看不到 docker 创建的链。

原因：docker 依赖 iptables 的 nat 表和 filter 表来创建 DOCKER 链、端口映射和网桥转发规则。如果机器上有其他网管脚本或安全软件在启动时执行iptables -F，docker 定义的链会被冲掉。离线环境里常见的是目标机开机没跑 iptables，systemctl 里 iptables 服务也被禁用，而 docker 启动时认为自己能接管，结果往一个不存在的链里插规则就失败了。

解决：按顺序处理，先把 docker 服务停掉，再清空 iptables，最后启动 docker：

systemctl stop docker iptables -F iptables -t nat -F iptables -t nat -X systemctl start docker

如果你对当前防火墙规则有业务依赖，先执行iptables-save > /root/iptables.rules留底。这里有个边界要说清楚：iptables -P FORWARD ACCEPT是让容器与外部通信能穿过内核转发，docker 默认会自己把它设成 DROP，所以如果你后面又改了 FORWARD 策略，容器出网失败时不要先怀疑 nvidia-docker2，把策略恢复成 ACCEPT 再看。

5.4 容器里跑不了 nvidia-smi：先查驱动再查 runtime

现象：docker run --rm --gpus all nvidia/cuda:10.2-base nvidia-smi输出NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver。

原因：分两层看。第一层，宿主机本身没有装 NVIDIA 驱动，或者驱动版本与当前内核 module 不匹配；第二层，宿主机驱动正常，但容器没有挂上设备节点，也就是 nvidia runtime 没有生效。很多人一看到容器里 nvidia-smi 失败就去重装 nvidia-docker2，其实多数情况是第一个可能。

解决：先在宿主机上执行nvidia-smi，能正常打印 GPU 列表，说明驱动没问题，再排查 docker 的 Runtimes 和 daemon.json。如果宿主机也报同样错误，那就是驱动问题，离线安装 docker 之前得先把 NVIDIA 驱动 rpm 或 runfile 也准备好。确认驱动没问题后，执行：

docker info | grep -A10 Runtimes docker inspect <容器ID> --format '{{json .HostConfig.Devices}}'

容器里的设备节点由 prestart hook 在容器运行时动态挂入，命令里的HostConfig.Devices如果输出空数组，说明 runtime 根本没走到，问题在 daemon.json 配置。

5.5 daemon.json 被安装脚本覆盖：提前备份是后悔药

现象：nvidia-docker2 安装时一切正常，重启 docker 后服务起不来，报错error parsing /etc/docker/daemon.json: invalid character ... looking for beginning of value。

原因：nvidia-docker2 的 rpm 在 postinstall 阶段会向 /etc/docker/daemon.json 写入运行时配置。如果你原文件里已有内容，且小版本脚本的合并逻辑与你的文件结构不兼容，可能生成一个“半覆盖”的文件。再加上有人习惯用编辑器手工改 daemon.json，引入制表符或多一个逗号，这些问题会集中在这一步爆发。

解决：把备份恢复回去，再手动合并 runtime 段：

cp /etc/docker/daemon.json.bak /etc/docker/daemon.json 2>/dev/null || echo '{}' > /etc/docker/daemon.json python -m json.tool /etc/docker/daemon.json

然后按 4.3 里的格式补上 runtimes 和 default-runtime。恢复备份后别直接重启，先用python -m json.tool验证一遍再动 systemctl。这会省掉至少半小时的定位时间。

6. 验证套路与顺手技巧：离线环境跑通 GPU 容器

离线环境最大的麻烦是测试镜像没有缓存，docker run一条命令进去后因为拉不到镜像卡住。所以我会在联网的中转机上预先准备一个最小的 CUDA 镜像 tar 包，用 docker save 打包，随后 load 进目标机器——这就解决了“起不来”和“跑起来还是靠猜”两个问题。

中转机上执行：

docker pull nvidia/cuda:10.2-base docker save nvidia/cuda:10.2-base -o cuda-base-10.2.tar scp cuda-base-10.2.tar root@目标机IP:/root/

目标机上执行：

docker load -i /root/cuda-base-10.2.tar docker run --rm --gpus all nvidia/cuda:10.2-base nvidia-smi

输出里如果能看到 GPU 型号、驱动版本和 CUDA Version，说明整套链路已经打通。这里有一个判断小技巧：如果 docker info 里 Runtimes 有 nvidia 且 default-runtime 是 nvidia，直接跑docker run --rm nvidia/cuda:10.2-base nvidia-smi也能过，说明这个 runtime 已经是全局默认；如果这条命令失败，而加--gpus all成功，说明只有 CLI 参数生效，daemon 配置里 runtimes 段没配好，需要回去看 4.3 的内容。

我自己的习惯是每次离线交付都自带一个这样的基础镜像 tar，因为 runtime 接入成功与否，只有真正跑一次 nvidia-smi 才算确认。单位里那些“装完了但报驱动错误”的工单，十有八九是没做这步验证就把机器交了出去。把上面的 docker load 和 docker run 两条命令记下来，嵌到你的交付检查单里，这台 CentOS 7.6 加上 docker-ce 19.03 和 nvidia-docker2 的组合就算彻底落地了。希望帮到你。

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