Hexo博客部署之前世今生

起因

一个月前开始重新学Java相关的东西，包括Spring，Netty等WEB和SERVER相关的东西，于是想在本地部署一个博客用于记录学习过程，想要的东西很简单，公网可以访问NAS,路由,博客.之前已经买好了三年的域名，三个服务仅仅三级域名不同，访问方式都是https://*.kaers.top.折腾之旅就此展开。

开搞

手上已经有的东西

黑裙NAS
K2路由器
千兆交换机
公网IP(会变，但是不频繁)，有443端口可用
域名(三年)

方案一：NAS跑博客，K2跑Nginx映射到公网

初始的计划是在NAS上面部署，然后直接用K2映射到公网，此时路由器的系统是H大的老毛子，上面有lnmp但是路由是最低配的K2,闪存太小根本没法正常初始化环境.试过内存中安装、SMB扩容之类的东西，但是结果都不理想。虽然可以直接手动安装nginx,不用lnmp环境，但是路由关机重启后这些东西都会掉还要写脚本在每次开机后自动去安装配置，很麻烦。尝试了两天后无果，放弃。后面的方案还会尝试刷LEDE用nginx,这是后话。

方案二：NAS虚拟机中跑软路由，USB扩展一个口作为WAN，K2作为纯AP

在方案1失败后想在NAS上面装软路由(主要是没试过软路由，听说性能非常强，想试试)，但是NAS是单网口，做单臂的话需要重新买千兆VLAN交换机，手里已经有一个网件的傻瓜交换机了，不想买新的，另一个原因是单臂必然会占用一部分带宽，虽然说只是50M的联通光纤，跑满了也就占用10M不到，但是强迫症心里不爽啊，SO只能买USB千兆网卡扩展出来一个网口，至于为啥不买一个PCI的网卡是因为华擎的N3150主板只有一个PCI接口，并且上面已经插了PCI转SATA卡.经过各种取舍，计划变成NAS虚拟机中跑软路由，USB扩展一个网口作为WAN，K2作为纯AP.

单臂路由器可以虚拟LAN达到单网口当做多口用，但是需要支持VALN的交换机或者路由器支持，同时交换机/路由器网口速度(VLAN设备)需要和软路由上的网口速度一致或更大，否则最大带宽就是VLAN设备的速度[木桶原理]。由于所有流量都是从这一个口走的，所以说如果虚拟出来两个口LAN+WAN，那么两口的可用带宽总和还是网口物理速度，这个很好理解，WAN口下载的同时从软路由复制东西就只能占用网口物理带宽-WAN口占用的带宽

接下来就开始找群晖支持的网卡芯片，自带的驱动支持的网卡芯片不多，可以从这里查看，有一定的参考价值，刚开始买的是一个AX88179芯片的usb转千兆的网卡，在群晖的/lib/modules/update下能找到芯片，且测试可用，但是速度一般，稳定在70M左右，发热略大，在win下面速度大概有90-100M，没有螃蟹卡速度快，测试后感觉不是太理想，于是退掉了，重新买了RTL8153芯片的转接卡，噩梦就此开始了，在这里花费了大量的时间，也导致中断了Java相关的学习大概半个月多，在这段时间里每天想的就是怎么能给他驱动起来。

螃蟹芯片的转接线到了后先是在win下面测试速度，稳定性还是蛮不错的，能达到110左右，基本和主板自带的网卡性能一致，非常满意，接下来插到群晖上面测试，认出来是usb设备，但是不认网卡。因为在买之前虽然是没在官网的列表中看到相关的网卡芯片的，但是在群晖系统的modules下看到了大量的r**.ko,rtl8**.ko,8**.ko驱动，于是想当然的认为rtl的芯片应该都是支持的蛮好的，结果被啪啪打脸，哈哈哈.MLGB

驱动既然不认，那我就手动编译驱动吧，毕竟这卡的速度还是蛮快的，win测试也非常稳定。从rtl官网找到8153芯片的linux驱动后在虚拟机里面直接编译，生成.ko驱动文件，一开始编译也是失败的，后来一一解决了，不过这解决了也没什么用，因为不是交叉编译，群晖是肯定不认的，这是后来才知道的。上网找各种资料后知道需要交叉编译，然后就在本地虚拟机中搭建交叉编译环境，交叉编译环境需要如下两个东西

Synology Open Source Project

XPEnology linux 3.x kernel source code

驱动交叉编译教程

第一个是交叉编译工具链，第二个是内核源码，第三个是编译教程，如果只是编译驱动的话，按照教程走到part2就够了。交叉编译工具链是DSM4.1的，我的系统的DSM6,我不知道失败的原因是不是与这个有关。也是因为编译驱动才知道这个东西，以前只是知道有交叉编译这个东西。

在交叉编译中，从RTL下载的驱动源码有些东西会报错，修改了一部分，交叉编译后的ko驱动复制到群晖，手动注入驱动依然是报错，经过大半夜+一天的尝试终于在周日的晚上注入驱动成功了，但是还是不认网卡。。。记得当时成功注入驱动成功的时候还和朋友说如果能用就买包辣条庆祝一下的(笑)

既然水平有限，自己编译驱动搞不定这网卡，于是就开始上网找有没有别人编译好的驱动，我直接拿来用，看看能不能驱起来于是找到了这个,下载后里面有extra.lzma，在linux下解压出来有r8152.ko的驱动程序(8152/8153是共用驱动的)，拿去注入没有报错，重启nas后依然凉凉。到这里我就打算放弃自己搞驱动来驱了，虽然当时找到的还有其他方法没有尝试，比如改引导之类的，但是当时意识到在这个上面花的时间太多了，于是就停下来了，退网卡，不搞了。但是博客还是没有搭起来啊，搭博客还是要搞的。然后就是下面的方案三。

方案三：路由器换LEDE系统在上面跑Nginx

之所以一开始没有直接换路由系统，一部分原因是因为老毛子提供的开箱即用和丰富的第三方脚本扩展用起来很方便，另一个是对第二种方案有点好奇，想试试。既然前两种方案都pass掉了，那就试试换个系统把，k2能刷的好用的系统也就那么几个，老毛子，lede,openwrt(已经合并到lede了)...
那么就试试LEDE把，系统版本有点老，是17年的系统，18年就没再更新了，不过想想也是，k2这匮乏到可怜的硬件也实在没法玩出来多大的花，下载、安装一气呵成，进入路由管理界面，看起来还是蛮小清新的，网络配置一下能上网后第一件事就是去找软件扩展，路由的软件中心使用的是opkg，这也是大多数路由系统用的软件包管理器了，比较轻量。找到nginx下载安装简单配置后就休息了，第二天晚上回来后一配置发现特么好像不支持ssl,这让我怎么玩，运营商80端口已经封了，就算不封也不打算用80，然后开始研究怎么把ssl支持打包进nginx,然后手动安装。lede系统比较小，8M闪存在剩下3M不到的样子，一个支持ssl的nginx大概在不到2M，空间还是够用的，找了好几个支持ssl的nginx安装包都无法正常安装进系统。两个原因让我立即放弃了这个方案，1.时间和精力。2.ssl支持需要在每次连接握手时耗费cpu资源在验证密钥，以及加解密相关的计算上，这对于7620的cpu来说还是有压力的(LEDE无法支持硬件转发，全靠CPU来做，最然K2本身硬件支持是有的[网上查到的不知道是否准确]). 虽然方案是放弃了，但是路由系统保留下来了，一些在老毛子上面用的脚本，比如动态域名更新，servChan微信通知等，都在LEDE上面弄好了，这块按下不表。

动态域名更新教程

动态域名更新脚本

方案四：NAS上装Gitlab、装虚拟机跑Nginx,博客,Jenkins

前面做了这么多事情好像都是在做和博客搭建无关的前期准备，到这个方案终于开始博客搭建相关的东西了。其实在最开始的时候在公司的虚拟机上面已经验证过Hexo博客的搭建，可以顺利跑起来，所以到真实环境下准备开搞的时候就跑去研究更完善的方法了。本方案将持续集成也加入进来，是由于博客更新的时候如果没有CI的话，每次发布新的内容都要手动重新生成，部署，很麻烦。Jenkins在公司想推的时候也有过相关的研究，算是有点熟悉，这个方案中真正麻烦的地方在于gitlab.本方案中Hexo博客+Jenkins+Nginx(作为所有服务的反向代理)运行在群晖虚拟机中，Gitlab是直接在群晖的套件中心下载安装的，到gitlab可以正常使用都是很顺利的，后面由于想要把Gitlab映射到公网访问的时候出现了麻烦，并且最后也没找到解决办法。

Gitlab出现的问题是Nginx代理时的302跳转(这个跳转会把https跳成http,但是运营商是封80端口的，不然可以在强制跳回去)，由于群晖套件中的Gitlab已经有内置有前置Nginx，如果想在前面再加一层Nginx需要关闭内置的Nginx,这样就可以很好的解决302问题。或者是把虚拟机中的Nginx增加Lua支持，然后在Nginx中处理掉302跳转，这样对于浏览器访问时就时完全透明的了。群晖套件中的Gitlab没有找到安装位置，也没法去关闭内置Nginx,从网上也没找到方法，可能它就是由群晖的Nginx默认托管的。总之关内置Nginx是关不掉了，那就只能在虚拟机中的Nginx做文章了。

用proxy-intercept-errors和recursive-error-pages代理多次302

为nginx添加ngx_lua模块并进行安装测试

如果想在虚拟机中的Nginx中处理掉302以使302对浏览器透明需要安装Lua支持，然后重新编译Lua模块到Nginx中

按照上面的两个教程又参照了其他搜索结果，给Nginx增加了Lua支持后Gitlab依然无法正常在公网访问.并且Jenkins增加Nginx代理后也会出现问题，登陆时会提示Request header is too large，这个在网上又解决方案，但是Gitlab没法正常公网访问，我也就没去验证解决方法是否能用，不过这个应该问题不大，用Nginx反代Jenkins的认挺多，默认Nginx配置都会有问题。解决方法点这里。

导致此方案流产的另一根稻草就是Jenkins和Gitlab占用内存是真的大。Jenkins轻松上1G,Gitlab也是毫不示弱，两个加起来用掉了大概2G内存，并且对N3150CPU压力很大，这俩家伙跑起来cpu轻松上60.所以由于Gitlab无法正常反代+资源占用过大，这个方案又一次被抛弃。

截至放弃此方案时，在内网的测试，已经可以实现push博客到GitLab->GitLab webhooks ->Jenkins ->拉取最新的博客+调用Hexo重新生成部署博客->浏览器刷新博客查看新内容。即我们只需要干两件事，push博客、刷新浏览器，这也是搭建博客都会使用的方案，不管是全部自己搭建还是下面的方案四使用的Github Pages.

方案五：Github Pages+Travis-ci实现blog分支推送自动部署

现在来到广大码农用户使用率最高的Github Pages方案了，一开始没选这个方案的原因时在开始折腾本文说的东西之前已经尝试过，感觉速度不是很理想，并且绝大多数时候都需要翻墙才能正常访问。上面各种方法都试过了，现在没办法只好在来试试这个方法了，这方面的教程很多，照着来很快就搞定了。下面既然还有方案六很显然这个方案也是被Pass掉的，问题就出在Travis-ci上，如果想让Github的Push事件触发Travis-ci的编译部署就需要在Github Integrations & services中添加Travis CI服务，但是这个持续集成服务即将在2018年10月1日被Github正式弃用了，算算时间还有四个月，后面不能用了还是要折腾。

虽然Github同时也提供Webhooks服务，但是没法和 Travis-ci公共服务联合起来,并且在网上也没找到相关的资料，大家也都不提webhook或者即将弃用的持续集成，好像Travis-ci直接用github账户登陆两者就能自动关联起来，Travis就可以监听到push事件一样。经过我的试验，还是需要在即将弃用的持续集成中配置好Travis-ci才能正常处理编译，部署。这个方案虽然可以实现两部操作：push博客、刷新浏览器，但是想想这是一个即将被放弃的方案，还是算了吧。

自行搭建的持续集成服务可以和Github配合起来用，只要可以公网访问到,但是想想Jenkins的资源占用。。。

基于Git的VCS软件都是支持webhook的[如GitHub,GitLab,类Github的国内平台]，这对于CI/CD非常有用，各种开源组织的每夜更新包，以及一些托管在Github上的代码的版本发布都是离不开这个

PS:其实也研究过Nginx cgi调用shell处理hooks,要写好长的处理脚本.头疼

方案六[最终定型]：NAS虚拟机中跑Hexo+Nginx

来到最后的方案，也是我现在使用的方案，现在用起来是这样的，平时写博客是保存在OneDrive中，公司和家里电脑都装有，可以自动同步，在哪儿都能写，写完后复制到群晖的blog目录下，此目录是共享的，在虚拟机中会开机自动挂载到/mnt/blog_source中，然后ssh进入虚拟机，cp到/home/blog-source下，虚拟机中的incron会监控这个目录，文件变更后会执行脚本生成，部署到nginx,然后刷新页面就可以看到了，同时脚本会将博客文件提交到github存档。所以要干的也就三件事儿：

1.从OneDrive复制到群晖Blog

2.ssh进虚拟机复制到/home/blog-source

3.刷新页面

如何使用 Incron 监控重要的文件和文件夹

下面是Incron执行的脚本文件内容，在博客更新时也会调用ServChan发送一个微信通知

#!/bin/bash

curl -s "http://sc.ftqq.com/这里是ServChan的Key.send?text=HexoBlog" -d "&desp=监控到博客source变更，开始更新" &

cd /home/kaers/blog/source/_posts
rm -rf *
cp -r /home/kaers/blog-source/. /home/kaers/blog/source/_posts 
cd /home/kaers/blog/source/_posts
rm -rf README.md

cd /home/kaers/blog
hexo clean
hexo g

systemctl restart nginx.service

cd /home/kaers/blog-source
git config user.name "xkaers"
git config user.email "github注册邮箱@qq.com"
git add --all
git commit -m "blog update at `date +"%Y-%m-%d %H:%M"`"
git push --force --quiet "https://[email protected]/xkaers/blog.git" master:master

curl -s "http://sc.ftqq.com/这里是ServChan的Key.send?text=HexoBlog" -d "&desp=博客更新完成" &

脚本很简单，就是繁杂的手动操作自动执行，没什么难度。

小结

到这里博客搭建算是告一段落了，经过一个月的折腾，我得到的仅仅是一个操作起来并不是很方便的博客，但是也已经满足我了，并且也不想继续投入时间精力搞这个东西了。前面的几个方案花费了大量的时间，简单来说就是好奇心害死猫，可是如果不是心存这份好奇，又怎么在技术这一行走下去呢，在允许的情况下还是需要花费尽可能多的时间折腾一个不熟悉的东西，接触到的很多东西可能暂时用不上，但是能很大的扩充知识面，这些东西就算是以后也不会用的上，至少经历过了，有收获有成就感，也是蛮开心的一件事儿，这或许也就技术的魅力吧

好了，下面是针对整个文章搞的事情的正式总结：

百兆以下宽带K2级别的路由器足够，不需要用软路由，费电

群晖对各种外设的驱动很匮乏，买之前查好资料，不然白白浪费时间精力

CI/CD对效率提升很重要，有时间还是熟悉一下，学起来很快。除了Jenkins，TeamCity也蛮好用，界面精细

Nginx玩的溜还是挺难的

Linux你值得拥有

很多时候你的需求其实很简单，不要随便加料，要花时间搞的