Posts 博客架构分拆
Post
Cancel

博客架构分拆

令人瑟瑟发抖的寒冬中,时间迈入了 2019 年。一片萧条的大环境下,人们注定要为今后的生活付出更多艰辛与努力。微软,大洋彼岸的 IT 巨头,似乎觉察到这点,于是大手一挥送温暖:于今年 1 月 8 日宣告 GitHub 对个人开发者免费提供私密仓库服务,数量无限制。要知道,此前私密仓库是要每月耗费 7 刀巨资啊。

收到这份新禧礼物后,我激动地把分散到各处小作坊平台的仓库统一迁移到 GitHub 上,逛 GitHub 的频率随之陡增。就是在这样的背景下,发现 GitHub 有人 Fork 我的博客仓库。像本站这种不走量不推广,且国内不备案的边缘博客,理论上没人关注的,于是好奇地进到那货的 GitHub 主页,一看 ID 是新注册的,而且每天大批量的搜索 GitHub 并 Fork 开源的仓库,一天几十上百的 Fork,典型的自动化脚本操作。

没图你会说我吹牛逼,下面就是那个账户的异常活动:

19011400

既然我把博客仓库开源了,自然没有什么敏感数据在上面。不过对于这种扫库行为,心里依然略有芥蒂,于是微微一笑,把那个马甲账户 Block 了。

一个小思考

这件趣事也引发了我的一个思考,如果某个项目真的存在一些敏感数据,怎样在保证开源的情况下隐藏这些数据呢?在梦中我找到了答案:把项目的仓库分拆。基础框架和敏感数据拆分,后者移出到新的私有仓库,刚好可以合理用上 GitHub 无限免费私仓服务。

借助这个思路,顺便可以把文章和博客框架也分拆开,包括需要隐藏的元数据( Google-ID, Disqus 等)在内,可以把原始仓库分成三部分:

  • Framework
  • Posts
  • Meta

拆分细节

Framework 作为通用模版而存在,方便别人对本站架构进行复用(虽然可能性约等于零),进一步贴近开源精神。

Posts 主要是文字创作内容,这可以很好的把 post 的更新记录从站点架构中分离出来,使两边的提交历史更加清晰明了。

Meta 部分对外透明,定义那些高度私人化、零复用价值的数据,即便这样,编译后的静态文件还是包含了这些数据,隐藏起来只是为了满足心里的仪式感,正所谓防君子不防小人。

工作流变化

分拆是个双刃剑,方便了内容管理,也给本地开发和线上的 CI 产生了阻力。为了解决这两个问题,我的解决方案如下:

  1. 更新基础架构或者修改文章后,用脚本把三个零散仓库通过拷贝合并起来,成为一个完整的项目,再进行构建和测试。
  2. 持续集成可以由 Framework 和 Posts 两个仓库触发。
  3. Travis CI 的只对公开仓库提供免费服务,所以 Meta 私有仓库是不能够触发线上 CI 的,必要时,可以到 Travis CI 上手动触发 Framework 或 Posts 的构建,即可把 Meta 的更新进行部署。由于此部分内容更新频率极低,所以影响不大。

后话

分拆的作业看着简单,但是耗费了整整一天。仓库内容分离以及 Travis CI 的脚本修改需要点耐心。最后顺利成功了,自然也是小有成就感,博客的项目演进又往前迈进了一小步。

OLDER POST NEWER POST

Comments powered by Disqus.

Search Results