小议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文件里有个空格。）