Docker Compose 实战入门：多容器项目为什么更适合用 compose 管理

如果项目里只有一个 Nginx，docker run 还能手敲；但只要开始出现：

• 应用服务
• MySQL
• Redis
• Nginx

再继续靠命令手动管理，迟早会乱。

这时真正该上场的就是 Docker Compose。

先说结论

Compose 的核心价值，不是“帮你少打一行命令”，而是把多容器项目的运行方式写成可维护配置。

这样你就能把下面这些信息固定下来：

• 用哪些镜像
• 起几个服务
• 端口怎么映射
• 数据目录怎么挂载
• 服务之间怎么互联

一、现在应该怎么理解 Compose

现在更推荐把它理解成 Docker 官方的 Compose v2 能力，常见命令写法是：

docker compose up -d

而不是旧时代单独安装的 docker-compose 独立二进制。

对新环境来说，优先记住下面这一套就够了：

• docker compose up -d
• docker compose down
• docker compose ps
• docker compose logs -f

二、一个最小可用示例

services:
  blog:
    image: nginx:1.27
    container_name: nginx-mumu-wiki
    ports:
      - "80:80"
    volumes:
      - /mydata/nginx/html:/usr/share/nginx/html:ro
      - /mydata/nginx/conf.d:/etc/nginx/conf.d:ro
    restart: unless-stopped

这类配置已经能覆盖你的静态站点部署场景。

三、放到当前个人技术站，这个文件通常放哪

如果是你现在这套技术站，更推荐把 Compose 文件固定在：

/mydata/nginx/docker-compose.yml

这样目录职责会比较清楚：

• /mydata/nginx/conf.d 放 Nginx 配置
• /mydata/nginx/html/mumu-wiki 放知识库静态文件
• /mydata/nginx/logs 放访问日志和错误日志

也就是说，Compose 管的是“容器怎么起”，真正长期保留的数据和配置仍然在宿主机目录里。

四、几个最常用字段要先会看

services

定义有哪些服务。

每个服务就是一个容器运行单元。

image

指定用哪个镜像启动。

ports

端口映射，格式一般是：

ports:
  - "80:80"

左边是宿主机端口，右边是容器端口。

volumes

目录挂载，最常用来解决：

• 配置持久化
• 数据持久化
• 本地文件映射到容器

restart

定义容器退出后的重启策略。

常见值：

• no
• always
• unless-stopped
• on-failure

五、为什么 Compose 比手写 docker run 更适合长期维护

1. 配置能落盘

不用再靠命令历史回忆当时怎么起的容器。

2. 团队协作更容易

同一个 compose.yml 就是环境说明书。

3. 修改和回滚更直接

改完配置之后：

docker compose up -d

就能按定义重新拉起。

4. 服务关系更清晰

一个项目有哪些容器、挂哪些目录、暴露哪些端口，都能集中看到。

六、工程里常见的写法

带应用和数据库

services:
  app:
    image: myapp:latest
    ports:
      - "8080:8080"
    depends_on:
      - redis

  redis:
    image: redis:7
    ports:
      - "6379:6379"

depends_on 可以控制启动顺序，但它不等于“服务已经可用”。如果应用强依赖下游真正就绪，还要配合健康检查或重试机制。

七、对当前站点更贴近实战的写法

如果后面你要继续维护 wiki 子站、blog 子站甚至后台站点，一个更贴近当前实际的写法会是：

services:
  nginx:
    image: nginx:1.27
    container_name: nginx-mumu-wiki
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /mydata/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - /mydata/nginx/conf.d:/etc/nginx/conf.d:ro
      - /mydata/nginx/html:/usr/share/nginx/html
      - /mydata/nginx/logs:/var/log/nginx
      - /etc/letsencrypt:/etc/letsencrypt:ro
    restart: unless-stopped

这类写法的关键点是：

• html 整体挂载，便于维护多个子站
• conf.d 单独挂载，便于按站点拆配置
• logs 单独挂载，方便后续排查
• letsencrypt 只读挂载，便于 HTTPS 证书续期后直接被 Nginx 使用

八、几个高频命令

启动

docker compose up -d

停止并删除容器

docker compose down

查看状态

docker compose ps

看日志

docker compose logs -f

只重建某个服务

docker compose up -d --force-recreate blog

九、常见误区

1. 以为 Compose 只能开发环境用

它当然很适合本地开发，但小型线上服务同样很适合用 Compose 管理。

2. 以为 depends_on 能保证服务完全可用

它只能保证启动顺序，不保证数据库已经初始化完成、端口已经可连。

3. 以为所有数据都该进容器里

真正需要长期保留的数据和配置，通常都应该挂载到宿主机或数据卷。

4. 改了 compose 文件就以为线上一定更新了

更稳的习惯是每次改完都做三步：

docker compose config
docker compose up -d
docker compose ps

这样能先看配置有没有问题，再确认服务是否真的按新定义重建成功。

一句话总结

当项目开始进入“多容器协作”阶段时，Compose 最大的价值就是把运行方式配置化、可重复、可维护。

对个人博客和小型后端项目来说，这通常已经是非常合适的部署层抽象了。