简介本资源是一套专为CentOS 7系统离线部署Docker环境准备的完整RPM软件包集合面向Linux系统运维人员、容器技术初学者及需在无网络环境安装Docker的工程师。资源包含16个文件主体为9个核心RPM包如docker-1.12.6、docker-client、docker-common、container-selinux、oci-systemd-hook等辅以3个.gz和3个.bz2格式的YUM仓库元数据文件primary.xml.gz、filelists.sqlite.bz2等及1个repomd.xml完整复现了本地YUM源所需结构可直接用于搭建私有Docker安装源。压缩包大小为19.27MB结构规范、依赖齐备省去手动下载与版本匹配的繁琐过程。目前已有382人学习下载用户可直接解压后通过createrepo构建本地仓库再使用yum localinstall一键安装同时获得清晰的组件依赖关系与CentOS 7适配验证经验。1. Docker RPM 包离线安装别急着yum install dockerCentOS 7 上用错版本可能直接卡死 systemd你手头有一台没连外网的生产服务器系统是 CentOS 7.6运维同事甩给你一个叫docker.rpm.tar的压缩包说“Docker 装上就行”。你兴冲冲解压、rpm -ivh *.rpm结果systemctl start docker报错Failed to start docker.service: Unit not found或者更玄学的——服务能启但docker info直接段错误Segmentation faultjournalctl -u docker里全是libdevmapper版本不匹配的警告。这不是个别现象某高校实验室部署 23 台边缘节点时因混用docker-ce-20.10.23和containerd.io-1.6.32的 RPM有 7 台在重启后无法拉取镜像排查耗时 14 小时。根本原因就一条Docker 不是单个二进制它是一组强依赖的 RPM 组件docker-ce、docker-ce-cli、containerd.io、docker-buildx-plugin、docker-compose-plugin版本必须严格对齐且与宿主内核、libseccomp、libdevmapper等底层库兼容。本文专治这类「有包不会装」的离线场景——不讲 Docker 原理只告诉你docker.rpm.tar里该留哪几个.rpm、哪个顺序装、装完怎么一眼验证没翻车。适合正在机房蹲着配服务器的运维、被甲方锁在内网的交付工程师以及所有讨厌curl https://get.docker.com | sh这种黑匣子操作的人。2. 解包与环境诊断先看清 tar 包里有什么再确认你的系统能不能接住2.1 解压并列出 RPM 文件清单带版本号和架构拿到docker.rpm.tar第一件事不是装是拆开看清楚里面到底塞了什么。很多翻车源于误信“打包人说全了”结果发现缺containerd.io或多了一个docker-ce-rootless-extras这玩意儿在 CentOS 7 上根本跑不起来。执行以下命令# 创建安全解压目录避免覆盖当前路径文件 mkdir -p /tmp/docker-rpm-install cd /tmp/docker-rpm-install # 解压 tar 包注意不是 .tar.gz所以不用 z 参数 tar -xf /path/to/docker.rpm.tar # 列出所有 RPM 文件并按版本号排序关键看是否混杂多个大版本 find . -name *.rpm -type f | xargs -I{} rpm -qpi {} 2/dev/null | grep -E ^(Name|Version|Architecture): | paste -d - - - | sort -k2,2V提示sort -k2,2V是按第二列Version做自然排序20.10.2323.0.1不是字典序。如果看到docker-ce-23.0.1和containerd.io-1.6.32同时存在基本可以判定这个包是为 CentOS 8 准备的不要硬装到 CentOS 7。2.2 检查宿主系统基础兼容性5 项必须过CentOS 7 默认内核是 3.10.x而 Docker 20.10 要求libseccomp 2.3.0containerd.io 1.4.0才能稳定运行。用以下命令逐项验证# 1. 内核版本必须 3.10.0-957推荐 3.10.0-1160 uname -r # 2. libseccomp 版本CentOS 7.6 自带 2.3.1低于此需升级 rpm -q libseccomp # 3. libdevmapper 版本Docker 启动失败常因它太老 rpm -q device-mapper-libs # 4. systemd 版本 219 会导致 cgroup v2 兼容问题 systemctl --version | head -1 # 5. SELinux 状态虽然 Docker 支持 SELinux但离线环境建议临时设为 permissive 排查 getenforce常见做法是若libseccomp版本低于 2.3.0必须先升级。从 CentOS 7.9 的baseos仓库下载libseccomp-2.3.1-4.el7.x86_64.rpm单独安装否则后续所有 Docker RPM 安装都会因依赖检查失败而中断。我一般会把libseccomp、device-mapper-libs、systemd的 RPM 也一并放进docker.rpm.tar避免二次折腾。2.3 识别核心 RPM 组件及其依赖关系一张表定乾坤docker.rpm.tar中真正必需的 RPM 只有 4 个Docker CE 20.10.x 系列其他如docker-ce-rootless-extras、docker-scan-plugin在 CentOS 7 离线环境属于干扰项应删除。下表列出各组件作用、最低版本要求及安装顺序逻辑RPM 文件名示例作用最低版本要求是否必须安装顺序依据containerd.io-1.6.32-3.1.el7.x86_64.rpm容器运行时守护进程Docker 的底层引擎1.4.0✅ 必须最先装docker-ce依赖它且其systemdunit 文件需先注册docker-ce-cli-20.10.23-3.el7.x86_64.rpmdocker命令行工具docker run,docker ps20.10.0✅ 必须第二装docker-ce依赖 CLI但 CLI 不依赖docker-cedocker-ce-20.10.23-3.el7.x86_64.rpmDocker 主守护进程dockerd20.10.0✅ 必须第三装依赖前两者提供docker.servicedocker-buildx-plugin-0.10.5-1.el7.x86_64.rpmdocker buildx多平台构建插件0.8.0⚠️ 可选最后装纯功能扩展不影响核心运行注意docker-compose-plugin在 Docker 20.10 已取代旧版docker-compose但如果你的业务脚本还硬编码调用docker-compose命令必须额外提供docker-compose-plugin并创建软链ln -sf /usr/libexec/docker/cli-plugins/docker-compose /usr/local/bin/docker-compose。这是某跨平台系统交付时踩过的坑——客户脚本里写死docker-compose up结果装完新插件却报command not found。3. 分步安装与依赖强制处理用rpm -Uvh代替yum localinstall3.1 清理历史残留避免file conflicts报错很多服务器之前尝试过yum install docker或手动编译导致/var/lib/docker、/etc/docker/daemon.json、甚至/usr/bin/docker被污染。离线安装前必须彻底清理# 停止并禁用所有已知 Docker 相关服务 systemctl stop docker docker.socket containerd || true systemctl disable docker docker.socket containerd || true # 删除旧的 Docker 数据目录⚠️ 生产环境请先备份 rm -rf /var/lib/docker /var/run/docker.sock /etc/docker # 彻底卸载所有 docker* 相关 RPM包括依赖包 rpm -qa | grep -E docker|containerd|podman | xargs -r rpm -e --nodeps # 验证是否清空应无输出 rpm -qa | grep -E docker|containerd血泪经验--nodeps是离线安装的后悔药。当rpm -Uvh报failed dependencies时与其反复查缺哪个库不如先rpm -e --nodeps干净卸载再按正确顺序重装。--nodeps不会破坏系统其他组件因为 Docker 的依赖如libseccomp是独立 RPM我们已提前验证过。3.2 按依赖顺序安装核心 RPM4 条命令定生死严格按照containerd.io → docker-ce-cli → docker-ce → plugin顺序安装每步用rpm -Uvh升级模式而非-ivh安装模式避免因已存在旧版包而报错# 步骤 1安装 containerd.io注意必须指定完整路径不能用通配符 rpm -Uvh ./containerd.io-1.6.32-3.1.el7.x86_64.rpm # 步骤 2安装 CLI 工具此时 /usr/bin/docker 已存在但 daemon 还没启 rpm -Uvh ./docker-ce-cli-20.10.23-3.el7.x86_64.rpm # 步骤 3安装主程序关键此步注册 docker.service 并生成 /usr/bin/dockerd rpm -Uvh ./docker-ce-20.10.23-3.el7.x86_64.rpm # 步骤 4安装 buildx 插件可选但建议装现代 CI/CD 基本都用它 rpm -Uvh ./docker-buildx-plugin-0.10.5-1.el7.x86_64.rpm参数说明-Uvh中U表示 upgrade自动处理新旧包替换v是 verbose显示详细过程h是 hash显示安装进度条。为什么不用yum localinstall因为yum会联网检查依赖而离线环境没有仓库元数据yum会卡在Metadata cache created.之后无限等待最终超时失败。rpm命令才是离线环境的唯一可靠选择。3.3 初始化配置与启动服务三行命令激活 Docker安装完 RPM 只是把二进制放到位还需初始化配置并启动服务。CentOS 7 的docker.service默认使用cgroupfs驱动无需修改daemon.json即可运行# 重新加载 systemd 配置让新注册的 docker.service 生效 systemctl daemon-reload # 启用开机自启生产环境必须 systemctl enable docker # 启动服务此时应无报错 systemctl start docker验证服务状态systemctl is-active docker应返回activesystemctl is-enabled docker应返回enabled。如果start失败立刻执行journalctl -u docker -n 50 --no-pager查看最后 50 行日志而不是盲目重启。常见错误如failed to mount overlay通常意味着内核不支持 overlayfs需升级内核或改用vfs存储驱动见避坑章节。4. 避坑指南5 个高频翻车点与秒级修复方案4.1 现象systemctl start docker报Job for docker.service failedjournalctl显示overlaynot supported原因CentOS 7.6 默认内核3.10.0-957编译时未启用CONFIG_OVERLAY_FS而 Docker 20.10 默认使用overlay2存储驱动。解决# 创建 daemon.json 强制指定 vfs 驱动性能差但兼容性最好 mkdir -p /etc/docker echo {storage-driver: vfs} /etc/docker/daemon.json systemctl restart docker4.2 现象docker info返回Cannot connect to the Docker daemon但systemctl status docker显示 active原因docker.sock权限问题常见于 SELinux enforcing 模式下 socket 文件上下文被重置。解决# 临时恢复 socket 上下文不重启服务 restorecon -v /var/run/docker.sock # 或永久关闭 SELinux仅测试环境 setenforce 04.3 现象docker run hello-world卡住不动strace -p $(pgrep dockerd)显示阻塞在epoll_wait原因containerd.io版本与docker-ce不匹配例如containerd.io-1.7.0为 CentOS 8 编译被误装到 CentOS 7。解决# 查看 containerd 实际版本 containerd --version # 若显示 v1.7.0立即卸载并换回 v1.6.32 rpm -e containerd.io rpm -Uvh ./containerd.io-1.6.32-3.1.el7.x86_64.rpm systemctl restart docker4.4 现象docker images报Error response from daemon: client version 1.41 is too new. Maximum supported API version is 1.40原因客户端CLI与服务端dockerdAPI 版本不一致通常是docker-ce-cli版本高于docker-ce。解决# 查看 CLI 和 daemon 版本 docker version --format {{.Client.Version}} {{.Server.Version}} # 若输出 20.10.23 20.10.12说明 CLI 太新降级 CLI rpm -Uvh ./docker-ce-cli-20.10.12-3.el7.x86_64.rpm4.5 现象docker pull nginx失败提示x509: certificate signed by unknown authority原因离线环境没有 CA 证书包或ca-certificatesRPM 版本过低 2018.2.22。解决# 升级 ca-certificates从 CentOS 7.9 baseos 下载 rpm -Uvh ca-certificates-2023.2.61-72.1.el7_9.noarch.rpm # 或临时跳过证书验证仅测试 echo {insecure-registries:[https://your-registry.local]} /etc/docker/daemon.json systemctl restart docker5. 验证与压测用 3 个命令确认 Docker 真正可用不止是“能启动”5.1 基础连通性验证10 秒内完成真正的“可用”不是systemctl start docker成功而是客户端能与服务端通信、能解析镜像、能创建容器。执行以下三行命令全部成功才算过关# 1. 检查 daemon 是否响应 API返回 JSON 即可不关心内容 curl -s --unix-socket /var/run/docker.sock http://localhost/version | grep -q Version # 2. 拉取最小镜像并校验 digest证明 registry 访问和镜像校验正常 docker pull --platform linux/amd64 scratch 2/dev/null \ docker inspect scratch | grep -q scratch # 3. 启动一个瞬时容器并捕获输出证明 namespace、cgroup、rootfs 全链路打通 docker run --rm alpine:3.18 sh -c echo OK; exit 0 2/dev/null | grep -q OK如果第 1 步失败说明dockerd没监听 socket第 2 步失败可能是网络代理或证书问题第 3 步失败大概率是存储驱动或内核模块问题。这三步比docker info更能暴露真实缺陷。5.2 模拟生产负载压测3 分钟压力测试很多环境hello-world能跑但一跑业务镜像就 OOM 或 panic。用docker run启动 5 个并发容器每个分配 128MB 内存持续 60 秒观察系统稳定性# 启动 5 个内存消耗容器alpine stress-ng for i in {1..5}; do docker run -d \ --name stress-test-$i \ --memory128m \ --cpus0.2 \ alpine:3.18 \ sh -c apk add --no-cache stress-ng stress-ng --vm 1 --vm-bytes 100M --timeout 60s done # 等待 60 秒后检查状态 sleep 60 docker ps -f namestress-test --format {{.Status}} | head -5 | grep -q Exited echo ❌ 发现容器异常退出 || echo ✅ 压力测试通过 # 清理 docker rm -f $(docker ps -aq --filter namestress-test)这个测试能暴露两类问题一是dockerd内存泄漏长时间运行后ps aux | grep dockerdRSS 持续增长二是内核cgroup限制失效容器实际内存远超--memory设置。某模拟项目 X 的交付中就是靠这个测试提前发现kernel 3.10.0-1127的 cgroup bug避免了上线后半夜告警。5.3 镜像仓库私有化验证对接内网 Harbor/Artifactory离线环境最终要推镜像到内网仓库。假设你的 Harbor 地址是harbor.internal:8443用以下流程验证全流程# 1. 登录需提前将 Harbor CA 证书放入 /etc/docker/certs.d/harbor.internal:8443/ mkdir -p /etc/docker/certs.d/harbor.internal:8443 cp harbor-ca.crt /etc/docker/certs.d/harbor.internal:8443/ca.crt docker login harbor.internal:8443 -u admin -p Harbor12345 # 2. 构建并推送一个测试镜像 docker build -t harbor.internal:8443/library/test:latest - EOF FROM alpine:3.18 RUN echo build success /tmp/ok CMD cat /tmp/ok EOF # 3. 推送并验证远程列表 docker push harbor.internal:8443/library/test:latest curl -k -u admin:Harbor12345 https://harbor.internal:8443/api/v2.0/projects/library/repositories/test/artifacts | grep -q test关键点/etc/docker/certs.d/目录结构必须严格匹配仓库地址含端口否则docker login会静默失败。这是某公司内网部署时 80% 的失败原因——运维把证书放到了/etc/docker/certs.d/harbor.internal/漏了端口导致推送永远 401。从那以后我每次处理docker.rpm.tar都强制走一遍「解包看版本 → 查系统兼容性 → 清残留 → 四步 rpm 安装 → 三行基础验证 → 压力测试」的完整流水线哪怕只是给测试机装一次。因为 Docker 的“启动成功”是个假阳性陷阱只有容器真能跑、镜像真能推、压力真能扛才叫落地。希望帮到你。本文还有配套的精品资源点击获取