博客迁移记 · 从 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 记录解析变更。整个过程近乎可以平滑切流,用户应该对本次变更完全无感。

2021-new-blog-traffic-design-public-pages

由于博客内容仍然使用笔者的 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。 ↩︎


知识共享许可协议
本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。