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-fpm
worker进程和daemon竟然不是同一个用户——可以理解,但是很坑。
最终,配置可以成功代理请求到容器内的fastcgi
,并且rewrite了一通,也可以正常用wp的伪静态页面功能了。
好耶。
顺带一个小插曲:当时还在配php-fpm
的时候,突然发现被人上了挖矿病毒,我可怜的单核CPU直接拉满。检查一通才发现,机器上防火墙不知道为啥关了,并且偷懒没用Unix Domain Socket
,导致被趁虚而入。
哭哭。