简介：这份资源面向需要在Linux环境下部署容器化应用的开发与运维人员，提供Docker与Docker Compose的离线安装包，解决内网或受限网络下无法直接拉取安装文件的问题。压缩包共4个文件，约84.53MB，包含tgz格式的Docker主程序安装包、docker-compose编排工具文件、docker.service系统服务单元以及install.sh安装脚本，覆盖从二进制部署到服务注册的完整环节，适合x86架构服务器使用。资源标签涉及测试场景，可用于搭建开发、测试与生产环境一致的容器运行环境，避免因环境差异导致的部署异常。目前已有266人学习下载，具备一定参考价值。通过其中的安装脚本与服务配置，读者可快速完成Docker引擎及Compose的本地化部署，省去逐条查找依赖与手动配置的步骤，也为后续多容器应用的编排管理打下基础。
1. 离线环境里，docker 和 docker-compose 安装包到底怎么选
上周帮一个做测试的朋友处理内网机器，他那边完全断外网，只有一台跳板机能拷文件进去。他问我：“docker 和 docker-compose 安装包到底下哪个？”这个问题其实问到了点子上——很多人第一次接触 docker 安装，直接去官网下了个 Docker Desktop 的 exe，结果装完发现内网机器根本拉不动镜像，或者 compose 命令压根不存在。docker 和 docker-compose 安装包不是同一个东西，Docker Engine 是运行时，docker-compose 是编排工具，两者版本要匹配，架构要对应，离线场景下还得提前把依赖库补齐。这份资源包解决的就是“手里有安装包，但不知道怎么选、怎么装、装完怎么验证”的问题。适合需要在 Windows 或 Linux 内网环境部署容器、又不想被在线安装器卡住的测试和运维人员。
2. Docker Engine 与 docker-compose 安装包拆解：版本、架构与依赖关系
2.1 安装包里到底有什么
拿到一个 docker 安装包，先别急着双击。以 Linux 为例，官方提供的静态二进制包通常包含dockerd、docker、containerd、runc、docker-proxy这几个可执行文件，外加docker.service和docker.socket两个 systemd 单元文件。docker-compose 则是一个独立的二进制文件，早期用 Python 写的，现在主流是 Go 重写的 v2 版本，文件名就叫docker-compose，放到/usr/local/bin/下加执行权限就能用。Windows 侧的 Docker Desktop 安装包本质是个大杂烩，里面塞了 WSL2 后端、Hyper-V 组件、Docker Engine、docker-compose 插件、Kubernetes 客户端，甚至还有一套图形界面。如果你只是想要命令行，装 Docker Desktop 会多出不少用不上的东西，但好处是省心——它帮你把 docker-compose 作为 CLI 插件注册好了，直接敲docker compose就能用。
这里有个容易混淆的点：docker-compose v1 和 v2 的命令形式不一样。v1 是docker-compose up，中间有横杠；v2 是docker compose up，中间是空格。安装包里如果只给了 v1 的二进制，你在新版 Docker Engine 上跑可能会遇到兼容性提示。常见做法是优先选 v2，除非你的脚本里写死了 v1 的调用方式。
2.2 版本匹配与架构确认
版本匹配这件事，说多了都是血泪经验。Docker Engine 20.10 之后的版本对 containerd 的版本有要求，如果你从旧环境拷了一个 19.03 的安装包，又混用了新版的 runc，启动时可能直接报failed to start daemon: error initializing runtime。docker-compose 这边，v2.0 到 v2.20 之间对 Compose 文件格式的支持也有差异，比如profiles字段是 2.1 之后才稳定的。我一般会先确认三件事：目标机器的 CPU 架构（x86_64 还是 arm64）、操作系统发行版和内核版本、以及是否已经有旧版 docker 残留。用uname -m看架构，用cat /etc/os-release看发行版，用docker version看是否已有安装。
提示：如果目标机器是 Windows 10 家庭版，Docker Desktop 需要 WSL2 后端，而 WSL2 又要求开启虚拟化。BIOS 里没开 VT-x 或 AMD-V 的话，装完会提示
virtualization support not detected，这个坑后面会细说。
2.3 离线安装的依赖补齐
离线安装最怕的不是主程序，而是动态链接库。docker-compose v2 是静态编译的，一般不需要额外库，但 Docker Engine 的dockerd依赖libz.so.1、libseccomp、libcgroup这些。如果目标机器是最小化安装的 Linux，很可能缺libz.so.1，运行时报error while loading shared libraries: libz.so.1: cannot open shared object file。解决办法是在同发行版的联网机器上用ldd dockerd列出所有依赖，把缺失的 so 文件一并拷过去，放到/usr/lib64/或/lib/x86_64-linux-gnu/下，再跑ldconfig刷新缓存。Windows 侧相对简单，Docker Desktop 安装包自带运行库，但 WSL2 内核更新包得单独下，这个在离线环境里容易被忽略。
3. 离线安装实操：从解压到 docker compose 跑通第一个服务
3.1 Linux 二进制包安装步骤
假设你拿到的是docker-24.0.7.tgz和docker-compose-linux-x86_64两个文件，目标机器是 CentOS 7 或 Ubuntu 20.04。先解压 docker 包，把二进制文件拷到系统路径，再注册 systemd 服务。
# 解压 docker 静态二进制包 tar -xzvf docker-24.0.7.tgz # 将可执行文件复制到系统路径 sudo cp docker/* /usr/bin/ # 创建 docker 用户组（如果不存在） sudo groupadd docker || true # 复制 systemd 单元文件（安装包里通常自带） sudo cp docker.service /etc/systemd/system/ sudo cp docker.socket /etc/systemd/system/ # 重新加载 systemd 配置并启动 docker sudo systemctl daemon-reload sudo systemctl enable docker sudo systemctl start docker # 验证 docker 是否正常运行 sudo docker version这段脚本的逻辑很直白：解压、拷贝、注册服务、启动。关键参数在docker.service里，默认的ExecStart指向/usr/bin/dockerd，如果你把二进制放到了别处，得改这个路径。另外docker.socket负责监听/var/run/docker.sock，少了它，客户端连不上守护进程。启动后docker version能同时看到 Client 和 Server 两段信息，才算真正跑通。如果只显示 Client，说明守护进程没起来，用journalctl -u docker -n 50看日志。
3.2 docker-compose 二进制部署与验证
docker-compose 的安装更简单，一个文件拷过去加执行权限就行。
# 将 docker-compose 二进制放到系统路径 sudo cp docker-compose-linux-x86_64 /usr/local/bin/docker-compose # 赋予执行权限 sudo chmod +x /usr/local/bin/docker-compose # 验证版本 docker-compose version # 如果要用 v2 的 docker compose 形式，可以创建软链接 sudo ln -sf /usr/local/bin/docker-compose /usr/local/bin/docker-compose-v2这里有个细节：docker-compose version输出里会显示 Compose 版本和 Docker Engine 版本。如果 Compose 版本是 v2.x，但命令还是docker-compose带横杠，说明你用的是独立二进制，不是 Docker CLI 插件。两种方式都能用，但插件方式更推荐，因为docker compose能自动读取 Docker 上下文配置。要启用插件方式，把二进制放到~/.docker/cli-plugins/docker-compose或/usr/local/lib/docker/cli-plugins/docker-compose，然后docker compose version就能识别。
3.3 用 docker compose 拉起一个测试服务
装完不跑个服务等于没装。写一个最简的docker-compose.yml，用 nginx 做验证，因为 nginx 镜像小、启动快、依赖少。
version: "3.8" services: web: image: nginx:alpine ports: - "8080:80" volumes: - ./html:/usr/share/nginx/html:ro restart: unless-stopped这个文件定义了一个叫web的服务，用nginx:alpine镜像，把宿主机 8080 端口映射到容器 80，挂载一个只读的 html 目录，重启策略是除非手动停止否则自动重启。在离线环境里，你得提前把nginx:alpine镜像导出成 tar 包，用docker load -i nginx-alpine.tar加载进去，否则docker compose up会卡在拉取镜像那一步。
# 加载离线镜像 docker load -i nginx-alpine.tar # 启动服务 docker compose up -d # 查看服务状态 docker compose ps # 测试访问 curl http://localhost:8080docker compose up -d里的-d是后台运行，不加的话日志会直接打在终端上。docker compose ps能看到容器状态和端口映射。如果 curl 返回 nginx 欢迎页，说明整条链路通了。失败的话先看docker compose logs web，再检查镜像是否加载成功、端口是否被占用。
4. 避坑排查：离线安装 docker 和 compose 的五个翻车现场
4.1 启动报错 libz.so.1 找不到
现象：执行dockerd或docker-compose时提示error while loading shared libraries: libz.so.1: failed to map segment from shared object。原因：目标系统缺少 zlib 库，或者库文件权限不对。解决：从同发行版的联网机器上拷贝libz.so.1到/usr/lib64/，执行sudo ldconfig，再用ldd $(which dockerd)确认所有依赖都能解析到。如果还不行，检查LD_LIBRARY_PATH是否被改过。
4.2 Docker Desktop 提示 virtualization support not detected
现象：Windows 上安装 Docker Desktop 后启动失败，弹窗提示virtualization support not detected或Docker Desktop failed to start because virtualisation support wasn't detected。原因：BIOS 里 CPU 虚拟化没开，或者 Hyper-V 与 WSL2 冲突。解决：重启进 BIOS 开启 Intel VT-x 或 AMD-V；Windows 功能里确保“虚拟机平台”和“适用于 Linux 的 Windows 子系统”都勾上；如果之前装过 VirtualBox 或 VMware，先关掉它们的虚拟化加速，避免抢占。
4.3 docker compose 命令找不到
现象：装完 docker-compose 二进制，敲docker compose提示docker: 'compose' is not a docker command。原因：二进制放的位置不对，Docker CLI 插件目录没识别到。解决：把文件放到/usr/local/lib/docker/cli-plugins/或~/.docker/cli-plugins/，文件名必须是docker-compose，然后chmod +x。用docker info看 CLI 插件路径，确认放对了地方。
4.4 离线加载镜像后 compose 仍然拉取
现象：已经docker load了镜像，但docker compose up还是去连 registry，超时后报错。原因：compose 文件里写的镜像名和本地加载的镜像 tag 不一致，或者写了build指令。解决：用docker images看本地镜像的准确名称和 tag，把 compose 文件里的image字段改成完全一致；如果服务定义里有build，离线环境要删掉或改成image引用。
4.5 容器启动后端口不通
现象：docker compose ps显示容器 Up，但 curl 宿主机端口没反应。原因：防火墙没放行，或者端口映射写成了127.0.0.1:8080:80只监听本地。解决：检查firewalld或iptables规则，临时用sudo systemctl stop firewalld排除；compose 文件里端口映射写成"8080:80"而不是"127.0.0.1:8080:80"，前者监听所有网卡。另外确认容器内服务确实在监听 80 端口，用docker exec -it <容器名> netstat -tlnp看一眼。
5. 进阶技巧：用 docker save/load 做离线镜像仓库与版本回滚
离线环境里最头疼的不是装 docker，而是后续怎么更新镜像。我一般会在联网机器上把需要的镜像批量导出成 tar 包，按镜像名-版本.tar命名，拷到内网后统一docker load。但这里有个效率问题：每次更新都传整个镜像，几个 G 的文件拷来拷去很折磨人。一个取巧的办法是用docker save的--output参数配合gzip压缩，能省不少空间。
# 联网机器上导出镜像并压缩 docker save nginx:alpine | gzip > nginx-alpine.tar.gz # 内网机器上解压并加载 gunzip -c nginx-alpine.tar.gz | docker load # 批量导出多个镜像 docker save -o all-images.tar nginx:alpine mysql:8.0 redis:7.0docker save后面可以跟多个镜像名，导出的 tar 包会包含所有层。加载时docker load -i all-images.tar会一次性导入。注意docker save和docker export不是一回事：save保留镜像的完整历史和元数据，export只导出容器的文件系统快照，后者加载后是镜像但丢了层信息，不推荐用于离线分发。
版本回滚也是离线场景的刚需。假设你更新了 mysql 镜像，发现新版本有兼容问题，想退回旧版。如果旧版镜像还在本地，直接改 compose 文件里的 tag 就行；如果已经被docker rmi删了，就得重新docker load旧版 tar 包。我习惯在加载新镜像前先docker tag给旧镜像打个备份标签，比如mysql:8.0-backup，这样回滚时不用重新传文件。
注意：
docker save导出的 tar 包不包含镜像的 tag 信息，加载后可能显示为<none>:<none>。解决办法是在导出前先docker tag成目标名称，或者加载后用docker tag重新打标签。
还有一个验证技巧：加载完镜像后，用docker run --rm <镜像名> <命令>跑一个一次性容器，确认镜像能正常启动。比如docker run --rm nginx:alpine nginx -v，能输出版本号就说明镜像完整。这个习惯帮我省过好几次事——有一次 tar 包传输过程中损坏，加载没报错但启动就崩，用这个方法当场就发现了。
从那以后我每次离线部署 docker 和 docker-compose，都强制走一遍“ldd 查依赖 → docker load 后跑一次性容器 → compose up 后 curl 验证”的流程，再也没在客户现场翻过车。希望帮到你。
本文还有配套的精品资源，点击获取
