简介这份 PPT 专为需要安装 Docker Compose 的 Docker 学习者、运维人员和开发工程师准备聚焦容器编排工具在 Linux 环境下的部署方法。内容依次讲解 Docker Compose 的基本概念与作用、通过下载官方软件包快速安装、通过源码仓库安装插件三种模块并专门对比两种方式安装后 docker-compose 与 docker compose 命令的差异帮助读者理解不同环境下的正确命令形式。在软件包方式下涉及 curl 下载、chmod 赋予可执行权限以及 docker-compose -v 版本验证在仓库源方式下则使用 yum 安装 docker-compose-plugin再通过 docker compose -v 验证两种方式都围绕让 compose 工具可用这一目标展开适合在真实服务器环境中边看边练。资料包仅含 1 个 PPTX 文件约 263KB轻量便于阅读可作为课堂演示或自学笔记使用。当前已有 158 人学习下载适合希望快速掌握 Docker Compose 安装流程、避免命令行混淆的入门与进阶用户。1. Docker 容器技术从“装个 Docker”到“compose 跑通”很多人以为 Docker 容器技术的安装难点在 Docker 本身实际上真正卡人的往往是 docker-compose 那一步命令在、版本号也打出来了一 up 就报 shared libraries 缺失或者 permission denied。我帮同事排过的安装问题里十有八九不是镜像拉不下来就是 compose 依赖库或权限不对。这份《Docker容器技术-安装Docker-compose》PPT 把从 Docker Engine 到 Compose 的安装链路作为主线恰好覆盖当前这几个高频翻车点。照着它装一次你收获的不只是两个命令能跑而是一套排查安装问题的固定思路。适合刚接触容器、被环境折腾过的新手也适合要准备团队容器培训的负责人。2. 镜像、容器与 Compose先搞清镜像容器与引擎的边界安装之前先把几个概念摆正。这不是为了把教程写得像课本而是因为后面每一步安装选择——装 Engine 还是 Desktop、用独立二进制还是插件、出了报错去查哪一层——都由这几个概念的边界决定。概念不清的时候所有的报错看起来都像玄学。2.1 镜像与容器类与实例的关系镜像就是只读模板容器是镜像的运行实例。这两者的关系最像编程里的类和实例一个镜像可以同时起多个容器容器之间互不影响镜像本身不会被运行过程污染要改配置只能重新构建新镜像。磁盘上的镜像用 docker images 查看运行中的容器用 docker ps 查看。docker images # 查看本地镜像SIZE 列看占用空间 docker ps # 只看运行中的容器 docker ps -a # 看全部容器含已退出的刚上手的人最容易犯的错是 docker ps 看不到容器就觉得它“丢了”其实加一个 -a 就出来了。真正需要排查的往往不是运行中的容器而是 Exited 状态的容器这个在后面第 5 章会专门展开。一条 docker run nginx 命令背后其实做了五件事先检查本地有没有 nginx 镜像没有就去仓库拉有就从镜像创建容器然后分配文件系统和网络栈执行镜像里声明的启动命令最后把容器挂到前台或后台。理解这条链路后面排查启动失败就会快很多。镜像不直接对外提供服务服务跑在容器里所以端口映射、数据卷这些参数都是在 docker run 或者 compose 文件里配的。这也是为什么后面第 6 章的验证要选 MySQL 和 Redis——它们能一次性把端口映射、环境变量、持久化这几个点全部测到。2.2 Docker Engine 与 Docker Desktop同一套 API两种安装形态Linux 上装的是 Docker Enginedockerd 作为系统服务直接跑在宿主机上没有多余的虚拟化层Windows 和 macOS 上装 Docker Desktop本质是在一个轻量虚拟机里运行 Linux 内核所以在安装之前必须先确认虚拟化支持。BIOS 里没开 VT-x或者 Windows 的虚拟机平台功能没启用Desktop 装好后也起不来报错就是那行 virtualization support not detected。这就是为什么同样一个 Docker 问题Linux 用户搜到的解法是改 systemd 服务Windows 用户搜到的解法是开 WSL2两条路本质上不冲突只是底层宿主不同。对比项Docker EngineDocker Desktop适用场景Linux 服务器、远程开发机Windows、macOS 桌面开发底层方式直接运行在宿主机运行在虚拟机或 WSL2安装体积小无 GUI大带图形界面高频问题权限、镜像源虚拟化检测失败、WSL 内核版本适合的使用者运维、后端本地开发、前后端调试选型上我的习惯是只要机器是 Linux一律装 EngineWindows 桌面开发就用 Desktop。团队里两种环境混用很常见不用强求统一但要注意后面第 4 章讲的 compose 形态差异——命令格式不同脚本里写死就会翻车。另外无论哪种形态对外暴露的都是同一套 Docker APIdocker-compose 文件在这两种环境下可以共用。差别主要体现在磁盘路径和端口映射的实现细节上比如 Desktop 的文件共享需要明确指定哪些目录能挂载进容器。2.3 Compose 解决的是编排一个 YAML 文件代替一串 run 命令单个容器用 docker run 完全够用但项目里数据库、缓存、应用服务加起来五六个容器时端口、映射、环境变量、依赖关系全散落在命令里没法版本管理也没法让新同事一眼看懂。Compose 把多个服务写进一个 YAML 文件一条 docker compose up -d 全部拉起清理时一条 docker compose down 全部停掉。很多人把 Compose 理解成“批量启动容器”这只是最表层。它真正的价值在于把服务间的依赖关系声明出来比如应用服务可以声明 depends_on: mysqlCompose 会先启动 MySQL 再启动应用。虽然这个字段不能保证数据库完全就绪但至少做到了启动顺序可控这比 docker run 脚本里人肉维护启动顺序靠谱得多。下面是一个最简示例services: web: image: nginx:1.25 ports: - 8080:80老教程里通常会在文件开头写 version: 3.8新版 Compose 已经忽略这个字段不写反而省事。ports 的写法 8080:80 表示把容器内的 80 端口映射到宿主机的 8080冒号左侧是宿主机端口右侧是容器端口。缩进必须用空格并且层级对齐这是 compose 文件最常见的报错来源到第 5 章排查时会专门讲。把上面文件放到任意目录执行 docker compose up -d 就会启动一个 nginx 容器浏览器访问 localhost:8080 就能看到欢迎页。一份 YAML 就是一份可以提交到 Git 的环境说明书这比一行行的 docker run 脚本好维护得多第 6 章会给出一个更完整的双服务版本到时候直接抄。3. 安装 Docker EngineLinux 最小化与 Windows 虚拟化检测安装 Docker 这件事看起来是复制三条命令实际踩的坑都在看不见的依赖上。先走一遍 Linux 最小化路径再说 Windows 上 Docker Desktop 的前置检查最后统一讲怎么判断安装结果是否真的可用。这套流程是官方源安装没有用第三方脚本原因是可控。官方源在国内机器上可能慢一些但至少不会装到被改过的二进制如果仓库连不通先把系统网络调通再继续不要跳过 GPG 验签。3.1 Linux 最小化安装五条命令背后的三个易错点以 Ubuntu/Debian 为例# 先补系统依赖curl 用来下载gnupg 用来验签 sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg # 添加 Docker 官方 GPG 密钥与仓库定义 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.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.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 sudo systemctl enable --now docker这段命令里最容易出问题的不是安装本身而是仓库地址拼错。arch$(dpkg --print-architecture) 会动态取到 amd64 或 arm64codename 会取到发行版代号比如 Ubuntu 22.04 对应 jammy如果你从论坛复制了一份固定写死代号的源换一台机器很可能 apt update 直接报错。另外就是 GPG 密钥那步不能省 chmod ar否则后续 apt update 会提示密钥不可用。CentOS/RHEL 系走 dnf 流程核心也是三步导入仓库、安装 docker-ce、enable --now。尽量用官方文档里对应发行版的命令不要用网上流传的万能脚本那些脚本为了兼容性往往引用了额外源出了问题不好定位。3.2 Windows 与 Docker Desktop先过虚拟化检测再谈安装Windows 下最常见的安装失败不是安装包损坏而是环境不满足。第一次装 Desktop 的人往往会忽略安装程序下方的说明直接一路 Next等启动时看到 failed to start because virtualisation support wasnt detected 才回头找原因。与其事后排不如装之前一分钟做完检查。Docker Desktop 在 Windows 上默认跑在 WSL2 后端装之前必须先确认三件事BIOS 里的虚拟化开了、Windows 的虚拟机平台功能启用、WSL2 是默认版本。systeminfo | findstr /i Hyper-V # 查看 Hyper-V 与虚拟化要求是否满足 wsl --status # 查看 WSL 版本 wsl --set-default-version 2 # 把 WSL2 设为默认版本如果是公司统一配发的电脑BIOS 里的 VT-x 可能被 IT 策略锁死软件层面怎么改都没用需要提工单让 IT 在 BIOS 里放开。wsl --set-default-version 2 执行后如果提示需要内核更新装一下官方内核更新包再重试。安装 Desktop 本身的界面没什么可说的重点是设置里运行时选 WSL2 而不是 Hyper-V否则部分机器下次开机可能起不来。另外Windows 上还有一种情况是装了 Docker Toolbox 这类旧工具跟 Desktop 抢虚拟化资源装新版之前先卸载干净。3.3 验证 Docker 是否真正可用version、hello-world、info 各自看什么装完先不急着部署跑三条命令把状态看清docker version docker run --rm hello-world docker infodocker version 会分 Client 和 Server 两段输出。看到 Server 段有内容说明 dockerd 已经正常起来如果只有 Client 没有 Server说明服务没启动先查 systemctl status docker。docker run --rm hello-world 测的是拉镜像、起容器、退出后清理全长链路如果卡在拉取阶段去处理镜像源问题。docker info 信息最全存储驱动、CPU、内存、镜像数、容器运行时都在里面后续排障的第一手证据基本都从这拿。还有一种常见的角落情况docker version 正常但 docker run 报 error during connect。这通常说明 docker 命令指向的执行上下文不对比如 Docker Desktop 里设置了不同的 endpoint。用 docker context ls 看一下当前使用的上下文一般就能发现问题。这三条命令看起来简单但确实覆盖了安装环节最重要的验证我每一台新机器装完都会跑一遍输出正常才继续往里装环境。4. 安装 Docker Compose三种方式对比与 libz.so.1 报错Docker 装好后如果项目涉及多容器编排就要装 Compose。这个环节的坑比 Docker 本身还多独立二进制的动态库缺失、旧版命令与新命令的混用、socket 权限。按下面顺序过一遍能省掉大半的踩坑时间。4.1 三种安装方式pip、包管理器与二进制怎么选第一种是 pip install docker-compose老项目里很常见但这个包官方已经很久不更新了新系统上装完基本是旧版本不推荐新项目。第二种是系统包管理器比如 apt install docker-compose优点是依赖自动处理缺点是版本通常落后一两年一些新语法不兼容。第三种是从 GitHub Releases 下载独立二进制版本最新、行为可复现缺点就是缺依赖库时会出现 4.2 里的报错。安装方式命令示例版本新鲜度适合场景pippip install docker-compose旧维护老项目包管理器apt install docker-compose中不追求新语法独立二进制curl 下载到 /usr/local/bin最新新项目、统一团队版本除此之外新版 Docker Engine 自带 compose 插件命令是 docker compose中间有空格不用单独装二进制而独立二进制叫 docker-compose带连字符。两者 YAML 语法基本兼容但命令格式不同。写脚本和文档时一定要分清团队里混用是常态README 里注明“以下用 docker compose 插件版”可以减少很多误导。4.2 二进制安装标准三步与 libz.so.1 报错的解码我用独立二进制的情况比较多流程固定三步export COMPOSE_VERSIONv2.24.1 # 示例版本号实际去 releases 页面取最新 sudo curl -L \ https://github.com/docker/compose/releases/download/${COMPOSE_VERSION}/docker-compose-$(uname -s)-$(uname -m) \ -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose docker-compose --version注意三点文件名里的 uname -s 和 uname -m 是动态拼接的Linux x86_64 机器会得到 docker-compose-linux-x86_64不要手动改写下载后必须加执行权限否则会直接报 Permission denied安装目录要在 PATH 里/usr/local/bin 是最常见的选择。这步装完如果执行 docker-compose --version 报 error while loading shared libraries: libz.so.1: failed to map segment不要怀疑安装步骤。这个报错的本质是二进制是动态链接的运行它需要系统里有 zlib 共享库而当前系统缺失。精简安装的发行版、或者从容器环境里二次安装的场景特别容易出现。解决方式是补库# Debian/Ubuntu 系 sudo apt install -y lib32z1 # RHEL/CentOS 系 sudo yum install -y zlib.i686补完再执行 version 验证。如果系统比较新、自带 compose 插件也可以直接放弃独立二进制改用 docker compose同样能走完后续所有操作。我实际处理时更倾向于补库后继续用独立二进制因为版本可控但如果只是要跑通插件形式最省心。4.3 权限坑/var/run/docker.sock 与被忽略的 docker 组另一条高频报错是 permission denied while trying to connect to the docker api at unix:///var/run/docker.sock。现象是 docker 和 docker-compose 都执行不了原因很简单Docker 的 socket 默认只有 root 和 docker 组的用户可以访问当前用户不在组里。解决方式不是去 chmod 777 这个 socket而是把用户加进 docker 组sudo usermod -aG docker $USER newgrp docker # 让组权限立即生效否则要重新登录 docker ps注意加组之后必须重新登录或者执行 newgrp否则看起来还是同样的报错。这里多说一句docker group 的成员关系存在 /etc/group 文件里用 groups $USER 可以随时确认自己当前在哪些组里别等报错才想起来查。生产环境中如果机器在安全管控范围内普通用户不加组、一律走 sudo 是正常策略这时候不需要改权限只需要让操作者知道命令前加 sudo。5. 安装与使用中的常见问题排查现象、原因、解决这几条是安装之后最常被搜到的问题统一按现象、原因、解决三小节写可以直接照着操作。5.1 镜像下载慢先配镜像源再重启 dockerd现象docker pull 卡在 waiting或者直接 failed to resolve。原因默认镜像仓库的全球分发链路不是所有地区都快。解决给 dockerd 配置镜像源地址用云厂商提供的专属镜像源或者公共镜像站多试两个总能通。改完必须重启 dockerd 才生效。{ registry-mirrors: [https://docker.mirrors.ustc.edu.cn] }sudo systemctl restart docker docker pull hello-world注意镜像源只影响后续拉取已经拉下来的镜像不受影响。配置写错了会让 dockerd 起不来所以改完先 systemctl status docker 确认服务在 running 再 pull。Docker Desktop 改镜像源是在设置界面的 Docker Engine 配置里不是同一个 daemon.json别混。5.2 compose 启动报错config 命令是第一个排障工具现象docker compose up -d 报 services.web.ports must be a list或者直接 YAML 语法错误。原因绝大多数是缩进或类型问题YAML 里 ports 必须是列表冒号后面必须有空格并且不能用 Tab 缩进。解决先跑 config 命令做解析它会打印最终配置报错会指明行号。docker compose config docker-compose config # 独立二进制用这个看到 services 树结构没问题再回去 up。我习惯的流程是任何 compose 文件改动后先 config 后 up这个顺序能挡掉一半以上的低级错误。还有一个常见误用有人看 YAML 没报错但启动后容器一直在 restart这种一般不是语法问题要到 5.4 的日志步骤去看。5.3 连不上容器里的 MySQL先查端口映射再看认证方式现象宿主机上 mysql -h 127.0.0.1 -P 3306 连不上容器里的 MySQL容器里却能登进去。原因可能是端口没有映射也可能映射的地址被限定为 127.0.0.1还可能是 MySQL 8 默认的 caching_sha2_password 认证插件不被老客户端兼容。解决先用 docker port 看实际映射关系。docker port mysql8 # 输出形如 0.0.0.0:3306 - 3306看到 0.0.0.0:3306 说明所有网卡都能访问如果只映射了 127.0.0.1 那就是本机限定外部机器连不上很正常。MySQL 8 的认证问题则需要在创建用户时指定 mysql_native_password或者用支持 caching_sha2_password 的新版客户端。新手容易忽略容器里的 localhost 是容器自己的网络栈跟宿主机是两回事需要登录时用宿主机 IP。5.4 容器秒退logs 和 ExitCode 比任何猜测都可靠现象docker compose up -d 之后 docker ps 里看不到目标容器docker ps -a 里它是 Exited。原因启动命令错误、环境变量未解析、端口冲突、初始化脚本失败都会导致容器退出。解决不要急着改配置重启先看日志和退出码。docker ps -a docker logs --tail 200 容器名 docker inspect 容器名 --format {{.State.ExitCode}}日志会直接告诉你原因比如文件缺失、端口被占用、命令不存在。ExitCode 137 一般是内存不足被 SIGKILL255 通常是程序主动退出0 之外的代码都值得去查。把日志最后几行贴到搜索引擎里基本都能定位。这比反复 docker compose restart 有用得多也是我在团队里要求所有人先看日志的原因。6. 用 Compose 部署 MySQL Redis一条命令验证安装是否成功6.1 一份 MySQL Redis 的 compose 文件到最后一步用一份真实可用的 compose 文件把前面安装的结果串起来。MySQL 和 Redis 各带端口映射、数据卷和重启策略写完就是一份能直接提交到 Git 的开发环境模板services: mysql: image: mysql:8.0 container_name: mysql8 restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: root123456 ports: - 3306:3306 volumes: - ./mysql_data:/var/lib/mysql redis: image: redis:7 container_name: redis7 restart: unless-stopped ports: - 6379:6379environment 里的 MYSQL_ROOT_PASSWORD 是 mysql 镜像自带的初始化逻辑第一次启动时会自动设置 root 密码volumes 把容器内数据目录挂到宿主机当前目录下的 mysql_data容器销毁后数据还在restart: unless-stopped 保证 Docker 重启后服务自动拉起。6.2 启动、连库、验证四个命令看清结果docker compose up -d docker compose ps docker exec -it mysql8 mysql -uroot -proot123456 -e select version(); docker exec -it redis7 redis-cli pingup -d 后台启动ps 看两个容器状态都必须是 Upexec 进容器执行验证命令MySQL 打印版本号、Redis 返回 PONG就说明镜像拉取、容器创建、端口映射、环境变量全部正常。MySQL 客户端会提示命令行密码暴露在进程列表里开发环境无所谓生产不要这样写。6.3 装完必跑的检查清单检查项命令预期结果Docker 服务状态systemctl status dockeractive (running)客户端与服务端docker versionServer 段有输出Compose 可用docker compose version返回版本号端口映射docker port mysql8 33060.0.0.0:3306容器日志docker logs mysql8 --tail 50无 ERROR 堆栈这张表是我每次换机器之后的固定动作不管什么发行版、什么虚拟机全部绿灯才继续往项目里放环境。装环境不是玄学系统再怎么千奇百怪最终都能落到这几条命令的输出上。从那以后我每次看到报错都先跑一遍这套检查再定位问题基本不会再被安装层面的事耽误时间希望帮到你。本文还有配套的精品资源点击获取