一般来说无状态服务比较适合进行容器化,以获得极强水平扩展能力,
但是对于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文件里有个空格。)