发布版说明

• 已对真实域名、公网 IP、具体云厂商指代做脱敏处理。
• 原始学习笔记未改动，这一版用于公开发布。

专题：Docker Compose 进阶

这篇不是教“怎么装 Docker”，而是把我前面已经做过的这些东西串起来：

• Uptime Kuma
• FileBrowser
• WordPress + MySQL

让我真正理解：

docker compose 到底在编排什么。

---

一、先讲清楚：Compose 不是“写个 yml 跑起来”这么简单

刚开始学的时候，很容易把 compose.yml 看成：

一份把命令抄进 YAML 的启动文件

这理解太浅了。

更准确的理解应该是：

Compose 是“一个应用栈的声明书”

它在描述：

1. 这个应用栈里有哪些服务
2. 每个服务用什么镜像
3. 它们之间怎么连
4. 数据存在哪里
5. 端口怎么暴露
6. 环境变量怎么传进去
7. 出问题后重启策略是什么

所以：

docker run 更像“手动起一个容器”
docker compose 更像“声明并管理一整套应用栈”

---

二、为什么我现在才开始学 Compose 进阶

因为前面我已经有了 3 种实际感受：

1. 单容器应用

• Uptime Kuma
• FileBrowser

特点：

• 一个服务就够了
• 没数据库依赖
• compose 比较简单

2. 多容器应用栈

• WordPress + MySQL

特点：

• 至少两个服务
• 服务之间需要通信
• 数据要分别持久化

3. Nginx 不属于 Compose 主体

前面我一直是把：

• 应用栈
• 和 Nginx 反代

拆开来做的。

这让我已经开始能看懂：

• 应用编排
• 和网关入口

其实是两个层面的事。

现在学 Compose 进阶，正是时候。

---

三、Compose 文件最核心的 3 个块

3.1 services

这是最核心的部分。

它表示：

这个应用栈里有哪些服务

比如：

services:
  db:
    image: mysql:8.0

  wordpress:
    image: wordpress:latest

这里的意思不是“有两个镜像”，而是：

• 一个服务叫 db
• 一个服务叫 wordpress

以后容器之间通信，就是通过这些服务名。

---

3.2 volumes

它表示：

数据怎么持久化

最常见有两类：

方式 A：绑定宿主机目录

比如：

volumes:
  - ./wordpress:/var/www/html

意思是：

• 把宿主机当前目录下的 wordpress
• 挂到容器里的 /var/www/html

优点：

• 目录透明
• 方便自己看文件
• 方便备份

缺点：

• 权限问题更容易碰到

方式 B：Docker 命名卷

比如：

volumes:
  - db_data:/var/lib/mysql

并在下面声明：

volumes:
  db_data:

优点：

• Docker 管理更完整
• 相对更独立

缺点：

• 新手不如宿主机目录直观

我前面学习阶段优先用宿主机目录，是对的，因为更容易理解。

---

3.3 networks

默认情况下，Compose 会自动给一套应用栈创建内部网络。

这意味着：

• wordpress 可以直接访问 db
• 不需要自己写 IP
• 不需要在宿主机上暴露 MySQL

这也是为什么前面可以直接写：

WORDPRESS_DB_HOST: db:3306

因为：

服务名本身就可以当 DNS 名来用

这是 Compose 最重要的能力之一。

---

四、服务之间到底怎么通信

这是我前面做 WordPress + MySQL 时真正开始理解的点。

4.1 错误直觉

很多新手会想：

WordPress 连 MySQL，是不是要写成宿主机 IP？

比如乱写成：

WORDPRESS_DB_HOST: 127.0.0.1:3306

这是错的。

原因：

• 127.0.0.1 在容器里只代表容器自己
• 它不是另一个容器

4.2 正确思路

Compose 里应该写服务名：

WORDPRESS_DB_HOST: db:3306

因为：

• db 是 Compose 服务名
• Compose 自动给它做了内部 DNS

一句话记：

Compose 多服务通信，优先用“服务名”，不要自己写 IP。

---

五、depends_on 到底能做什么

很多人一看到这个就以为：

depends_on 可以保证 MySQL 完全准备好，WordPress 再启动

这是误解。

它真正能做的

它只能保证：

• 启动顺序

比如：

depends_on:
  - db

表示：

• 先启动 db
• 再启动 wordpress

它做不到的

它不能保证：

• db 已经初始化完成
• MySQL 已经可连接
• 数据库已经 ready

这就是为什么前面可能会遇到：

• MySQL 容器起来了
• 但 WordPress 一开始还是连不上数据库

所以以后看到这类问题，要记住：

depends_on 解决的是“先后”，不是“就绪”

---

六、Compose 里最常用的字段，按“会用”标准整理

6.1 image

指定镜像：

image: mysql:8.0

6.2 container_name

自定义容器名：

container_name: wp-mysql

优点：

• docker logs wp-mysql 好记

缺点：

• 以后多环境复制时不够灵活

学习阶段可以用，生产环境是否保留视情况。

6.3 restart

重启策略：

restart: unless-stopped

我现在优先记这个：

• 机器重启后自动拉起
• 手动停掉后不会自己乱起

6.4 ports

端口映射：

ports:
  - "127.0.0.1:8082:80"

记法：

宿主机IP:宿主机端口:容器端口

6.5 environment

传环境变量：

environment:
  MYSQL_DATABASE: wordpress

本质是把配置传给容器启动时的应用。

6.6 volumes

前面已经讲过，本质是挂载数据。

---

七、我前面做的 3 个项目，分别对应什么 Compose 水平

7.1 Uptime Kuma

对应能力：

• 单容器
• 一个数据目录
• 本机端口绑定

说明我已经会：

• 最小 Compose
• 基础持久化

7.2 FileBrowser

对应能力：

• 单容器
• 多数据目录
• 仍然是本机端口绑定

说明我已经开始理解：

• 不同应用的数据拆分方式不同

7.3 WordPress + MySQL

对应能力：

• 多容器
• 服务间通信
• 不同服务有不同数据卷
• 主应用依赖数据库

说明我已经进入：

真正的“应用栈编排”

---

八、Compose 日常运维最常用的命令

以后别只会 up -d。

8.1 启动

docker compose up -d

8.2 看状态

docker compose ps

8.3 看日志

docker compose logs
docker compose logs -f
docker compose logs --tail 100
docker compose logs -f wordpress

8.4 重启整个栈

docker compose restart

8.5 重启单个服务

docker compose restart wordpress
docker compose restart db

8.6 停止

docker compose stop

8.7 停止并删除容器

docker compose down

8.8 停止并删除容器、网络、匿名卷

docker compose down -v

这个命令危险，别乱用。
如果挂的是数据库卷，可能把数据一起清了。

8.9 拉最新镜像并重建

docker compose pull
docker compose up -d

---

九、我以后看 compose 文件时的阅读顺序

以后看到任何一个 compose.yml，按这个顺序读：

1. 先看有几个 services
2. 再看每个服务的 image
3. 再看有没有 ports
4. 再看 volumes
5. 再看 environment
6. 最后看服务之间的关系，比如 depends_on

这样读，不容易被 YAML 吓住。

---

十、这节课真正要记住的 6 件事

1. Compose 本质上是在描述一套应用栈

不是“把命令写成 YAML”。

2. 服务之间优先通过服务名通信

不要乱写 IP。

3. depends_on 只保证顺序，不保证 ready

这是多服务排障的重要前提。

4. 数据卷设计本身就是部署设计的一部分

不是附属细节。

5. 单容器应用和多容器应用栈，思维方式不同

前者只要应用自己活着。
后者还得考虑依赖服务。

6. 先理解 Compose，后面看 LNMP/LDNMP 才不会像看天书

因为它们本质上也是一套更复杂的应用编排。

---

十一、这节课之后最适合继续什么

建议继续顺序：

1. Nginx 多站点与反向代理
2. Redis 与缓存
3. PHP-FPM / LNMP / LDNMP

原因：

• Compose 已经帮我理解了“应用栈”
• 下一步应该理解“入口层”
• 再后面才去学“缓存层”和“完整网站底座”

---

一句话给未来的自己

前面我是“会用 compose 起项目”，
这节课之后，要开始变成：

知道 compose 文件里的每一块到底在描述什么，以及多个服务为什么能组成一套完整应用栈。