【其他】个人博客的搭建

个人博客的搭建

上次把博客跑起来是 19 年的事了。最近又想起来这个事情,所以花了点时间把它重新搭起来。

需求:

  • 和之前一样,仍然是纯静态页面。
  • 想添加一个评论系统(虽然可能并不会有人评论),简单查了以下,有一些对静态博客的评论功能的解决方案。
  • 希望访问速度快一点(github 总是有各种连接问题)

做的时候也牵扯了很多别的事情。因为之前用的是 hexo+gitpages(github) 实现的,但是 github 总是被墙,所以想换一个支持 gitpage 的平台。所以我研究了一些平台:

  • gitee:最可行的方案,也是国内的,访问速度很快。但是 gitpage 服务从今年五月起因为某些原因就一直在改造,也不知道什么时候能行。

  • gitlab:gitlab 也支持 gitpage,但区别在于,github 是直接将生成的 html 页面放到仓库里,而 gitlab 则使用 CI/CD 的方式。我理解的 CI/CD 就是在 gitlab 提供的服务器进行编译和打包。但是由于最近的矿潮,gitlab 的 pipeline 被滥用了,所以 gitlab 官方要求用户提交信用卡号来认证,认证后才能使用 pipeline。然鹅我并不是美国公民,所以这个方案也被 pass 了。

  • netlify:是一个提供自动部署的平台。解决方式是,把我的 gitlab 仓库授权给 netlify,然后 netlify 就会自动追踪我 gitlab 仓库的更新,然后自动部署到 netlify 上。免费用户也可以使用。我试了一下,访问速度也可以接受,也算是为 github 提供了一个备选项吧。由于 bitbucket 允许私人仓库,所以最后选择了 bitbucket 而不是 gitlab。

    在知乎上看到了一个额外的自动部署平台:vercel,等有空的时候或者 netlify 挂掉的时候就研究一下。

为 hexo 博客添加评论系统也有很多选择,我只调研了两种:

  • Disqus:付费,所以被我直接 pass 了(b 站老白嫖怪了)
  • valine:需要注册一个 learn cloud 账号,使用 learn cloud 来保存评论数据。learn cloud 提供开发版本,作为一个自娱自乐的博客来说已经足够了。

最后的解决方案:netlify + bitbucket 仓库 + valine 评论系统。

什么是 CI/CD 和 pipeline?

从在 gitlab 中看到这个名词时,这个问题就开始困扰我。所以简单研究一下。

CI/CD : Continuous Integration/Continuous Deployment,即:持续集成/持续部署

根据RedHat: 什么是 CI/CD 中提到的:

现代应用开发的目标是让多位开发人员同时处理同一应用的不同功能。但问题发生在合并时:

  • 当一位独立工作的开发人员对应用进行更改时,有可能会与其他开发人员同时进行的更改发生冲突
  • 如果每个开发人员都自定义自己的本地集成开发环境(IDE),而不是让团队就一个基于云的 IDE 达成一致,那么就会让问题更加雪上加霜。

所以,CI(持续集成)可以帮助开发人员更加频繁地将代码更改合并到共享分支或“master”中。具体来说,一旦开发人员对应用所做的更改被合并,系统就会通过自动构建应用并运行不同级别的自动化测试,来确保更改没有造成破坏

对于一个成熟的 CI/CD 管道来说,最后的阶段是持续部署。持续部署可以自动将应用发布到生产环境

而 pipeline,则指的是 CI/CD 的整个流程

netlify 中 CI/CD 的使用

我的 netlify 使用的是 bitbucket 的一个私人仓库。这个仓库是从我的 gitlab 仓库里 fork 过来的。目录结构如下:

博客仓库信息

可以看到里面的 .gitlab-ci.yml 文件,就是我之前试图使用 gitlab 的 pipeline 功能时编写的部署脚本,符合 gitlab 的部署要求。其实是从 hexo 官网上抄的。具体内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
image: node:10-alpine # use nodejs v10 LTS
cache:
paths:
- node_modules/

before_script:
- npm install hexo-cli -g
- npm install

pages:
script:
- hexo generate
artifacts:
paths:
- public
only:
- master

但让我比较欣慰的是,在使用 netlify 部署时,netlify 也能够正常识别部署脚本,使得我不用做额外的操作。所以我很好奇 netlify 是怎么部署的,以及它有无自己的部署脚本。

我找到了我的 netlify 的部署信息:

netlify的部署信息

根据我的猜想,就是在目录下执行 npm run build,然后去 public 目录下将内容部署上去。

根据CSDN: npm run build发生了什么?的介绍,执行 npm run build 后,会寻找 package.json 。而我目录下的 package.json 内容是:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
{
"name": "hexo-site",
"version": "0.0.0",
"private": true,
"scripts": {
"build": "hexo generate",
"clean": "hexo clean",
"deploy": "hexo deploy",
"server": "hexo server"
},
"hexo": {
"version": "5.4.0"
},
"dependencies": {
"hexo": "^5.0.0",
"hexo-asset-image": "git+https://github.com/CodeFalling/hexo-asset-image.git",
"hexo-deployer-git": "^3.0.0",
"hexo-generator-archive": "^1.0.0",
"hexo-generator-category": "^1.0.0",
"hexo-generator-index": "^2.0.0",
"hexo-generator-tag": "^1.0.0",
"hexo-renderer-ejs": "^1.0.0",
"hexo-renderer-markdown-it-plus": "^1.0.4",
"hexo-renderer-mathjax": "^0.6.0",
"hexo-renderer-stylus": "^2.0.0",
"hexo-server": "^2.0.0",
"hexo-theme-landscape": "^0.0.3"
}
}

在 script 字段中,build 指令对应 hexo generate 。所以本质上执行的是 hexo generatepackage.json 中也包含 dependencies 字段,那么简单认为它在执行 build 之前会先将依赖安装,这样一切都听起来比较合理了。所以这样看来,一切都和 .gitlab-ci.yml 没有甚么关系。。。。如果想要更多地理解 hexo,就需要学习 vue 的相关内容了。等我有空或者有兴趣了再说。