首页 > 网站技巧 > 服务器 > 云和虚拟化 > docker > Docker Compose容器编排

Docker Compose容器编排深度解析与实战小结

2025-12-22 09:41:31 作者：Undoom

Docker Compose 是 Docker 官方推出的开源项目,用于定义和运行多个 Docker 容器的应用工具,简化了多容器应用的部署和管理,本文介绍Docker Compose：容器编排深度解析与实战指南,感兴趣的朋友一起看看吧

第一章 Docker Compose 核心定义与架构分析

1.1 什么是 Docker Compose

Docker Compose 是 Docker 官方推出的开源项目，其核心代码由 Python 编写。在技术实现层面，它通过直接调用 Docker 服务的 API 来实现对容器的精细化管理和编排。官方将 Docker Compose 定义为“用于定义和运行多个 Docker 容器的应用工具”。

在 Docker Compose 的体系结构中，存在两个至关重要的核心概念，这决定了其管理容器的逻辑维度：

服务 (Service)：服务代表一个应用容器。在实际生产中，一个服务可以由若干个运行相同镜像的容器实例组成。它是逻辑上的一个单元，通过镜像名、环境变量、网络配置等属性进行定义。
项目 (Project)：项目是由一组互相关联的应用容器构成的完整业务单元。项目的所有属性都在 docker-compose.yml 文件中定义。可以说，一个 docker-compose.yml 文件就代表了一个完整的项目。

Docker Compose 的默认管理对象是项目。通过一套简洁的子命令，开发人员可以对项目中的一组容器进行便捷的生命周期管理，从而极大地简化了多容器应用的协同工作。

1.2 为什么引入 Docker Compose

Docker 遵循单一职责原则，其官方推荐在每个 Docker 容器中仅运行一个进程。这种轻量化的设计提高了镜像的复用性，但也给复杂应用的部署带来了挑战。

在实际开发中，一个完整的业务应用往往需要依赖多个环境，例如 Nginx 作为反向代理、MySQL 提供数据持久化、Redis 提供缓存服务。如果采用传统方式，我们需要分别为应用代码、MySQL 数据库和 Nginx 创建独立的容器，并逐一手动启动。

手动管理的弊端显而易见：

繁琐性：每次启动应用都需要执行多次 docker run 命令，或者编写复杂的 Shell 脚本。
管理分散：容器之间是独立且分散的，不利于统一的镜像版本控制和资源分配。
逻辑脱节：这些容器本质上是为同一个业务目标服务的，但在管理层面上却缺乏一个有机的整体视角。

Docker Compose 的出现解决了上述问题。它将属于同一个业务逻辑的所有容器整合在一起，通过一个配置文件进行统筹。

1.3 Docker Compose 的安装验证

在现代 Docker 环境中，docker-compose-plugin 通常作为默认组件被安装。这意味着在安装 Docker 时，Compose 功能已经集成在内。

通过执行以下命令可以验证安装情况：

docker compose version

执行结果如图所示：

图片显示了当前系统中 Docker Compose 的版本信息，这确认了环境已经准备就绪。

1.4 Docker Compose 的核心功能与使用场景

1.4.1 使用步骤

使用 Compose 遵循标准的三步走策略：

定义环境：使用 Dockerfile 定义应用程序环境。
定义服务：在 docker-compose.yml 中定义构成应用的服务，使其可以在隔离环境中协同运行。
启动运行：执行 docker compose up 命令，一键启动并运行整个应用程序。

1.4.2 核心管理能力

Compose 涵盖了应用程序全生命周期的命令体系：

服务的启动、停止与自动化重建。
实时查看运行服务的状态监控。
流式传输并聚合查看所有运行服务的日志输出。
在特定服务上执行单次命令。

1.4.3 典型使用场景

单主机部署：在开发或测试阶段，快速搭建单节点的完整环境。
多环境隔离：通过指定不同的项目名称（Project Name），在同一台主机上运行多套相互隔离的环境（如开发环境、预发布环境）。

第二章 Docker Compose 配置文件（docker-compose.yml）详析

docker-compose.yml 是 Docker Compose 的核心，其采用 YAML 格式。YAML 语法的严谨性要求必须正确处理缩进和数据类型。

2.1 配置文件核心参数

以下是一个标准的配置文件参数模板及其含义：

version: "3.8" # 定义版本，表示当前使用的 docker-compose 语法的版本
services: # 服务容器配置块
  servicename: # 服务自定义名称，同时作为内部 bridge 网络的 DNS 名称
    image: # 必选，指定使用的镜像名称
    command: # 可选，覆盖镜像默认的 CMD 指令
    environment: # 可选，设置环境变量，等同于 docker run --env
    volumes: # 可选，挂载数据卷，等同于 docker run -v
    networks: # 可选，指定网络，等同于 docker run --network
    ports: # 可选，端口映射，等同于 docker run -p
    expose: # 可选，暴露内部端口，不映射到宿主机
    build: # 可选，指定 Dockerfile 所在的构建目录
    depends_on: # 可选，定义服务间的启动依赖关系
    env_file: # 可选，指定环境变量文件路径
volumes: # 定义全局数据卷
networks: # 定义全局网络

2.2 核心指令：image

image 指令指定容器运行的基础镜像。它支持多种格式，包括本地镜像名、带标签的镜像名、带摘要（digest）的镜像名，以及来自私有仓库的镜像。

示例如下：

image: redis
image: redis:5
image: redis@sha256:0ed5d5928d4737458944eb604cc8509e245c3e19d02ad83935398bc4b991aac7
image: my_private.registry:5000/redis

实战演练 prj1：基础容器启动

首先创建一个名为 mycompose 的目录，在其下创建子目录 prj1，并编写 docker-compose.yml：

version: "3.8"
services:
  web:
    image: nginx:1.23.3

如图所示，目录结构清晰，仅包含一个简单的 YAML 文件：

在 prj1 目录下执行启动命令：

docker compose up -d

图中信息显示，Docker Compose 自动创建了一个默认网络（prj1_default）并启动了一个容器（prj1-web-1）。

通过 docker ps -a 和 docker network ls 进行查询验证：

查询结果证实，容器和网络已经成功建立。

进一步查看网络详情：

docker inspect prj1_default

图中 Containers 节点下清晰地展示了该网络已经绑定了 prj1-web-1 容器。

通过 docker compose ps 可以直观查看当前项目下的服务状态：

最后，执行 docker compose down 即可实现一键清理：

图片显示，不仅容器被停止并删除，连同之前自动生成的项目网络也被一并移除，这体现了 Compose 的整洁管理特性。

2.3 核心指令：command

command 用于覆盖容器启动时的默认命令。

实战演练 prj2：命令覆盖对比

在 prj1 的基础上拷贝出 prj2 目录，并修改配置文件。prj1 保持默认启动 Nginx，而 prj2 则指定启动命令：

version: "3.8"
services:
  web:
    image: nginx:1.23.3
    command: ["tail","-f","/etc/hosts"]

如图所示，我们将 web 服务的启动指令改为持续监控 /etc/hosts 文件。

分别启动 prj1 和 prj2 的服务。执行 docker inspect 查看容器详情：

（这是 prj1 的默认 CMD 状态）

（这是 prj2 启动时的状态信息）

通过 docker inspect prj2-web-1 可以观察到其命令确实变更为我们指定的 tail 命令：

验证功能性差异：
对 prj1-web-1 执行 curl：

docker exec -it prj1-web-1 curl 127.0.0.1

返回了 Nginx 默认首页，说明 Nginx 进程正在运行。

对 prj2-web-1 执行 curl：

docker exec -it prj2-web-1 curl 127.0.0.1

系统提示拒绝连接。这是因为 tail 命令覆盖了 Nginx 的启动命令，容器内部并没有 Nginx 监听 80 端口。这有力地证明了 command 参数的生效机制。

2.4 核心指令：entrypoint

entrypoint 与 command 类似，但它直接覆盖镜像定义的入口点。

实战演练 prj3：入口点覆盖

编写 prj3 的配置文件，使用 entrypoint 查看系统发行版信息：

version: "3.8"
services:
  web:
    image: nginx:1.23.3
    entrypoint:
      - tail
      - -f
      - /etc/os-release

启动服务后查看进程列表：

图中 COMMAND 栏目明确显示容器正在执行 tail -f /etc/os-release。

查看 docker inspect 详情：

Entrypoint 节点已经被完全重写。

2.5 核心指令：environment

该参数用于向容器注入环境变量。

实战演练：环境变量注入

修改 prj1 的配置文件，加入自定义变量：

environment:
  Test: 1

执行 up -d 后，Docker Compose 识别到配置变更，会自动触发容器重建（Recreate）：

通过 docker inspect 验证环境变量：

图中 Env 列表中清晰地出现了 Test=1。

2.6 核心指令：networks

通过该指令可以精细化控制容器的网络连接。

实战演练 prj4：多网络连接

在 prj4 中定义两个自定义网络，并将 web 服务同时加入：

version: "3.8"
services:
  web:
    image: nginx:1.23.3
    networks:
      - mywebnet1
      - mywebnet2
networks:
  mywebnet1:
  mywebnet2:

图中可见，Compose 同时创建了两个网络。

执行 docker network ls 可以观察到新生成的网络：

通过 inspect 查看容器网络详情：

容器成功获得了两个不同网段的 IP 地址，具备了跨网络通信的能力。

2.7 核心指令：volumes

volumes 实现宿主机与容器间的数据持久化与共享。

实战演练 prj5：存储卷绑定

在配置文件中将宿主机目录挂载到 Nginx 的网页根目录：

volumes:
  - /data/kk/vol1:/usr/share/nginx/html/

在正式运行前，使用 docker compose config 检查语法：

图中显示配置无误，挂载类型被标识为 bind。

启动服务：

进入容器查看：

在宿主机挂载点 /data/kk/vol1 下创建测试文件：

再次 curl 访问：

返回内容即为我们在宿主机编辑的内容，证明数据同步实时生效。

2.8 核心指令：ports

用于指定容器端口与宿主机端口的映射关系。

实战演练 prj6：端口发布

ports:
  - 8083:80

启动后，通过 docker compose ps 查看端口映射状态：

或者使用 docker port 命令精确定位：

直接通过宿主机 IP 加 8083 端口进行 curl 测试：

外部访问成功。

2.9 核心指令：expose

与 ports 不同，expose 暴露的端口仅能被同一网络内的其他服务访问，不对外开放。

实战演练 prj7：内部暴露

在配置文件中设置暴露 3030 端口：

启动服务进入容器内部进行测试：

内部 curl 显示端口已开放，但切换到宿主机尝试 curl 该端口：

宿主机无法连接，这展示了 expose 的安全隔离特性。

2.10 核心指令：depends_on

该参数定义服务间的启动顺序和健康状态依赖。

实战演练 prj8：健康检查与顺序启动

我们希望 web 服务在 mysql 服务达到“健康”状态后再启动：

services:
  web:
    depends_on:
      mysql:
        condition: service_healthy
  mysql:
    image: mysql:5.7
    healthcheck:
      test: mysql -u root -phuyunkai -e 'select 1;'
      interval: 10s
      timeout: 5s
      retries: 10

执行启动命令：

图中显示 web 服务处于 Waiting 状态，因为它在等待 mysql 完成健康检查。

当 mysql 变为 healthy 后，web 才会启动：

停止服务时，Compose 会遵循逆序：先停止依赖者（web），再停止被依赖者（mysql）：

重新启动也是同理，必须先验证被依赖服务的健康度：

2.11 核心指令：env_file

通过外部文件管理环境变量，提高配置的可维护性。

实战演练 prj9：多文件引用

在 prj9 目录下创建 commenv 和 webenv 文件：

在 YAML 中引用：

env_file:
  - ./commenv
  - ./webenv

启动服务并进入容器执行 env 命令：

图中显示来自两个不同文件的环境变量都已经生效。

第三章 Docker Compose 常用命令全集

命令	功能描述
`up`	构建、创建并启动所有容器，支持后台运行 `-d`
`down`	停止并删除容器、网络、镜像以及卷（带 `-v`）
`ps`	列出项目中的所有容器状态
`config`	验证并查看 Compose 文件的实际配置
`logs`	查看容器的日志输出
`exec`	在运行中的容器内执行命令
`restart`	重启服务
`stop` / `start`	停止或启动现有的容器实例
`run`	在服务上运行一次性命令，常用于临时调试
`port`	打印服务的端口映射信息

3.1 命令行全局选项

-f, --file：指定配置文件。默认使用 docker-compose.yml。
-p, --project-name：指定项目名。默认使用所在目录名。

例如，指定一个非默认名称的配置文件启动：

docker compose -f ./prj1/docker-compose.txt up -d

3.2up命令深度解析

up 是最常用的指令。它集成了镜像拉取、容器创建、网络设置等一系列动作。

前台运行：不加 -d 时，日志直接输出到控制台。按 Ctrl+C 会导致容器停止：

强制重建：使用 --force-recreate。当配置文件发生逻辑变更（如挂载路径修改）时非常有用：

3.3down命令与数据清理

默认 down 只删除容器和网络。如果需要清理关联的卷映射，必须加 -v：

3.4run与一次性任务

run 主要用于在不影响主服务运行的情况下，启动一个新容器执行特定任务。

注意：执行 run 时需要指定服务名而非镜像名。

第四章综合操作案例：多层级拓扑构建

4.1 复杂拓扑关系配置

设计一个包含 Nginx、MySQL 和 Redis 的三层架构，并设置严格的依赖与健康检查：

核心配置逻辑：

MySQL 和 Redis 设置 healthcheck。
Web 服务通过 depends_on 监控前两者的 service_healthy 状态。

启动过程如图：

系统会精确控制启动时机，确保数据库就绪后应用才上线。

4.2 网络与持久化配置

在拓扑基础上，加入自定义 bridge 网络 mytestnetwork，并挂载存储卷：

通过 docker compose ps 确认所有组件均处于 Healthy 状态：

访问映射端口 8085，可以看到自定义的首页：

第五章企业级应用实战：部署 WordPress 站点

WordPress 是一个典型的 Web + DB 的应用。我们需要配置 WordPress 访问数据库所需的四个关键环境变量：主机地址、用户名、密码、数据库名。

5.1 编写部署脚本

在配置文件中，将 db 服务的健康状态作为 wordpress 启动的前置条件：

services:
  wordpress:
    depends_on:
      db:
        condition: service_healthy
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: undoom
      WORDPRESS_DB_PASSWORD: huyunkai
  db:
    image: mysql:5.7
    healthcheck:
      test: mysql -u root -proot -e "select 1;"

5.2 启动与验证

执行 up -d 后，系统自动拉取镜像并按顺序创建环境：

通过浏览器访问服务器端口，进入 WordPress 安装引导页面：

配置完成后，一个完整的博客系统就运行起来了：

由于配置了 volumes，即使执行 down 命令清理了容器，宿主机目录中的数据库文件和网页文件依然得以保留：

第六章常见问题与总结

6.1 up、run、start 的本质区别

up：全自动化命令。它会检查镜像、网络、容器是否存在。如果不存在则创建，如果配置变动则重建，并将容器拉起到运行状态。
run：侧重于执行。它会为指定的服务临时创建一个新容器来执行命令，执行完毕后容器通常处于停止状态。
start：侧重于恢复。它只能启动已经存在且处于停止状态的容器，不会处理配置变更或重建逻辑。

6.2 总结

Docker Compose 通过声明式的 YAML 文件，将复杂的多容器协作关系简化为单一的配置文件管理。它不仅控制了服务的生命周期，还通过 depends_on 和 healthcheck 解决了服务启动的时序性问题。无论是对于本地开发环境的快速复现，还是中小型生产环境的快速部署，Docker Compose 都是不可或缺的利器。

到此这篇关于Docker Compose容器编排深度解析与实战小结的文章就介绍到这了,更多相关Docker Compose容器编排内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！