构建与编排篇：Dockerfile、Compose 和服务拓扑

动手前先知道

这篇文章对应的真实任务是：解释 Dockerfile 与 Compose 的分工，建立小艾知行录的 web、api、nginx、mysql 服务拓扑。

第一次阅读先弄清“为什么需要这一步、它改变了哪个运行对象、失败时去哪里检查”，再执行命令。命令可以查，运行模型和排障路径才是长期能力。

这一章进入“构建与编排”。如果说前一章解决 Docker 对象是什么，那么这一章解决的是：怎么把小艾知行录的前端、后端、Nginx 和依赖服务组织成一个能启动、能更新、能上线的系统。

Dockerfile 负责什么

Dockerfile 是镜像构建说明书。

它回答：

• 基础镜像用什么。
• 依赖怎么安装。
• 项目怎么构建。
• 最终镜像里保留什么。
• 容器启动命令是什么。

对 Go 后端来说，常见做法是多阶段构建：第一阶段编译，第二阶段只保留二进制文件。

对 Next.js 前端来说，常见做法是先安装依赖并构建，再用更轻的运行镜像启动。

Compose 负责什么

Docker Compose 不是构建单个镜像，而是编排多个服务。

它回答：

• 系统里有哪些服务。
• 每个服务用哪个镜像。
• 服务之间怎么依赖。
• 哪些端口对外暴露。
• 哪些环境变量注入容器。
• 哪些目录或数据卷挂载进去。

个人博客这种项目，非常适合 Compose。

为什么不用一堆 docker run

手写 docker run 可以学习概念，但不适合维护真实项目。

因为一个系统通常不止一个容器：

• web
• api
• nginx
• mysql
• redis
• worker

如果全部用命令启动，很快就会变成一堆难以复现的手工操作。

Compose 的价值是把这些操作写进文件里，让部署过程可重复。

构建与编排的推荐流程

代码更新
  ↓
构建后端镜像
  ↓
构建前端镜像
  ↓
更新 Compose 使用的镜像版本
  ↓
docker compose up -d
  ↓
健康检查
  ↓
清理旧资源

其中健康检查非常关键。部署不是容器启动了就结束，而是要确认页面能访问、API 能访问、数据库连接正常。

小艾知行录的服务边界

当前项目建议保持简单：

web：Next.js 公开站和管理端页面
api：Go 后端接口
nginx：统一入口、反向代理、静态缓存、HTTPS
mysql：生产数据库
worker：如果后续后台任务增多，可以从 api 拆出

早期 worker 可以先不拆，等后台任务、搜索索引、AI 生成任务真正变多再拆。

这一章的验收标准

构建与编排做完后，至少要能做到：

• 一条命令启动整套服务。
• 一条命令停止整套服务。
• 日志能按服务查看。
• 配置不写死在镜像里。
• 数据不会因为容器重建而丢失。
• 更新失败能回滚上一版镜像。

这才算从“会用 Docker”走到了“能用 Docker 部署项目”。