简介面向开发、测试与运维场景的Docker及Docker Compose安装包适合在离线或内网环境中快速搭建容器平台。压缩包共4个文件主要包括Docker 27.3.1官方二进制tgz包、用于将Docker注册为系统服务的docker.service文件、一键执行环境配置与安装的shell脚本以及独立的docker-compose可执行文件整体大小约84.53MB。借助安装脚本使用者可一次性完成Docker守护进程的注册、服务启动与Compose工具的配置无需手动下载依赖或调整复杂参数。当前已有265人学习下载尤其适用于统一版本管控且无法直接访问外网的服务器环境。这套资源提供了一套可直接落地的容器环境安装方案能明显缩短环境准备时间让开发与测试人员更快将精力投入到容器化部署和业务验证中对维护统一容器环境的团队尤为实用。1. docker和docker-compose安装包解决的是离线和版本对齐问题很多人搜 docker 和 docker-compose 安装包其实是想要一套能离线复现、版本锁定的运行环境。尤其是内网交付、机房部署、给客户搭 demo 这类场景apt 源和 Docker Hub 都不可用安装包里的几个二进制文件反而成了最可靠的资产。这个标题要解决的问题有两层第一层是 Docker 引擎本身怎么装第二层是 docker-compose 这个编排工具怎么跟引擎对上版本。适合的人也很明确不想依赖 Docker Desktop 的图形界面希望用一条命令把环境拉起来、用一纸清单交付给同事的开发者或运维。2. 安装包里有什么引擎、CLI 与 compose 插件的真实关系“docker 和 docker-compose 安装包”从来不是一个文件而是一组配合使用的组件。Docker Engine 本身由 dockerd守护进程、docker CLI客户端、containerd容器运行时、runc低层运行器组成而 docker-compose 是独立分发的编排工具它可以作为独立二进制存在也可以作为 Docker CLI 的插件存在。这直接带来一个常见困惑你装完了 docker却找不到 docker-compose或者 docker-compose 装好了docker 命令调用不到它。要搞清楚这些先得明白安装包的形态差异和它们各自被放在什么位置。2.1 Docker Engine 安装包与 Docker Desktop 安装包两种形态怎么选常见的安装包形态是下面这几种选型时可以直接对照安装包形态包含内容适合场景主要缺点Docker Desktop 安装包exe/dmg引擎、CLI、compose 插件、Kubernetes、图形界面Windows / macOS 本机开发自带虚拟化黑匣子故障难排查不适合服务器Docker Engine 系统包deb/rpmdockerd、docker CLI、containerd、runcLinux 服务器、生产环境依赖关系需要自行处理手动下载的静态二进制docker CLI、dockerd、containerd 各自独立定制安装路径、离线交付需要自己管 systemd 服务文件docker-compose 插件二进制compose v2 单文件配合 Docker CLI 使用放错目录就不会被识别我一般会在服务器上明确放弃 Docker Desktop直接用 Linux 系统包或静态二进制。原因很简单Desktop 的 VM 层在 Linux 服务器上不存在反而会在 CI 环境里引入一堆无意义的资源占用而系统包能感知系统里已有的 iptables、systemd 等组件安装时自动给出依赖提示。Windows 上则反过来优先考虑 Docker Desktop 安装包因为它会把 WSL2 所需的虚拟化平台一并检查和处理省去手动配置的时间。但这不意味着装完就能用前置的虚拟化检测过了才轮得到安装包本身这一点在第四章的踩坑记录里单独展开。2.2 docker-compose v1 与 v2 插件装完到底调用哪个如果你搜过“docker-compose 下载”大概率会看到两种命令写法docker-compose up和docker compose up。这俩不是美观差异而是两代工具。v1 是 Python 写的独立程序安装后是/usr/local/bin/docker-compose这样的独立文件命令名带横杠。v2 是 Go 写的插件安装后放在 Docker CLI 的插件目录里命令名是docker compose中间有空格。v2 插件只认固定目录最常见的三个位置是~/.docker/cli-plugins/当前用户生效/usr/local/lib/docker/cli-plugins/全系统生效/usr/libexec/docker/cli-plugins/某些发行版系统包默认位置如果你用 apt 安装docker-compose-plugin这个包它会把插件放到/usr/libexec/docker/cli-plugins/docker-compose命令自然就是docker compose。如果你手动下载二进制常见的做法是放到/usr/local/lib/docker/cli-plugins/并赋予执行权限。放错位置的表现很典型docker compose version报docker: unknown command compose而docker-compose --version却能通过一个旧版 Python 程序返回结果。2.3 用命令确认你的安装包是否完整生效安装包装没装对不要看目录里有多少文件要看命令交互结果。下面的顺序是我每次装完都会跑的验证序列# 客户端与守护进程版本信息Server 部分不能缺 docker version # 查看存储驱动、镜像源等关键状态 docker info --format {{.ServerVersion}} driver{{.Driver}} # 确认 compose 插件是否被 CLI 识别 docker compose versiondocker version输出里如果只有 Client 没有 Server说明引擎守护进程没起来多半是插件或依赖有问题。docker info里的 Driver 字段在 Linux 上一般是 overlay2Windows 上可能是windowsfilter或linux的 WSL 后端。最后一条docker compose version能输出到 v2 的版本号才算整个“docker 和 docker-compose 安装包”闭环成功。提示不要用docker-compose --version替代上一条验证。它验证的是 v1 独立程序验证不了插件目录是否被 CLI 正确加载。3. 把安装包落到具体系统Linux 与 Windows 的落地命令从安装包这个词出发真正的问题往往是“我在当前这台机器上到底该怎么装”。这一章按两个主流平台拆开Linux 服务器Ubuntu/Debian 系最典型和 Windows 开发机。前者以 deb 安装包为主后者以 Docker Desktop 安装包为主两者都要兜住离线场景。3.1 Linux 在线与离线场景deb 安装包与依赖修复命令在 Ubuntu 上官方仓库装的是 docker-ce、docker-ce-cli、containerd.io、docker-buildx-plugin、docker-compose-plugin 这五个包。联网时用 apt 最省事但离线环境必须走 deb 文件手动安装。先把联网流程写清楚因为离线安装包的获取也依赖这套流程生成的源定义# 添加 Docker 官方 GPG key 与 apt 源 sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \ sudo gpg --dearmor -o /etc/apt/keyrings/docker-archive-keyring.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker-archive-keyring.gpg] \ https://download.docker.com/linux/ubuntu $(. /etc/os-release echo $VERSION_CODENAME) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin这段命令的核心是把下载地址绑定到当前系统版本代号比如 jammy22.04或 noble24.04。dpkg --print-architecture会返回 amd64 或 arm64保证拿到的 deb 包架构匹配。signed-by参数指定 keyring 文件路径避免 apt 警告无签名。离线环境没有 curl 到公网的条件做法是换一台能联网的同架构机器用 apt 把 deb 包全部下载下来再拷走# 在联网机器上下载全套 deb 包含依赖但不含已安装的系统基础库 mkdir -p docker-packages cd docker-packages apt-get download docker-ce docker-ce-cli containerd.io docker-compose-plugin apt-cache depends docker-ce | grep Depends | \ awk {print $2} | xargs apt-get download 2/dev/null第二段apt-cache depends的意图是拉取 docker-ce 的依赖列表把 iptables、libslirp0 这类运行期依赖一并下载。离线机器上安装时用dpkg -i遇到依赖缺失再apt-get -f install修复。这里有个很容易翻车的点apt-get download只下载包不解析依赖如果联网机器本身缺少某些依赖得到的目录就不完整。所以拷回去之后第一次安装失败不要慌看dpkg -i报错里列出的缺包名逐个补或者直接让 apt 自动修复一次。3.2 Windows 场景WSL2 前置检查与 Docker Desktop 安装包Windows 上装 docker 和 docker-compose 安装包本质是装 Docker Desktop WSL2 后端。搜“docker desktop 安装教程”的人一半会卡在虚拟化检测这一步。先跑一个前置检查脚本# 以管理员身份打开 PowerShell 执行 # 检查 WSL 是否安装以及版本是否为 2 wsl --status wsl --update # 检查虚拟化是否开启返回 True 才满足 Docker Desktop 条件 (Get-CimInstance Win32_ComputerSystem).HypervisorPresent # 若 Hyper-V 未启用开启后需要重启 bcdedit /set hypervisorlaunchtype autowsl --status输出的关键信息是“默认版本”是否为 2以及内核是否最新。Docker Desktop 的安装包本身不负责装 WSL它只检测环境。HypervisorPresent返回 True 说明虚拟化层可用返回 False 就先去 BIOS 打开 Intel VT-x 或 AMD-V。bcdedit那一条会在 Windows 引导配置里开启 Hypervisor 启动类型执行后必须重启。注意bcdedit /set hypervisorlaunchtype auto只适用于支持 Hyper-V 的 Windows 版本家庭版没有 Hyper-V 组件需要先通过“启用或关闭 Windows 功能”勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”。装好 Docker Desktop 安装包后首次启动如果看到 “Docker Desktop failed to start because virtualization support not detected”不要反复重装安装包问题几乎肯定出在 WSL 或 BIOS 层。在日常使用中用 WSL2 后端而不是 Hyper-V 后端资源占用会低很多这也是安装包默认推荐项。3.3 手动把 compose 二进制放进 cli-plugins 目录无论是离线还是在线我习惯再手动校验一次 compose 插件的位置。Linux 上下载的 compose 二进制安装方式如下# 创建一个全系统可访问的插件目录 sudo mkdir -p /usr/local/lib/docker/cli-plugins # 下载 compose v2 二进制替换为实际发布版本号 sudo curl -sSL \ https://github.com/docker/compose/releases/download/v2.29.7/docker-compose-linux-x86_64 \ -o /usr/local/lib/docker/cli-plugins/docker-compose # 赋予执行权限并将 v1 风格命令软链到同目录 sudo chmod x /usr/local/lib/docker/cli-plugins/docker-compose sudo ln -s /usr/local/lib/docker/cli-plugins/docker-compose /usr/local/bin/docker-composechmod x这步不能省插件没有执行权限则 Docker CLI 加载时直接跳过且不报错。软链docker-compose是为了兼容旧脚本——很多历史部署脚本还在调用带横杠的 v1 命令不软链这些脚本会报command not found。这里没有写死版本号细节实际落地时以你从官方 Release 页面拿到的文件名为准注意区分linux-x86_64和linux-aarch64。4. 安装包阶段的常见坑现象、根因与处置办法安装包装不上的时候用户最容易把锅甩给“安装包损坏”“系统不兼容”实际上绝大多数问题出在环境条件上。这章列五条我踩过的真实高频坑每条按现象、原因、解决的顺序展开Windows 和 Linux 各占一半。4.1 Windows 启动报 virtualization support not detected现象Docker Desktop 安装完成后启动界面直接弹错误明确写着 “virtualization support not detected”或者后来装好的环境在重启后消失。原因WSL2 需要 Windows 虚拟机平台而这依赖 CPU 虚拟化接口。最常见的情况是 BIOS 里的 Intel VT-x / AMD-V 没开其次是 Windows 功能里没勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”少一个都不行。解决先跑wsl --status看 WSL 是否可用不可用就wsl --install补全。再以管理员身份确认bcdedit /set hypervisorlaunchtype auto已执行。如果两条都对进 BIOS 打开虚拟化开关。最后的重启动作别省很多机器 BIOS 改动后必须断电重启才生效。每次遇到这个报错先按这个顺序排查比反复卸装 Docker Desktop 高效得多。4.2 Docker Desktop 提示 failed to connect to the docker api at npipe现象Windows 上执行docker info或docker ps返回failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxen。原因Docker CLI 连不上 Docker Desktop 内部的 Linux 引擎 socket。常见原因是 Desktop 还在启动过程中daemon 没就绪另一个原因是系统里存在多个 docker contextCLI 指向了错误的端点。解决先看任务栏鲸鱼图标是否还在转圈转圈就是没启动完等一会儿重试。稳定报错时执行docker context ls把当前 context 切回desktop-linuxdocker context use desktop-linux docker context ls如果docker context ls里根本看不到desktop-linux说明 Desktop 的 Linux 后端没起来。此时在 PowerShell 执行wsl --shutdown等待十几秒再重新打开 Docker Desktop一般能恢复。这个问题和安装包本身无关是 Windows 上引擎状态和 CLI 端点的匹配问题不要动安装文件。4.3 离线 deb 安装后 docker 命令全部报 shared libraries 缺失现象离线机器上dpkg -i docker-ce_*.deb成功后执行sudo docker run hello-world报error while loading shared libraries: libslirp.so.0或者systemctl start docker起不来journal 里全是依赖库缺失。原因dpkg -i不像 apt 那样自动解析下载依赖。docker-ce 依赖 iptables、libslirp0、libseccomp2 等一系列运行期库离线目录里漏掉任何一个都会翻车。我在 3.1 里写的apt-cache depends二次下载就是为这一步准备的但漏依赖仍是离线安装最频繁的坑。解决按报错库名反查包归属库名是libslirp.so.0就找libslirp0然后补齐 deb。补完执行sudo apt-get -f install -y sudo dpkg -i docker-ce*.deb docker-ce-cli*.deb containerd.io*.deb docker-compose-plugin*.deb systemctl restart docker systemctl status dockerapt-get -f install会修复损坏的依赖树顺便把能自动补的依赖从本地缓存装齐。如果离线环境没有 apt 缓存就用dpkg -i逐个尝试直到报错清单为空。这个坑的核心教训是离线安装包不是单个 deb而是一个依赖集合。4.4 用上国内镜像源后 docker pull 仍然卡住现象docker pull mysql:8.0长时间卡在 Pulling进度条不动或者下载到一半断开重试。原因默认的 Docker Hub 仓库源对部分网络环境不友好拉取大镜像时 TCP 连接被重置。常见做法是给 daemon.json 配置 registry mirror但很多人只写了镜像源地址没有重启 docker或者源地址本身失效了。解决在/etc/docker/daemon.json里加入 registry-mirrors 配置然后重启 docker 守护进程{ registry-mirrors: [ https://docker.mirrors.cloud.tencent.com, https://docker.mirrors.ustc.edu.cn ] }sudo systemctl daemon-reload sudo systemctl restart docker docker info | grep -A 5 Registry Mirrorsdocker info能直接看到当前生效的镜像源列表这是验证配置有没有生效最快的手段。内网环境不要配这段内网自有仓库直接填对应的镜像地址即可。配置好之后拉镜像仍然慢就检查是否是单层大镜像考虑用离线导出的 tar 包分发。4.5 docker 命令报 Permission denied 或 socket 权限错误现象Linux 上执行docker ps报permission denied while trying to connect to the Docker daemon socket。原因当前用户不在 docker 用户组里。docker 命令默认通过/var/run/docker.sock与 daemon 通信该 socket 归属于 root 和 docker 组。安装包装完只会自动创建 docker 组不会自动把你加进去。解决sudo usermod -aG docker $USER newgrp docker docker psusermod -aG把用户追加到 docker 组newgrp docker让当前会话立即生效避免重新登录。这里要给一个提醒docker 组等同于 root 权限任何能执行 docker 命令的用户都可以挂载宿主机目录、读写任意文件。在生产机器上只给真正需要管理容器的账号加这个组不要图方便把整个用户组都加进去。5. 把安装包固化成交付目录离线分发与验证到这一步你已经有了能跑的 docker 引擎和 compose 插件。但真正让“安装包”这个词产生价值的是把它变成一个可重复复制的交付目录让同事、客户在另一台机器上一条命令复现环境。5.1 离线交付目录的结构与文件清单我常用的交付目录长这样文件分类明确每个目录都有唯一职责目录/文件内容说明debs/所有 deb 安装包及依赖离线安装引擎的基础bin/compose 二进制、自定义脚本插件与辅助工具images/docker save导出的镜像 tar 包无需拉取公网镜像conf/daemon.json、docker-compose.yml运行时配置scripts/init-docker-env.sh一键初始化入口镜像导出环节常见做法是把编排文件里会用到的镜像全部先落到本地docker image save \ mysql:8.0 \ redis:7.2 \ elasticsearch:8.11.0 \ -o images/services.tardocker save支持多镜像打包到一个 tar-o指定输出文件。加载时用docker image load -i images/services.tar。这里注意save 和 load 是镜像层打包不会迁移容器数据和 compose 网络数据和配置仍然通过 volume 与 bind mount 单独传递。5.2 一键初始化脚本与验证命令初始化脚本的作用是让安装过程从“人肉敲 N 条命令”变成“执行一个 shell”核心逻辑是安装 deb、配置 daemon、加载镜像#!/usr/bin/env bash set -euo pipefail # 1. 安装引擎与依赖 sudo dpkg -i debs/*.deb || sudo apt-get -f install -y # 2. 放置 compose 插件 sudo mkdir -p /usr/local/lib/docker/cli-plugins sudo cp bin/docker-compose /usr/local/lib/docker/cli-plugins/ sudo chmod x /usr/local/lib/docker/cli-plugins/docker-compose sudo ln -sf /usr/local/lib/docker/cli-plugins/docker-compose /usr/local/bin/docker-compose # 3. 写入镜像源与日志配置 sudo mkdir -p /etc/docker sudo cp conf/daemon.json /etc/docker/daemon.json # 4. 启动引擎并加载镜像 sudo systemctl daemon-reload sudo systemctl restart docker sudo docker image load -i images/services.tar # 5. 用 compose 拉起编排栈 cd $(dirname $0) sudo docker compose -f conf/docker-compose.yml up -dset -euo pipefail让脚本在任一步出错时立即退出避免半初始化状态被误认为成功。dpkg -i || apt-get -f install的写法是先尝试直接安装失败则让 apt 修复依赖。最后一步docker compose up -d会按 compose 文件里的服务定义拉起整套容器。验证动作同样写死在脚本尾部最稳妥我会加一条健康检查sudo docker compose -f conf/docker-compose.yml ps sudo docker ps --format table {{.Names}}\t{{.Status}}看到所有服务状态为Up且没有Restarting这个安装包才算完整交付。GitLab、MySQL、Redis 这类重容器首次启动可能需要几十秒健康检查才通过不要一看到未就绪就重新执行脚本先docker logs看具体服务日志。我现在的交付习惯是在任何客户现场跑脚本之前先在本地干净虚机里完整执行一遍初始化脚本跑通了再打包带走。这一遍演练能提前暴露 deb 依赖漏项、镜像 tar 完整性、compose 文件路径引用错误这三类问题省得在别人机器上对着日志翻车。这个目录式的安装包方案维护成本很低每半年更新一次版本号重新制作即可希望帮到你。本文还有配套的精品资源点击获取