Appearance
HTTPS 证书续期和自动化部署怎么衔接
这篇文章最容易混淆的地方在于：它其实是两条不同的链路。
- 一条是站点内容发布链路
- 一条是 HTTPS 证书续期链路
很多人把这两件事绑死在一起，结果后面不是发布变复杂，就是证书续期不稳定。
先说结论
- 静态站点发布和 HTTPS 证书续期，最好拆成两条独立流程
- 续期的核心不是“证书文件更新了”，而是“更新后 Nginx 已经重新加载”
- 对你现在这类 Docker Nginx + VitePress 站点，更稳的做法是宿主机管理证书，容器只读挂载使用
- 发布博客文章时，不应该依赖重新申请证书；续期证书时，也不应该顺手改站点内容
一、先把核心对象和链路串起来
放到你当前这套环境里，更推荐这样理解：
text
本地写文章 -> VitePress build -> rsync 到 /mydata/nginx/html/mumu-wiki -> Nginx 提供静态站点
域名解析 -> Certbot/acme.sh 申请证书 -> 证书文件更新 -> reload Nginx这里最重要的一点是：
- 发布链路主要影响站点内容
- 证书链路主要影响 HTTPS 可用性
这两个动作可以同时存在，但不应该相互耦合。
二、工程判断不要只看单点
很多线上问题不是证书本身坏了，而是链路没衔接好。
常见有 3 种情况：
- 证书已经续期成功，但 Nginx 没 reload，线上仍然是旧证书
- 发布内容时顺手重建 Nginx，结果把证书挂载或配置搞错
- 证书放在容器内部，容器一重建，续期和回滚都变麻烦
所以更稳的拆法是：
- 证书文件放宿主机
- Nginx 容器只负责读取证书
- 证书续期后只做轻量 reload
- 站点发布只同步静态文件，不碰证书流程
三、什么时候最容易踩坑
常见踩坑点往往不是“不知道”，而是：
- 证书申请一次成功后，就以为后面不用管了
- 只看
certbot renew是否执行成功，不看线上实际证书是否已切换 - 续期命令和 Nginx reload 没串起来
- 容器重建后，证书路径、配置路径和挂载路径对不上
尤其对 Docker Nginx 场景，最值得提前确认的是：证书到底是在宿主机持久化，还是在容器内部临时存在。
四、放到当前这套站点，更推荐的结构
如果你现在站点目录是这套思路：
text
/mydata/nginx/conf.d
/mydata/nginx/html/mumu-wiki
/mydata/nginx/logs那么 HTTPS 更推荐也按“宿主机持久化”思路来管。
一个常见做法是：
- 宿主机上申请和续期证书
- 把
/etc/letsencrypt只读挂载进 Nginx 容器 - Nginx 配置里直接引用挂载后的证书路径
例如 Compose 里通常会有：
yaml
volumes:
- /etc/letsencrypt:/etc/letsencrypt:ro这类做法的价值是：
- 容器升级和重建不会丢证书
- 续期流程和站点发布流程天然解耦
- 排障时可以直接在宿主机验证证书文件是否已更新
五、一个更稳的续期流程应该长什么样
推荐你把续期流程理解成固定的 4 步：
- 执行续期
- 判断是否真的有证书更新
- reload Nginx
- 验证线上证书是否已经生效
例如：
bash
certbot renew
docker exec nginx-mumu-wiki nginx -s reload如果你不方便直接依赖容器内命令，也可以在宿主机通过 Nginx 所在方式执行 reload。核心不是命令形式，而是“续期之后一定要刷新 Nginx 对证书文件的加载”。
六、自动化时最容易忽略的验证动作
很多人把任务写进 cron 就觉得结束了，其实还差最后一步：验证。
至少建议补两个动作：
- 定期执行
certbot renew --dry-run - 用
curl或openssl看线上实际证书
像你现在这类站点，可以直接从服务器本机验证：
bash
curl -k --resolve wiki.mumuxiaojia.site:443:127.0.0.1 https://wiki.mumuxiaojia.site/这类验证的意义不是看页面内容，而是确认：
- 443 正常响应
- 证书链路没有因为配置变更失效
- Nginx reload 后 HTTPS 入口仍然正常
七、发布链路为什么不要顺手重载证书流程
你现在的博客发布本质上是：
- 本地构建
rsync到/mydata/nginx/html/mumu-wiki
这一步通常只是在替换静态文件。
所以更稳的做法是：
- 发布内容时不去碰证书目录
- 发布内容时不重新申请证书
- 除非改了 Nginx 配置，否则也不必每次都因为文章更新去折腾 HTTPS
这样链路边界更清楚，出问题也更好排。
八、常见误区
1. 把续期和发布写成一个大脚本
脚本看起来省事，但只要其中一个环节失败，排障就会变得更模糊。
2. 只关心证书文件，不关心 Nginx 是否已使用新证书
文件更新不代表线上已经切换成功。
3. 把证书放到容器内临时目录
容器一旦重建，续期和回滚都会更被动。
一句话总结
对个人知识库这类静态站点来说，HTTPS 续期和自动化发布最稳的衔接方式不是“全绑在一起”，而是把内容发布和证书续期拆开，各自自动化、各自验证。