Wordpress 转 Hexo 历程

前言

在使用 Wordpress 的过程中,我经常会担心一个问题,就是 IDC 服务商突然倒闭,或者因为某些问题被突然强制闭站(虽然微乎其乎),导致网站备份无法拷贝到本地,数据丢失。所以我都会设置日历,定期手动备份到本地。

而且在网站迁移的过程中,需要打包目录,导出导入数据库,还要考虑数据库版本及字符格式是否兼容。各种 Apache 配置, Nginx 配置,也要备份和还原。每个组件的升级,也都要考虑兼容性。

总之,如果是自行搭建的环境,升级和迁移都面临着很多的坑要填。故很多公司看到了商机,推出了集成管理平台,比如 Plesk , cPanel 等。使用集成平台可以很方便地进行一键部署,定期备份,一键还原,快捷配置等功能,还有很多其他的附加功能。总之比自行部署少折腾了很多事情。不过价格嘛……

后来发现有人使用 Github 的 Pages 功能来搭建网站,刚开始感觉是不屑的,因为 Github 是存放代码的地方,即使是 Pages ,也应该是存放跟项目相关的文档,不应该薅羊毛似地用来搭建博客。

但随着对 Git 的使用越来越频繁,感觉如果将博客内容也用 Git 来做版本控制,分布管理,这样就能避免因为服务提供商的问题而导致的数据丢失,即使提交错了什么,也可以方便及时地进行回退修改。也不用担惊受怕地定期进行异地备份。

再后来就入坑了,既然有这么个大带宽,多线路的平台可以免费使用,何乐而不为呢?而且 Gitlab 本身似乎也并不抵触在其平台上搭建博客的行为。故找了个时间,对比 Hexo 和 Jekyll 后,最终选择了 Hexo 作为博客静态化框架工具。(各种优缺点就不说了,网上大把。)

方案

网上的各种 Hexo + Github Pages 的搭建方案也不说了,官方也有详细的搭建文档。主要是分享一下我结合工作上持续集成所搭建的方案:Hexo + Gitlab + Runner + Github Pages

其中 Gitlab + Runner 是著名的开源 CI/CD 方案,就是传说中的持续交付,持续集成。

部署流程

编写好文章或改好配置后,将 Hexo 的博客文件夹提交到 Gitlab , Runner 检测到 Gitlab 上的源码变动后,触发预先设置好的脚本,执行 hexo d -g , 将文章发布到 Gitlab Pages 上。

hexo_gitlab

优势

这种方案相比于普通的 Hexo + Github 的优势在于:

  1. Hexo 和文章源码保存在两个地方: Gitlab.com本地 。相当于异地存储,保证安全性。
  2. Runner 可以接手静态生成及文章发布,可以实现提交后不管的便捷。(即文章写好提交后,就可以去喝咖啡了。)
  3. 如果 Runner 部署在远程服务器上,文章提交后,可以直接关机走人。
  4. 灵活自由,可以预设 Runner 需要执行的命令,一步到位。

不足

当然这种方案的也有不足的地方,那就是配置略为麻烦,而且需要一定的 Gitlab + Runner 持续集成的知识及配置经验。

如果 Runner 部署在远程服务器,还需要付费购买远程主机(也可以将家里不用的 PC 作为远程服务器使用)。

其他

不熟悉 Gitlab + Runner 作为持续集成的话,也可以选择使用 Hexo + Github + Jenkins + Github Pages 的方式进行集成部署。各种集成的流程都是一样的,不一样的是使用的工具。

总结

磨刀不误砍柴工 ,项目持续集成化是一个趋势,博客也用持续集成虽然显得大材小用,但也正是因为如此,才让便捷更加便捷。