离线环境Docker与Docker-Compose安装包完整准备指南

简介这份资源面向需要在 Linux 环境下快速搭建容器运行环境的开发与运维人员尤其适合刚接触容器化部署、希望一次性完成 Docker 与 Docker Compose 安装配置的初学者和测试人员。压缩包共 4 个文件整体约 84.53MB包含 tgz 安装包、service 系统服务文件、sh 安装脚本以及 docker-compose 配置文件分别对应主程序安装、服务注册、自动化部署与多容器编排配置覆盖了从安装到编排的完整链路。目前已有 266 人学习下载说明其在同类安装包中具备一定参考价值。借助其中的安装脚本与服务配置读者可以省去逐条查阅官方文档的时间快速完成 Docker 环境初始化并基于 Compose 配置体验多容器应用的统一编排与启停适合作为测试环境搭建与容器化入门的实用工具包。1. 离线环境里docker和docker-compose安装包到底该怎么备很多团队第一次在内网或隔离环境部署服务时都会卡在同一个地方机器上没有任何外网出口apt install docker-ce或yum install docker-ce直接超时而 docker 和 docker-compose 的安装包又不是一个单独的二进制文件那么简单。有人以为下载一个docker可执行文件丢到/usr/bin就完事了结果systemctl start docker报错containerd 找不到runc 版本不匹配最后排查半天才发现缺了半套运行时组件。这个标题真正要解决的问题是在没有稳定外网、或者需要批量复制到多台机器的场景下如何把 docker 引擎和 docker-compose 的安装包完整地准备好并且保证装上去能跑起来。适合两类人一类是负责内网服务器交付的运维另一类是在客户现场做私有化部署的工程师。核心不是“下载”而是“知道要下哪些东西、版本怎么对齐、装完怎么验证”。2. 先搞清楚要准备哪些包docker 引擎不是单个二进制2.1 docker 引擎的组件拆分与依赖关系在动手下载之前必须理解 docker 引擎在 Linux 上的实际组成。以常见的 deb 系发行版为例docker-ce这个包本身并不包含全部运行时它依赖几个关键组件组件作用是否可省略docker-cedocker 守护进程和 CLI 客户端不可省略docker-ce-cli命令行工具与守护进程通信不可省略containerd.io容器运行时负责容器生命周期不可省略docker-buildx-plugin构建扩展支持多平台构建按需docker-compose-plugincompose v2 插件按需很多人只下载docker-ce一个包安装时 apt 会自动去拉依赖但离线环境没有源直接失败。所以正确做法是把这些包全部下载到本地用dpkg -i或rpm -ivh一次性安装。另一个容易忽略的点是 runc。在较新的 docker 版本中runc 被打包进了 containerd.io 或者作为独立依赖存在。如果目标机器的内核版本较老还需要确认 runc 版本是否兼容。常见做法是先用docker version看客户端和服务端版本再用containerd --version和runc --version确认底层运行时。2.2 docker-compose 的两种形态独立二进制与插件docker-compose 目前有两个流派。老版本是 Python 写的独立二进制docker-compose放在/usr/local/bin下用docker-compose up调用。新版本是 Go 重写的 compose v2作为 docker 的插件存在调用方式是docker compose up二进制文件通常放在/usr/libexec/docker/cli-plugins/或~/.docker/cli-plugins/下。离线准备时如果目标环境用的是 docker 20.10 以上版本建议直接准备 compose v2 插件因为 v1 已经停止维护而且 v2 在性能和对新 compose 文件格式的支持上更好。但要注意compose v2 插件对 docker 引擎版本有最低要求一般需要 docker 19.03 以上。如果目标机器上装的是更老的 docker就得退回 v1 独立二进制。下载 compose v2 插件时文件名通常类似docker-compose-linux-x86_64放到插件目录后需要重命名为docker-compose并赋予执行权限。这个细节在离线文档里经常被漏掉导致docker compose命令提示找不到插件。2.3 版本对齐别让 CLI 和守护进程打架一个血泪经验docker CLI 和 docker 守护进程的版本差得太远时会出现各种玄学问题。比如用 24.x 的 CLI 去连 19.03 的守护进程某些命令会报 “client version is too new” 或者 API 不兼容。所以离线包里docker-ce和docker-ce-cli的版本号必须一致。同样containerd.io 的版本也要和 docker 引擎匹配。docker 官方在每个 release note 里会写明推荐的 containerd 版本范围。如果随便拿一个最新版 containerd 配老版 docker可能出现容器启动后网络不通、cgroup 驱动不匹配等问题。我一般会这样做先确定目标机器要装的 docker 版本然后去官方下载页找到对应版本的包列表把docker-ce、docker-ce-cli、containerd.io、docker-compose-plugin四个包一起下载版本号全部对齐。如果是 rpm 系还要注意docker-ce-rootless-extras和docker-scan-plugin这类可选包不需要就不下避免依赖冲突。3. 离线下载与打包把安装包完整带到目标机器3.1 用官方源下载指定版本的 deb 包在有外网的机器上最稳妥的方式是通过 apt 的--download-only参数把包下载到本地缓存再打包带走。先配置好 docker 官方源然后执行# 创建下载目录 mkdir -p /tmp/docker-offline/packages cd /tmp/docker-offline/packages # 下载指定版本的 docker-ce 及其依赖不安装 apt-get download \ docker-ce5:24.0.7-1~ubuntu.22.04~jammy \ docker-ce-cli5:24.0.7-1~ubuntu.22.04~jammy \ containerd.io1.6.24-1 \ docker-buildx-plugin0.11.2-1~ubuntu.22.04~jammy \ docker-compose-plugin2.21.0-1~ubuntu.22.04~jammy # 查看下载了哪些文件 ls -lh这段命令的关键是apt-get download它只下载不安装而且会解析依赖。版本号里的5:是 epoch不能省略否则 apt 会认为版本不匹配。~ubuntu.22.04~jammy是发行版标识如果目标机器是 20.04就要换成~ubuntu.20.04~focal。下载完成后目录里会出现多个.deb文件。把它们全部拷贝到目标机器的一个目录下然后执行# 在目标机器上一次性安装所有 deb 包 sudo dpkg -i /path/to/packages/*.deb # 如果提示依赖缺失用以下命令修复但离线环境可能仍然缺依赖 sudo apt-get install -f注意dpkg -i不会自动解决依赖所以下载时必须把依赖包也下全。如果目标机器缺的依赖不在 docker 包里比如libseccomp2版本太低就需要额外下载系统依赖。这种情况在 CentOS 7 上尤其常见因为默认的 libseccomp 版本不满足 containerd 的要求。3.2 rpm 系发行版的下载与打包如果是 CentOS、Rocky Linux 或 Fedora用yumdownloader或dnf download来下载 rpm 包。先安装yum-utils然后# 创建目录 mkdir -p /tmp/docker-offline/rpms cd /tmp/docker-offline/rpms # 下载 docker-ce 及其依赖到当前目录 yumdownloader --resolve --destdir. \ docker-ce-24.0.7-1.el7 \ docker-ce-cli-24.0.7-1.el7 \ containerd.io-1.6.24-1.el7 \ docker-compose-plugin-2.21.0-1.el7 # 查看下载结果 ls -lh--resolve参数会递归下载所有依赖这是离线打包的关键。下载完成后目标机器上执行# 进入 rpm 所在目录一次性安装 sudo rpm -ivh *.rpm --nodeps --force # 或者用 yum 本地安装能自动处理依赖顺序 sudo yum localinstall *.rpm -y--nodeps --force是暴力安装不推荐除非你确认依赖已经满足。更稳妥的是yum localinstall它会按依赖顺序安装。但离线环境下 yum 可能仍然尝试联网所以最好加上--disablerepo*参数。3.3 docker-compose 独立二进制的下载与放置如果目标环境需要 compose v1 独立二进制直接从官方发布页下载对应架构的文件即可。假设下载的是docker-compose-linux-x86_64# 下载 compose v1 二进制示例版本号实际按需选择 curl -L -o docker-compose \ https://github.com/docker/compose/releases/download/v2.21.0/docker-compose-linux-x86_64 # 赋予执行权限 chmod x docker-compose # 放到系统 PATH 目录 sudo mv docker-compose /usr/local/bin/ # 验证 docker-compose --version如果是 compose v2 插件放置路径不同# 创建插件目录 sudo mkdir -p /usr/libexec/docker/cli-plugins/ # 下载并重命名 sudo curl -L -o /usr/libexec/docker/cli-plugins/docker-compose \ https://github.com/docker/compose/releases/download/v2.21.0/docker-compose-linux-x86_64 # 赋予执行权限 sudo chmod x /usr/libexec/docker/cli-plugins/docker-compose # 验证注意是 docker compose中间有空格 docker compose version这里的关键区别v1 是独立命令docker-composev2 是 docker 的子命令docker compose。放置路径错了命令就找不到。另外如果目标机器是 ARM 架构要把下载链接里的x86_64换成aarch64。4. 安装后的验证与常见问题排查4.1 安装完先别急着跑容器按顺序验证这四项装完包之后不要直接docker run hello-world先按顺序检查# 1. 检查 docker 服务状态 sudo systemctl status docker # 2. 检查 docker 版本信息确认客户端和服务端都正常 sudo docker version # 3. 检查 containerd 是否在运行 sudo systemctl status containerd # 4. 检查 runc 版本 runc --version如果docker version只显示 Client 不显示 Server说明守护进程没起来。常见原因是 systemd 服务文件没装好或者 containerd 没启动。用journalctl -u docker --no-pager -n 50看日志通常会提示具体原因。4.2 避坑离线安装 docker 和 compose 最常见的五个翻车点现象一docker compose提示 “docker: compose is not a docker command”。原因compose v2 插件没放到正确的插件目录或者文件名不对。 解决确认文件在/usr/libexec/docker/cli-plugins/docker-compose且权限是 755。如果放在~/.docker/cli-plugins/下只对当前用户生效。现象二dpkg -i安装时提示依赖libseccomp2版本过低。原因目标系统的 libseccomp 版本不满足 containerd 的最低要求。 解决在有外网的机器上下载对应发行版的libseccomp2新版本 deb 包一起带到目标机器安装。CentOS 7 上则可能需要升级libseccomprpm。现象三docker 服务启动失败日志显示 “failed to start daemon: error initializing graphdriver: overlay2 not supported”。原因目标机器的内核不支持 overlay2 存储驱动或者文件系统不是 ext4/xfs。 解决检查内核版本uname -r一般需要 4.x 以上。如果是 xfs确认挂载参数包含ftype1。实在不行在/etc/docker/daemon.json里把存储驱动改成vfs但性能会差很多。现象四docker-composev1 执行时报 “ImportError: No module named ssl_match_hostname”。原因v1 是 Python 写的依赖 Python 环境离线机器上缺 Python 模块。 解决这正是推荐用 compose v2 的原因。如果必须用 v1需要把对应的 Python 依赖也打包进去或者直接用 PyInstaller 打包的独立二进制。现象五安装完 docker 后普通用户执行docker ps提示权限不足。原因当前用户不在 docker 组里。 解决sudo usermod -aG docker $USER然后重新登录。注意这个操作在离线环境同样有效不需要联网。4.3 用 systemd 确认 docker 和 containerd 的启动顺序离线安装时有时候 containerd 的 systemd 服务文件没被正确安装导致 docker 启动时找不到 containerd 的 socket。检查两个服务文件是否存在# 检查 containerd 服务文件 ls -l /lib/systemd/system/containerd.service # 检查 docker 服务文件 ls -l /lib/systemd/system/docker.service # 如果 containerd 服务文件缺失手动重新加载 systemd sudo systemctl daemon-reload正常情况下docker.service 里会有Aftercontainerd.service和Requirescontainerd.service保证启动顺序。如果 containerd 没起来docker 会一直重试。用systemctl list-units | grep containerd确认服务是否被 systemd 识别。5. 批量交付时的一个实用技巧把安装包做成自解压脚本5.1 用 makeself 把 deb/rpm 和安装脚本打包成一个文件当需要把 docker 和 docker-compose 安装包分发到几十台机器时逐个拷贝 deb 包再手动安装效率太低。我一般会做一个自解压安装脚本把所有包和安装逻辑打包成一个.run文件目标机器上执行一次就完成安装。核心工具是makeself它能把一个目录打包成自解压的 shell 脚本。先准备好目录结构# 创建打包目录 mkdir -p /tmp/docker-installer/packages mkdir -p /tmp/docker-installer/scripts # 把之前下载的 deb 包复制进来 cp /tmp/docker-offline/packages/*.deb /tmp/docker-installer/packages/ # 编写安装脚本 cat /tmp/docker-installer/scripts/install.sh EOF #!/bin/bash set -e # 判断发行版 if [ -f /etc/debian_version ]; then echo 检测到 deb 系发行版开始安装... dpkg -i /tmp/docker-installer/packages/*.deb || apt-get install -f -y elif [ -f /etc/redhat-release ]; then echo 检测到 rpm 系发行版开始安装... yum localinstall -y /tmp/docker-installer/packages/*.rpm --disablerepo* else echo 不支持的发行版 exit 1 fi # 启动服务 systemctl daemon-reload systemctl enable containerd systemctl start containerd systemctl enable docker systemctl start docker # 验证 docker version docker compose version || docker-compose --version echo 安装完成 EOF chmod x /tmp/docker-installer/scripts/install.sh然后用 makeself 打包# 安装 makeself在有外网的机器上 # 如果离线机器没有 makeself可以直接用 tar 打包手动解压执行 # 使用 makeself 打包 makeself /tmp/docker-installer docker-installer.run \ Docker offline installer ./scripts/install.sh生成的docker-installer.run就是一个自包含的安装文件拷贝到目标机器后chmod x再执行即可。它会自动解压到临时目录运行安装脚本然后清理。5.2 验证自解压包在目标机器上的完整流程在目标机器上执行# 赋予执行权限 chmod x docker-installer.run # 执行安装 sudo ./docker-installer.run # 安装完成后验证 sudo docker run --rm hello-world如果hello-world能正常输出说明 docker 引擎、containerd、runc 全部就位。然后再验证 compose# 创建一个最简单的 compose 文件 cat /tmp/docker-compose-test.yml EOF services: web: image: nginx:alpine ports: - 8080:80 EOF # 启动 docker compose -f /tmp/docker-compose-test.yml up -d # 检查容器状态 docker compose -f /tmp/docker-compose-test.yml ps # 清理 docker compose -f /tmp/docker-compose-test.yml down这个验证流程能同时确认 docker 引擎和 compose 插件都正常工作。如果 compose 命令报错回到第 4 章的排查步骤重点检查插件路径和权限。5.3 一个容易忽略的细节安装包的架构匹配最后提醒一个我踩过的坑在 x86 机器上下载的包拿到 ARM 机器上装dpkg -i会直接报 “package architecture (amd64) does not match system (arm64)”。所以打包前一定要确认目标机器的架构。用uname -m查看x86_64对应 amd64aarch64对应 arm64。下载包时deb 包名里会带架构标识rpm 包名里也会带x86_64或aarch64。如果团队里两种架构的机器都有就分别打两个自解压包别混在一起。另外如果目标机器是国产化芯片平台比如某些基于 ARM 或 LoongArch 的环境docker 官方可能没有现成的包需要从发行版自己的源里找或者用社区维护的版本。这种情况我一般会先在一台样机上手动装通确认所有依赖都满足再把整个安装过程脚本化。离线交付这件事最怕的就是想当然多花十分钟在样机上验证比到了现场翻车再补救要划算得多。希望帮到你。本文还有配套的精品资源点击获取