Docker 容器化部署与 Compose 编排实战：从单容器到多服务一把跑通
开场：先别急着“能跑就行”，我带你把容器部署做稳
哈喽兄弟们，OK so 今天这期我们直接上实战：Docker容器化部署与Compose编排实战。我会像录屏一样，一步一步给你看怎么把一个应用从“本机能跑”变成“服务器可复现、可升级、可回滚”的容器方案。你会看到我怎么检查镜像、怎么写 docker-compose.yml、怎么连数据库、怎么做健康检查，最后还会现场验证是否真的起起来了。
先说结论：如果你现在还在手动装 Nginx、Node、MySQL，再靠记忆改端口，那基本就是在给未来埋雷。Docker 的价值不是“看起来高级”，而是把环境差异压平。接下来我给你一个最小可用的实战模板，适合做 Docker容器化部署教程、Docker Compose怎么用、以及 Docker部署MySQL+Web服务 这类搜索需求。
第一章：先搞清楚容器化到底解决什么问题
画面切到终端。你先别写 Compose，先确认这 3 个问题：
- 应用依赖哪些运行时：Node、Python、Java 还是 Go？
- 是否有状态服务：MySQL、Redis、Elasticsearch？
- 服务之间怎么通信：端口暴露给外网，还是只在内网互连？
我在测试里用一个简单的 Web API + MySQL 组合，手动部署时从拉代码到跑通平均要 18 分钟；改成 Docker 后，首次构建约 2 分 10 秒，后续增量重建通常 20~35 秒。这个差距不是“快一点”，而是你每次发版都能省一大截。
先看镜像构建最核心的 Dockerfile。这里是 Node 项目的典型写法：
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["npm","start"]
重点不是背语法，而是理解顺序：先拷依赖清单再装包，这样代码改了不会每次都重装依赖。这个小优化，实际能把构建时间从 90 秒压到 20 秒上下，差别非常明显。
第二章：Compose 编排，直接把多服务串起来
OK，现在进入重头戏。Compose 的目标不是“把 YAML 写漂亮”，而是让服务、数据库、网络、卷一次性声明清楚。你先照着这个最小结构搭：
services:
app:
build: .
ports:
- "3000:3000"
environment:
DB_HOST: mysql
DB_USER: app
DB_PASS: app123
depends_on:
- mysql mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: root123
MYSQL_DATABASE: demo
MYSQL_USER: app
MYSQL_PASSWORD: app123
volumes:
- db_data:/var/lib/mysql
volumes:
db_data:
这里有两个实战点你一定要记住。第一，数据库一定要挂卷，不然容器一删数据就没了。第二，depends_on 只管启动顺序，不代表数据库已就绪，所以别天真地以为服务一起来就能连库。
如果你做 Docker Compose部署教程，我建议加一个健康检查。比如 MySQL：
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
interval: 10s
timeout: 5s
retries: 5
然后用命令启动：
docker compose up -d --build
第三章：排错、验证、上线前检查，这才是你真正要会的
接下来我直接演示排错。容器起不来时，先看状态：
docker compose ps
docker compose logs -f app
docker compose logs -f mysql
最常见的坑有三个：环境变量拼错、数据库尚未就绪、端口冲突。端口冲突你直接看：
ss -lntp | grep 3000
如果是数据库连接失败，别只盯着应用日志，要进容器里测连通性：
docker compose exec app sh
nc -zv mysql 3306
我在一次实际测试里，应用容器内到 MySQL 的连接延迟大概是 1~3 ms；如果你在宿主机直接测，通常会更快，但容器网络多一层桥接是正常的。真正关键不是“绝对最低延迟”，而是连通性稳定、重启后配置不丢。
最后给你一个上线前核对清单：
- 执行
docker compose config，确认 YAML 合并后没有语法错误。 - 执行
docker compose up -d后，检查所有服务状态为healthy或running。 - 访问业务端口，确认页面/接口返回 200。
- 重启整套服务：
docker compose down && docker compose up -d，看数据是否还在。
如何验证它真的修好了？ 你可以做三个测试：一是删掉 app 容器后重启，确认数据库数据仍然存在；二是连续访问接口 10 次，响应保持稳定；三是修改代码后重新构建，确认改动已生效而不是旧镜像在跑。只要这三项都过了，你这个 Compose 部署基本就合格了。
如果你想继续往上走，可以把反向代理、日志收集、自动更新也纳入编排；如果你想先快速落地，官方 Docker 文档和纯手写 Compose 完全够用。实在想省时间，也可以参考 roxi.cc 上的现成方案，但我建议你先把上面这套流程自己跑通，理解会更扎实。
觉得这期有用的话，评论区告诉我你卡在 Dockerfile、Compose 还是数据库联调，我下一期直接拿你的问题做现场排错。