Docker离线环境依赖包安装完整指南

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

简介：Docker是Linux系统下广泛使用的容器化技术，可将应用及其依赖打包至可移植容器中，实现高效部署与虚拟化。本文详细讲解在无网络环境下如何安装Docker及其依赖包，适用于RHEL/CentOS等使用RPM包管理的系统。通过在联网机器下载RPM依赖包，传输至目标主机并配置本地yum源，用户可完成Docker的离线安装、服务启动与自启设置。本教程涵盖从准备依赖、创建本地仓库到最终验证运行的全流程，帮助用户在隔离环境中成功部署Docker。

1. Docker容器化技术的核心价值与离线部署背景

Docker的核心价值与架构简析

Docker通过 容器运行时（containerd） 、 镜像分层存储 和 命名空间/控制组（Namespaces/Cgroups） 实现进程级隔离，将应用及其依赖打包为可移植的镜像。这种“一次构建，处处运行”的特性极大提升了开发、测试与运维的一致性。

离线部署的现实挑战

在金融、军工等高安全场景中，生产服务器常处于 物理隔离内网 ，无法访问互联网。传统的 yum install docker-ce 依赖在线仓库元数据（repodata），此时完全失效。

离线安装的技术路径选择

必须借助 RPM 包管理机制 实现离线部署。关键在于预先获取完整依赖树（如 docker-ce 、 containerd.io 、 libcgroup 等），并通过本地 YUM 源模拟在线安装行为，确保操作系统层级依赖兼容。这为后续章节的实操奠定理论基础。

2. 离线安装Docker的技术路径与依赖解析

在企业级IT基础设施中，Docker的部署往往面临复杂的网络环境限制。尤其是在金融、军工、能源等对安全性要求极高的行业场景下，生产服务器通常被置于物理隔离或逻辑隔离的内网环境中，无法直接访问互联网。这种“空气隔离”（Air-Gapped）架构虽然提升了系统安全性，但也带来了软件部署方式的根本性转变——从在线拉取到离线交付。因此，理解如何在无外网连接的前提下完成Docker的完整安装，不仅是一项运维技能，更是构建可审计、可追溯、可复制的标准化交付流程的核心能力。

本章将深入剖析离线安装Docker的技术实现路径，重点围绕其底层依赖关系展开分析。不同于简单的RPM包拷贝与安装操作，真正的离线部署必须解决组件依赖树的完整性问题。Docker并非单一二进制程序，而是由多个相互关联的软件包构成的复杂系统，包括容器运行时、命令行工具、镜像管理服务以及操作系统级别的支撑模块。若忽略这些依赖项，即使主程序看似安装成功，也可能在启动时因缺少关键库文件或策略配置而失败。为此，必须掌握RPM包管理系统的工作机制，特别是 yum 如何通过元数据自动解析并满足依赖链。

此外，技术选型也直接影响部署效率与维护成本。例如，在批量部署数百台边缘节点的云边协同架构中，是否采用本地YUM源代替手动逐台安装？是否需要锁定特定版本以避免升级冲突？这些问题都需要基于对Docker组件结构和包管理原理的深刻理解来回答。接下来的内容将从实际应用场景出发，逐步拆解Docker CE的依赖体系，并结合Linux系统层面对包管理器的行为进行机制级解读，为后续章节中的自动化打包与本地仓库搭建提供理论依据。

2.1 离线部署的应用场景与技术选型

离线部署并非一种权宜之计，而是在特定业务需求和技术约束下形成的标准化实践模式。它广泛应用于高安全等级网络、物理隔离系统以及大规模边缘计算节点的统一管控中。每种场景都有其独特的限制条件和目标诉求，决定了最终的技术实现路径和工具选择策略。

2.1.1 高安全等级网络环境中的限制条件

在金融、政府、国防等领域，核心业务系统的服务器普遍运行于封闭内网中，严禁任何形式的外部网络接入。这类环境遵循严格的《信息安全等级保护制度》（等保2.0），要求所有软件变更必须经过审批、验证和签名认证，杜绝未经审核的代码流入生产系统。在此背景下，传统的 yum install docker-ce 命令完全失效，因为YUM默认会尝试连接远程仓库（如 https://download.docker.com/linux/centos/ ）下载元数据和RPM包。

更进一步地，某些单位甚至禁用了DNS解析功能，仅允许基于IP白名单的内部通信。这意味着即便是搭建代理服务器缓存远程内容，也需要额外的安全评估流程。因此，最稳妥的做法是提前在外网可达的“跳板机”上准备好所有必需的RPM包及其依赖项，通过光盘、U盘或内部文件共享服务传输至目标主机，再利用本地YUM源完成安装。

该过程的关键挑战在于 依赖完整性保障 。例如，仅下载 docker-ce-24.0.5-1.el7.x86_64.rpm 是远远不够的，它依赖于 docker-ce-cli 、 containerd.io 、 libcgroup 等多个子包。任何一个缺失都会导致安装中断。因此，必须借助包管理工具预先递归获取整个依赖树，并确保所有RPM包版本兼容。

安全级别	网络状态	典型部署方式	工具链要求
一级（涉密）	完全断网	物理介质传输 + 本地repo	createrepo, rpm-sign
二级（重要）	内网隔离，无公网出口	内部NFS/Samba共享	yum-utils, rsync
三级（一般）	可访问私有镜像站	私有Harbor + 本地缓存	Harbor CLI, skopeo

flowchart TD
    A[发起安装请求] --> B{是否允许外网访问?}
    B -- 是 --> C[执行 yum install docker-ce]
    B -- 否 --> D[检查本地是否存在RPM包]
    D -- 存在 --> E[搭建本地YUM源]
    D -- 不存在 --> F[从镜像主机导出RPM包]
    F --> G[yumdownloader --resolve]
    G --> H[校验sha256sum]
    H --> I[复制至目标机器]
    I --> E
    E --> J[yum install docker-ce --nogpgcheck]
    J --> K[启动Docker服务]

上述流程图清晰展示了离线部署的整体决策路径。可以看出，无论起点如何，最终都收敛到“本地YUM源+强制GPG校验绕过”的安装模式。这说明技术选型的本质是对 可控性与安全性之间平衡点的把握 。

2.1.2 物理隔离服务器与云边协同架构需求

随着边缘计算的发展，越来越多的企业开始构建“中心云—区域云—边缘节点”的三级架构。其中，边缘设备往往部署在工厂车间、变电站、基站等偏远位置，不具备稳定公网连接能力，但又需要运行容器化应用以支持AI推理、实时监控等功能。

在这种云边协同架构中，Docker成为统一运行时的标准选择。然而，由于边缘节点数量庞大且地理位置分散，若采用手工方式逐台安装Docker，不仅效率低下，还极易出现版本不一致的问题。例如，某次安全补丁发布后，若只更新了部分节点，可能导致跨节点容器编排失败。

因此，必须建立一套 可复用、可版本化、可自动化 的离线安装方案。理想情况下，应能通过Ansible、SaltStack等配置管理工具，结合本地YUM源，实现一键推送安装。这就要求：

1. 所有RPM包集中存储在一个标准目录下；
2. 每个包附带版本号和哈希值清单；
3. 支持增量更新与回滚机制；
4. 提供脚本化安装入口。

为此，推荐使用如下目录结构组织离线包：

/opt/docker-offline/
├── rpm/
│   ├── docker-ce-24.0.5-1.el7.x86_64.rpm
│   ├── docker-ce-cli-24.0.5-1.el7.x86_64.rpm
│   ├── containerd.io-1.6.21-1.el7.x86_64.rpm
│   └── ...
├── repodata/
│   ├── primary.xml.gz
│   ├── filelists.xml.gz
│   └── ...
├── scripts/
│   └── install-docker-offline.sh
└── SHA256SUMS

该结构便于集成CI/CD流水线，也可作为Ansible playbook的资源目录直接调用。

2.1.3 企业级批量部署对可重复性的要求

在大型数据中心中，成百上千台服务器需要统一安装Docker引擎。此时，“一次成功”不再是唯一目标，更重要的是 部署动作的可重复性与一致性 。所谓可重复性，是指无论何时何地执行相同流程，结果都应保持一致；一致性则强调所有节点上的软件版本、配置参数、依赖关系完全相同。

为了达成这一目标，必须摒弃“凭经验操作”的传统做法，转而采用声明式配置方法。具体而言：

• 使用 yumdownloader --resolve 命令确保每次获取的依赖包集合完整且固定；
• 锁定Docker CE的具体版本号（如 docker-ce-24.0.5 ），避免因仓库更新导致意外升级；
• 对所有RPM包进行SHA256校验，防止传输过程中损坏或篡改；
• 编写幂等性安装脚本，支持多次执行而不产生副作用。

以下是一个典型的批量部署准备脚本示例：

#!/bin/bash
# prepare-offline-pkgs.sh

REPO_DIR="/opt/docker-offline/rpm"
DOCKER_VERSION="24.0.5"

# 添加官方Docker仓库
cat > /etc/yum.repos.d/docker.repo << 'EOF'
[docker-ce-stable]
name=Docker CE Stable - $basearch
baseurl=https://download.docker.com/linux/centos/7/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
EOF

# 安装yum-utils用于下载工具
yum install -y yum-utils

# 清除旧缓存
yum clean all

# 递归下载Docker CE及其全部依赖
yumdownloader --resolve --destdir=$REPO_DIR docker-ce-$DOCKER_VERSION

# 生成校验码清单
cd $REPO_DIR
sha256sum *.rpm > ../SHA256SUMS

echo "离线包准备完成，共 $(ls *.rpm | wc -l) 个RPM文件"

代码逻辑逐行解读 ：

• 第6行：定义RPM包存储路径，便于后续统一管理；
• 第7行：明确指定Docker版本号，防止自动获取最新版造成不一致；
• 第10–18行：写入Docker官方仓库配置，确保能正确识别远程元数据；
• 第21行：安装 yum-utils ，其中包含 yumdownloader 工具；
• 第24行：清理本地YUM缓存，避免旧数据干扰；
• 第27行： --resolve 参数触发依赖解析，自动下载所有必需包；
• 第30–31行：生成SHA256校验文件，用于后期完整性验证；
• 最终输出统计信息，便于人工确认。

该脚本体现了企业级部署的核心思想： 一切皆可编码、可验证、可审计 。通过将原本分散的手动步骤封装为自动化流程，极大降低了人为错误风险，并为后续的持续集成奠定了基础。

2.2 Docker CE的组件构成与依赖树分析

Docker Community Edition（CE）并不是一个孤立的可执行文件，而是一套由多个RPM包组成的软件栈。每个组件承担不同的职责，彼此之间通过严格的依赖关系耦合在一起。要实现成功的离线安装，必须全面掌握这些组件的功能定位及它们之间的依赖层级。

2.2.1 主要RPM包清单：docker-ce、docker-ce-cli、containerd.io

Docker CE的核心安装包主要包括以下三个：

RPM包名称	功能描述	是否必需
docker-ce	Docker守护进程（dockerd）及核心服务	是
docker-ce-cli	Docker命令行客户端（docker binary）	是
containerd.io	容器运行时，负责镜像管理、容器生命周期控制	是

其中， docker-ce 是主程序包，包含 dockerd 守护进程，负责监听API请求、管理容器网络和存储卷。 docker-ce-cli 提供用户交互接口，即我们常用的 docker ps 、 docker run 等命令。值得注意的是，自Docker 18.09起，CLI工具已从主包中分离出来，形成独立发布单元，以便与其他项目（如Podman）共用同一套客户端。

containerd.io 则是底层容器运行时，由Docker公司捐赠给CNCF基金会，现已成为Kubernetes默认的CRI（Container Runtime Interface）实现之一。它脱离了Docker Engine的绑定，可以独立运行，但在Docker架构中仍扮演着“引擎中的引擎”角色。

这三个包构成了Docker运行的基本三角关系：

graph LR
    A[docker-ce-cli] -->|调用API| B(dockerd)
    B -->|调用gRPC| C[containerd]
    C -->|操作runc| D[runtime-spec]

如图所示，当用户输入 docker run nginx 时，CLI向 dockerd 发送HTTP请求， dockerd 再通过Unix Socket调用 containerd 创建容器，最后由 runc （未列在RPM中，但由containerd自动管理）执行OCI规范的容器启动流程。

2.2.2 系统级依赖项：libcgroup、selinux-policy、iptables

除了上述三大核心包外，Docker还依赖一系列操作系统级别的组件，这些往往容易被忽视，却可能成为离线安装失败的根源。

常见系统依赖项列表：

依赖包	作用说明	故障表现
libcgroup	控制组（cgroups）库，用于资源限制	启动报错：failed to initialize cgroup manager
selinux-policy	SELinux安全策略规则	容器无法启动，权限拒绝
iptables	网络防火墙工具，用于NAT和端口映射	容器间通信异常，端口无法绑定
audit-libs	审计日志支持	dockerd无法记录安全事件
device-mapper-libs	存储驱动依赖（devicemapper）	图层挂载失败，overlay2报错

例如，在CentOS 7系统中，若未预装 libcgroup ，即使 docker-ce 安装成功，执行 systemctl start docker 时也会立即退出，并在journal日志中显示：

failed to start daemon: failed to initialize cgroup manager: mountpoint for devices not found

这是因为Docker需要挂载 /sys/fs/cgroup/devices 等路径来进行CPU、内存限额控制。而 libcgroup 提供了 cgconfig 服务和相关库函数，是启用cgroups的前提。

类似的，SELinux若处于enforcing模式但缺少对应策略，会导致容器进程被强制终止。可通过临时设置 setenforce 0 规避，但这不符合安全规范。正确的做法是确保 selinux-policy-targeted 包已安装，并加载Docker专用策略模块。

2.2.3 使用rpm -qpR命令查看RPM包依赖关系

在准备离线包时，必须验证每个RPM文件的实际依赖项，避免遗漏。Linux提供了 rpm 命令行工具来查询包元数据，其中 -qpR 选项用于打印指定RPM文件的依赖列表。

例如，查看 docker-ce-24.0.5-1.el7.x86_64.rpm 的依赖：

rpm -qpR docker-ce-24.0.5-1.el7.x86_64.rpm

输出示例：

/bin/sh
/bin/systemctl
config(docker-ce) = 24.0.5-1.el7
docker-ce-root = 24.0.5-1.el7
libcgroup >= 0.40.rc1-5
libsystemd.so.0()(64bit)
libsystemd.so.0(LIBSYSTEMD_209)(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
systemd-units

参数说明 ：

• -q ：查询模式；
• -p ：指定本地RPM文件（而非已安装包）；
• -R ：列出该包所依赖的其他包或符号；

输出中包含两类依赖：

1. 显式包名依赖 ：如 libcgroup >= 0.40.rc1-5 ，表示必须安装此版本以上的cgroup库；
2. 动态库符号依赖 ：如 libsystemd.so.0()(64bit) ，表示需要系统中存在该共享库；
3. 虚拟提供依赖 ：如 config(docker-ce) ，由同名config包提供配置文件支持。

通过该命令，我们可以逐个扫描所有待传入内网的RPM包，构建完整的依赖图谱。建议编写脚本批量处理：

#!/bin/bash
for rpm in *.rpm; do
    echo "=== 依赖项：$rpm ==="
    rpm -qpR "$rpm"
done > ALL_DEPS.txt

该输出可用于生成依赖矩阵，辅助判断是否存在环形依赖或版本冲突，是构建可靠离线包集的重要环节。

3. 基于yumdownloader的RPM依赖包获取策略

在企业级离线部署场景中，Docker容器化平台的构建离不开对底层操作系统包管理机制的深度掌控。尤其是在无法连接互联网的内网服务器上，传统的 yum install docker-ce 命令将因无法访问远程仓库而失效。因此，必须提前在外网可达的“镜像主机”上完成所有必要的RPM包及其完整依赖树的预下载，并确保这些软件包能够在目标环境中无冲突地安装和运行。这一过程的核心工具是 yumdownloader ，它属于 yum-utils 工具集的一部分，具备递归解析并下载指定软件包及其全部依赖项的能力。

本章重点剖析如何通过 yumdownloader 实现高效、可靠、可复用的离线依赖获取策略。从准备镜像主机开始，到精确控制版本与架构兼容性，再到文件完整性校验，整个流程不仅要求操作严谨，还需深入理解YUM包管理器的行为逻辑。尤其值得注意的是，一个看似简单的 docker-ce 安装请求背后，可能涉及数十个间接依赖包（如 containerd.io、libcgroup、iptables-services 等），若遗漏任一关键组件，都将导致后续安装失败或服务异常。因此，依赖包的完整性、一致性与可追溯性成为决定离线部署成败的关键因素。

3.1 准备具备外网访问能力的镜像主机

为了实现高效的离线部署准备阶段，必须首先建立一台与目标生产环境尽可能一致的“镜像主机”。这台主机的作用不仅是作为RPM包的下载源，更是整个离线部署方案的技术锚点——其操作系统版本、CPU架构、仓库配置等都直接影响最终生成的RPM集合是否能在目标系统上成功安装。

3.1.1 操作系统版本匹配的重要性（CentOS 7/8 vs RHEL）

选择正确的基础操作系统是确保兼容性的第一步。尽管 CentOS、RHEL 和 Rocky Linux 在大多数情况下二进制兼容，但不同主版本之间的库依赖关系可能存在显著差异。例如：

• CentOS 7 使用 systemd-219 和较旧的 glibc-2.17 ，默认启用 iptables 而非 nftables ；
• CentOS 8 / Stream 则基于更新的内核和用户空间工具链，使用 nftables 作为默认防火墙后端，并引入了 dnf 作为默认包管理器。

这意味着为 CentOS 7 编译的 RPM 包可能无法在 CentOS 8 上正确安装，反之亦然。更严重的是，某些 Docker 组件（如 containerd.io ）在不同发行版中的依赖路径存在硬编码差异。

为此，推荐遵循以下原则进行镜像主机选型：

目标环境操作系统	推荐镜像主机系统	兼容风险等级	备注
CentOS 7 x86_64	CentOS 7 x86_64	低	建议最小化安装
CentOS 8 x86_64	CentOS 8 x86_64	低	需关闭Stream干扰
RHEL 7	CentOS 7 或 RHEL 7	中	若有订阅优先使用RHEL
Rocky Linux 8	CentOS 8 或 Rocky 8	低至中	注意SELinux策略同步

⚠️ 特别提醒：避免跨大版本混用。例如不要用 CentOS 8 主机为 CentOS 7 目标系统下载 RPM 包，即使手动复制也可能因 ld-linux.so 版本不匹配而导致 containerd 启动失败。

实践建议：

应尽量使用虚拟机或容器创建多个标准化的镜像主机模板，分别对应不同的生产环境组合。可通过 Packer 自动化构建此类镜像，确保每次离线准备工作的起点一致。

3.1.2 配置官方Docker仓库（docker.repo）

仅依赖系统自带仓库无法获取最新版 Docker CE，必须手动添加 Docker 官方提供的 YUM 源。该步骤的核心在于编写 /etc/yum.repos.d/docker-ce.repo 文件，明确指向稳定的发布通道。

以下是标准配置内容示例：

[docker-ce-stable]
name=Docker CE Stable - $basearch
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

[docker-ce-stable-debuginfo]
name=Docker CE Stable - Debuginfo $basearch
baseurl=https://download.docker.com/linux/centos/$releasever/debug-$basearch/stable
enabled=0
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

[docker-ce-stable-source]
name=Docker CE Stable - Source
baseurl=https://download.docker.com/linux/centos/$releasever/source/stable
enabled=0
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

参数说明：

参数	含义说明
baseurl	动态URL，自动替换 $releasever 为当前系统版本（如7或8）， $basearch 替换为 x86_64
enabled=1	启用此仓库；设为0则禁用
gpgcheck=1	启用GPG签名验证，防止恶意包注入
gpgkey	指定公钥地址，用于验证RPM包来源合法性

执行后需刷新缓存：

yum makecache fast

此时可查询可用的 Docker 版本列表：

yum list available --disablerepo="*" --enablerepo="docker-ce-stable" docker-ce

输出类似：

Available Packages
docker-ce.x86_64  3:24.0.5-1.el7  docker-ce-stable
docker-ce.x86_64  3:24.0.7-1.el7  docker-ce-stable

✅ 提示：若网络受限，可预先导出 .repo 文件并通过SCP传输至镜像主机，避免临时编辑错误。

3.1.3 启用正确的存储库通道（stable、nightly）

Docker 提供三种主要的发布通道：

通道类型	更新频率	稳定性	适用场景
stable	每季度一次	高	生产环境首选
nightly	每日构建	极低	开发测试专用
test	不定期预览	中	新功能评估

对于离线部署而言，强烈建议锁定 stable 通道，以保证长期维护和支持。虽然 nightly 提供最新特性，但其依赖结构频繁变动，极易引发版本错配问题。

可通过修改 .repo 文件临时启用其他通道：

[docker-ce-nightly]
name=Docker CE Nightly - $basearch
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/nightly
enabled=0
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

然后按需启用：

yum --enablerepo=docker-ce-nightly list docker-ce

但在正式打包前，务必确认最终使用的仍是 stable 版本。

3.2 使用yumdownloader工具递归下载所有依赖

一旦镜像主机配置完毕，下一步便是利用 yumdownloader 工具全自动拉取 docker-ce 及其完整的依赖树。这是整个离线准备流程中最关键的技术环节之一，直接决定了后续能否顺利安装。

3.2.1 安装并验证yum-utils工具集

yumdownloader 并不属于默认安装的 yum 命令套件，而是包含在 yum-utils 包中。因此需先安装该工具集：

yum install -y yum-utils

安装完成后可通过以下命令验证其可用性：

which yumdownloader
# 输出：/usr/bin/yumdownloader

此外，还可查看帮助文档了解高级选项：

yumdownloader --help

常见参数包括：

参数	作用
--destdir	指定下载目录
--resolve	递归解决并下载所有依赖
--urls	仅输出下载链接而不实际下载
--source	下载源码RPM（SRPM）

💡 技巧：若担心误操作污染系统，可在容器中运行 yumdownloader 。例如使用 docker run -v $(pwd):/rpms centos:7 yum install -y yum-utils && yumdownloader ... 实现隔离化下载。

3.2.2 执行yumdownloader –resolve docker-ce命令详解

核心命令如下：

mkdir -p /opt/docker-offline/rpm
yumdownloader --resolve --destdir=/opt/docker-offline/rpm docker-ce-3:24.0.7-1.el7

命令逐行解读：

• mkdir -p /opt/docker-offline/rpm
  创建统一的RPM存储目录，便于后期迁移与组织。

• yumdownloader
  调用下载器主程序。

• --resolve
  最关键参数 ：开启依赖解析模式。YUM会遍历依赖树，找出所有必需的RPM包（包括间接依赖），并一并下载。例如 docker-ce 依赖 docker-ce-cli ，而后者又依赖 containerd.io ，再往下还可能涉及 libcgroup , slirp4netns 等。

• --destdir=/opt/docker-offline/rpm
  明确指定输出路径，避免文件散落在当前目录。

• docker-ce-3:24.0.7-1.el7
  精确指定版本号。此处使用完整 NEVRA 格式（Name-Epoch:Version-Release.Architecture），避免自动升级到更高版本。

实际输出示例：

--> Running transaction check
---> Package docker-ce.x86_64 3:24.0.7-1.el7 will be installed
--> Processing Dependency: docker-ce-cli for package: docker-ce-3:24.0.7-1.el7.x86_64
--> Processing Dependency: containerd.io >= 1.6.21 for package: docker-ce-3:24.0.7-1.el7.x86_64
(18 dependencies resolved)
Downloading packages:
containerd.io-1.6.21-3.1.el7.x86_64.rpm                    |  32 MB  00:05
docker-ce-cli-24.0.7-1.el7.x86_64.rpm                       |  40 MB  00:06
docker-ce-24.0.7-1.el7.x86_64.rpm                           |  22 MB  00:03
Total                                            16 MB/s | 120 MB  00:07

最终在 /opt/docker-offline/rpm 下生成约 15~20 个 RPM 文件，构成完整安装所需的所有组件。

3.2.3 下载目录组织与文件完整性校验（sha256sum）

下载完成后，应对所有RPM文件进行完整性校验，防止传输损坏或中间篡改。

推荐目录结构：

/opt/docker-offline/
├── rpm/
│   ├── docker-ce-24.0.7-1.el7.x86_64.rpm
│   ├── docker-ce-cli-24.0.7-1.el7.x86_64.rpm
│   └── containerd.io-1.6.21-3.1.el7.x86_64.rpm
│   └── ...
├── checksums.sha256
└── packages.list

生成 SHA256 校验码：

cd /opt/docker-offline/rpm
sha256sum *.rpm > ../checksums.sha256

内容示例：

a1b2c3d4...  docker-ce-24.0.7-1.el7.x86_64.rpm
e5f6g7h8...  docker-ce-cli-24.0.7-1.el7.x86_64.rpm
i9j0k1l2...  containerd.io-1.6.21-3.1.el7.x86_64.rpm

同时记录所选版本信息：

echo "Docker CE Version: 24.0.7" > packages.list
rpm -qpi *.rpm | grep 'Name\|Version\|Release\|Architecture' >> packages.list

这样可在目标系统安装前执行双重验证：

sha256sum -c ../checksums.sha256
# 输出：OK 表示一致

🔐 安全增强：若处于高安全等级环境，建议额外导入 Docker GPG 公钥并使用 rpm --checksig *.rpm 验证签名有效性。

3.3 跨平台迁移中的兼容性控制

即便完成了依赖包的下载，仍不能保证其能在目标机器上顺利安装。跨平台迁移过程中常见的三大陷阱是：CPU架构不匹配、版本漂移以及运行时库缺失。只有严格控制这些变量，才能确保离线部署的可靠性。

3.3.1 架构一致性检查（x86_64 vs aarch64）

现代服务器已广泛采用 ARM 架构（如华为鲲鹏、AWS Graviton）。若在 x86_64 主机上下载的 RPM 包被部署到 aarch64 系统，将出现“Unsupported architecture”错误。

可通过以下命令检查每个 RPM 的目标架构：

rpm -qp --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' *.rpm

输出示例：

docker-ce-24.0.7-1.el7.x86_64
containerd.io-1.6.21-3.1.el7.aarch64  ← 此包无法在x86上运行！

理想情况是所有包均为 x86_64 （或统一为 aarch64 ）。

解决方案：

使用 --archlist 参数强制限制下载架构：

yumdownloader --resolve --destdir=./rpm --archlist=x86_64 docker-ce

该参数会忽略不符合指定架构的包，避免混入异构文件。

此外，也可绘制依赖拓扑图辅助分析：

graph TD
    A[docker-ce] --> B[docker-ce-cli]
    A --> C[containerd.io]
    B --> D[slirp4netns]
    C --> E[libcgroup]
    C --> F[iptables]
    E --> G[glibc >= 2.17]
    F --> H[kernel-modules]
    style A fill:#4CAF50, color:white
    style B fill:#2196F3, color:white
    style C fill:#FF9800, color:white

图解说明：上述 Mermaid 流程图展示了 docker-ce 的主要依赖层级。其中绿色为核心包，蓝色为CLI工具，橙色为运行时引擎。箭头方向表示依赖关系，有助于识别潜在架构敏感节点。

3.3.2 版本锁定避免自动升级冲突

YUM 默认行为是在安装时尝试拉取最新版本，但在离线环境下，这种动态行为会导致失败。因此必须显式锁定版本。

假设我们只下载了 docker-ce-24.0.7 ，但目标系统之前曾安装过 24.0.5 ，执行 yum install docker-ce 可能触发自动更新检测，进而尝试联网获取元数据。

解决方案如下：

1. 卸载旧版本（如有）

yum remove -y docker docker-common docker-engine

2. 使用完整 NEVRA 名称安装

yum localinstall /opt/docker-offline/rpm/docker-ce-3:24.0.7-1.el7.x86_64.rpm

3. 在 repo 文件中禁用远程更新

[docker-ce-stable]
enabled=0  # 安装完成后关闭在线源

4. 使用 versionlock 插件永久锁定

yum install -y yum-plugin-versionlock
yum versionlock docker-ce docker-ce-cli containerd.io

该插件会将锁定版本写入 /etc/yum/pluginconf.d/versionlock.list ，防止意外升级。

3.3.3 处理不同glibc版本导致的运行时错误

即使RPM包成功安装，也可能在启动 dockerd 时遇到如下错误：

/lib64/libc.so.6: version `GLIBC_2.18' not found

原因在于： containerd.io 在较新版本中编译时链接了高于目标系统的 glibc 库。例如 CentOS 7 默认提供 glibc-2.17 ，而某些新版 containerd 需要 2.18+ 。

分析方法：

检查目标系统 glibc 版本：

ldd --version
# 输出：ldd (GNU libc) 2.17

检查 containerd 所需符号：

objdump -T /usr/bin/containerd | grep GLIBC_2.18

若发现依赖，则必须降级 containerd.io 至兼容版本。

推荐做法：

在镜像主机上指定旧版 containerd.io ：

yumdownloader --resolve --destdir=./rpm \
    docker-ce-3:24.0.7-1.el7 \
    containerd.io-1.6.21-3.1.el7

或者使用 --setopt 强制版本偏好：

yumdownloader --resolve --destdir=./rpm \
    --setopt=obsoletes=0 \
    'docker-ce-24.0.7*' 'containerd.io-1.6.21*'

🛠️ 替代方案：对于无法降级的情况，可考虑使用静态编译的 containerd 二进制包替代 RPM，但这会脱离包管理系统，增加运维复杂度。

综上所述，基于 yumdownloader 的依赖获取策略不仅仅是“下载几个文件”，而是一套涵盖环境准备、精确控制、完整性保障与跨平台适配的系统工程。唯有如此，才能为后续的本地YUM源搭建和离线安装打下坚实基础。

4. 本地YUM源搭建与Docker RPM包安装实践

在完成离线环境中所需RPM包的完整采集后，下一步的核心任务是将这些二进制文件组织为一个可被系统识别和使用的本地软件仓库。这一过程不仅决定了后续安装操作的成功率，也直接影响到批量部署时的一致性与可维护性。本章聚焦于如何基于已下载的Docker CE及相关依赖RPM包，构建一个结构规范、元数据完整、行为可控的本地YUM源，并在此基础上执行安全可靠的离线安装流程。

通过科学地设计目录结构、生成标准化的 repodata 索引信息、正确配置 yum.repo 文件并验证其可用性，可以实现与在线YUM源几乎完全一致的操作体验。这使得即使在网络隔离环境下，依然能够利用YUM强大的依赖解析能力自动处理复杂的组件关系，极大降低人为干预带来的出错风险。此外，该方法具备良好的扩展性，适用于其他需要离线部署的开源软件栈，如Kubernetes节点组件、Prometheus监控套件等。

整个实践流程强调“可重复”、“可审计”、“可增量更新”的运维理念，确保每一次安装都建立在确定性的基础之上，避免因版本漂移或依赖缺失导致服务异常。以下将从仓库初始化、元数据生成、源配置到最终安装验证，逐层展开详尽的技术实现路径。

4.1 创建标准化的本地RPM仓库目录结构

构建本地YUM源的第一步是创建一个逻辑清晰、命名规范且权限受控的RPM存储目录。合理的目录结构不仅是后期维护的基础，也能显著提升团队协作效率，尤其是在多环境（开发、测试、生产）或多架构（x86_64、aarch64）共存的情况下。

4.1.1 设计清晰的存储路径（/opt/docker-offline/rpm）

推荐使用 /opt/docker-offline/rpm 作为主存储路径，原因如下：

• /opt 是Linux标准中用于存放第三方应用程序的目录；
• docker-offline 明确标识用途，便于与其他离线包区分；
• 子目录 rpm 集中存放所有RPM文件，结构扁平化利于脚本扫描。

# 创建目录结构
sudo mkdir -p /opt/docker-offline/rpm

若需支持多种操作系统版本或CPU架构，建议进一步细分：

路径	说明
/opt/docker-offline/rpm/centos7/x86_64/	CentOS 7 x86_64 架构RPM包
/opt/docker-offline/rpm/centos8/aarch64/	CentOS 8 ARM64 架构RPM包
/opt/docker-offline/rpm/common/	跨平台通用工具包（如createrepo）

这种分层结构可通过自动化脚本动态选择目标路径，提升部署灵活性。

4.1.2 统一命名规范提升可维护性

为了便于追踪和管理，应对所有RPM包采用统一的命名约定。推荐格式为：

<package-name>-<version>-<release>.<arch>.rpm

例如：

docker-ce-24.0.5-1.el7.x86_64.rpm
containerd.io-1.6.21-3.2.el7.x86_64.rpm

禁止对原始RPM包进行重命名或压缩打包（如tar.gz封装），否则会导致YUM无法正确解析元数据。同时应保留原始包名以保证哈希校验一致性。

可通过以下命令检查当前目录下所有RPM包的基本信息：

for rpm in /opt/docker-offline/rpm/*.rpm; do
    echo "=== $rpm ==="
    rpm -qpi "$rpm" | grep -E "(Name|Version|Release|Architecture)"
done

代码逻辑逐行解读 ：
- for rpm in ... : 遍历指定目录下的所有 .rpm 文件；
- rpm -qpi : 查询RPM包的详细信息（包括描述、依赖、大小等）；
- grep -E : 提取关键字段，过滤冗余输出；
- 整体作用是批量查看每个RPM包的名称、版本、发布号和架构，确保无错误混入。

该脚本可用于快速发现不合规的包，比如误拷贝了调试版本（debuginfo）或不同发行版的包（el8误用于el7）。

4.1.3 权限设置防止非法修改（chmod 644 *.rpm）

安全性是离线部署不可忽视的一环。一旦RPM包被篡改，可能导致恶意代码注入。因此，在完成传输后应立即设置只读权限：

sudo chmod 644 /opt/docker-offline/rpm/*.rpm
sudo chown root:root /opt/docker-offline/rpm/*.rpm

参数说明 ：
- 644 表示文件所有者可读写，组用户和其他人仅可读；
- root:root 确保只有超级用户才能修改或删除；
- 若未来需更新包，应临时提升权限再操作，完成后重新锁定。

此外，建议定期计算并记录SHA256校验值，形成“黄金镜像”清单：

cd /opt/docker-offline/rpm
sha256sum *.rpm > SHA256SUMS

此文件应在可信通道中保存，供后续部署时做完整性比对：

sha256sum -c SHA256SUMS

若输出均为 OK ，则说明RPM包未被篡改；若有失败项，则必须中断安装流程并排查来源。

flowchart TD
    A[开始] --> B[创建目录 /opt/docker-offline/rpm]
    B --> C[复制RPM包至目录]
    C --> D[执行 chmod 644 & chown root:root]
    D --> E[生成 SHA256SUMS 校验文件]
    E --> F{是否跨架构？}
    F -->|是| G[按 arch/version 分子目录]
    F -->|否| H[保持扁平结构]
    G --> I[结束]
    H --> I

上述流程图展示了从零构建RPM仓库目录的完整生命周期，涵盖了物理存储、权限控制、完整性保护三大核心要素。该结构将成为后续 createrepo 操作的数据输入源，也是保障整个离线安装链路可信的关键起点。

4.2 利用createrepo生成元数据索引

YUM并不直接扫描RPM文件进行安装决策，而是依赖一个名为 repodata 的元数据目录，其中包含所有包的依赖关系、版本信息、校验码等内容。 createrepo 工具的作用正是根据指定目录中的RPM集合，自动生成这套结构化的XML索引文件。

4.2.1 安装createrepo工具并初始化仓库

首先需在离线主机上安装 createrepo ，但因其本身也有依赖项（如 python-deltarpm 、 xmltok 等），最佳做法是在具备外网访问的镜像主机上提前下载：

# 在联网主机执行
yum install --downloadonly --downloaddir=./createrepo-deps createrepo

然后将所有相关RPM包传入目标服务器并手动安装：

sudo rpm -ivh ./createrepo-deps/*.rpm

注意 ：避免使用 --force 或 --nodeps ，除非确认不会破坏现有系统。

安装完成后验证是否可用：

createrepo --version

输出类似：

createrepo 0.10.3

表示工具就绪。

接下来进入RPM存储目录并初始化仓库：

cd /opt/docker-offline/rpm
sudo createrepo .

该命令会在当前目录下生成 repodata/ 文件夹，内含多个XML和压缩文件，如：

• primary.xml.gz : 主要包信息（名称、版本、大小、依赖）
• filelists.xml.gz : 每个包包含的文件列表
• other.xml.gz : 其他元数据（变更日志、许可证等）
• repomd.xml : 元数据清单，指向各部分的具体位置

这是YUM解析依赖的核心依据。

4.2.2 生成repodata目录与comps.xml支持组安装

默认情况下， createrepo 不生成软件组信息（group data）。但在某些场景中，可能希望以“功能模块”方式安装（如 [docker-group] 包含全部容器组件），此时需配合 comps.xml 文件。

先创建示例 comps.xml ：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE comps PUBLIC "-//Red Hat, Inc.//DTD Comps info//EN" "comps.dtd">
<comps>
  <group>
    <id>docker-engine</id>
    <name>Docker Engine</name>
    <description>Container runtime and CLI tools.</description>
    <default>true</default>
    <uservisible>true</uservisible>
    <packagelist>
      <packagereq type="mandatory">docker-ce</packagereq>
      <packagereq type="mandatory">docker-ce-cli</packagereq>
      <packagereq type="mandatory">containerd.io</packagereq>
    </packagelist>
  </group>
</comps>

将其保存为 /opt/docker-offline/rpm/comps.xml ，然后重新运行 createrepo 并加载该文件：

sudo createrepo -g comps.xml .

参数说明 ：
- -g comps.xml : 指定软件组定义文件；
- 后续可通过 yum groupinstall "Docker Engine" 实现一键安装；
- 对于大规模集群部署尤其有价值。

生成后的 repodata/ 中会新增 group.xml 或嵌入 repomd.xml 的 group 字段。

4.2.3 增量更新时的clean与rebuild流程

随着时间推移，可能需要升级Docker版本或添加新组件。此时不应简单覆盖旧包，而应遵循安全的增量更新流程：

1. 备份原 repodata/ 目录；
2. 将新RPM包复制进 /opt/docker-offline/rpm/ ；
3. 删除旧元数据：

sudo rm -rf repodata/

4. 重新生成索引：

sudo createrepo -g comps.xml .

为何不能跳过删除？
因为 createrepo 默认不会清理已被移除的包的元数据条目，可能导致YUM仍尝试引用不存在的文件，引发报错。

为提高效率，也可使用 createrepo --update 模式，但它仅适用于已有 repodata 且仅追加新包的情况：

sudo createrepo --update -g comps.xml .

适用条件 ：原有包未被删除，仅新增；否则仍需全量重建。

以下表格对比两种模式的特性：

特性	全量重建	增量更新（–update）
执行速度	慢（遍历全部RPM）	快（仅扫描新增）
磁盘占用	高（临时空间大）	低
安全性	高（彻底刷新）	中（残留风险）
推荐场景	版本大更新、结构调整	日常补丁添加

flowchart LR
    A[检测是否有新RPM包] --> B{是否删除旧包？}
    B -->|是| C[rm -rf repodata/]
    B -->|否| D[保留 repodata/]
    C --> E[createrepo -g comps.xml .]
    D --> F[createrepo --update -g comps.xml .]
    E --> G[更新完成]
    F --> G

该流程图体现了元数据重建的判断逻辑，帮助运维人员根据变更类型选择最优策略。

4.3 配置本地yum源（/etc/yum.repos.d/docker.repo）

元数据准备就绪后，最后一步是让YUM系统识别这个本地仓库。这通过在 /etc/yum.repos.d/ 下创建 .repo 文件实现。

4.3.1 编写repo文件的关键参数说明（baseurl=file://）

创建配置文件：

sudo tee /etc/yum.repos.d/docker-offline.repo << 'EOF'
[docker-offline]
name=Docker Offline Repository
baseurl=file:///opt/docker-offline/rpm
enabled=1
gpgcheck=0
cost=500
EOF

参数详解 ：
- [docker-offline] : 仓库唯一标识符，不可重复；
- name : 显示名称，用于 yum repolist 输出；
- baseurl=file://... : 使用本地文件协议，注意三斜杠（file:///）；
- enabled=1 : 启用此源；
- gpgcheck=0 : 关闭GPG签名验证（离线环境下难以获取公钥）；
- cost=500 : 设置较高成本值，避免与其他源冲突时优先被选中；

⚠️ 注意事项：
- baseurl 必须使用绝对路径，且目录需存在；
- 若路径拼写错误（如少一个 / ），YUM将静默忽略该源；
- 可通过 file:/// 支持NFS挂载的共享仓库，实现多机共用。

4.3.2 关闭GPG校验的合理使用场景

虽然 gpgcheck=0 存在安全风险，但在严格管控的离线环境中是可以接受的，前提是：

• 所有RPM包来源于可信构建流水线；
• 已通过SHA256SUMS完成完整性校验；
• 物理访问受到限制。

更优方案是导入官方GPG密钥并启用校验：

# 下载并导入Docker官方GPG Key
sudo rpm --import https://download.docker.com/linux/centos/gpg

# 修改 repo 文件
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Docker

但此方式要求提前将密钥文件传入离线主机，增加复杂度。对于一次性部署，关闭校验更为实用。

4.3.3 测试本地源可用性（yum repolist enabled）

配置完成后必须验证源是否生效：

yum repolist enabled | grep docker-offline

预期输出：

docker-offline          Docker Offline Repository                    5

数字5表示仓库中包含5个可用包。若无输出，说明配置有误。

进一步测试依赖解析能力：

yum deplist docker-ce

应列出所有依赖项及其提供者，确认没有“未满足依赖”。

若出现如下错误：

No package docker-ce available.

常见原因包括：

错误原因	解决方案
repodata未生成	运行 createrepo .
baseurl路径错误	检查是否为 file:/// 开头
RPM包架构不匹配	使用 uname -m 确认系统架构
yum缓存未刷新	执行 yum clean all && yum makecache

执行缓存清理命令：

sudo yum clean all
sudo yum makecache

makecache 会强制重新读取 repodata ，建立本地索引数据库。

flowchart TB
    A[编辑 /etc/yum.repos.d/docker-offline.repo] --> B[填写 baseurl 和参数]
    B --> C[运行 yum clean all]
    C --> D[执行 yum makecache]
    D --> E[调用 yum repolist enabled]
    E --> F{是否显示 docker-offline？}
    F -->|是| G[测试 yum install docker-ce]
    F -->|否| H[检查路径、权限、repodata]
    H --> I[修正后重试]
    I --> D

该流程图完整描绘了从配置到验证的闭环操作路径，确保每一步都有反馈机制支撑。

4.4 执行离线安装并验证服务状态

当本地YUM源成功注册后，即可启动Docker的离线安装流程。

4.4.1 使用yum install docker-ce从本地源安装

执行安装命令：

sudo yum install -y docker-ce

YUM将自动解析依赖树，并从本地源拉取 docker-ce 、 docker-ce-cli 、 containerd.io 等必要组件，无需联网。

执行逻辑分析 ：
- YUM读取 /etc/yum.repos.d/ 中所有启用的源；
- 根据 repomd.xml 加载本地仓库元数据；
- 计算 docker-ce 的依赖链，查找满足条件的RPM包；
- 下载（实为本地复制）并按顺序安装；
- 最终调用 post-install 脚本初始化服务单元。

安装成功后可通过以下命令确认版本：

rpm -q docker-ce

输出示例：

docker-ce-24.0.5-1.el7.x86_64

4.4.2 解决潜在依赖冲突的强制安装方案

尽管YUM能自动解决大多数依赖问题，但在混合使用不同来源的RPM包时，可能出现版本冲突或文件覆盖警告。此时可采取以下措施：

方案一：忽略依赖（慎用）

sudo rpm -ivh --nodeps *.rpm

❌ 风险极高，可能导致运行时崩溃。

方案二：替换已安装包

sudo yum install -y docker-ce --skip-broken

跳过无法解析的部分，优先安装可满足的组件。

方案三：强制更新

sudo yum update docker-ce -y --disablerepo="*" --enablerepo="docker-offline"

限定仅从指定源更新，避免意外引入外部版本。

最稳妥的方式仍是确保RPM包集完整且版本兼容。

4.4.3 检查服务单元状态（systemctl status docker）

安装完成后，Docker服务并不会自动启动，需手动启用：

sudo systemctl enable docker --now

--now 参数等价于 enable + start

验证服务运行状态：

systemctl status docker

正常输出应包含：

● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since ...

若显示 failed 或 inactive ，可通过日志排查：

journalctl -u docker.service --since "5 minutes ago"

常见问题包括：

• cgroup挂载点缺失；
• SELinux策略阻止；
• /var/lib/docker 目录权限不足。

修复后重启服务：

sudo systemctl restart docker

最终验证容器运行能力：

sudo docker run --rm hello-world

若能成功打印欢迎信息，则表明整个离线安装链路完全打通。

至此，本地YUM源搭建与Docker RPM包安装全过程已完成。该方案兼具可靠性、可复用性和可审计性，适用于金融、军工、电力等高安全等级行业的基础设施建设需求。

5. Docker服务初始化配置与长期运维建议

5.1 启动Docker服务并设置开机自启

安装完成后，Docker 服务并不会自动启动或注册为系统服务。必须手动启用并启动 docker 服务单元，以确保容器运行时环境处于可用状态。

# 启用Docker服务，使其在系统启动时自动运行
sudo systemctl enable docker

# 立即启动Docker守护进程
sudo systemctl start docker

# 检查服务状态，确认是否正常运行
sudo systemctl status docker

执行上述命令后，应看到类似输出：

● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2025-04-05 10:23:45 CST; 1min ago
     Docs: https://docs.docker.com
 Main PID: 12345 (dockerd)
    Tasks: 12
   Memory: 58.7M
   CGroup: /system.slice/docker.service
           └─12345 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

其中 enabled 表示已设置开机自启， active (running) 表示服务正在运行。这是生产环境中保障容器平台高可用性的基础步骤。

此外，建议将当前用户加入 docker 用户组，避免每次使用 sudo 执行 Docker 命令：

# 将当前用户添加到docker组
sudo usermod -aG docker $USER

# 切换会话使组权限生效（或重新登录）
newgrp docker

验证权限变更：

docker info | grep "Username"

若返回用户名，则说明配置成功。

5.2 功能验证：运行首个容器进行端到端测试

为验证整个 Docker 安装链路的完整性，包括镜像拉取、存储驱动初始化、网络配置和容器运行时联动，推荐使用官方提供的最小化测试镜像 hello-world 进行功能验证。

# 拉取并运行hello-world镜像
docker run hello-world

预期输出如下：

Hello from Docker!
This message shows that your installation appears to be working correctly.


To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
 3. The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal.

该过程验证了以下关键组件：
- Docker CLI 与 Daemon 的通信机制
- 镜像拉取流程（即使离线环境也需确认缓存或私有 registry 可用性）
- 容器生命周期管理能力（create → start → exec → stop）

⚠️ 若目标主机完全离线且未提前导入镜像，此命令将失败。此时可预先在联网主机导出镜像包：

# 在联网主机执行
docker pull hello-world
docker save hello-world > hello-world.tar

# 传输至离线主机并加载
docker load < hello-world.tar
docker run hello-world

5.3 配置Docker守护进程：优化daemon.json策略

Docker 的行为可通过 /etc/docker/daemon.json 文件进行精细化控制。该 JSON 格式配置文件支持多种高级选项，适用于性能调优、安全加固和运维标准化。

典型 daemon.json 示例：

{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  },
  "storage-driver": "overlay2",
  "registry-mirrors": [
    "https://mirror.ccs.tencentyun.com",
    "https://hub-mirror.c.163.com"
  ],
  "insecure-registries": [
    "192.168.10.100:5000"
  ],
  "live-restore": true,
  "default-shm-size": "64M"
}

参数说明如下表所示：

参数	说明
exec-opts	推荐使用 systemd cgroup 驱动以与系统一致，避免 kubelet 冲突
log-driver	设置日志驱动为 json-file ，便于集中采集
log-opts.max-size	单个日志文件最大尺寸，防止磁盘占满
log-opts.max-file	最多保留的日志文件数量
storage-driver	推荐 overlay2 ，性能优于 devicemapper
registry-mirrors	配置国内镜像加速器提升 pull 效率
insecure-registries	允许访问 HTTP 协议的私有仓库
live-restore	Docker 守护进程重启时保持容器运行
default-shm-size	调整共享内存大小，避免某些应用OOM

修改配置后需重载 systemd 并重启服务：

sudo systemctl daemon-reload
sudo systemctl restart docker

可通过以下命令验证配置是否生效：

docker info | grep -E "(Cgroup Driver|Logging Driver|Storage Driver|Registry Mirrors)"

5.4 版本管理与企业级运维规范建议

为保障容器平台的可持续演进，建议建立标准化的企业级运维体系，涵盖版本锁定、补丁更新、文档追溯与内部知识沉淀。

5.4.1 版本锁定防止意外升级

在生产环境中，应通过 yum 版本锁插件固定 Docker 版本：

# 安装yum-plugin-versionlock
sudo yum install -y yum-plugin-versionlock

# 锁定当前Docker版本
sudo yum versionlock docker-ce docker-ce-cli containerd.io

查看已锁定版本：

sudo yum versionlock list

输出示例：

docker-ce-18.09.9-3.el7.*
docker-ce-cli-18.09.9-3.el7.*
containerd.io-1.2.6-3.3.el7.*

5.4.2 构建内部RPM包知识库

建议维护一个结构化的离线包管理清单，例如 CSV 或数据库记录，包含以下字段：

包名	版本	架构	SHA256校验值	来源URL	适用OS	安装日期	维护人
docker-ce	18.09.9	x86_64	a1b2c3d…	https://download.docker.com/linux/centos/7/x86_64/stable/Packages/docker-ce-18.09.9-3.el7.x86_64.rpm	CentOS 7	2025-04-01	张三
docker-ce-cli	18.09.9	x86_64	e4f5g6h…	https://download.docker.com/linux/centos/7/x86_64/stable/Packages/docker-ce-cli-18.09.9-3.el7.x86_64.rpm	CentOS 7	2025-04-01	张三
containerd.io	1.2.6	x86_64	i7j8k9l…	https://download.docker.com/linux/centos/7/x86_64/stable/Packages/containerd.io-1.2.6-3.3.el7.x86_64.rpm	CentOS 7	2025-04-01	张三
libcgroup	0.41	x86_64	m1n2o3p…	http://mirror.centos.org/centos/7/os/x86_64/Packages/libcgroup-0.41-21.el7.x86_64.rpm	CentOS 7	2025-04-01	李四

此类表格可用于审计、合规检查和故障回溯。

5.4.3 持续关注官方文档与安全公告

Docker 官方定期发布 版本发布日志 和 CVE 漏洞通告 。建议订阅其 RSS 或邮件列表，并结合自动化脚本监控新版本：

# 示例：获取最新稳定版信息（需解析HTML，仅示意）
curl -s https://download.docker.com/linux/centos/7/x86_64/stable/Packages/ | grep docker-ce | grep .rpm | head -n1

同时，参考官方特定版本安装指南，如：

https://docs.docker.com/engine/install/centos/#install-from-a-package

特别注意废弃通知（deprecation）和依赖变更，例如从 docker-engine 到 docker-ce 的迁移路径，或 docker-compose 被 docker compose plugin 替代的趋势。

最后，建议绘制企业内部 Docker 部署流程图，明确各环节责任人：

flowchart TD
    A[外网镜像主机] -->|yumdownloader --resolve| B[RPM包下载]
    B --> C{完整性校验}
    C -->|SHA256匹配| D[拷贝至内网]
    D --> E[搭建本地YUM源]
    E --> F[批量部署Docker]
    F --> G[配置daemon.json]
    G --> H[加入监控体系]
    H --> I[纳入CMDB资产库]
    I --> J[定期安全扫描]
    J --> K[制定升级/回滚预案]

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

简介：Docker是Linux系统下广泛使用的容器化技术，可将应用及其依赖打包至可移植容器中，实现高效部署与虚拟化。本文详细讲解在无网络环境下如何安装Docker及其依赖包，适用于RHEL/CentOS等使用RPM包管理的系统。通过在联网机器下载RPM依赖包，传输至目标主机并配置本地yum源，用户可完成Docker的离线安装、服务启动与自启设置。本教程涵盖从准备依赖、创建本地仓库到最终验证运行的全流程，帮助用户在隔离环境中成功部署Docker。

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