离线环境安装Docker：docker.rpm.tar包解压、依赖与排错实践

简介：这是一份面向CentOS 7系统的Docker离线安装RPM软件包集合，专为无法直接访问外网或需要快速批量部署Docker的环境准备。压缩包内含docker主程序、docker-client客户端、docker-common公共组件及container-selinux、oci-systemd-hook等必要依赖，并附带完整repodata仓库元数据（含xml描述、gz与bz2压缩索引），可直接配置为本地yum源使用。整个包共16个文件，其中9个RPM安装包覆盖核心程序与依赖组件，3个GZ文件和3个BZ2文件存放仓库元数据，另有1个XML文件提供索引描述，整体大小约19.27MB，轻量易传输。目前已有379人学习下载，适用于系统运维人员或需要在内网搭建Docker环境的开发者。通过这份包，用户可在离线条件下完成Docker的标准化安装，免去逐个排查依赖的繁琐过程，尤其适合多台机器批量部署或教学实验场景，也便于保存分发和版本管理。

1. docker.rpm.tar软件包到底是什么，以及为什么离线环境离不开它

很多从互联网公司出来、习惯了yum install docker-ce一条龙安装的工程师，第一次走进银行、电力或军工内网机房时，都会对着没有外网的空白CentOS发呆。你手头只有一台运维终端、一个加密U盘，以及一个名为docker.rpm.tar的软件包——它本质上是一个用tar打包的、内含多个.rpm文件的压缩归档，是离线环境安装Docker的“标准生存工具”。它要解决的不是“装哪个版本”的偏好问题，而是“在不通外网的前提下，把Docker引擎、containerd、CLI客户端和依赖库完完整整铺到目标机器上”的合规性问题。适合谁？适合所有需要在内网交付容器平台、复制Docker二进制环境、或给客户做私有化部署的一线工程师。读完这篇，你不仅能解开这个包，还能知道依赖顺序怎么排、启动后怎么验、翻车了怎么救。

2. 先过解压这一关：tar包的结构检查与三种解压方式

2.1 解压前先看包：tar -tf 列出内容而不是直接解压

拿到docker.rpm.tar这个文件，我建议大家先克制住直接tar -zxvf的冲动。先花十秒钟看一眼包里装的是什么，能规避掉后面至少三分之一的玄学问题。常见的错误是把rpm的tar包和其他二进制压缩包搞混，解压出来一坨源码，或者一解压就报“Cannot open: No such file or directory”，搞得人一头雾水。

# 第一件事：查看tar包内的文件清单，但先不解压 tar -tf docker.rpm.tar # 如果包是用gzip压缩过的，加一个-z选项也能正常读取 tar -tzvf docker.rpm.tar

这两条命令会输出归档内的完整路径列表。tar -tf输出的第一列如果是-rw-r--r--这类权限位，并且文件路径以.rpm结尾，就说明这确实是我们预想中的RPM软件包集合。如果输出里出现的是docker/docker、containerd/这种目录树结构，那这个包可能是一个免安装的二进制版本，后续安装逻辑完全不同。参数说明里，-t表示列出内容，-f指定归档文件名，-v让输出带上权限、属主和大小，方便判断包的类型。这里有个小细节：tar -tf是纯读取操作，不会对当前目录产生任何写入，出错的话只会报“tar: Error opening archive: No such file or directory”，不会弄脏环境，是天然的排错前置命令。

2.2 正式解压并核对rpm文件完整性

看完清单确认无误后，就可以正式解压了。这一步看似简单，但很多生产事故其实发生在解压这一步，比如解压权限过大、覆盖了同名的旧文件却毫无察觉。

# 常规解压，gzip压缩的tar包用-z自动识别 tar -zxvf docker.rpm.tar -C /opt/docker-offline/ # 如果包没做gzip压缩，只是单纯的tar归档，去掉-z即可 tar -xvf docker.rpm.tar -C /opt/docker-offline/

命令解释：-x代表解压，-C指定目标目录。我习惯先手动mkdir -p /opt/docker-offline再解压，避免-C指向一个不存在的路径时报错。解压完成后，立刻用ls -l /opt/docker-offline/*.rpm核对文件是否齐全。常见的docker.rpm.tar里至少包含docker-ce、docker-ce-cli、containerd.io这几个核心rpm，以及docker-buildx-plugin和docker-compose-plugin这两个可选插件。如果你看到的包只有docker-engine和docker-client，那是老版本命名，安装顺序和依赖关系会略有差异。这里必须强调一个血泪教训：解压后立刻用md5sum或sha256sum校验文件完整性，这些校验值一般会在包附带的下发单或SHA256SUMS文件里，千万不要想当然地跳过——离线包在拷贝过程中U盘损坏是常态，跑一遍校验只要几秒钟，却能帮你省下后面排错几天的时间。

2.3 把tar包交给xargs：批量处理rpm的进阶姿势

解压只是第一步，做完之后很多人习惯性地cd进去，然后手打rpm -ivh docker-ce.rpm，如果依赖报错再手忙脚乱地找缺什么。这里我一般会用tar管道xargs组合拳，在解压前就把依赖关系摸清楚。

# 用tar -tf列出所有rpm包，再用xargs逐个交给rpm查询依赖 tar -tf docker.rpm.tar | grep '\.rpm$' | xargs -I {} rpm -qpR {} # 如果需要同时查看每个包的版本、Release信息，可以用rpm -qip tar -tf docker.rpm.tar | grep '\.rpm$' | xargs -I {} rpm -qip {}

这个命令的精髓在于：tar -tf送到标准输出的文件名列表，被xargs转成了后续rpm命令的参数。这里的-I {}指定了替代符号，让rpm -qpR {}对每一个文件都执行一次查询，-qpR是“查询未安装的包文件所依赖的运行时库”的专用参数。输出效果会非常直观：你立刻能看到docker-ce依赖docker-ce-cli，而docker-ce-cli可能又依赖libcgroup等其他rpm。如果这些依赖在包里找不到，就需要你去别的地方补齐了。这一招能把原本黑匣子一样的依赖安装过程，变成可见的文件清单，是离线环境排障的必备起点。

3. 安装顺序和依赖之争：rpm -ivh 与 yum localinstall 怎么选

3.1 为什么离线环境优先用 localinstall 而不是 rpm -ivh

很多教程还在教用rpm -ivh *.rpm一把梭，这在CentOS 7时代确实能蒙对，因为彼时docker依赖的libcgroup、libseccomp通常系统自带了。但到了CentOS 8、RHEL 9和openEuler这些新系统上，依赖版本更新很快，rpm -ivh经常会报“libseccomp.so.2()(64bit) is needed by docker-ce”，因为系统自带的libseccomp版本太旧了。

# 致命错误示范：直接暴力安装，可能造成系统内rpm数据库混乱 rpm -ivh /opt/docker-offline/*.rpm --nodeps --force # 推荐做法：用yum localinstall走本地依赖解析 yum localinstall -y /opt/docker-offline/*.rpm

yum localinstall和rpm -ivh的最大区别，在于它会把本地文件路径里的rpm包当成“源”来解析依赖。它优先检查本地这些rpm之间能否互相满足依赖，缺了才去找已配置的yum源。如果机器完全离线，需要加上--disablerepo=*让它别去联网尝试，避免长时间卡在“Loading mirror speeds...”。这也顺带回答了热搜里的一个高频疑问：为什么我rpm -ivh装成功了，启动docker却还是报错？答案就是--nodeps --force强行跳过了依赖检查，rpm数据库里确实记录了安装成功，但程序运行时的动态链接库根本对不上，不是segment fault就是cannot open shared object file。所以我的建议是：除非你极清楚这个包的所有依赖都已经在系统里、且版本恰好兼容，否则永远别在docker安装上使用--nodeps，这不是捷径，这是给自己挖坑。

3.2 离线依赖打包：docker的rpm依赖从哪里找

既然离线环境讲究“一次打包，处处可用”，那依赖从哪来就成了核心问题。有些人图省事，在生产机器上用rpm -ivh --nodeps硬塞进去，结果网络一挂就原形毕露。正规的离线安装必须把依赖收集齐。常见做法是在一台同样操作系统版本、且有外网的机器上，用yumdownloader把目标rpm和依赖全部拉下来，再放进tar包里。

# 在有外网的机器上，安装yum-utils工具 yum install -y yum-utils # 下载docker-ce及其所有依赖到指定目录 yumdownloader --resolve --destdir=/opt/docker-rpm-collection docker-ce docker-ce-cli containerd.io

参数说明：--resolve是核心，它会让yumdownloader不仅下载目标包，还把依赖树上的所有rpm一并拉下来，并且自动去重。--destdir指定输出目录。执行完后，ls一下会发现目录里多了一堆名字前排是libcgroup-0.41-21.el7.x86_64.rpm的第三方依赖包。然后把整个目录tar -czvf docker.rpm.tar /opt/docker-rpm-collection打包，就生成了标准的docker.rpm.tar软件包。如果你在openEuler这类国产系统上操作，思路完全一致，只是yumdownloader可能需要换成dnf download，命令逻辑并无二致。

3.3 安装后的文件布局：docker主程序与containerd的落点

安装完成后别急着跑命令，花两分钟确认文件布局，能帮你在排错时快速定位问题。RPM方式安装的Docker，文件布局和二进制解压包有很明显的差异，理解这些差异，你就知道出问题时该去看哪个目录的日志。

用rpm -ql docker-ce可以打印出该rpm包在系统上的完整文件清单，这是定位“某个文件去哪儿了”最直接的命令。比如你发现docker-compose命令找不到，用rpm -ql docker-compose-plugin一看，文件落在/usr/libexec/docker/cli-plugins/docker-compose，由于它不在常规的PATH目录下，所以直接敲docker-compose当然找不到。但是你敲docker compose（注意中间有空格）就能正常调起插件，这正是目录设计上的一个微妙差异。

4. 启动与自启：系统集成阶段必须调通的四个配置点

4.1 配置 /etc/docker/daemon.json 并设定 storage-driver

rpm安装的docker-ce，在CentOS 7上默认存储驱动是devicemapper，这是个性能瓶颈明显的旧方案，在新版本内核里尤其吃亏。装完第一件事就是手动创建/etc/docker/daemon.json，把存储驱动切到overlay2。如果在安装时没配这一步，很多机器启动后跑几个容器就会出现“failed to mount overlay”的内核报错，极其折腾。

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

这是个标准的离线配置模板。重点解释三个参数：exec-opts里的native.cgroupdriver=systemd是给kubelet等编排工具预留的平滑接口，用cgroupfs驱动在纯docker环境没问题，但一旦上层叠加K8s集群，cgroup驱动不一致会导致节点无法加入集群，这是集成测试阶段最典型的翻车原因。log-driver和log-opts限制单个容器日志文件大小和保留个数，不设这个，一个跑着Nginx的容器能把磁盘写满，到时候/var/lib/docker所在分区爆掉，整个节点的容器全部异常退出。registry-mirrors留空数组，意思是内网环境不依赖公网镜像加速，走私有仓库或docker load离线导入镜像。

4.2 让docker随系统启动：systemctl enable的两层含义

离线安装的机器重启后，如果docker没起来，所有依赖容器的业务全部瘫痪。手动启动很简单，但让它“开机自启”里面有个很容易被忽略的坑：systemctl enable docker和systemctl enable --now docker是两码事。

# 正确姿势：设置开机自启并立即启动 systemctl enable --now docker # 查看当前自启状态和进程运行情况 systemctl is-enabled docker systemctl status docker

enable只创建符号链接，把docker.service挂到multi-user.target.wants目录下，机器下次开机才会自动拉起来。而--now参数会在当前时间点立即触发一次systemctl start docker。很多工程师装完docker，只敲了systemctl start docker忘了enable，结果过几天机房断电重启，整个容器环境都没了，然后大半夜打电话叫你去现场处理。另外systemctl status显示的“Active: active (running)”只代表守护进程活着，不代表容器都恢复到了期望状态，这是后话，后面验车章节再展开。

4.3 验证网络模式：从 bridge 到 host 的参数差异

容器网络是离线安装后另一个常见“黑匣子”。docker0网桥依赖iptables的FORWARD链放行，很多刚装好的机器上，iptables的FORWARD策略默认是DROP，导致docker run创建容器后，容器内能ping通宿主机网关，但访问不了另一台机器上的服务。想要定位网络问题，第一步是看iptables规则链。

# 查看docker网桥和iptables规则是否正常生成 iptables -t nat -L -n | grep docker iptables -L FORWARD -n -v

如果发现FORWARD链的policy是DROP，而且没有docker放行规则，那多半是firewalld或者其他网络管理组件和docker的iptables管理产生了冲突。把/etc/sysctl.conf里的net.ipv4.ip_forward设为1，执行sysctl -p让内核转发开启，然后重启docker。至于bridge和host两种模式的选择，我的实践经验是：单机开发调试用host模式最省心，因为端口映射直接打到宿主机上，少一层NAT转换，排查网络问题少绕很多弯。但生产集群里容器必须走bridge模式，让docker自己管理网段和端口映射。切换方式：

# 创建容器时指定网络模式为host docker run --rm --network host nginx:alpine # 指定为bridge模式则不加--network参数即可（默认即为bridge） docker run --rm -p 8080:80 nginx:alpine

参数--network的取值有bridge、host、none三种最常见。none模式下容器只有lo回环接口，完全隔离网络栈，适合跑一些定时任务或离线计算型容器。理解这些参数差异，是后续容器网络排错的基础。

5. 落地避坑：docker.rpm.tar离线安装的5个典型翻车现场

5.1 现象：tar解压报错“Cannot open: No such file or directory”

原因：这个报错有八成是tar包在拷贝过程中损坏了。U盘/移动硬盘从Windows拷贝到Linux，FAT32格式下的文件可能被截断，或者拷贝时缓存未刷新就拔盘。另外，如果包是在Windows上用压缩软件压的，解压到Linux时也容易出现路径分隔符导致的内层嵌套问题。解决：重新用md5sum校验整个tar包的完整性，再换一种方式传输。如果手头没有校验值来源，可以尝试直接看包尾部的日志：

# 查看tar包压缩方式和损坏情况（gzip包会有明显报错） gzip -t docker.rpm.tar && echo "gzip校验通过" file docker.rpm.tar

file命令会识别出这是“gzip compressed data”还是“POSIX tar archive”。如果gzip -t直接报“gzip: docker.rpm.tar: unexpected end of file”，那就别纠结了，重新去源机器上导包吧，这个包已经废了。我的习惯是用rsync替代cp来拷tar包，因为rsync一边拷一边做校验，拷完还默认核对文件大小和修改时间，能显著降低这种低级翻车概率。

5.2 现象：rpm -ivh 报缺依赖，比如 libseccomp 版本过旧

原因：CentOS 7自带的libseccomp版本是2.3.1，而较新的containerd.io要求至少libseccomp.so.2.4以上。rpm -ivh只会死板地检查rpm数据库里已安装的库版本，版本号低一位它就拒绝安装，不会帮你自动升级依赖。解决：扔了rpm，改用yum localinstall让它走本地依赖解析器，如果本地包里恰好还有更新的libseccomp，yum会自动帮你升级它再装docker；如果本地包里也没带，那就必须去镜像站下载对应系统版本的支持库rpm，放进同一个目录再执行一次yum localinstall *.rpm。需要特别提一句的是：有些人在内网环境硬要装CentOS 7上根本不存在的libseccomp-devel，折腾半天纯属白费力气，因为devel包是给编译环境用的，程序运行时只需要.so库文件，搞清楚rpm包q和d包的区别能少走很多弯路。

5.3 现象：docker启动失败，报错“driver not supported”或“overlay2 is not supported”

原因：新装好的CentOS 7.6内核是3.10.0-957，这个内核版本的overlay模块确实能加载，但docker的overlay2驱动要求内核支持d_type（目录条目类型），而早期XFS文件系统格式化时如果不带ftype=1参数，d_type支持就是关闭的。overlay2驱动会拒绝在这种文件系统上工作。解决：

# 先查当前docker数据目录所在文件系统的挂载参数 findmnt -n -o FSTYPE,OPTIONS /var/lib/docker # 如果是xfs且没有ftype=1，需要重新格式化（务必先备份数据） mkfs.xfs -n ftype=1 /dev/sdb1 vim /etc/fstab # 确认挂载参数包含 pquota

findmnt输出里如果看到rw,seclabel,relatime这样的默认参数，没有ftype=1，那事情就大了。重新格式化能解决，但代价是数据清空，所以这个坑的最佳处理方式是前移：在解压docker.rpm.tar准备安装之前就确认好数据盘格式，不要等到docker启动失败再去救火。另外还有一个临时绕过的方案，就是把daemon.json里的storage-driver从overlay2临时改成vfs，但vfs的性能和存储占用非常惨，只适合应急验证连通性。

5.4 现象：docker网络不通，容器内ping不通外部主机

原因：宿主机开启了firewalld，它把FORWARD链的默认策略设成了DROP。docker每次创建docker0网桥时，会往FORWARD链插入自己的规则，但firewalld的策略优先级更高，直接把docker的转发规则拦住了。解决：二选一，要么彻底停用firewalld（内网服务器一般没有违规风险），要么放行docker网段：

# 方案一：停用firewalld（生产环境不推荐，但最常见） systemctl stop firewalld && systemctl disable firewalld # 方案二：显式放行FORWARD链上的docker网段（推荐） iptables -I FORWARD -i docker0 -o eth0 -j ACCEPT iptables -I FORWARD -i eth0 -o docker0 -j ACCEPT

如果上面两条iptables命令执行完还是不通，接着查/etc/sysctl.conf里的net.ipv4.ip_forward，确认它等于1。sysctl -p刷新生效之后，再重启docker服务，这时容器网络基本就通了。还有一个容易被忽视的隐藏设置：如果宿主机上有多个网卡，且多网卡属于不同网段，需要手动指定--fixed-cidr来规划docker0网段，避免docker默认分配的172.17.0.0/16和公司办公网或业务网段重叠，一旦重叠，路由表会把容器网络导去物理网关，离线环境排这个错非常折腾。

5.5 现象：docker compose 命令不存在，但 docker-compose 又装不上

原因：从docker-ce 20.10+开始，官方就主推docker compose插件模式，单独的docker-compose二进制逐渐停止更新。你手里的docker.rpm.tar里如果只包含docker-compose-plugin这个rpm，那系统里只有docker compose子命令，没有独立的docker-compose可执行文件。解决：验证的方法很简单：

# 检查插件是否安装到位 rpm -qa | grep docker-compose-plugin docker compose version # 如果业务脚本里顽固地使用docker-compose，就需要手动做个软链接 ln -s /usr/libexec/docker/cli-plugins/docker-compose /usr/local/bin/docker-compose

软链接这条路实测可行，因为docker-compose-plugin里的实现本质是一个二进制程序，只是官方把它放在了/usr/libexec/docker/cli-plugins/目录下。不过我要给大家一句劝：尽早把CI/CD脚本里的docker-compose改成docker compose，不要为了兼容老脚本而养着一个软链接，因为新版本docker一旦升级，这个软链接路径可能就失效了，到时候半夜升级完发现所有发布流水线全部中断，慌都来不及。

6. 装完怎么证明它真的好了：三个验证命令与一个诊断技巧

6.1 docker info 是体检报告，不是版本炫耀

docker version大家都会敲，但那个输出只能证明客户端能连上守护进程，根本看不出系统层面的健康度。我每次装完docker，必看的命令是docker info，它才是正儿八经的系统体检报告。重点看三个字段：Storage Driver必须是overlay2，如果是vfs说明配置没生效或内核不支持；Cgroup Driver必须是systemd，如果显示cgroupfs，后续接K8s必出幺蛾子；Server Version和你的docker.rpm.tar包的版本号能对得上，防止U盘里塞了旧包。

6.2 用 tar 做增量快照给 docker 二进制留后悔药

这是我个人的一个习惯：装完一套可用环境之后，立刻把整个docker相关的二进制和配置目录打成tar快照，放到一个安全目录里。这相当于给系统状态拍了张“后悔药”照片，以后万一有人手贱改了配置导致docker起不来，你不用重装系统，直接解压这个快照回去就能恢复。快照目录可以精简到只打包关键路径。

# 确认二进制路径 which dockerd docker containerd # 打出快照（排除containerd的root目录太大，只打核心二进制和配置） tar -czvf docker-backup-$(date +%F).tar.gz \ /usr/bin/docker /usr/bin/dockerd /usr/bin/containerd* \ /etc/docker/ \ /usr/lib/systemd/system/docker.service

这套快照组合拳的好处在于：rpm安装的docker和免安装版不同，升级或卸载时可能会直接删除二进制文件，而有了这个tar压缩包，就算rpm数据库全乱了，你也能用tar -zxvf把二进制和systemd单元文件手动铺回去，恢复一个可用的docker。这不是官方推荐的恢复方式，但作为最后的兜底手段，实测有效。

6.3 一个诊断技巧：strace 看 docker 启动时的配置读取顺序

如果linux上装了strace，这是一个极其强大的黑匣子排查工具。当docker启动后行为异常，但journalctl日志里看不出什么时，我会用strace跟踪一下dockerd进程的启动流程，看它到底读了什么配置文件、走了哪些系统调用、卡死在哪一步。

# 如果docker服务已经起不来，直接前台带debug跑 dockerd --debug # 或者用strace跟踪主进程的系统调用和文件读取顺序 strace -f -e trace=file dockerd --debug 2>&1 | tee /tmp/dockerd-strace.log

命令参数说明：-f是跟随子进程，因为dockerd会fork出多个goroutine对应的线程；-e trace=file只跟踪涉及文件访问的系统调用，避免刷出几万行乱七八糟的socket和connect记录；2>&1 | tee把标准错误输出同时打到屏幕和日志文件里，方便事后回看。排错时重点grep -E "conf|json|docker.sock" /tmp/dockerd-strace.log，你会立刻看到它依次读取了/etc/docker/daemon.json、/etc/systemd/system/docker.service环境变量文件等等，如果某个路径被写成中文引号或者带不可见字符，进程会在openat调用这里直接报ENOENT，一眼就能定位问题。

最后说一句：离线部署docker这事，80%的坑都出在tar解压、依赖解析、内核特性这几个土味环节上。与其在网上搜那些“一键安装脚本”，不如静下心把rpm和tar这两把刀磨利。装了这么多年docker，我最大的教训就是永远不要在解压前跳过文件清单检查，也永远不要在生产环境用--nodeps给自己埋雷。希望帮到你。

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