博客迁移记 · 从 Cloudflare Workers 到 Cloudflare Pages

在 博客迁移记 · 从 WordPress 到 Hugo + Cloudflare Workers 中提到，笔者的博客静态页是由 Hugo 生成，并部署与 Cloudflare Workers 这个 Serverless 服务上。

自从使用 Cloudflare Workers 来部署后，笔者编写博客的工作流就变成了：

1. 编写博文，放置于项目仓库中（使用 Git 进行版本控制）。
2. 提交 Git commit 并 push 到远端 GitHub 仓库存档。
3. 在本地使用 Hugo 生成静态网站文件。
4. 最后使用 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 上配置构建、发布规则和自定义域名即可访问。

至此，笔者编写博客的流程已经缩减成了如下两步：

1. 编写博文，放置于项目仓库中（使用 Git 进行版本控制）。
2. 提交 Git commit 并 push 到远端 GitHub 仓库存档。

Cloudflare Pages 在收到了 GitHub 的 webhook 后，会进行如下步骤：

1. 用指定的构建命令 hugo 生成静态网页。
2. 将构建产物发布于 Cloudflare 全球网络中。

这样，笔者的博客就完成了上线和更新 🎉

1. 由于众所周知的网络原因，提交 Cloudflare Workers 的过程会有一定概率失败，给博客发布这件事增加了一点难度。 ↩︎

2. 当然也可以使用 GitHub Actions 来完成构建，再提交的步骤，但 GitHub Pages 本质还是没有内置的 CI/CD 工具的。 ↩︎

3.  根据不同套餐有构建配额限制，如免费套餐的每月发布构建的次数为 500。 ↩︎