小熊の数字花园

外观

Compose 服务编排基础

约 1290 字大约 4 分钟

DockerDocker Compose编排部署

2026-03-20

1. Compose 解决什么问题

当一个服务不再只是单个容器，而是需要数据库、缓存、反向代理、业务服务一起协作时，单独执行多条 docker run 命令会很快变得难维护。

Compose 的核心作用，就是把多容器应用的启动方式写成一份声明式配置，然后统一管理。

它通常解决下面几类问题：

  1. 多个容器要一起启动、停止和重建。
  2. 端口、挂载目录、环境变量和网络需要统一描述。
  3. 同一套服务要在不同机器上重复部署。
  4. 部署过程需要尽量减少手工命令。

2. 最小结构长什么样

Compose 最常见的入口文件是 docker-compose.yaml 或 compose.yaml。

一个最小示例如下：

services:
  web:
    image: nginx:1.27.4
    ports:
      - "8080:80"

这表示启动一个名为 web 的服务，使用 nginx:1.27.4 镜像，并把宿主机 8080 映射到容器 80。

3. 一个稍完整的示例

services:
  app:
    image: node:22
    working_dir: /app
    command: npm run start
    volumes:
      - ./app:/app
    ports:
      - "3000:3000"
    environment:
      NODE_ENV: production
      API_BASE_URL: http://api:8080
    depends_on:
      - api
    networks:
      - app-net

  api:
    image: node:22
    working_dir: /app
    command: npm run start
    volumes:
      - ./api:/app
    expose:
      - "8080"
    networks:
      - app-net

networks:
  app-net:
    driver: bridge

这份配置里已经包含了几个最常见的编排点：

  1. services 定义有哪些服务。
  2. ports 定义端口映射。
  3. volumes 定义宿主机挂载。
  4. environment 定义环境变量。
  5. depends_on 描述服务启动依赖关系。
  6. networks 让多个服务加入同一个网络。
  7. expose 只在容器网络内部声明端口，不对宿主机公开。

4. 常用字段怎么理解

image

指定服务使用哪个镜像。生产环境建议尽量固定版本号，而不是长期依赖 latest。

container_name

可以显式指定容器名，但不建议对所有服务都强依赖固定容器名。很多情况下直接使用服务名更稳妥，也更利于后续扩展。

ports

定义宿主机端口到容器端口的映射，例如：

ports:
  - "8080:80"

volumes

用于挂载代码、配置或持久化数据目录，例如：

volumes:
  - ./data:/var/lib/mysql

environment

用于传入服务启动所需的配置，例如数据库账号、运行模式、外部地址等。

depends_on

它表示启动顺序依赖，但不等于目标服务已经完全可用。也就是说，api 先于 app 启动，不代表 api 此时一定已经完成初始化。

如果服务确实依赖下游组件完全就绪，应该再加健康检查、重试机制，或者在应用启动阶段自己做等待逻辑。

5. 常用命令

启动服务

docker compose up -d

停止并删除容器

docker compose down

查看服务状态

docker compose ps

查看日志

docker compose logs -f

重新构建并启动

docker compose up -d --build

拉取最新镜像

docker compose pull

6. 环境变量建议怎么管理

如果环境变量较多，不建议全部直接堆在 Compose 文件里。

比较常见的方式有两种：

  1. 使用 .env 文件统一管理变量。
  2. 只在 Compose 文件里保留关键结构，把敏感信息放到外部环境或专门的配置方案中。

例如：

services:
  app:
    environment:
      APP_ENV: ${APP_ENV}
      DB_HOST: ${DB_HOST}

对应的 .env 文件可以是：

APP_ENV=production
DB_HOST=mysql

7. 为什么说 Compose 很适合单机部署

对于个人项目、内部服务、小型站点和开发测试环境，Compose 是非常合适的单机编排方案。

原因通常有三点：

  1. 上手成本低。
  2. 可读性强，部署结构一眼能看懂。
  3. 迁移方便，把目录和配置带走就能重建环境。

8. Compose 的边界在哪里

Compose 很适合单机和轻量级环境，但它不是完整的集群编排系统。

如果场景开始出现下面这些需求，就该考虑更高层的方案：

  1. 多台机器统一调度。
  2. 自动扩缩容。
  3. 更复杂的服务发现和故障自愈。
  4. 多环境统一发布流水线。

这类场景通常会转向 Kubernetes、Nomad 或其他更完整的编排平台。

9. 一个实用的组织建议

如果一个项目准备长期维护，建议把 Compose 目录整理成下面这种结构：

project/
  compose.yaml
  .env
  data/
  config/
  logs/

这样做的好处是：

  1. 配置、数据和日志边界清晰。
  2. 备份时知道该备份哪些目录。
  3. 后续迁移到其他机器更直接。

10. 初学者最常见的误区

  1. 把所有服务都暴露端口到宿主机。
  2. 依赖 depends_on 判断服务已经可用。
  3. 一直使用 latest，导致版本不可控。
  4. 没有把数据目录挂载出来，容器重建后数据丢失。
  5. 配置改完后不重建或不重启，结果以为 Compose 没生效。
  6. 用 ports 暴露了本来只需要内部访问的服务，增加攻击面和端口冲突概率。

版权归属：Ailurus-2233

许可证：署名 4.0 国际 (CC-BY-4.0)