一般来说无状态服务比较适合进行容器化，以获得极强水平扩展能力，但是对于WordPress这种应用，进行容器化就不可避免地要遇到数据持久化的问题。数据持久化主要在体现在两个方面：wp-content文件夹和数据库。
经典的部署方案是本地创建一个数据卷，然后再加上一个容器化的数据库。那么对于容器化的终极目的——水平扩展能力——这样的经典方案是远不能达到要求的。
首先是经典方案中容器化的数据库，个人建议还是独立到其他服务器，或者干脆直接安排在宿主机上。第一、虚拟化是有开销的，像数据库这类偏重IO的应用，潜在地会降低性能；第二、容器化后的数据库并没有得到更高的水平扩展能力，同时各数据库间的数据同步将成为一个大问题（会有一个dockerd和mysqld谁先挂掉的问题，谁能保证dockerd这头鲸鱼搁浅之前能恰当地杀掉mysqld这只海豚？）
另一个就是本地数据卷的问题，个人建议数据卷直接挂载NFS共享，而不是挂载本地文件系统，这样就能省去很多wp-content目录数据同步的麻烦。挂载NFS共享还可能有一个读写分离的好处，毕竟读者只需要读操作，编者才需要写操作（然而并没有太大意义）。
因此总体而言docker-compose.yml文件看起来就会像下面这样
version: "3"
services:
wordpress:
image: wordpress:latest
ports:
- "8000:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:port # <---这里是数据库的地址和端口
WORDPRESS_DB_USER: wordpress # <---这里是数据库用户名
WORDPRESS_DB_PASSWORD: wordpress # <---这里是数据库密码
volumes:
- wp-data:/var/www/html
volumes:
wp-data:
driver: local
driver_opts:
type: nfs
o: "addr=192.168.1.54,rw,sync" # <---这里是NFS的地址
device: ":/wordpress-files" # <---这里是NFS的共享路径
那么此时水平扩展只需要多开几个docker-compose，然后前端nginx恰当地反向代理、负载均衡即可（一定不要把proxy_set_header Host漏了，不然就会冒出充满血泪的Warning: Cannot modify header information - headers already sent by ...，一般的troubleshot只会提示你说可能php文件里有个空格。）