众所周知,WordPress 是一个对 MySQL 强依赖的 CMS。MySQL 众所周知也可以用 MariaDB 代餐。不过不管是 MySQL 还是 MariaDB,保持在后台运行都要狂吃 200+ m 内存。这对于个人站点当然是特别浪费的。
但是官方给出了一个插件 SQLite Database Integration,据称是为了测试他们即将合并入主线的 SQLite 支持而提前放出的插件。而这个插件又是 fork 的 别人的 东西,因此按理来说应该是 battle-tested 了。于是脑子一热,就整了一些迁移。
迁移的过程就不提了,没什么技术含量,基本上就是安装插件,然后重新走一遍安装流程,导入备份的文章就行了。我怕手贱,还把插件丢到了 mu-plugins 里面,不过看着 db.php 上面写着的
* This file is auto-generated and copied from the sqlite plugin.
* Please don't edit this file directly.
我知道显然这不是建议的操作。于是又丢回 plugins 了。希望我的手安分一点。
在迁移的同时,将服务器上的所有服务放在了同一个 docker-compose.yaml 里面。或许这才是把我又耗到一点的根本原因:先是把 WordPress 换成 fpm 镜像和 caddy 合并跑,再因为不想看到跨镜像挂载换回 apache 镜像拿 caddy 接着做反向代理,又在把 volume mount 的内容转成 bind mount 的过程中 cp 不带 -p 没保留权限而暴毙,还忘记改 wp-config.php 的一众 secret key 而差点成为公网靶场。
12/1 10:38 更新,因为一些洁癖又换回了 fpm(不会真有人拿 Caddy 反代 Apache 吧!!!)。
btw,感谢 Caddy,有着全世界最好配置的 php_fastcgi。配置文件放在下面,用做记录。
另外记录一个很烦的一点:WordPress 不支持检测 Caddy 的 Rewrite。
存放一些杂七杂八的配置文件
docker-compose.yaml
version: "3"
services:
wordpress:
image: php:8.2-fpm-alpine
restart: unless-stopped
volumes:
- $PWD/wordpress/html:/var/www/html
- $PWD/wordpress/php.ini:/usr/local/etc/php/conf.d/wordpress.ini
caddy:
image: caddy:alpine
restart: unless-stopped
cap_add:
- NET_ADMIN
ports:
- "80:80"
- "443:443"
- "443:443/udp"
volumes:
- $PWD/caddy/Caddyfile:/etc/caddy/Caddyfile
- $PWD/caddy/site:/srv
- $PWD/wordpress/html:/srv/wordpress
- caddy_data:/data
- caddy_config:/config
volumes:
caddy_data:
caddy_config:
Caddyfile
hymint.space {
root * /srv/wordpress
php_fastcgi wordpress:9000 {
root /var/www/html
}
file_server
}
总之暂时是安稳下来了。我是真的体会到 Docker 这东西和 Traditional PHP 就是八字不合。然而又有什么办法呢?总不能真用 Debian 12 给的 wordpress 包吧——诶,不过大概也不是不行,它可是 Debian 啊。就是版本应该会太老了点。
12/1 10:48 更新,续上面的配置文件,其实按照这样配置 Docker WordPress 也还不错。