GitHub Action + OSS | Hexo的最终归宿

本文最后更新于:6 个月前

又是看官方文档,又是看 GitHub Action教程,在 n 多次 Build failed 之后,终于不用自己操心了,但是这个过程中,只顾着自己低头闷搞,部署完才发现原来网上挺多类似的教程的。本来想写写这个 CD 的教程,也索性就罢。

stability stable

那就写写,当我使用 Hexo ,我经历了什么?

入坑 Hexo 有一段时间了,框架是个挺好的框架,但是一系列的下来,有几个地方的确花费。下面进入正题。

一、_config.yml

在修改 _config.yml 之前,先要学会 Hexo 的基本使用命令,阅读官方文档 最为高效。

此外,还需要清楚以下几件事:

  • hexo init 生成的各个文件夹都代表这什么。

  • _config.yml 中的选项都有什么作用。

  • _config.yml 使用 Yaml 语法写的,要清楚其格式。

同样 阅读官方文档 最为高效。清楚了这些后,就可以肆无忌惮折腾本地博客了。

二、上云

21世纪是一场 ABC(AI + Big Data + Cloud)的革命,不能老在本地玩耍,咱也要上云啊。(当然了,整个静态博客和 ABC 没有半毛钱关系,手动滑稽)

1.GitHub Page

首先选择了 github 的 page 服务,在此之前需要注意:

  • 添加 CNAME 文件才能自定义域名。

  • 考虑好图片存储的问题,建议使用对象存储做图床。

  • HTTPS 访问 需要全站都是 HTTPS 链接,混入 HTTP 会产生 跨域 问题。

⚠️缺点

  • 国内访问速度太慢。
  • Github 屏蔽了来自 BaiduSpider 的请求

2.Gitee Page

部署在码云上,主要是看中它的速度,速度是不错的。

⚠️缺点

  • 不能自定义域名(pro版支持)
  • 不能自动部署(pro版支持)
  • pro版需要 ¥99 保护费

3.Coding Page

Coding 现在是腾讯旗下的代码托管平台,也提供 Page 服务。优点多多,堪称完美,我一度是使用了很久,但是缺点也很致命。

🎉优点

  • 速度不错

  • 支持搜索引擎收录

  • 自定义域名,还附赠 SSL证书

  • 静态文件更新时自动部署

  • 操作界面好看呐

⚠️缺点

  • 服务很不稳定,会出现长时间无法访问的情况,而且并不是因为他们的服务器不行。Coding Page 的服务器实际上在新加坡,如果大量国内用户访问国外的同一个IP,自然会被墙。(当然 Coding 团队并不这样认为,他们每次都将一切问题推给上游的服务提供商。)
  • 所以他们不换服务器 或者 找到 ‘靠谱’ 的上游服务商,这个问题根本没有改进的可能。三十六计,走为上策

4.GitLab

缺点同 GitHub。

5.Netlify

Netlify是一家国外的静态网站的托管平台。可以通过 Travis CI + GitHub 实现全自动持续部署,非常好用,提供 HTTPS 以及 SSL证书,自定义域名,几乎没有缺点。

⚠️缺点

  • 国内访问速度不佳。虽然可以套一层CDN,但是在不保证 100% 命中率的情况下,回源速度不佳也会影响体验,。

6.七牛云

由于我的图床是放在七牛云上的,所以就想着把静态文件也放在它的对象存储中,而且七牛云收费明确,只收取 HTTPS 费用,(腾讯的COS,阿里的OSS 的定价真是让人头秃,种类繁杂)。同类的还可以使用又拍云,相当于白嫖了,15GB的 HTTPS CDN流量。

⚠️缺点

  • 呈现给用户的文件管理,也是存储时所用的扁平化方式,没有目录树结构,看文件层级十分困难。
  • 不支持子目录访问,也就意味着任何页面末尾都要加上 index.html

PS:如果你也想使用七牛云来做图床,可以考虑使用我的邀请链接注册:portal.qiniu.com,我可能会因此得到一些优惠卷。

7.阿里云

最后使用了阿里的 OSS + CDN,上述缺点都能解决。

⚠️缺点

  • 提交工单超级慢,而且有时还关闭了入口。今天我的 CDN 访问资源出了点问题,提交工单真是难于上青天。

三、优化工作流

1.原始的写 blog 步骤

(1)写 bolg。

(2)清除本地静态文件。

(3)在本地重新生成静态文件。

(4)利用 Hexo 插件或者 ossutil,将静态资源上传到 OSS 。

总之很麻烦,还要在本地保留一大堆插件以及 node_modules 的各种依赖包,换一台电脑写 blog,还有重新下载这些插件和依赖包,(虽然我并没有第二台电脑,hhhhh)。

2.能不能将本地从工作流中去掉呢?

还真的可以,那就是 GitHub Action。它可以将上面的步骤优化为:写blog + 源文件 push 到仓库 。GitHub Action 主要提供两个功能:自动构建、持续部署。

(1)自动构建

将源文件上传到仓库中,GitHub Action 可以帮你在它的虚拟机里,完成环境部署插件安装生成静态文件上传至 OSS

这就意味着,本地不需要保留任何插件、依赖包、静态文件。只需要保留一个不到 1M 的 git 仓库,来储存源文件。当然源文件其实也可以不保留,需要的时候直接从仓库 pull 一下

(2)持续部署

不用手动去激活 Action,可以设计成,当仓库出现 push 后,自动执行 Action,也就达到了持续部署的目的。

四、写在最后

1.说一说 GitHub Action

GitHub Action 是19年11月份正式发布的。开源项目是免费的,私有仓库的话,有2000分钟/月的额度,对于构建博客也绝对够用了。GitHub Actions 的配置文件是一个 yaml 文件,使用的时候注意格式。(比如不能使用 tab 键)

当我第一次使用的时候,我的第一感觉: 这不就是 iPhone 的捷径嘛!,不了解 捷径 的同学可以康康 「捷径」怎么用。捷径 在被 Apple 收购之前,叫做 Workflow 。在 GitHub Action 里,持续集成一次运行的过程,也叫做一个 workflow。

由于需求不一样,二者也有不同。捷径 使用的是本地的 IOS 系统。GitHub Action 可就厉害了,不仅把系统上云了,还支持 Window、Liunx、macOS。

最后学好英语挺重要的,看文档不用脑壳疼(大哭.jpg。

2.说一说这篇文章

这篇文章算是记录一下折腾的过程。要知道你遇到的大部分问题,世界上早就有人遇到过了。

对于Hxeo,如果你想要入坑或者正在路上,希望这篇文章能给你提供一个引子,之所以不写具体的教程,是因为网上的教程数不胜数,善用搜索引擎,远离CSDN就好了。


本博客所有文章均个人原创,除特别声明外均采用 CC BY-SA 4.0协议,转载请注明出处!

 目录

致敬李文亮及各路英雄好汉!