2022年7月8月，我终于想起来，我原来还有个博客（误）。
看了下上一篇博客的时间，还是2020年元旦——两年半前，这也太长了。本着“过去的事情就翻篇”的原则，前面干了些啥经历了些啥就暂且不提了。近况也蛮复杂的，毕了业找了工作，这些就哪天开一篇新博客详谈吧。
今天主要想说下博客重启的主要变化。
第一个是博客由原先的地址(https://blog.baka.pw) 迁到了现在的新地址 (https://i.lyt.moe) ，主要的动机其实很简单，就是域名闲置好长时间了，赶紧用用吧。
第二个，之前一直使用的服务器机房迁移，竟然无法保留数据。应用数据库这种备份了下来，但是环境什么的就得重新配了，哭哭。
之前的机器上一直使用的Nginx+Docker的技术栈，很好用，功能也很强大，不过既然迁移了，那就得搞点不一样的了。于是，现在的服务器上，使用了Caddy作为反向代理服务器，并且用Podman替代了Docker 的使用。一番折腾后，用起来还是比较舒服的。可以来简单分享下我是这么配置的。
Podman
想玩这个东西好久了。但其实硬要想为什么要用它，也没法给出一个非常具有说服力的原因，可能就是想玩玩新东西吧。
如果硬要给一个理由的话，那就是Podman是Daemonless的，不需要跑一个要了命的Daemon，Daemon挂了会把容器一起带挂（我一直就很好奇，升级Docker大版本，就非得要停掉所有容器吗，这也太怪了），并且甚至还可以以非root的权限来跑容器，也足够安全；并且它和Docker基本完全兼容（在CLI和API上都是），无缝开心迁移。
不过，如果要迁移docker-compose跑的应用的话还是有些小麻烦。可以考虑尝试一下podman-compose，不过当时我配置服务器的时候不知为何完全没看到这个项目（也许是关注在和Docker API完全兼容上了），所以走了比较麻烦的方式，起一个Podman Socket来模拟Docker API。
systemctl enable podman.socket
默认会启动在/run/podman/podman.sock这里，不想设置什么环境变量之类的了，就直接改一下，把sock位置改到/var/run/docker.sock吧。
[Unit]
Description=Podman API Socket
Documentation=man:podman-system-service(1)
[Socket]
ListenStream=%t/docker.sock
SocketMode=0660
[Install]
WantedBy=sockets.target
重新启动下podman.socket，docker-compose就能正常使用了。
好耶。
顺带搞个alias到docker，就更完美了。
alias docker="podman -r --url unix:/var/run/docker.sock"
Caddy
上班时间和nginx打交道比较多，不想在个人服务器上再玩nginx或者openresty了，于是选了个简单的方案：用Caddy。
这个选型思路可比上面那个清晰多了：就是为了能够减轻天天配TLS证书的负担！
遥想当年还在搞某统计网站的时候，因为年少无知且链路搞得比较复杂（虽然好像现在更复杂一些），配置证书一直都是个很痛苦的事情。时至今日，我依旧没把nginx多服务器全自动泛域名证书搞明白（更新完证书还得reload的，你说气不气）。所以，干脆搞一个能自动配证书的算了，于是Caddy成功入了选。
当然，用Caddy到把博客配置起来，其实还是有点折腾的。
众所周知，wordpress是一个基于php开发的博客系统，因此一般的架构就是 php -> php-fpm -> wordpress 这样一个走法，顺手跑一个mariadb当数据库。之前使用了bitnami/wordpress这一个镜像，暴露出端口，用nginx做一个反代。wordpress的版本全跟镜像版本走，镜像里还得多一个apache。虽然数据挂出来了，但是升级wp版本，装插件什么的依旧是老大难问题。
所以，这次换了个形式，wordpress源码放在本机上，但是数据库和php-fpm依旧使用了镜像，前端走Caddy直接走fastcgi到php-fpm。镜像启动还是好说的，简单写个docker-compose拉起来就行了。之后就是研究怎么把Caddyfile写对。摸索了大半天，终于发现这样可行：
i.lyt.moe {
@rewriteable {
not path /wp-*
}
rewrite @rewriteable /index.php?{query}
root * /var/www/wordpress # 本地路径
php_fastcgi localhost:9000 {
root /app # 容器内路径
try_files {path} {path}/index.php
}
encode gzip
file_server
}
再顺带一提，当时折腾了大半天，发现权限有问题，看了半天才发现容器内php-fpmworker进程和daemon竟然不是同一个用户——可以理解，但是很坑。
最终，配置可以成功代理请求到容器内的fastcgi，并且rewrite了一通，也可以正常用wp的伪静态页面功能了。
好耶。
顺带一个小插曲：当时还在配php-fpm的时候，突然发现被人上了挖矿病毒，我可怜的单核CPU直接拉满。检查一通才发现，机器上防火墙不知道为啥关了，并且偷懒没用Unix Domain Socket，导致被趁虚而入。
哭哭。