简介面向需要在离线或内网环境部署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 启动时会因为标签缺失直接报错。下面表格里的内容基本就是一套能跑起来的最小集合。包名作用备注docker-ce-19.03.*.el7.x86_64.rpmdockerd 守护进程与启动文件版本要和你最终选择的 19.03 小版本一致docker-ce-cli-19.03.*.el7.x86_64.rpmdocker 命令行工具必须和 docker-ce 同版本containerd.io-*.el7.x86_64.rpmcontainerd 容器运行时19.03 依赖 containerd不能漏container-selinux为容器进程准备的 SELinux 策略在 extras 仓库里离线环境很容易漏nvidia-docker2 自己有另外一串依赖主包 nvidia-docker2 依赖 nvidia-container-runtimeruntime 又依赖 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 和 createrepoyum-utils 提供 yumdownloadercreaterepo 用来生成本地仓库元数据。命令如下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-docker2yum 会认为 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-*.rpmrpm -qpR不会安装包只打印该 rpm 的 Requires 列表。看到docker-engine不用紧张docker-ce 会 provide 它看到nvidia-container-runtime、libnvidia-container1这类名字就要确认目录里对应的 rpm 文件存在。检查通过后执行 createrepocreaterepo ./ # 查看是否生成 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.*/enabled0/ /etc/yum.repos.d/CentOS-*.repo # 方式三命令行临时禁用不修改文件 # yum --disablerepo* --enablerepolocal install ...方式一最干净yum 不会扫描 backup 子目录所以移进去后就等于停用。方式二适合你之后还想用系统源的情形但离线环境下没必要保留。方式三适合只想临时搭一次本地安装、不想动 repo 文件的情况。随后写一个只指向本地目录的 repo 文件名字随意后缀必须是 .repocat /etc/yum.repos.d/local.repo EOF [local-docker] nameLocal Docker Offline Repo baseurlfile:///root/rpms enabled1 gpgcheck0 EOF yum clean all yum repolistbaseurl 用file://前缀指向目标机本地目录。gpgcheck0 是离线仓库的正常处理因为包已经从中转机带过来中转机当时在镜像站已经完成过一次校验如果你手头有镜像站的 GPG 公钥也可以把 key 导入 rpm 数据库后开 gpgcheck1这里为了少出幺蛾子就关掉。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也可以直接走 yumyum install -y --disablerepo* --enablerepolocal docker-ce docker-ce-cli containerd.io用--disablerepo*可以完全屏蔽系统里其他 repo同时--enablerepolocal只开放刚才写的 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.xStorage Driver 应当是 overlay2 或 overlayRuntimes 这一行现在应该只有 runc因为 nvidia-docker2 还没装。看到这几个指标后docker-ce 本体这步就算收工了。4. 安装 nvidia-docker2runtime 配置与 daemon.json 关键坑4.1 nvidia-docker2 想干什么一个 hook 和一个 runtimenvidia-docker2 有点像一个“开关盒”它本身不包含 GPU 驱动也不包含 CUDA 库它做的事情是把 NVIDIA 的设备挂载逻辑接入到 docker 运行容器的那条链路上。docker 启动容器时调用的是 runcnvidia-docker2 提供的 nvidia-container-runtime 在 runc 之前插入一个 prestart hook这个 hook 检查容器的 NVIDIA_VISIBLE_DEVICES 环境变量决定把宿主的哪些 /dev/nvidia* 设备节点、驱动库和二进制文件映射进容器。没有这个 runtime 时就算你在 docker 命令里加--gpus allDocker 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。如果该文件原先已有内容脚本会用自带模板覆盖或尝试合并不同小版本行为不一样。先备份等于给自己买了后悔药。安装完成后重启 dockersystemctl 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-runtimenvidia-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不需要每条命令额外写--runtimenvidia。对 GPU 服务器来说这是常见配置。如果你不希望普通容器也挂 GPU 设备可以把这一行删掉保留 runtimes 段然后用docker run --runtimenvidia显式指定。我遇到过的失败案例里最常见的就是runtimeArgs里写成了 Docker 19.03 不认识的参数或者 path 写成了 hook 的绝对路径再加了一串参数结果 daemon 直接起不来。daemon.json 是严格 JSON注释和尾逗号都会导致解析失败。改完后先做一步校验再重启python -m json.tool /etc/docker/daemon.json systemctl daemon-reload systemctl restart dockerpython -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补完后没有再执行 createrepoyum 读取的元数据里就没有这些新包也不认识新增版本。另一种可能是用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 -Fdocker 定义的链会被冲掉。离线环境里常见的是目标机开机没跑 iptablessystemctl 里 iptables 服务也被禁用而 docker 启动时认为自己能接管结果往一个不存在的链里插规则就失败了。解决按顺序处理先把 docker 服务停掉再清空 iptables最后启动 dockersystemctl 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 couldnt 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 的组合就算彻底落地了。希望帮到你。本文还有配套的精品资源点击获取
空间实战解析)
