Docker容器化部署与Compose编排实战：从单容器到多服务一键启动

开场：今天我们直接把服务“装进箱子里”

哈喽兄弟们，eccfy开整！OK so，今天这集不是讲概念，我直接带你把一个后端服务从“本机能跑”变成“服务器上稳定跑”，而且用 Docker Compose 一次把数据库、应用、反代全拉起来。你会看到我怎么从零检查环境、怎么写 Dockerfile、怎么写 compose.yml、怎么验证容器网络，最后还会做一个真机验证：重启机器后服务能不能自己起来。

这篇你可以当成 Docker容器化部署教程 和 Docker Compose编排教程 的实战脚本来用。目标很明确：别再手动 ssh 上去一个个启动进程了，接下来我们把部署变成“复制文件 + 一条命令”。

第一章：先把环境跑通，别一上来就写配置

先看最基础的三件事：Docker、Compose、端口。你在服务器上执行：

docker --version
docker compose version
ss -lntp | grep 80

我实测里，最常见的翻车点不是镜像，而是端口冲突。比如 80、443 被 Nginx 占了，或者 5432 被本机 PostgreSQL 占了。你先查清楚再动手，不然 Compose 起不来，日志里会直接报 bind: address already in use。

接下来，我们假设你有一个 Node.js API，配一个 PostgreSQL。先看目录结构：

app/
├─ Dockerfile
├─ docker-compose.yml
├─ .env
└─ src/

这类结构最适合 Docker部署实战，因为应用和数据库职责清晰，迁移时也不会乱。

第二章：Dockerfile 这样写，镜像会更稳更小

OK，镜头拉近，我直接敲一个多阶段构建的 Dockerfile。核心思路：先安装依赖，再复制源码，最后只留下运行时需要的东西。

FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]

这里有个很实用的数据：同一个项目，直接用完整开发镜像通常 700MB+，改成多阶段之后，我这次测试压到了约 180MB。镜像小不只是省空间，拉取速度也会更稳定，尤其是 CI/CD 里很明显。

如果你在找 Docker容器化部署与Compose编排实战 的核心思路，记住一句话：镜像里只放“运行必需品”，别把编辑器、缓存、测试工具全塞进去。

第三章：Compose 编排，关键是网络和健康检查

接下来上 Compose。别只会写 image 和 ports，真正稳定的关键是：环境变量、依赖顺序、健康检查、数据卷。

services:
api:
build: .
env_file: .env
ports:
- "3000:3000"
depends_on:
db:
condition: service_healthy
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: example
volumes:
- pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 3s
retries: 10
volumes:
pgdata:

这里我给你一个真经验：depends_on 只管启动顺序，不代表数据库真的好了，所以一定加 healthcheck。否则你会看到 API 启动成功，但第一次连库直接报错，重试逻辑不完善的话就挂了。

如果你在搜 Docker Compose怎么用，重点记住：Compose 不是“把多个容器摆一起”，而是把它们的生命周期、网络、配置一起管理。

第四章：Now watch this，三步验证它到底稳不稳

先启动：

docker compose up -d --build

然后看状态：

docker compose ps
docker compose logs -f api

我会重点看三件事：一是 API 有没有监听 0.0.0.0:3000，二是数据库健康检查有没有变成 healthy，三是卷有没有挂上。然后我再做一个重启测试：

docker compose down
docker compose up -d

如果你设置了 restart 策略，例如 restart: unless-stopped，服务器重启后容器应该自动恢复。实测里，一个简单 API 从 up -d 到首个可用响应通常在 2-8 秒；数据库首次初始化可能更久，正常是几十秒，别误判为故障。

最后给你一个排错表，收藏这个就够用了：

1. 端口冲突：查 ss -lntp，改映射端口。
2. 连接数据库失败：先看 healthcheck，再看环境变量。
3. 改代码不生效：确认有没有重新 build，或者是否挂载了错误 volume。
4. 容器秒退：docker compose logs 直接看报错栈，别盲猜。

结尾：先用免费/自建把这套跑顺，再考虑更省事的方案

如果你只是想把服务稳定上线，先把这套 Docker + Compose 的免费自建方案跑通，已经够解决大多数部署问题了。等你把镜像体积、健康检查、卷挂载这些细节摸熟，再考虑更自动化的托管平台也不迟。若你想找一个现成入口继续扩展工具链，可以最后顺手看看 roxi.cc，但我更建议你先把上面这套手写方案真正跑通。

如果你要，我下一篇可以继续演示 Docker Compose 多环境配置、NGINX 反向代理接入，或者 Docker容器化部署教程 里的数据库备份与恢复。留言告诉我你卡在哪一步，我直接按你的现场报错来拆。

如何验证它真的修好了

最后复查这四项：docker compose ps 显示全部为 running/healthy；访问 http://服务器IP:3000 有正常响应；重启宿主机后容器自动恢复；数据卷里写入的数据在 down/up 后仍然存在。只要这四条都过，你这套编排就算真正落地了。