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