在 博客迁移记 · 从 WordPress 到 Hugo + Cloudflare Workers 中提到,笔者的博客静态页是由 Hugo 生成,并部署与 Cloudflare Workers 这个 Serverless 服务上。
自从使用 Cloudflare Workers 来部署后,笔者编写博客的工作流就变成了:
- 编写博文,放置于项目仓库中(使用 Git 进行版本控制)。
- 提交 Git commit 并 push 到远端 GitHub 仓库存档。
- 在本地使用 Hugo 生成静态网站文件。
- 最后使用
make deploy
(笔者自己写的 Makefile,其实是调用了 Cloudflare Workers 的 wrangler 工具的wrangler publish
)将新生成的静态页面部署到 Cloudflare Workers 上。
每次发布文章都需要做这四个步骤。而第一步的内容编写和第二步的版本控制,是无法进行缩减的。那么能否将后两步再优化一下,使得发布博客流程更加简单且稳定1?
这就让笔者想到了工作中日常使用的 CI/CD 流程,在 GitHub 上注册一个 webhook,监听 GitHub 仓库的变更,随即触发 CI 任务构建与 CD 部署,后两步不就不再需要作者操作了么?
在一次偶然的与 @miaotony 的闲聊中,得知 Cloudflare 原来还出了服务,名为 Cloudflare Pages (仍处于 Beta 阶段,但已经可用)。其与 GitHub Pages 不同的是:GitHub Pages 的仓库内容已经是生成好的网页文件2,而 Cloudflare Pages 中自带了 CI/CD 流程3 。而这个 CI/CD 流程,恰恰是能够替代上述发布流程中的后两步的服务。进而阅读了下 Cloudflare Pages 的文档,由于其属于纯静态页部署,可以直接使用 CDN 分发,因此其在免费套餐中不限制访问带宽,也不限制请求次数。这简直就是博客 Hosting 的完美服务啊,于是笔者的博客切换到 Cloudflare Pages 就这样提上了日程。
对于引流设计,在切换到 Cloudflare Pages 上后,引流设计没有太大的变动:仅仅是后端服务变化,涉及一个 DNS 记录解析变更。整个过程近乎可以平滑切流,用户应该对本次变更完全无感。
由于博客内容仍然使用笔者的 GitHub 仓库,因此不再需要做博客内容迁移,只需要在 Cloudflare Pages 上配置构建、发布规则和自定义域名即可访问。
至此,笔者编写博客的流程已经缩减成了如下两步:
- 编写博文,放置于项目仓库中(使用 Git 进行版本控制)。
- 提交 Git commit 并 push 到远端 GitHub 仓库存档。
Cloudflare Pages 在收到了 GitHub 的 webhook 后,会进行如下步骤:
- 用指定的构建命令
hugo
生成静态网页。 - 将构建产物发布于 Cloudflare 全球网络中。
这样,笔者的博客就完成了上线和更新 🎉
本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。