简介一份面向Docker初学者与运维开发者的容器编排工具安装指南PPT课件聚焦docker-compose的两种主流安装方式。课件先介绍Docker Compose如何按docker-compose.yml规范文件一次性启动多个具依赖关系的容器解决手动启动多服务耗时易错的问题再分步演示下载软件包方式安装包括使用curl获取2.16.0版本安装包、添加可执行权限并查看版本号以及使用源码仓库/Yum源安装docker-compose-plugin插件并对两种方式的实际命令差异docker-compose -v与docker compose -v进行对比帮助读者避免混淆。资源包共1个pptx文件约263KB内容以图文步骤、命令示例和对比说明为主结构清晰单文件体量轻便下载后即可直接用于课堂教学或自学翻阅。已有158人学习下载能为需要搭建Compose环境的读者提供直接可用的操作思路尤其适合在实验环境中边看边练。1. 安装 Docker Compose 这件事为什么值得单独写一页 PPT当一份培训材料的标题落到「Docker容器技术-安装Docker-compose.pptx」说明你已经越过了 docker run 单容器这把新手村武器开始琢磨怎么让一堆容器像一台机器那样被编排起来。你可能是正在补 Docker 入门教程的开发者也可能是接手微服务项目部署的运维两者都会遇到同一类尴尬教程让装 Compose但有的环境装了用不了有的环境根本不提示要装。这篇笔记把 Docker Compose 的安装路径拆成 Linux、Windows、macOS 三条线讲清楚哪些环境自带、哪些需要手动、装完怎么快速验证以及五处最容易让人翻车的细节。2. 安装前先分清三种环境Compose 是插件还是独立程序取决于 Docker 是怎么来的很多人安装 Docker Compose 失败问题不在命令而在没搞清楚自己这台机器上的 Docker 是哪种形态。Docker 这东西现在有两个完全不同的家族Docker Engine 是纯命令行时代的产物只包含 dockerd 守护进程和 docker 客户端Docker Desktop 是带图形界面的整套环境把虚拟机、引擎、插件都给你打包好了。Compose 在这两类环境里的存在形式完全不同安装策略也跟着不同。在 Docker Engine 里Compose v2 是一个「CLI 插件」docker 命令会去几个固定目录找它在 Docker Desktop 里Compose 是内置组件装好 Desktop 就等于装好了 Compose。如果你不先分清这一点很容易出现两种尴尬一是按 Linux 教程在 Windows 上手动装 exe结果跟 Desktop 自带的版本打架二是按 Windows 教程在 Linux 服务器上找 GUI 设置找了半天发现根本没有。2.1 Linux 服务器Docker Engine 默认不带 Compose需要单独装Debian、Ubuntu 上通过系统源装 docker.io或者通过 Docker 官方仓库装 docker-ce都不会自动带上 Compose 插件。docker.io 是发行版自己打包的版本通常比较旧docker-ce 是 Docker 官方维护的版本更新及时。无论哪一种装完以后 docker 命令能跑但 docker compose 会提示 command not found这是完全正常的不代表你装错了 Docker。CentOS 和 RHEL 上的情况类似yum install docker 装出来的是老版本 Engine同样不带 Compose。所以在 Linux 上安装 Docker Compose 永远是一个独立的步骤这一步的细节我会在第 3 章展开。这里先记住一个结论别拿 docker -v 的输出当成一切正常docker -v 只说明客户端在服务端和插件是两回事。2.2 Windows 与 macOSDocker Desktop 已经内置 Compose别再手动装一套Docker Desktop 从 2.x 版本开始就把 Compose v2 作为内置组件带上了。在 Windows 或 macOS 上装好 Desktop打开终端敲 docker compose version基本都能直接看到版本输出。问题往往出在「教程说要去下载 docker-compose 文件」——如果你在 Windows 上还去下载一个 docker-compose.exe 手动放进 PATH等于给系统里塞了两套 Compose将来项目里到底用的是哪一套就成了一个说不清楚的黑匣子。Windows 上更常见的翻车是 Desktop 本身起不来。比如报错 virtualizaton support not detected, docker desktop failed to start because v...原文是 virtualization support not detected这说明 BIOS 里的虚拟化功能没开或者 Windows 的虚拟机平台组件没启用。再比如 failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxen这说明 Desktop 的引擎服务没跑起来compose 命令自然连不上。这些问题不是 Compose 的锅是 Docker Desktop 的运行环境没就绪得先解决底盘再看 compose。2.3 先跑三条命令确认你的 Docker 底盘是不是干净的不管哪条安装路线我都建议先执行下面这三条命令把环境摸清楚再动手# 查看客户端和服务端版本判断 Docker 是否真的可用 docker version # 只看服务端版本避免客户端和服务端混装造成的误判 docker info --format {{.ServerVersion}} # 检测 compose 插件是否已经存在 docker compose version第一条命令会分别输出 Client 和 Server 两段信息。如果 Server 段报错说明守护进程没起来常见原因包括 dockerd 没启动、当前用户没有 socket 权限或者系统里根本没有装服务端。第二条命令用 --format 只取服务端版本号这在排查「客户端新版、服务端旧版」这类混装问题时很管用比如客户端是 26.x 但服务端还是 19.x很多新语法都会莫名失败。第三条命令如果报 command not found就说明 Compose 还没装或没被 docker 识别到接下来按环境选安装方式。下面把三种典型环境的情况汇总一下运行环境Docker 形态Compose 是否内置推荐安装方式Ubuntu/Debian 服务器Docker Enginedocker-ce否用 apt 安装 docker-compose-pluginCentOS/RHEL 服务器Docker Enginedocker-ce否下载二进制放入 cli-plugins 目录Windows 10/11Docker DesktopWSL2 后端是无需安装检查 Desktop 是否启动macOSDocker Desktop是无需安装检查 Desktop 是否启动这个表是我处理过的绝大多数机器的情况。如果你是 Ubuntu 服务器、Windows 笔记本各一台两条路线的操作完全不同后面两章就按这个表分别展开。3. Linux 上安装 Docker Compose v2三种方式推荐顺序与适用边界Linux 是 Docker Compose 使用率最高的环境也是安装方式最多、最容易混淆的环境。常见做法有三种用 apt 装官方插件包、下载二进制放入插件目录、用 pip 装独立程序。我一向推荐的顺序是apt 插件优先二进制其次pip 只在老项目里才碰。下面把每种方式的操作和适用场景说透。3.1 方式一推荐用 apt 安装 docker-compose-plugin如果你的机器已经通过 Docker 官方仓库装好了 docker-ce那么装 Compose 只需要一条命令加一个重启 docker不需要下载任何东西# 前提docker-ce 已通过官方仓库安装 sudo apt-get update sudo apt-get install -y docker-compose-plugin # 重载并验证 sudo systemctl restart docker docker compose version这个包会把 compose 插件放到 /usr/libexec/docker/cli-plugins/ 目录下文件名是 docker-composedocker 命令启动时会自动扫描该目录并把 docker compose 注册为子命令所以你不需要改 PATH也不需要管 /usr/bin 下有没有 docker-compose 文件。为什么说这是最推荐的方式因为它是官方仓库直接分发的版本与 docker-ce 一并维护卸载干净升级只要 apt upgrade不会出现二进制文件权限、路径冲突这类问题。需要注意一个前提apt 方式的唯一要求是 docker-ce 来自官方仓库。如果你是用系统自带的 docker.io 装的 Docker这个包装上去可能找不到对应版本的引擎因为 docker.io 的插件目录结构与官方包不完全一致。碰到这种情况建议先确认 docker-ce 的仓库已经配置好再回来执行上面的命令。3.2 方式二二进制方式适合 CentOS 或需要指定版本的场景CentOS、RHEL 以及一些没有官方 apt 仓库的发行版没有 docker-compose-plugin 可装最可靠的方式是把 compose 的二进制文件下载到 Docker 的插件目录让 docker 自动识别# 创建插件目录 sudo mkdir -p /usr/local/lib/docker/cli-plugins # 下载 compose v2 二进制版本号以官方 releases 页面为准 sudo curl -SL \ https://github.com/docker/compose/releases/download/v2.32.1/docker-compose-linux-x86_64 \ -o /usr/local/lib/docker/cli-plugins/docker-compose # 赋执行权限 sudo chmod x /usr/local/lib/docker/cli-plugins/docker-compose # 验证 docker compose version逻辑说明/usr/local/lib/docker/cli-plugins 是 Linux 上 CLI 插件的用户级目录Docker 会优先扫描它然后是系统级的 /usr/lib/docker/cli-plugins。文件名必须是 docker-compose不带架构后缀否则 docker 不会把它识别成 compose 子命令。curl 的 -S 参数让出错时显示错误信息-L 参数跟随 GitHub 重定向少了 -L 经常下载出来一个 404 页面还浑然不觉。参数说明v2.32.1 只是示例版本号实际安装前先到 Docker Compose 的官方 releases 页面确认最新版本别拿着旧教程里的版本号硬装。CPU 架构也要注意x86_64 对应 Intel/AMD 的常规服务器ARM 架构的机器要改成 docker-compose-linux-aarch64。下载慢或者超时的时候可以试着用国内可达的镜像源下载但记得核对 sha256 校验值避免拿到被改过的文件。3.3 方式三pip 安装 docker-compose为什么我一般不建议搜索引擎里偶尔还能看到sudo pip3 install docker-compose这样的命令它能装出一个叫 docker-compose 的独立程序。问题在于pip 上这个包是 Compose v1基于 Python 的 docker-py 库开发依赖链又长又深跟系统里的 Python 包很容易互相顶掉版本。而且 Compose v1 在 2022 年就进入了维护冻结期官方明确不再加新功能只修安全漏洞。我不建议在新环境里用 pip 装不是因为装不上而是因为将来你照着 v2 的文档写 compose.yamlv1 解析器可能会对某些字段报错比如新版才支持的 depends_on.condition 写法。如果你的团队有老项目还在用 docker-compose up 这种命令而且没有迁移预算那这条路线可以作为过渡但至少要把 docker-compose 的可执行路径和 v2 插件的路径分开避免互相覆盖。3.4 装完先对齐版本docker compose 与 docker-compose 是两个程序装完之后建议同时执行下面两条命令对比一下# 查看 compose v2 插件版本 docker compose version # 查看是否有独立的 compose v1 程序 docker-compose version如果第一条有输出而第二条报 command not found说明环境里只有 v2 插件这是最清爽的状态。如果两条都有输出说明 v1 独立程序和 v2 插件共存这时候要特别小心脚本里写的是 docker compose 还是 docker-compose两者解析同一个 YAML 文件时可能给出不同结果。从命令格式就能看出区别docker compose 是 docker 的子命令由 CLI 插件机制提供docker-compose 是一个独立可执行文件。接下来所有项目和自动化脚本建议统一用 docker compose 这种 v2 写法别让两种命令混在同一个 CI 里。4. Windows 与 macOS 上装 Docker ComposeDesktop 已内置重点在校对运行环境Linux 之外的机器绝大多数人用的是 Docker Desktop。这份标题既然叫「安装 Docker Compose」那 Windows 和 macOS 上的安装动作其实很轻Desktop 装好即自带真正的工夫花在让 Desktop 正常跑起来以及避免在 WSL2 里重复安装造成版本混乱。4.1 WindowsDocker Desktop 内置 Compose但先解决两个启动报错Windows 上安装 Docker Desktop 之后Compose 就已经在系统里了。打开 PowerShell 或 CMD 执行 docker compose version正常能看到 v2 版本号。如果报错九成是 Desktop 本身没起来而不是 Compose 没装。最常见的两条报错一条是 virtualization support not detected一条是 failed to connect to the docker api at npipe。第一条报错的意思是 Windows 的虚拟化支持没有打开。Docker Desktop 在 Windows 上靠 Hyper-V 或 WSL2 跑 Linux 虚拟机BIOS 里的 Intel VT-x 或 AMD-V 必须开启同时系统功能里的「虚拟机平台」和「适用于 Linux 的 Windows 子系统」要勾选上。解决步骤是重启进 BIOS 打开虚拟化然后在「启用或关闭 Windows 功能」里勾上对应组件重启电脑再启动 Desktop。第二条报错通常是 Desktop 的引擎服务没起来或者 WSL2 内核出了问题可以先右击系统托盘里的 Docker 图标选择 Restart还不行就在 PowerShell 里执行 wsl --shutdown把 WSL2 虚拟机整个关掉重来。4.2 WSL2 后端与 Hyper-V 后端compose 网络行为不一样Docker Desktop 有两种后端默认是 WSL2老版本用的是 Hyper-V。WSL2 的好处是资源开销小容器和 Windows 文件系统互通方便Docker 的 socket 通过 npipe 暴露给 Windows 进程Hyper-V 是传统虚拟机方案隔离更彻底但资源占用高。对 Compose 来说后端选择直接影响网络行为。在 WSL2 模式下compose 创建的 bridge 网络跑在 WSL2 虚拟机内部Windows 宿主机访问映射端口时走的是 localhost一般不需要额外设置。但有一个坑很常见Windows 防火墙偶尔会拦下容器映射出来的端口现象是浏览器访问 localhost:8080 转圈而容器内部 curl 一切正常。排查思路是去 Windows 防火墙放行 Docker Desktop 相关的程序而不是去 compose 文件里改端口。另外如果你在设置里切到了 Windows 容器模式那 compose 文件里的 Linux 镜像全部起不来报错信息会提示镜像平台不匹配。这个模式的切换在 Desktop 的 Settings 里日常使用 Linux 容器模式就够了。4.3 在 WSL2 里再装一套 Compose版本冲突的根源很多人在 Windows 上装完 Desktop 之后又打开 WSL2 的 Ubuntu 终端照着第 3 章的命令再装一遍 Docker 和 Compose结果系统里出现两套环境。WSL2 发行版本身的 docker 命令连的是 WSL2 里自己启动的 dockerd而 Windows 侧 docker 命令连的是 Desktop 的引擎两边互不相认。我一般建议装了 Desktop 就别在 WSL2 里重复装 Engine直接使用 Desktop 提供的 docker 命令。如果在 WSL2 里跑构建脚本时才发现调用的 docker 是另一套可以用 docker context ls 查看当前上下文再用 docker context use desktop-linux 切回 Desktop 的引擎。Compose 的版本冲突同理Desktop 自带的 compose 插件和 WSL2 里 apt 装的那一套属于同一文件结构里的不同来源PATH 顺序决定调用了谁。最省事的做法是把 WSL2 里的 docker-ce 卸载干净统一走 Desktop让 docker compose version 只输出一个确定的版本。5. 安装 Docker Compose 的避坑清单五个常见翻车现场与排查方法这一章写给已经把命令敲下去、结果不顺利的人。我整理了五个反复出现的安装踩坑场景每条按「现象 → 原因 → 解决」的顺序写方便你直接对照。5.1 现象docker compose 命令找不到执行 docker compose version 直接提示 command not found。这种情况在 Linux 上最常见。原因是多方面的要么 compose 插件压根没安装要么装了但放错了目录比如把二进制放到了 /usr/local/bin/ 而不是 cli-plugins 目录还有一种可能是你用的是系统自带的 docker.io它的 CLI 插件目录和官方 docker-ce 不一致识别不到新放进去的插件。解决方法是先执行 docker info 查看输出末尾的 Plugins 段落如果里面没有 compose说明插件没被扫描到。然后按照第 3 章的方式重新安装Ubuntu 用 docker-compose-plugin 包其他发行版把二进制放进 /usr/local/lib/docker/cli-plugins/ 并确认文件名是 docker-compose再执行 chmod x。注意手动创建的目录属主要处理好否则 docker 可能因为目录权限拒绝扫描。5.2 现象docker compose version 与 docker-compose version 版本不一致两个命令都返回结果但版本号不同甚至一个显示 v2 一个显示 v1。这说明环境里同时存在 CLI 插件和独立程序。原因是历史遗留早期安装 docker-compose 用的是 pip 或二进制放到 /usr/local/bin后来新项目引入了 compose v2 插件两者并存在 PATH 或插件目录的不同位置。解决的关键是统一命令风格。新写项目全部用 docker compose up 这种带空格的 v2 语法老脚本如果依赖 docker-compose 命令要么明确锁定 v1 版本不动要么做一次迁移。我个人的习惯是只在 .bashrc 里保留一个别名 docker-composedocker compose不让 v1 独立程序继续参与解析这样至少行为可预期。如果你在 CI 里同时用两套命令早晚会在 depends_on 写法这类差异上翻车。5.3 现象权限错误 permission denied while trying to connect to the Docker daemon socket执行 docker compose up 报出连接 /var/run/docker.sock 权限不足。原因是当前用户不在 docker 组里docker.sock 的默认权限只允许 root 和 docker 组成员访问。很多教程里用 sudo docker 临时绕过去了但 sudo 也会带来新问题比如 sudo 环境下的 HOME 变了compose 项目里依赖 HOME 的路径会跟着漂移。解决的规范做法是把当前用户加入 docker 组然后重新登录使组生效# 添加当前用户到 docker 组 sudo usermod -aG docker $USER # 重新登录后验证 docker info这里要提醒一句别图省事直接 chmod 777 /var/run/docker.sock。那样任何进程都能操作 Docker等于把本机所有容器当成了公共后花园生产环境这么做是给自己埋雷。重新登录后如果组仍然没生效可以执行 newgrp docker 临时切换到新组再看。5.4 现象镜像下载慢或者直接超时compose 文件写好了docker compose up 拉镜像时卡住或者报 EOF 错误。原因是默认从 Docker Hub 拉取镜像网络链路不佳时经常断流。这类问题跟 Compose 本身没有关系但会让你的第一次体验非常糟糕很多人误以为 Compose 装坏了。解决方法是给 Docker 配置镜像加速。编辑 /etc/docker/daemon.json加入 registry-mirrors 配置然后重启 docker{ registry-mirrors: [ https://your-mirror-address ] }镜像加速地址可以从国内云厂商的容器镜像服务控制台获取个人用户一般是免费额度申请后复制专属地址填进去。注意重启之后要执行 systemctl daemon-reload 再 restart docker避免配置没被重新读取。配置完成后docker info 的输出里会多出 Registry Mirrors 一栏可以看到生效的加速地址列表。如果公司内网有私有的镜像仓库还可以在 daemon.json 里加 insecure-registries让 Docker 跳过 HTTPS 校验直接通过 HTTP 拉取内网镜像。5.5 现象compose 启动后容器间网络不通docker compose up -d 一切正常但容器之间通过 IP 访问失败或者宿主机访问不到容器端口。这类问题排在安装之后出现也很容易被人误归因到 Compose 版本上。原因是 compose 默认创建了一个 project 级别的 bridge 网络服务之间应该用服务名互相访问而不是用容器 IP宿主机访问则要用映射端口而不是容器内端口。排查路径是先 docker compose ps 看端口映射列是否显示 0.0.0.0:8080-80/tcp 这样的输出再用 docker compose exec 进入目标容器用 curl 或 getent hosts 验证服务名解析如果宿主机访问不通检查防火墙是不是拦了映射端口。这里给一个实用的结论在 compose 项目里服务名就是 DNS 名这是网络编排的核心设计直接用 IP 等于绕过编排本身迟早出问题。6. 装完别急着跑用最小 compose.yaml 验证编排能力再决定要不要上微服务6.1 最小验证一个 nginx 加 redis 的 compose 文件安装完成后我习惯用最短的 YAML 验证整条链路是否正常而不是直接套用复杂的微服务模板。下面这个文件不需要任何额外配置services: web: image: nginx:1.27-alpine ports: - 8080:80 depends_on: - cache cache: image: redis:7-alpine保存为 compose.yaml 后执行docker compose up -d docker compose ps逻辑说明这个文件故意不写 version 字段因为 Compose v2 已经废弃了顶层的 version 声明写了反而会收到 deprecation 提示。web 服务映射 8080 端口到容器 80cache 服务不对外映射只在项目网络内部暴露 6379。depends_on 让 cache 先启动web 后启动虽然这个例子不真的使用 redis但能验证编排顺序是否生效。执行 docker compose ps 时如果两行都显示 running 或 healthy说明 compose 安装和配置基本没有问题可以放心进入下一阶段。6.2 从 v1 迁移到 v2 的三个注意点如果你过去用的是 docker-composev1现在切到 docker composev2有三个地方要主动改一是去掉 YAML 顶层的 version: 3.8 这类声明v2 不需要二是 depends_on 的 condition 写法升级了v1 里只能控制启动顺序v2 可以加 condition: service_healthy 搭配 healthcheck 使用三是环境变量插值语法保持一致都是 $VAR 和 ${VAR:-default}但 v1 对特殊字符的容错更差。验证完最小文件后再看你的真实需求。如果目标是 docker 部署微服务项目下一步值得研究的方向是用 docker compose scale 扩展无状态服务、给服务加 healthcheck、用多个 compose 文件通过 -f 参数做环境区分以及把镜像构建纳入 CI 流程。这些都是同一套命令体系自然延伸出来的能力也就是 PPT 标题背后真正要撑住的东西。我自己的习惯是任何时候接到一台陌生机器先 docker version 看服务端再看 docker compose version 看插件两个都正常才开始写 YAML。安装顺序没理顺的时候排查问题会同时面对 Docker 引擎和 Compose 两重不确定性等于把黑匣子叠着用翻车了都说不清元凶。版本这件事没有后悔药装错一套不如晚动手两分钟。希望帮到你。本文还有配套的精品资源点击获取