搭博客踩过的那些坑

感觉大家建好博客后的第一篇必然写“如何搭博客”,然而我一直拖着没写,觉得并没有太多参考价值(其实就是懒) 一言以蔽之,无论是之前的 GitHub 静态页面 + Hexo 还是现在的 wp,小白都只会 follow 别人的教程,没有什么 technical 的部分拿得出手(特此感谢此方的引路文章)所以就只记录下至今遇到过的各种奇怪问题和解题思路。

GitHub static page + Hexo

初步搭建 Hexo 的时候看了这些教程( )因为全部混着看了所以已经不记得主要跟的是哪个了,大概是 ② ,反正都挺大同小异。当时大概花了两天时间?我是那种摸鱼就非常 dedicated 的人……旧址在 这里 ,使用的是基于默认主题 landscape 的 paperbox,因为根本无需维护所以估计就一直放置了。

出问题是必然的,第一个问题是因为_config.yml里自己的域名没有改掉无法deploy。其实人家教程里有写,但我一开始没注意到这个地方。解决问题绕了很大的圈子,就不多赘述。

第二个问题是由于我完全没有代码基础,直接使用了别人写的 theme,导致我无法理清对方写的css文件。虽然直观来说css的语法已经非常好懂,不比C++Java等等(地图炮对不起),各种导入的文件不知道在哪里,变量定义也不知道在哪个文件里还是相当让人头大的。当然不折腾什么都好说,然而作为一个没技术又想高度个性化的麻烦精真的是要吐血。想加插件时即使已经有了现成的代码,但还是不知道应该粘贴在哪个文件里,更别提这个架构下一个文件出了问题整个网站都会崩溃。

第三个问题可以说是第二个的衍生。各种图片和文件的默认引用路径出现问题所以无法显示背景等等,debug 还要找半天写在哪个文件里。最后简单粗暴地直接引用网络链接解决了,直接脱离本地路径

优点

  1. 不用花钱,完全免费(当然)
  2. 主题选择很多,个性化空间大
  3. GitHub 不需要翻墙

缺点

  1. 某些国内网络 公司内网 可能会无法访问 GitHub 的静态页面
  2. 搭建 + 写博客几乎可以说是全代码环境
  3. 小白出问题 debug 难度高
  4. 插件不好配置

但于我个人而言整个过程还是有不少好处,比如它让我对于htmlcssMarkdown都有了一定的了解,应该可以算是入门了。也知道了sshGit,更意外的收获是有天突然灵光一闪突然知道了 GitHub 名字的来源(大概)

VPS + WordPress

飞速厌倦了 Hexo 后在毛象上围观了此方搭建博客的过程,立马又对 WordPress 感到心动,云五老师 发现的 Oracle 免费服务器羊毛 更是让人有种 “不用立亏100%” 的感觉。这次的搭建用时比第一次短了不少,加上买域名(选择了 namecheap)也就七个小时左右。在写docker-compose.yml的时候修改了一下镜像版本,全部使用了最新的,解决了此方在文中提到php版本过低的问题(wp 管理界面显示 “您已经在使用php最新版本” 所以我想是解决了)

当然,不可避免地,第一个问题:跟着教程走到 certbot 的地方发现自己的 output 不一样,状态是Exit 1。然而此教程并没有写如何解决任何问题,只给了一句

… be sure to check the service logs with the docker-compose logs command docker-compose logs service_name

就没了,没了,没了……

有一说一,作为小白如果没看到这句话是肯定想不到要看 log 的,所以还是起到了决定性的作用。在网上一通搜索,看到这位老哥的 回复 ,其中提到了 publicly routable IP,用 ping 来检测。然而这个地方我其实又掉进了很蠢的一个坑:在虚拟机里自己 ping 自己……那不管怎样当然是 ping 得通的啦!以为不是这个问题,又绕了一大圈,终于发现原来本机是 ping 不通的。最后 turns out 是端口无法访问,因为 Oracle 是默认没有开防火墙(但我至今不理解为什么没开反而无法访问)开启后加上了 22 端口的规则就解决了。

第二个问题是前段时间网站就开始时不时地down掉,显示 “建立数据库连接时出错”,并且时间毫无规律让人摸不着头脑。第一次发现的时候惊慌失措,根据 “重启可以解决一切问题” 的小白中心思想让网页恢复了正常。然而这显然并非长久之计,于是:

Attemp 1:试图给 Oracle 的客服发了 support ticket,客服:我们预约一个 zoom 会话吧!我:(社恐发作)不要。于是客服就又向我要了一大堆 OCID,结果哪个我都不知道是什么……客服大概感到十分无奈,于是和我说你要不看看 server/application log,我:sounds good。于是找到系统的 log 文件夹/var/log ,像开彩票一般随便挑名字顺眼的文件开始查看,最后在某个 log 里发现原来是内存溢出,导致 MySQL 的进程直接被杀掉。又监测了一下进程,发现光 MySQL 就占用了服务器可怜的 1G 内存的 35~40%。系统本身也要 40% 左右,再加上 php(~20%)等等不爆炸才奇怪。

Attemp 2:于是开始搜索如何优化 MySQL 占用内存过大。最普遍的方法是直接改 configmy.cnfmy.ini文件,在里面对某些变量加上限制就可以了。这位大佬写的 参数说明 非常详尽,此外还参考了 这个配置 和 MySQL的中文文档 ,不过后者非常 technical 并且是 5.7 版本的手册,并不是我现在使用的 8.0。然!而!由于我安装时用的是docker-compose(并且和docker本身貌似还有一些细微区别),所以这个配置文件并不在它的默认目录/etc/mysql/conf.d下。根据我的理解简单来说 MySQL 是运行在docker-compose生成的暂时 container 里,有关它的文件只能进入 container 才能查看修改等等,并不能直接在硬盘上找到。

这里也分三种方法:

  1. docker-compose.yml里修改 command 选项(教程链接
    然而搭博客的教程中这一行用单引号括了起来,和这个链接里不一样,而我也不知道为什么。继删掉单引号后加选项、在单引号外加选项和在单引号内加选项的尝试都失败后(无法建立 container)放弃了这个方法;

  1. 在同一文件里加上自己的 config 文件路径(图中高亮行上一行)没有出现 bug 但貌似也没有起效;
  2. 进入 container(docker bash)修改配置文件(教程链接
    $ docker exec -it db bash
    # 安装一个编辑器(我喜欢所以选了 nano,原作者装了 vim)
    $ apt-get update
    $ apt-get install nano

    在 /etc/mysql/conf.d 下打开 docker.cnf,在里面写自己想要的 option

    # 根据大佬们的文章我自己写的一个配置
    [mysqld]
    skip-host-cache
    skip-name-resolve
    innodb_buffer_pool_size=128M
    query_cache_size=16M
    tmp_table_size=64M
    key_buffer_size=32M 
    interactive_timeout=7200
    max_heap_table_size=32M
    thread_cache_size=8

    保存,退出 bash,重启 container。然后就发现重建后什么改动都没了……一切又回到了原点。但是此后 MySQL 进程的内存占用好像稳定在了 35~36%,所以也不知道到底有没有起到作用了。

Attemp 3:椒盐豆豉老师 提到可以给服务器添加虚拟内存(swap)并且直接发送了一个教程(感激不尽!)简单来说就是让你的系统把内存中现在用不到的东西暂时放到硬盘上保存,这样可怜的物理内存就可以腾出一点空间。这个教程有适用于不同系统 Linux 的分支,非常之友好并且很好 follow,无脑 copy paste 五分钟搞定没有出任何问题。内存占用在半天内逐步下降,现在稳定在 86% 左右。

希望这就是关于内存问题我的最后一个 attempt 了……

优点

  1. 图形界面!图形界面!!天知道我对着 Git Bash 的黑框框和命令行折腾了那么久以后又看到图形管理界面是有多么激动
  2. 主题多,自定义程度极高而且简单
  3. 插件多,wp的插件真的不用我再赘述了(PS:随便哪个衍生或者原装插件五分钟就可以搞好 Google Analytics,马上让你对网站访问量有一个非常直观的认识,对一个刚刚起步的人来说激励作用真的非常非常大;相比之下虽然之前找到了不蒜子的统计插件,然而我根本不知道怎么装在网页上)
  4. 小流量的个人域名几乎不会有被墙的可能性

缺点

  1. 搭建部分还是需要和代码打交道,一并加上 VPS 可能出现的其他问题
  2. 小白 debug 依旧比较困难
  3. (缺点?)域名还是要自己花钱买,服务器如果你要求高一点也要花钱买,没有办法像 GitHub 托管网页一样做到完全免费

总的来说还真是踩了不少奇怪的坑……虽然最后也没搞明白为什么光博客托管就占了这么多内存(有友邻说在 1G 服务器上托管了两个博客)但是暂时也没有要搞其他东西的计划,所以只要这个博客能一直顺利在线不出问题我就满意了。如果以后有空搞其他的(并且决定 commit to it)会选择去另外买个好点的VPS。衷心希望这篇文章再无大更新之日了!

2 评论

  1. _(:з」∠)_ 看的我都想搭博客了呢。
    不过感觉我这种对写文章过敏的家伙一个字都不会有的hh
    话说只需要邮箱的评论超棒,这种形式确实方便。

    • 想搭就搭 233333 我觉得博客最难的还是长期输出啦,要有东西写才行
      wp 的自带评论系统确实方便

回复 Kuria取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注