小议WordPress的容器化

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

留下评论