离线环境安装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/*.rpmyum 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文件布局和二进制解压包有很明显的差异理解这些差异你就知道出问题时该去看哪个目录的日志。路径作用出现阶段/usr/bin/dockerdocker主程序CLIdocker-ce-cli包安装后/usr/bin/dockerddocker守护进程二进制docker-ce包安装后/usr/bin/containerdcontainerd容器运行时containerd.io包安装后/var/lib/docker/docker默认数据目录dockerd首次启动时自动创建/etc/docker/daemon.jsondocker主配置文件需手动创建/lib/systemd/system/docker.servicesystemd服务脚本docker-ce包自动生成用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-driverrpm安装的docker-ce在CentOS 7上默认存储驱动是devicemapper这是个性能瓶颈明显的旧方案在新版本内核里尤其吃亏。装完第一件事就是手动创建/etc/docker/daemon.json把存储驱动切到overlay2。如果在安装时没配这一步很多机器启动后跑几个容器就会出现“failed to mount overlay”的内核报错极其折腾。{ exec-opts: [native.cgroupdriversystemd], 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.cgroupdriversystemd是给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 dockerenable只创建符号链接把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拷贝到LinuxFAT32格式下的文件可能被截断或者拷贝时缓存未刷新就拔盘。另外如果包是在Windows上用压缩软件压的解压到Linux时也容易出现路径分隔符导致的内层嵌套问题。解决重新用md5sum校验整个tar包的完整性再换一种方式传输。如果手头没有校验值来源可以尝试直接看包尾部的日志# 查看tar包压缩方式和损坏情况gzip包会有明显报错 gzip -t docker.rpm.tar echo gzip校验通过 file docker.rpm.tarfile命令会识别出这是“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让它走本地依赖解析器如果本地包里恰好还有更新的libseccompyum会自动帮你升级它再装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文件系统格式化时如果不带ftype1参数d_type支持就是关闭的。overlay2驱动会拒绝在这种文件系统上工作。解决# 先查当前docker数据目录所在文件系统的挂载参数 findmnt -n -o FSTYPE,OPTIONS /var/lib/docker # 如果是xfs且没有ftype1需要重新格式化务必先备份数据 mkfs.xfs -n ftype1 /dev/sdb1 vim /etc/fstab # 确认挂载参数包含 pquotafindmnt输出里如果看到rw,seclabel,relatime这样的默认参数没有ftype1那事情就大了。重新格式化能解决但代价是数据清空所以这个坑的最佳处理方式是前移在解压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 tracefile dockerd --debug 21 | tee /tmp/dockerd-strace.log命令参数说明-f是跟随子进程因为dockerd会fork出多个goroutine对应的线程-e tracefile只跟踪涉及文件访问的系统调用避免刷出几万行乱七八糟的socket和connect记录21 | 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给自己埋雷。希望帮到你。本文还有配套的精品资源点击获取