Docker Compose 部署多容器应用：配置、启动与故障排查

我平时不太愿意把一组 docker run 命令抄在笔记里。服务一多，端口、环境变量和数据目录很快就对不上。Docker Compose 的作用就是把这些配置放进一个文件，之后在目录里执行几条命令就能启动整套服务。

先建一个干净目录

下面用 Nginx 和 Redis 做例子。它不是完整业务系统，但足以说明 Compose 的基本用法。

mkdir demo-stack
cd demo-stack
notepad compose.yaml

在 Linux 上可以把最后一条命令换成 vi compose.yaml。文件名使用 compose.yaml，新版本 Docker Compose 可以直接识别。

写 compose.yaml

services:
  web:
    image: nginx:stable
    ports:
      - "8080:80"
    depends_on:
      - cache
  cache:
    image: redis:7
    volumes:
      - redis-data:/data

volumes:
  redis-data:

访问宿主机的 8080 端口时，请求会转发到 Nginx 容器的 80 端口。Redis 没有配置 ports，因此不会直接暴露到宿主机；Compose 网络中的其他服务可以使用 cache:6379 访问它。

真实项目中不要长期使用浮动的镜像标签。数据库和缓存也要明确配置数据卷，否则删掉容器后很容易把数据一起丢掉。

启动前先检查配置

第一次启动不要直接使用 -d 把日志藏起来。先让 Compose 解析配置：

docker compose config

这个命令可以较早发现 YAML 缩进、变量替换和字段拼写问题。确认没有报错后，再拉取镜像并启动：

docker compose pull
docker compose up -d
docker compose ps

看到容器状态为 Up 只能说明进程还在运行，不代表应用一定可用。浏览器打开 http://服务器地址:8080，同时查看日志：

docker compose logs -f web

更新容器时注意数据

更新镜像可以先拉取新版本，再重新创建容器：

docker compose pull
docker compose up -d
docker compose ps

docker compose stop 只停止容器，适合临时维护。docker compose down 会移除容器和网络，但默认保留命名卷。不要随手加上 --volumes，除非已经确认卷里的数据可以删除。

几个容易踩到的坑

端口被占用

如果提示端口已被占用，检查宿主机上的监听进程，或者只修改映射左侧的端口。例如把 8080:80 改为 18080:80，容器内部的 80 端口不用变。

容器之间访问失败

容器内的 localhost 指向当前容器，不是另一个服务。访问 Redis 时应使用 Compose 服务名 cache，而不是 127.0.0.1。

容器启动后马上退出

先看对应服务的日志：

docker compose logs --tail=100 服务名
docker compose ps -a

如果是配置文件、权限或环境变量问题，日志通常比 docker ps 更有用。

最后检查一遍

一份能启动的 Compose 文件还不算完成。至少要确认端口没有不必要地暴露到公网，重要服务使用了持久化卷，镜像版本可以追溯，更新前也有备份。这样以后换服务器时，复制目录和数据卷就能比较快地恢复环境。