★ FEATURED ARTICLE 简介本资源是一套专为CentOS 7系统离线部署Docker 1.12.6版本定制的完整RPM依赖包集合面向Linux系统运维人员、容器技术初学者及受限网络环境下的企业IT工程师解决无外网YUM源时无法直接安装Docker的核心痛点。压缩包共16个文件包含9个核心RPM包如docker、docker-client、docker-common、container-selinux、oci-systemd-hook等、3个.gz格式元数据文件primary.xml.gz、filelists.xml.gz、other.xml.gz及3个.bz2格式SQLite索引文件辅以repomd.xml构成可本地构建YUM仓库的完整结构总大小19.27MB。已有382人学习下载用户可直接解压后通过createrepo命令快速搭建本地Docker安装源避免逐一手动解决依赖冲突包内已预集成SELinux策略、OCI运行时钩子及容器存储配置工具显著降低离线环境部署门槛与排错成本。1. 这不是 Docker 官方安装包docker.rpm.tar是个被反复打包的“压缩套娃”专治 CentOS/RHEL 系统离线部署焦虑你手头拿到一个叫docker.rpm.tar的文件名字像 Docker 安装包但后缀又不是.rpm——它其实是个「tar 打包的 RPM 集合」常见于内网环境、信创服务器或无法直连互联网的生产集群。它不提供 Docker CLI 或 daemon 的源码也不含构建逻辑而是把docker-ce-cli、containerd.io、docker-ce、docker-ce-rootless-extras等多个 RPM 包预先打成 tar 归档省去逐个下载、校验、依赖解析的麻烦。适合某高校实验室批量部署 20 台国产化服务器也适合某公司金融核心区的离线测试环境快速拉起容器运行时。但它不是开箱即用的“一键安装器”没有自动依赖解决、不校验 GPG 签名、不处理 systemd 单元冲突、不清理旧版残留——这些都得你手动补全。如果你正对着tar -xvf docker.rpm.tar解压完一堆.rpm文件却卡在error: Failed dependencies上说明你已经踩进这个“看似简单、实则埋雷”的离线部署黑匣子了。本文就带你一层层拆开这个docker.rpm.tar从解包、校验、安装到验证把每一步的参数、顺序、报错信号都落到具体命令和日志上。2. 拆包与结构识别先看清里面到底装了哪些 RPM、版本是否匹配系统架构拿到docker.rpm.tar第一反应不该是rpm -ivh而是先确认它“装了什么、能不能用”。很多翻车案例源于没看清包名里藏着的架构陷阱比如 x86_64 包误用于 aarch64 服务器或版本越界如docker-ce-24.0.0强行装在内核 3.10 的 CentOS 7 上。这步必须做且不能跳过。2.1 解压并列出 RPM 文件清单带架构与版本提取# 创建安全解压目录避免污染当前路径 mkdir -p ./docker-rpm-pkgs cd ./docker-rpm-pkgs # 解压 tar 包注意不是所有 tar 都用 -xvf有些含 gzip 压缩需 -xvzf tar -xvf ../docker.rpm.tar # 列出所有 .rpm 文件并用 rpm -qpi 提取关键元数据需 rpm 工具已安装 for rpm in *.rpm; do echo $rpm rpm -qpi $rpm 2/dev/null | grep -E ^(Name|Version|Release|Architecture|Build Date|Vendor) echo done | tee rpm_inventory.log逻辑说明rpm -qpi读取 RPM 包头信息不安装即可获知 Name如docker-ce、Version如24.0.7、Architecture必须为x86_64或aarch64与目标机uname -m严格一致、Build Date判断是否过旧、Vendor确认是否来自 Docker Inc. 或国内镜像站二次打包。参数说明2/dev/null屏蔽无权限读取警告grep -E仅提取关键字段避免冗长描述干扰判断tee同时输出到终端和日志文件便于后续回溯。2.2 架构与系统兼容性交叉验证三步必查光看 RPM 名字不够必须做三重校验校验项检查命令合格标准不合格后果目标机 CPU 架构uname -m输出x86_64或aarch64若为i386/i686所有x86_64RPM 将拒绝安装RPM 包架构一致性rpm -qp --queryformat %{ARCH}\n *.rpm | sort -u仅输出一行且与uname -m完全相同混合架构如同时含x86_64和noarch可接受但若出现i686则整包作废系统发行版与内核版本cat /etc/redhat-releaseuname -rCentOS 7内核 ≥3.10、CentOS 8/Stream≥4.18、Rocky/AlmaLinux 8≥4.18CentOS 6 或内核 3.10 的机器无法运行docker-ce-20.10会报kernel too old# 一行命令完成三重校验建议复制执行 echo 【系统架构】$(uname -m) \ echo 【RPM 架构】$(rpm -qp --queryformat %{ARCH}\n *.rpm 2/dev/null | sort -u) \ echo 【OS 版本】$(cat /etc/redhat-release 2/dev/null \| head -n1) \ echo 【内核版本】$(uname -r)为什么必须做某导师在某高校信创实验室曾用docker.rpm.tar含aarch64包部署到 x86_64 服务器rpm -ivh直接报package docker-ce-24.0.7-1.el8.aarch64 is intended for a different architecture耗时 2 小时排查才意识到解压前没看架构。血泪经验解压即校验校验不过不进下一步。2.3 RPM 依赖图谱生成可视化缺失依赖docker-ce不是单体包它强依赖containerd.io、runc、iptables、libseccomp等。docker.rpm.tar通常已打包全部依赖 RPM但顺序错乱或版本不匹配仍会导致安装失败。用rpm -qpR提取每个 RPM 的 Requires 字段再用sort | uniq -c统计缺失项# 提取所有 RPM 的依赖列表过滤掉系统基础库聚焦 Docker 生态 for rpm in *.rpm; do rpm -qpR $rpm 2/dev/null | grep -E (docker|containerd|runc|libseccomp|iptables|pigz|fuse-overlayfs) || true done | sort | uniq -c | sort -nr | head -20 dependency_summary.txt # 查看统计结果 cat dependency_summary.txt输出示例10 containerd.io 1.6.0 8 runc 1.1.0 5 libseccomp 2.3.0 3 iptables 1.4.21这说明containerd.io是最高频依赖若docker.rpm.tar中containerd.io版本低于1.6.0则docker-ce必然安装失败。此时需检查containerd.ioRPM 的Version是否达标见 2.1 步骤不达标则需替换对应 RPM。3. 安装策略选择rpm -ivh强制安装 vsyum localinstall智能依赖解析docker.rpm.tar解压后是一堆孤立 RPM 文件安装方式决定成败。新手常直接rpm -ivh *.rpm结果因依赖顺序错误而中断老手倾向yum localinstall但需确认本地 yum repo 配置是否干扰。这里必须讲清两种方式的适用边界、参数细节和 fallback 方案。3.1rpm -ivh手动安装精准控制但需严格排序这是最底层、最可控的方式适用于① 系统无网络、无 yum 源② 需跳过特定依赖如已有新版iptables不想降级③ 排查具体哪个 RPM 导致失败。但必须按依赖拓扑排序安装否则Failed dependencies报错不可避免。# 生成依赖排序列表基于 rpm -qpR 分析人工确认后执行 # 实际顺序应为containerd.io → runc → libseccomp → docker-ce-cli → docker-ce rpm -ivh containerd.io-1.6.28-3.1.el8.x86_64.rpm rpm -ivh runc-1.1.12-1.el8.x86_64.rpm rpm -ivh libseccomp-2.5.4-1.el8.x86_64.rpm rpm -ivh docker-ce-cli-24.0.7-1.el8.x86_64.rpm rpm -ivh docker-ce-24.0.7-1.el8.x86_64.rpm参数说明-iinstall-vverbose显示详细过程-hhash marks进度条关键技巧加--nodeps可跳过依赖检查仅调试用生产禁用加--force可覆盖已存在文件慎用可能破坏旧服务为什么顺序重要docker-ce的%post脚本会调用containerd命令若containerd.io未安装docker-ce安装虽成功但服务无法启动。3.2yum localinstall自动解析推荐主力方案但需规避 repo 冲突yum localinstall会自动读取 RPM 头部的Requires并尝试从已配置的 yum 源中补全缺失依赖。对docker.rpm.tar这种“全量打包”场景它能自动忽略已存在的依赖只安装 tar 包内 RPM是最省心的选择——前提是你的系统没有启用会干扰的第三方 repo如 epel、docker-ce-stable。# 临时禁用所有非 base repo只留本地文件系统作为源 yum --disablerepo* --enablerepobaseos,appstream localinstall *.rpm -y # 或更稳妥创建临时 repo 指向当前目录推荐 cat /etc/yum.repos.d/docker-local.repo EOF [docker-local] nameDocker Local RPMs baseurlfile:///root/docker-rpm-pkgs enabled1 gpgcheck0 repo_gpgcheck0 EOF yum clean all yum makecache yum install docker-ce docker-ce-cli containerd.io -y逻辑说明--disablerepo*关闭所有远程源避免yum试图从互联网下载containerd.io而非使用 tar 包内版本file://协议让 yum 把当前目录当成本地仓库yum install会自动解析依赖并安装指定包名而非通配符*.rpm更符合生产习惯。注意gpgcheck0是因为docker.rpm.tar内 RPM 通常未签名或签名密钥未导入强行校验会失败。3.3 安装后服务初始化systemctl daemon-reload不是可选项即使rpm -ivh或yum install显示Complete!Docker 服务也不会自动启动。docker-ceRPM 的%post脚本会安装/usr/lib/systemd/system/docker.service但 systemd 缓存未刷新systemctl start docker会报Unit docker.service not found。# 必须执行的三连缺一不可 systemctl daemon-reload # 重新加载 unit 文件 systemctl enable docker # 设置开机自启写入 /etc/systemd/system/multi-user.target.wants/ systemctl start docker # 启动服务 # 验证状态 systemctl is-active docker # 应返回 active systemctl is-enabled docker # 应返回 enabled为什么强调daemon-reload某公司金融区部署时运维同学跳过此步docker version报Cannot connect to the Docker daemon排查 1 小时才发现systemctl list-unit-files | grep docker为空——根本没加载 service 文件。daemon-reload是 systemd 的“刷新缓存”操作和source ~/.bashrc类似不能省。4. 避坑五个高频翻车点与现场急救命令docker.rpm.tar部署中最容易在最后一步功亏一篑。下面五条全是真实血泪记录按“现象→原因→解决”结构整理每条都附可直接粘贴的诊断命令。4.1 现象docker version报Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?原因dockerd进程未启动或启动失败后静默退出。常见于containerd未正确安装、/var/run/docker.sock权限错误、SELinux 拦截。解决# 查看 docker 服务真实状态非 systemctl is-active systemctl status docker -l # 若显示 failed看 containerd 是否在运行 systemctl status containerd # 若 containerd 也 failed检查其日志 journalctl -u containerd -n 50 --no-pager # 常见修复重启 containerd 再启 docker systemctl restart containerd systemctl start docker4.2 现象systemctl start docker卡住不动journalctl -u docker显示levelinfo msgStarting up后无下文原因dockerd启动时默认等待containerd就绪但containerd因配置错误如/etc/containerd/config.toml不存在或语法错无法启动形成死锁。解决# 手动启动 containerd 并查看实时日志 containerd --config /etc/containerd/config.toml --log-level debug # 若报 config.toml 不存在生成默认配置 containerd config default /etc/containerd/config.toml # 重启 containerd systemctl restart containerd4.3 现象docker run hello-world报Error response from daemon: failed to create endpoint... no such file or directory原因docker-ceRPM 安装时未正确创建/var/lib/docker目录或该目录属主不是root:root导致存储驱动如 overlay2初始化失败。解决# 检查目录是否存在及权限 ls -ld /var/lib/docker # 若不存在或权限错手动创建并赋权 mkdir -p /var/lib/docker chown root:root /var/lib/docker chmod 700 /var/lib/docker # 重启 dockerd不重启 containerd systemctl restart docker4.4 现象yum install docker-ce提示Package docker-ce-24.0.7-1.el8.x86_64.rpm is not signed原因RPM 包未签名而系统gpgcheck1强制校验。docker.rpm.tar中的包多为构建机直接打包无 GPG 签名。解决# 临时关闭 gpgcheck仅本次安装 yum install --nogpgcheck docker-ce docker-ce-cli containerd.io -y # 或永久关闭修改 /etc/yum.repos.d/ 下相关 repo 的 gpgcheck0 sed -i s/gpgcheck1/gpgcheck0/g /etc/yum.repos.d/docker-local.repo4.5 现象docker info显示WARNING: bridge-nf-call-iptables is disabled和WARNING: bridge-nf-call-ip6tables is disabled原因内核模块br_netfilter未加载或 sysctl 参数未开启导致 Docker 网络桥接失效容器间无法通信。解决# 加载模块并写入开机加载 modprobe br_netfilter echo br_netfilter /etc/modules-load.d/docker.conf # 开启 netfilter 参数 cat /etc/sysctl.d/docker.conf EOF net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 EOF sysctl --system # 重启 docker systemctl restart docker5. 验证与加固用docker system info和hello-world完成闭环再加一道 SELinux 安全锁安装完成不等于可用。必须通过docker system info获取完整运行时上下文再用hello-world镜像验证拉取、运行、清理全流程。更重要的是在 CentOS/RHEL 系统上SELinux 默认策略会拦截 Docker 的部分操作如挂载宿主机目录必须显式放行否则后续docker run -v会静默失败。5.1 全维度运行时验证不只是docker versiondocker version只验证客户端和服务端进程存在docker system info才暴露真实健康状况。重点关注以下字段字段正常值示例异常信号诊断命令Server Version24.0.7空或unknowndocker version --format {{.Server.Version}}Storage Driveroverlay2vfs性能极差或空docker info | grep Storage DriverKernel Version4.18.0-477.13.1.el8_8.x86_64低于3.10CentOS 7或4.18RHEL 8docker info | grep Kernel VersionOperating SystemCentOS Linux 8 (Core)显示Unknown或Red Hat Enterprise Linux版本错docker info | grep Operating SystemSecurity Optionsseccompselinux缺少selinux表示未启用docker info | grep Security Options# 一键获取关键字段生产环境建议保存为 check-docker.sh docker system info 2/dev/null | awk /Server Version|Storage Driver|Kernel Version|Operating System|Security Options/ {print}为什么必须看Security Options某跨平台系统在 RHEL 8 上部署时docker info显示Security Options: seccomp但无selinux导致后续挂载/etc/localtime进容器时报Permission denied。根源是 SELinux 策略未加载需执行 5.2 步骤。5.2 SELinux 策略加载与容器挂载验证绕过chcon的硬核方案RHEL/CentOS 默认启用 SELinuxDocker 容器进程默认标签为system_u:system_r:container_t:s0但挂载宿主机目录时若目录 SELinux 上下文不是svirt_sandbox_file_t就会被拒绝。手动chcon治标不治本正确做法是加载container-selinux策略包并设置布尔值。# 检查 container-selinux 是否已安装docker.rpm.tar 通常不含此包 rpm -qa | grep container-selinux # 若未安装从 EPEL 或官方源获取此处以 EPEL 为例 yum install epel-release -y yum install container-selinux -y # 启用关键布尔值允许容器读写宿主机文件 setsebool -P container_manage_cgroup on setsebool -P container_use_cephfs on setsebool -P container_use_fusefs on # 验证挂载功能创建测试目录并挂载 mkdir -p /tmp/test-mount echo test content /tmp/test-mount/hello.txt docker run --rm -v /tmp/test-mount:/mnt alpine cat /mnt/hello.txt输出应为test content。若报Permission denied说明 SELinux 策略未生效需检查sestatus是否为enabled以及getsebool container_manage_cgroup是否为on。5.3hello-world全流程压测模拟真实镜像生命周期很多教程只跑一次docker run hello-world就算结束但实际生产中镜像拉取、存储、运行、清理任一环节出问题都会导致故障。用以下脚本模拟完整生命周期#!/bin/bash # save as test-docker-lifecycle.sh set -e # 任一命令失败即退出 echo 【1/4】拉取 hello-world 镜像... docker pull hello-world echo 【2/4】运行容器并捕获输出... OUTPUT$(docker run --rm hello-world 21) if [[ $OUTPUT *Hello from Docker!* ]]; then echo ✅ 拉取与运行成功 else echo ❌ 运行输出异常: $OUTPUT exit 1 fi echo 【3/4】检查镜像是否存在于本地... if docker images | grep -q hello-world; then echo ✅ 镜像已缓存 else echo ❌ 镜像未缓存 exit 1 fi echo 【4/4】清理所有停止容器和 dangling 镜像... docker container prune -f docker image prune -f echo ✅ 生命周期测试完成 # 最终验证确保无残留容器 docker ps -a | grep -q hello-world (echo ⚠️ 发现残留容器 exit 1) || echo ✅ 无残留执行命令chmod x test-docker-lifecycle.sh ./test-docker-lifecycle.sh为什么需要-e和set -e这是工程师的后悔药。某图像处理 Demo 在自动化部署脚本中漏了set -edocker pull失败后脚本继续执行docker run报错信息被淹没最终定位耗时 4 小时。加set -e让失败立即暴露是离线部署的第一道防线。从那以后我每次用docker.rpm.tar部署新环境都强制走一遍test-docker-lifecycle.sh哪怕只是单台测试机。它不保证 100% 无坑但能把 90% 的低级错误挡在上线前。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
