Docker Compose 多容器编排入门：一条命令拉起整套服务

在本地开发一个完整服务时，常常不是只有一个进程在跑：前端页面要起一个服务，后端接口要起一个服务，数据库、缓存、消息队列也各占一个。刚开始用 Docker 的时候，很多人会为每个容器各写一条很长的 docker run 命令，端口、挂载目录、环境变量、网络全靠手敲和记忆，一旦参数写错一个，排查起来非常费时间。更麻烦的是，换一台电脑或者交给同事接手，同一套命令还要重新拼一遍，环境很难保持一致。Docker Compose 就是为了解决这个问题而生的：它用一个 YAML 文件把整套服务描述清楚，再用一条命令把它们按顺序拉起来。

Compose 是什么

简单说，Compose 是一个多容器编排工具。你在 docker-compose.yml 里声明有哪些服务、每个服务用什么镜像、暴露什么端口、挂载哪些目录、依赖谁、用什么网络，Compose 会负责创建网络、按依赖顺序启动容器，并在停止时一起清理。服务之间默认处在同一个网络里，可以直接用服务名当作主机名互相访问，不需要再记容器的 IP 地址。这是 Compose 最省心的一点：配置即文档，文件本身就是这套环境的说明书。

一个能直接跑起来的例子

假设我们要做一个最常见的组合：一个 Web 应用加数据库和缓存。目录里放一个 docker-compose.yml，内容大致如下：

services:
  web:
    build: ./web
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=mysql://app:secret@db:3306/appdb
      - REDIS_URL=redis://cache:6379/0
    depends_on:
      - db
      - cache
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=secret
      - MYSQL_DATABASE=appdb
    volumes:
      - db_data:/var/lib/mysql
  cache:
    image: redis:7-alpine
    volumes:
      - cache_data:/data
volumes:
  db_data:
  cache_data:

这个文件里有三个关键点。第一，services 下的每个名字就是一个服务，web 用本地代码构建，db 和 cache 直接用官方镜像。第二，web 通过环境变量里的 db 和 cache 这两个服务名连接数据库和缓存，Compose 会在同一个网络里解析这些名字。第三，db_data 和 cache_data 是命名卷，数据写在卷里而不是容器层里，容器删了重建，数据还在。

一条命令拉起整套服务

在文件所在目录执行 docker compose up -d，Compose 就会创建网络和卷、拉取镜像、构建 web 服务、按依赖顺序启动三个容器。加上 -d 是后台运行，不加则可以在前台直接看到所有服务的日志。想看状态用 docker compose ps，想看某个服务的日志用 docker compose logs -f web，想进容器里排查用 docker compose exec web sh。改完代码后执行 docker compose up -d --build 重新构建并更新，开发阶段非常顺手。服务不用了，执行 docker compose down 停止并删除容器和网络；如果连卷也想一起清理，可以加 -v，但这一步要格外小心，因为卷里的数据会被一起删掉。

网络、卷与环境变量：三个最容易踩的坑

第一个坑是启动顺序不等于就绪。depends_on 只能保证 db 容器先启动，不能保证数据库已经可以接受连接。Web 服务一启动就去连数据库，很可能连不上就直接退出了。比较稳妥的做法是在应用里做重试，或者给数据库加健康检查，再用 depends_on 的 condition: service_healthy 来等它真正就绪。第二个坑是端口冲突。ports 里冒号左边是宿主机端口，右边是容器端口，如果宿主机的 8000 端口已经被别的程序占了，启动就会失败，改一个宿主机端口通常就能解决。第三个坑是把密码和配置硬编码在文件里。敏感信息尽量放到 .env 文件或者环境变量里传进来，docker-compose.yml 只保留结构性的配置，这样文件可以放心地进版本库，不同环境用不同的 .env 覆盖即可。

让 Compose 文件更好维护的习惯

服务一多，文件容易变长。可以把公共配置抽成锚点复用，或者按环境拆成多个文件，比如基础文件加 docker-compose.override.yml，开发环境自动合并覆盖。镜像尽量固定具体版本号，不要长期用 latest，否则今天能跑的环境，下个月拉到新镜像未必还能跑。构建上下文里注意写好 .dockerignore，别把 node_modules、.git 和本地缓存文件一起打进构建上下文，既慢又容易出意外。提交之前，先在干净的目录里跑一次 docker compose up -d，确认从零拉起也能成功，这一步能挡住很多只在自己电脑上能跑的问题。

结语

Docker Compose 并没有引入多少新概念，它的价值在于把散落在各条命令里的端口、网络、卷和依赖关系收进一个文件，让整套服务变得可描述、可重复、可移交。对个人开发者来说，它是本地联调最顺手的工具；对小团队来说，它是一份可以共享的环境说明书。先从三个服务的小例子开始，把 up、ps、logs、down 这几个命令练熟，再逐步加上健康检查、环境变量和多文件拆分，就能用一条命令稳定地拉起整套服务，把时间留给写业务代码本身。