用Docker部署网站一年后的真实感受：省心和踩坑各占一半

去年把三个WordPress站和一个Node.js项目全搬到了Docker上。当时的想法很简单：统一环境、方便迁移、不怕依赖冲突。一年下来，省心的地方确实省心，但坑也没少踩。

为什么搬

之前的部署方式是宝塔面板直接装PHP+MySQL+Nginx。三个WordPress站，一个要PHP 7.4，一个要PHP 8.1，一个插件必须PHP 8.2。宝塔切换PHP版本虽然支持，但每次切都心慌——怕影响别的站。Node.js项目更麻烦，系统自带的Node版本和项目要求的不一样，nvm管理也经常出问题。

Docker的好处就在这：每个项目一个容器，环境完全隔离。WordPress 6.7用PHP 8.2，老项目用PHP 7.4，互不干扰。

实际部署流程

用的docker-compose，一个文件定义整套环境。典型的WordPress部署：一个Nginx容器做反向代理，一个PHP-FPM容器跑WordPress，一个MySQL容器存数据，一个Redis容器做缓存。四个容器一个网络，数据卷持久化到宿主机。

迁移的时候特别爽。以前搬家要装PHP、装MySQL、配Nginx、导数据库，少说半天。现在把docker-compose.yml和数据目录拷过去，docker-compose up -d，五分钟搞定。上个月把一个站从阿里云搬到腾讯云，就是这么干的。

踩过的坑

第一个坑：容器内文件权限。WordPress容器里的进程跑www-data用户，但宿主机上挂载的数据卷是root创建的。结果WordPress无法写入wp-content/uploads，上传图片报错。解决方案：创建数据卷目录时指定uid 33（www-data的UID），或者在docker-compose里用user: "33:33"。

第二个坑：MySQL数据卷的位置。一开始把MySQL数据放在容器内，没挂载外部卷。容器重建的时候数据全没了。血的教训。现在所有有状态的服务（MySQL、Redis、上传文件）全部挂载外部卷，而且备份目录权限收紧。

第三个坑：容器间通信。WordPress容器要连MySQL容器，不能用localhost，得用容器名。一开始不知道，数据库连接一直报「Connection refused」。在docker-compose里定义同一个network，然后用服务名（比如db）作为主机名就行了。

第四个坑：日志管理。Docker默认日志不轮转，跑半年日志文件好几个G。在daemon.json里加了"max-size": "10m"和"max-file": "3"就好了，但这个坑我踩了三个月才发现。

性能对比

跑了一年的数据。同一个WordPress站点：裸机部署TTFB平均180ms，Docker部署TTFB平均210ms。多出来的30ms主要是Nginx容器多了一层网络转发。对用户来说感知不到，但对追求极致性能的场景要注意。

内存占用：裸机PHP-FPM+Nginx+MySQL总共占约400MB，Docker版本多一层容器运行时，总共约450MB。服务器从2GB内存升到4GB就够了，多花不了多少钱。

CPU基本没差别。Docker的性能开销在IO和网络，不在计算。

什么场景适合Docker

多项目共存、环境版本不同、需要频繁迁移——这三种情况Docker优势最大。个人博客就一个PHP版本，宝塔完全够用，没必要上Docker。

不适合的场景：需要极致性能的高并发站（裸机少一层开销）、服务器内存小于1GB（Docker本身占资源）、以及不熟悉Linux的运维人员（Docker出了问题排查比裸机复杂）。

一年后的结论

Docker不是银弹，但它解决了「环境隔离」和「快速迁移」这两个真实痛点。如果你管着3个以上不同技术栈的项目，值得上。如果就一个WordPress站，宝塔足够了。

我现在维护三个WordPress站+一个Node.js项目，每月花在运维上的时间从8小时降到了2小时。主要省在不用反复配环境和处理依赖冲突。但Docker本身的学曲线，大概要花一到两周。

标签： Docker WordPress部署 容器化 服务器运维 网站迁移