前段时间我要在一台空服务器上把服务跑起来。以前我都是直接装环境,这次改用 Docker。刚开始我想得很简单:装好 Docker,把服务跑起来就完了。结果实际做下来,踩的坑比我预想的多。这篇把整个过程从头记一遍。

我为什么选 Docker

• 环境一次装好,以后换机器不用重新折腾依赖
• 配置和数据都放在一个目录里,备份和迁移都简单
• 出问题的时候,删掉容器重建就行,不会有残留

我实际走的流程

图 1:我实际走的部署流程(卡在「健康检查」那步三次)

看上去六步很顺,但我在这条路上来回走了三次 —— 每次都卡在「健康检查」这一步。

我踩的三个坑

坑一:权限。服务起不来的第一个原因,是容器里的用户和宿主机上的文件属主对不上,日志里一堆「权限不足」。后来我把数据目录的属主调成容器里跑服务的那个用户,问题就没了。

坑二:端口没放开。我在 compose 里映射了端口,本地 curl 也通,但外面访问不了 —— 因为防火墙没放行。这个坑很隐蔽,因为「本地能通」和「外面能通」是两件事。

坑三:环境变量没读到。我把数据库密码写在 .env 里,但 compose 里没显式引用,容器里读到的就是空值。表现是服务起来了、页面也能打开,但一连数据库就报错。

我的目录结构

图 2:配置和数据放同一个项目目录,备份时整体打包

这么放的好处是:后来升级版本时,我直接打包整个目录就是完整备份,回滚也只需要这一个目录。

我的结论

用 Docker 之后,我把部署步骤固定成四句话:

1. 先确认服务器上装好了 Docker 和 compose
2. 所有可变的东西(端口、密码、路径)都写进 .env,不写死在配置里
3. 起完先做健康检查,不看「端口通没通」
4. 改任何配置前,先把整个项目目录备份一份

这套流程走下来,现在再布一个新服务,我大概十来分钟就能搞定,而且心里有底。