这周博客从本地的 Docker Compose 环境搬到了生产环境的 VPS 上。
目标很简单:让各个服务保持可复现,保住数据不丢,让部署变成一件可以重复做的事,而不是把服务器当成一台一次性机器来将就。
搬了什么
这个应用是以一组 Compose 服务的形式跑起来的:前端、认证服务、博客 API、邮件服务、日志服务、Postgres、MinIO,还有 Caddy。
Postgres 和 MinIO 的数据是直接迁移到 VPS 上的,不是从空卷开始的。这样一来,原有的用户、文章、媒体文件和各服务的数据都保住了。迁移过程中 Postgres 的密码做了轮换,生产环境的配置文件也是放在服务器上,而不是放进仓库里。
Caddy 负责 blog.bjornmagne.com 的 HTTPS。公开站点会跳转到对应语言的首页,各服务的健康检查也让整个部署容易检查状态。
部署
第一次上生产用的是本地构建好的镜像,先安全地把站点跑起来再说。现在仓库里也有了一套基于镜像仓库的 Compose 叠加配置,还有一个 GitLab 的部署任务。main 分支的构建会打上提交 SHA 作为标签,部署任务会等公开的 HTTPS 健康检查通过之后,才判定这次发布成功。
这样就有了一条清楚的回滚路径:选上一个镜像标签,把整套服务重新拉起来,再验证同一个健康检查端点。
一个关于认证的小教训
数据迁移过程中暴露出一个很容易被忽略的细节。认证服务的签名密钥在静态存储时是用一个部署密钥加密的。数据库和加密后的密钥可以一起搬,但加密这些密钥用的那个密钥也得跟着一起搬。
VPS 最初用的环境是另一个密钥。密码校验还是能正常工作,但认证服务没法解密出签名密钥,也就发不出访问令牌。把那个用不了的迁移密钥废弃掉,重新生成一个 VPS 本地的签名密钥,问题就解决了。原有的会话全部失效了,签名密钥换掉之后这么处理是对的取舍。
接下来要做什么
剩下的部署工作是接通 GitLab 的镜像仓库和受保护的 CI 变量,然后跑一次经过所有者确认的正式发布和回滚演练。站点现在已经上线了,但部署流程要等新版本发布和回滚都实际测过一遍,才算真正完成。