Docker Compose 入门：一条命令拉起整套服务

为什么需要 Compose

只跑一个容器时，一条 docker run 就够了。可一旦服务多起来，事情立刻变烦：先建网络，再逐个起容器，每个容器都要写一遍端口映射、环境变量和挂载目录，重启一次就要重复一次。更麻烦的是启动顺序，数据库还没起来，应用就已经开始连接，结果连不上直接退出。手工维护这些命令既容易出错，也很难交给同事复现。Docker Compose 就是为了解决这个问题：把一整套服务写进一个文件里，用一条命令拉起来，配置即文档，谁拿到都能跑出同一套环境。

compose.yaml 的结构

Compose 的配置文件通常叫 compose.yaml，核心只有三块。services 定义每个服务：用什么镜像、映射哪些端口、挂载哪些目录、设置哪些环境变量。networks 定义容器之间的网络，同一个网络里的服务可以直接用服务名互相访问，不用写 IP。volumes 定义数据卷，让数据库这类有状态服务的数据在容器重建后还能保留下来。写清楚这三块，一套多容器应用的骨架就有了。

一个可跑的示例：Nginx + 简单 Web 服务

下面是一个最小的例子，Nginx 对外提供页面，另一个服务提供接口：

services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
  api:
    image: python:3.12-slim
    command: python -m http.server 8000
    working_dir: /app
    volumes:
      - ./app:/app
    depends_on:
      - web

在文件所在目录执行 docker compose up -d，打开本机 8080 端口就能看到 Nginx 返回的页面，api 服务则在后台提供数据。想改页面内容，改 html 目录下的文件即可，不用重建镜像。

常用命令

up -d 以后台方式启动整套服务，down 停止并删除容器，ps 查看各服务运行状态，logs -f 跟踪某个服务的日志输出，restart 重启指定服务，config 在真正启动前检查配置文件写得对不对。日常开发基本靠这几个命令就能运转。

常见坑

第一个坑是端口冲突。宿主机端口一旦被别的程序占用，容器就起不来，报错里会出现 address already in use，改一个空闲端口映射即可。第二个坑是 depends_on 的语义，它只保证启动顺序，不保证服务就绪：数据库容器启动了，不代表数据库已经可以接受连接。稳妥的做法是在应用里加重试，或者用 healthcheck 等健康状态变为正常后再启动依赖方。第三个坑是数据卷误删，down 本身不会删数据，但 down -v 会连命名卷一起删掉，没备份的数据就找不回来了，清理之前务必确认卷里没有重要数据。

结尾

Compose 的价值不在命令多炫，而在把散落的启动命令收进一个文件，让环境变得可复制、可交接。先从两三个服务的 compose.yaml 练手，遇到端口冲突、启动顺序和数据卷的问题时回想上面三条，日常开发的大部分多容器场景就够用了。