记录建此博客的过程。包括前后端技术及决策的点。
完全从0开始。
方案比较和选择
需求:简单的,最好不花钱的。数据库等目前不需要。
自我扫盲:博客构成
写文章,现在通常用markdown,xxx.md。
→ 需要有东西将.md文件编译成html/css静态文件,可以被浏览器识别的文件。
这一步就是为什么要找博客搭建平台,hugo、wordpress等平台基础功能,以及静态平台主要功能就是这个。
→ 生成的html/css静态文件需要有网站间运行。hugo hexo这类静态平台不包,要自己解决,可以自己搭后台也可以托管给专门的服务器。有的大型的平台包这部分,包括提供数据库等。
自创抽象博客架构:
【 [前端] +(后端)+ [网站空间] +(其他:域名,(图床,加速器等))】
【】便是一个博客。[]内为必要内容,()内为可要可不要内容,越()越不重要。我大概理解。
-
前端|Frontend
必要。废话前端展示内容。
需要将文章文本(现在一般是markdown),转换成前端页面。 -
网站空间|Hosting
必要。布在网上运行,别人才能访问。
常见的网站空间购买形式有:共享主机,VPS,云托管和专用主机。 -
后端 | Backend
大型站需要。需要数据库存数据之类。可在后台界面进行操作。 -
域名 | Domain Name
流量大需要。可通过域名访问而不是ip地址。一般得买,其实是租,域名不能买断。 -
其他
- 图床,存图的。可能还需要压缩图的。以及提高访问速度的
- 评论区,适合中国宝宝体质的麻烦部分。
部署方式
根据不同前后端选择方式来选择网站空间。
从方便到麻烦,按自己理解,粗粗排序,不精确!:
全自动大型内容管理系统 > 动态模式带后台 > 静态模式带框架 > 纯纯自己手搓
-
大型网站一键部署,比如用Ghost。太重了。
-
自己一键搭,比如wordpress、halo等框架,还带数据库。目前不需要。
-
动态网站,意思是带后台管理,依赖服务器和数据库,动态生成html页面。也不需要。
-
静态模式,本地编辑静态文件,静态生成html。轻。但每增删改一个页面,都得重新上传服务器。 有的功能比如评论,得自己搭。
- 关于页面,自动搭博客框架很多,比如Jekyll,hexo,hugo等静态网站生成器带的框架。也可以自己用vue,react等写。
- 后端,也有框架,可以自己写。一般动态网站要买域名和hosting。
静态页面资源少,可以免费部署。一般这几种托管/发布方式:自己的 vps 主机 / GitHub Pages / Vercel等(Serverless 平台)。然后通过github仓库关联。
-
还有不用懂代码的,gridea,用过,感觉不太好用,主题也限制比较多。
最后选择
→ 功能上不需要太重
✔︎ 使用静态。淘汰wordpress、halo等动态平台
→ 静态里尽量快。高人气平台速度:Hugo (golang) > Hexo (Node.js) > Jekyll (Ruby)
✔︎ 使用Hugo。
→ 托管: 选国外的,国内收录、访问速度等不优先考虑,先搭起来再说。
✔︎ 使用Github Page托管。
静态 Hugo + Github Page
优点:轻,快,方便部署,便宜。而且是使用比较喜欢的golang语言。
缺点:速度慢。百度不收录检索。无法做CDN加速。发文章麻烦。慢慢用着调整,不行后续再换。
github page 限制:
- 单个文件大于50MB将受到警告。
- 单个文件大于100MB无法上传。
- 仓库大小「强烈建议」少于5GB。
- 每小时可构建10次。
- 每月流量100GB。
本地搭建
需求:
简约。一定要有文章大纲显示(TOC )。不要纯横版,两边特别浪费 看着还不紧凑。
hugo必须一开始就选择主题,于是挑了一圈。最后选定了eureka
补充:
您猜怎么着,最后没用hugo发布的主题,纯自己写了原生html+css。
所以需要单独剥离出一篇Hugo内容,和一篇html+css的基础前端笔记。
搭建步骤
下载,基本不用复杂安装 —> 选主题。主题配置好 —> 文章发布流程 —> 启动服务
-
下载
brew install hugo
下载前还要在终端翻墙,参见安装存档
验证:hugo version更新版本: brew update brew upgrade hugo hugo version -
初始化blog
hugo new site <yourblogname>
cd 进去,观察它结构,顺便下载brew install tree, 直接用tree命令看 -
安装。必须安装某个主题就在这里了。一般选的主题都会有说明如何安装,这里抽象一个通用代码。
git init git submodule add <GITHUB URL> themes/<THEME NAME> # 这里的GITHUB URL是该主题提供给你的,它仓库地址。 THEME NAME是你自己自由起的名字,一般就命名为该主题名字。搜了一圈下载有两种命令,git clone,git submodules,又搜了一圈区别。
概括就是sub方式比较严谨安全,此命令隔绝原版来拉代码,保证自己拉的分支和原作master不起冲突。那用这个命令。
因为后面在.gitignore里添加了theme文件夹,导致后面拉theme要使用:
git submodule add -f <GITHUB URL> themes/<THEME NAME> -
根据各个主题要求操作,比如可能主题代码content中没内容,要去theme文件夹中复制,等等。然后就可以自己配置了。
however,最后我自己写了主题。 -
本地调试运行网页
流程:# 新生成一篇文章 hugo new posts/hello-world.md # 编译 hugo # 启动服务 hugo server💡 要注意的是:
- new步骤:
new后面的路径是从content为根的。所以此文章生成路径hugo根目录/content/posts/hello-world.md,需要hugo下有content文件夹,content就是放博文的。
之所以又加一层posts文件夹,是因为hugo的结构,content下放的是所有内容。content下一级文件夹,相当于navigation的分类,可以自定义各种分类,所有文章都放在posts。但是如果有人有自定义其它的栏目,比如about、friend,或者将技术和非技术文章分开放,或者添加momes,书影音等项目,可以在content下建立相应的文件夹。
hugo的文章都需要有一些文章头部设定的声明,但不用担心,使用此命令生成的.md自动带,当然自己外面写好,添加头部复制进来也可以。这种简单的事情,搜了一圈没弄清。 - server步骤:
要在根目录运行。默认地址 http://localhost:1313/
还有一些别的可用命令,比如 后缀-D,草稿可见。
我喜欢用hugo server --disableFastRender,可以一改动就即时看到渲染。
- new步骤:
发布文章 部署服务
hugo有两种发布方式。
-
使用github 唯一的个人主页仓库发布。必须创建一个 .github.io 仓库来托管生成的静态页面。
发布后域名为https://<USERNAME>.github.io,config里的baseUrl也要设成https://<USERNAME>.github.io -
创建普通的项目仓库,通过项目主页发布。发布后域名为
https://<USERNAME>.github.io/<PROJECT_NAME>。config里的baseUrl也要改成这个。
一般建议通过个人主页发布,因为第二种方法常出bug。
首次发布要额外设置的
-
创建个人主页仓库。仓库名必须为github名字。分支要和本地一样,现在好像默认都是main。
-
因为此仓库只存静态页面,即写完blog,运行
hugo之后编译成的,存在public文件夹里的文件。所以需要单独将public/ 专门设git init以便提交。但是我记得git仓库不能嵌套.git,而这时 public/ 的父级已经是git包里。于是又踟蹰了,并且思考了一些,那我前端代码的layout等部分要单独建仓库存吗?我博文.md的内容要单独建仓库存吗?之类的问题。
最终设置是,在 myblogsite的大文件夹,添加.gitignore,把 content/ 和 public/ 屏蔽掉。因为我自己写主题,但是下了一堆别人的主题在 themes/ 里学习,所以也把这个文件夹屏蔽掉。然后:
cd public
git init # 创建子层本地仓库
git remote add origin <SSH path>
接下来的步骤就是最基本的,每次发文章都需执行的步骤。
结果有一次删掉了public。幸好这里做了笔记。
除了要重新执行上面三行代码之外,还需要在push的那一步改成执行强制推送:git push origin main -f
所以不要删除public!!!
发布文章步骤
#(写文章)
# 编译
hugo
# 进public
cd public
# 发布
git add .
git commit -m '备注'
git push origin main
多试几次就会觉得麻烦,有自动脚本可以执行这个。
再嫌麻烦之后可以试 github actions自动部署。
一股脑丢这些相似的名词容易晕,github page是托管编译的静态页面,并发布的。github actions是帮忙自动部署和管理的,相当于高阶自动脚本帮跑上面那个编译发布步骤。
自动化脚本
官方提供的。复制之,保存在 deploy.sh文件中。
官方自动化脚本
#!/bin/sh
# 任一步骤执行失败都会终止整个部署过程
set -e
printf "\033[0;32mDeploying updates to GitHub...\033[0m\n"
# 构建静态内容
hugo # if using a theme, replace with `hugo -t <YOURTHEME>`
# 切换到 Public 文件夹
cd public
# 添加更改到 git
git add .
# 提交更改
msg="rebuilding site $(date)"
if [ -n "$*" ]; then
msg="$*"
fi
git commit -m "$msg"
# 推送到远程仓库
git push origin main
文件在你blog的根目录下保存完,执行chmod +x deploy.sh添加可执行权限。然后执行
bash deploy.sh
用github action
// todo
后续可选搭建的
域名
// todo
todo
使用 GitHub Pages 生成网站会自动分配一个 xxx.github.io 的默认域名,通过这个域名就可以直接对生成的博客网站进行访问,也可以通过域名解析配置自己的域名,如我的网站就是解析了 pseudoyu.com 这个域名。
我的域名是在 NameSilo 购买的,并通过 Cloudflare 平台进行 CDN 加速,提升访问体验,并实现了域名重定向等功能,关于博客访问优化这一点后续会单独讲解。
我后来为了方便管理,把 NameSilo 域名迁移到了 Cloudflare,大家可以直接在 Cloudflare 上购买,教程包含在《Hugo + GitHub Action,搭建你的博客自动发布系统》中。
评论系统
// todo
todo
图片管理
// todo
待整理
todo
发布流程
通常 GitHub Pages 发布博客需要本地 hugo 命令生成静态站点文件目录,cd 到 public 目录,并使用 git add、git commit、git push 等命令提交到 GitHub Pages 仓库,实现博客的发布,因为每次更新都需要进行重复操作,且博客源 Markdown 文件无法进行很好的备份和版本管理。
因此,我建立了一个博客源文件仓库,通过 GitHub Action 实现了一套自动化发布流程,仅需将 Hugo 博客源文件上传至 GitHub 仓库,会自动触发 CI 生成静态站点文件并推送到 GitHub Pages 仓库。
Hugo 搭建与 GitHub Action 配置教程已更新:《Hugo + GitHub Action,搭建你的博客自动发布系统》
为什么托管到Github?
因为大部分的博客渲染工具(hexo,hugo,gridea)都是依赖于github,国内的coding page无论是从稳定性还是操作便捷程度都不及github,推送代码还有广告,而这完全取决与你的氪金程度.所以还是推荐使用github托管.可能你会说coding page在国内访问快,但是单单这一个优势无法称作是最佳实践,而且下文的netlify会解决这一系列的问题,先按下不表.
最重要的是我们把github仅仅作为博客的托管仓库,不使用它的github page部署
为什么使用Netlify?
先说一下它的功能:
- 可以托管静态资源
- 可以将静态网站部署到CDN上,加速国内访问
- Continuous Deployment 持续部署,当你提交改变到git 仓库,它就会自动运行build command,进行自动部署
- 可以添加自定义域名
- 可以启用免费的TLS证书,启用HTTPS
- 最强大的cms,用来管理静态资源
- 自带 CI、支持自定义页面重定向、自定义插入代码、打包和压缩 JS 和 CSS、压缩图片、处理图片
github page:
- github虽然没有被墙,但是那个访问速度非常的慢,对国内访问的用户来说体验极差
- 百度无法抓取,众所周知国内用百度的还是多,如果你写的文章,无法被百度抓取收录,那还是有点坑的
- 无法做CDN加速.未备案域名服务器,无法使用国内的cnd加速服务
Netlify 与 Travis CI 的区别:
- 我们可以看到使用Netlify可以轻松的帮你自动持续部署博客,也就是说,他会自动检测到你的博客源码的更改,自动执行hexo d+ hexo g.
- Netlify 与 Travis CI 等等都是持续集成工具, 但是它更加关注前端, 或者说网站或者 web app 的持续集成与持续部署, 这也是它与其他持续集成工具最大的区别. 目前对于 Netlify 的使用也非常简单, 但是这是其他持续集成工具没有的.
所以说使用了Netlify,就等于替代了GithubPage+ Travis CI.并且比较完美的弥补了两者的不足.
ps:我在查询相关的资料的时候发现有的博客的做法是把源码和渲染后的网页放在两个分支(这也是 hexo 提倡的做法),但是却只是让 netlify 托管渲染后的分支,这样的话 netlify 无法做到自动部署,此时的 netlify 仅仅是充当了githubpage的角色
为什么使用Netlify CMS?
什么是CMS?
内容管理系统(英语:content management system,缩写为CMS)是指在一个合作模式下,用于管理工作流程的一套制度。该系统可应用于手工操作中,也可以应用到电脑或网路里。作为一种中央储存器(central repository),内容管理系统可将相关内容集中储存并具有群组管理、版本控制等功能。版本控制是内容管理系统的一个主要优势。
Netlify CMS的优势
- 我们可以通过Netlify CMS来在线编辑我们的文章,而不用在本地比较繁琐的操作
- 虽然它是作为一款团队的编辑工具,但作为轻量的博客编辑,我们可以暂时把他定位为个人的在线编辑工具,这样的话你可以随时随地修改,编辑你的博客,而不用考虑多设备如何同步的问题.
- Netlify CMS提供Hexo的插件,可以简单的开启你的Netlify CMS服务
参考:https://immmmm.com/