花了两周把WordPress从单机迁到Docker集群，踩过的坑全在这了

说出来你可能不信——一个日均PV不到五万的个人博客，为什么要折腾集群？答案很简单：我想学。而且原来的单机服务器五年没重装过系统，各种依赖版本乱成一锅粥，PHP 7.4和8.1同时装在上面，composer经常炸。

趁着五一假期，干脆整个推倒重建。目标：三个阿里云ECS节点搭Docker Swarm，WordPress容器化，MySQL独立RDS，Redis做对象缓存，NFS做共享存储。

听起来挺标准的对吧？但实际搞起来碰到的坑，没有一个教程提前告诉过你。

坑一：wp-content/uploads的一致性陷阱

Docker Swarm会把请求随机分发到不同节点。用户上传一张图片到了节点A的容器里，下一个请求可能被路由到节点B——然后图片404。教程要么让你用S3插件（一个月几十刀），要么让你挂NFS（性能差）。

最后用了NFS但是加了varnish缓存层。图片第一次从NFS读，之后都从内存命中。实测首页加载时间比原来单机还快了200ms。

坑二：wp-cron并发执行

容器一多，wp-cron就疯了。三个节点各有自己的cron触发器，定时任务被重复跑了三次——发邮件发了三封，数据库清理也跑了三次，有个计划发布还提前了。

解决办法是把wp-cron禁掉，换成系统级的crontab只在管理节点上跑一条wp cron事件触发命令。简单粗暴，但管用。

坑三：.htaccess不生效

Nginx容器里根本没有.htaccess这个概念。之前在Apache上配的几十条重定向规则全废了。一条一条翻译成nginx rewrite，搞了我整整一个下午。

建议别偷懒——如果你的站URL结构比较复杂，迁移之前就先把rewrite规则整理成nginx格式，别等到网站挂了再手忙脚乱。

坑四：Session丢失

WooCommerce和几个会员插件依赖PHP Session，默认是文件存储。请求漂到别的节点就登出了。改Redis存储Session以后好了，但要注意Redis的maxmemory设够，不然它会在你不知道的时候悄悄淘汰session数据。

值不值？

折腾了两周，网站本质上还是一样的网站。但好处也很实在：现在一个节点挂了流量自动切，升级WordPress只需要重新构建镜像然后滚动更新，回滚也只要一条命令。更重要的是，再也不怕服务器环境了——现在所有依赖都锁在Dockerfile里，换机器部署就是docker stack deploy一条命令。

如果你只有一个小网站并且不在乎这些，别学我折腾。但如果你想把这些东西搞明白——动手，你学到的远比教程多。

标签： wordpress Docker 网站迁移 运维经验 踩坑记录