Docker 实战：让服务从本地可运行走向可交付

Docker 的价值不只是“把程序装进容器”，而是把运行环境、依赖和启动方式一起描述出来，让本地、测试和服务器尽量使用同一份交付物。

一个服务至少需要说明什么

源码与依赖
        ↓
Dockerfile 构建镜像
        ↓
环境变量、端口、数据卷与网络
        ↓
Compose 编排多个服务
        ↓
健康检查、日志与发布验证

如果只写了 Dockerfile，却没有说明配置从哪里来、数据是否持久化、服务如何互联，部署时仍会回到“在服务器上手工试命令”的状态。

常用本地验证流程

docker compose up -d --build
docker compose ps
docker compose logs --tail=100

先确认容器状态，再看日志，再访问健康检查或核心接口。不要只看到容器启动就认为服务可用：进程可能仍在等待数据库、环境变量可能未加载、端口也可能没有暴露到预期位置。

三个容易被忽略的点

配置不进镜像

真实密钥和环境差异应在运行时注入，不应烘焙进镜像或提交到仓库。项目可以提供 .env.example 说明变量名称和用途，但不放真实值。

数据要有明确归属

数据库、用户上传内容和任务状态如果只存于容器内部，重建容器就可能丢失。需要明确哪些目录使用数据卷，哪些内容可以随镜像重建。

健康检查要覆盖真正依赖

健康检查不应只验证“HTTP 端口打开”。对依赖数据库或队列的服务，更有意义的是验证应用已完成初始化，并能访问必要依赖。

发生问题时的定位顺序

1. docker compose ps：容器是否正在运行、是否反复退出。
2. docker compose logs：首次报错发生在哪里。
3. 配置与挂载：变量是否加载、文件路径是否正确、权限是否足够。
4. 网络与端口：服务名、内部端口、宿主机映射是否一致。
5. 数据状态：依赖服务是否就绪、数据卷是否符合预期。

容器化的目标是减少环境差异，而不是把排障变得更神秘。把启动、配置、数据和验证写清楚，才是真正可交付的 Docker 服务。