普通视图

发现新文章,点击刷新页面。
昨天以前首页

新年给博客迁新服

2025年1月6日 22:48

✨1/8日更新:3天AWS新服体验不佳,吃灰已久的Jetpack宕机监控功能3天下来跳了几次,已迁至阿里云港服。从 🇸🇬🇯🇵 再到 🇭🇰,博客站物理位置离自己更近了👏


博客重新上线时用的是Amazon Lightsail最低标准,配置是512MB内存 2vCPU,每月3刀,一个WordPress小博客站点够用了。用了一段时间有了折腾后发现不够用,就单单一次上传多个图片就能给整爆失联,得重启服务器恢复。后来干脆快照形式搬迁至1GB内存 2vCPU配置,每月5刀,用到现在没出现什么问题,期间亚马逊AWS还涨过一次价至7刀。

以上用的实例位置均在新加坡,期间有博友发现其无法畅通访问得挂梯子并告诉我(其实我自己用的网络环境中并没有遇到过,网络运营商处理这些在我看来有点玄学)。之后就心念着想换位置,理想位置是香港,毕竟是没有备案的最佳选择。还有一个想换的原因是用Bitnami栈打包的Apache服,怎么说呢,Bitnami非常好非常安全非常稳定,但对我来说太麻烦了,修改一些文件权限要整来整去,一些服务版本的更新还得大动干戈,就想换成原味。主要是自己的懒惰,就一直搁着。

新年嘛,就趁新年第一个周末给站点搬家。看了阿里云ECS和腾讯云CVM,最终选择了老东家亚马逊。亚马逊的EC2有港服,但没港服的Lightsail它更便宜!选了和原来一样的配置7刀/月,不同的是位置从新加坡换到了日本,离中国近一点哈哈,经过测试真的是快了一点~阿里云和腾讯云的轻量应用服务器也便宜且有港服,但当我看到“建站内容也是受限制的,出现违规域名会被封禁。”时总觉得会缺少点什么,虽然自己爱国守法,但还是算了,这些年使用过和正在使用的服全是外面的,也无所谓运营商玄学,就对搬回来这欲望并不是那么强烈。

周六上午就开好实例,用Debian12作服务器系统,习惯了Debian,很好。下午只需要旧服备份数据新服搭建环境后一气呵成。然而过程中出了一些状况,需要放下手头其他事,搁置了已经进行到一半的搬迁事宜。当时就连把域名解析回旧服ip从而恢复访问的操作都不想做,出现502 404 TIMED OUT之类已经无所谓了,因为儿子生病了。

周六当天儿子出现两次呕吐症状,第一次呕吐物比较少,里面有少许上午吃的水果。期间儿子还说过自己肚子痛痛,但我们仅凭他当时精神状态很正常,并就有没太多处理,只是揉揉肚子和各种无知的揣测原因。隔三四个小时后出现第二次呕吐,我们这时才意识到问题的严重性,并立马带他去医院,医生给的诊断结果是小儿病毒性肠炎。晚上儿子就出现发热症状,又是一个不眠夜。第二天还在发热,但属于低烧范围,已经不会再呕吐,也说肚子不痛痛了,状态也不错。

周日下午才有完全属于自己的时间接着去处理搬新服后续的事,算是比较顺利。出现问题是服务器莫名过载让网站无法访问,SSH也连接不上且持续很长时间,得重启服务器恢复。线索来源于“PHP message:Connection refused”,先排查插件发现W3TC所使用的缓存方式会导致此问题,Redis与Memcached都试过但问题依旧,干脆先停用,反正新服速度不错。病根应该是php,先搁置,等有空再处理~ //已解决,PHP权限问题

Lightsail真的很Light很轻量,CPU给压的死死的,便宜嘛,这货持续高负载就卡挂。属于突增型,就是说你平时使用CPU的利用率低于10%时(性能基准,实例配置不同基准百分比不同),能积累一种“能量”,当CPU利用率高于10%时,累积的“能量”就会消耗,如果持续高负载直至“能量”耗尽,CPU最大利用率就会压回10%,这就是为什么会挂掉的原因。以上是我对突增型服务器的理解,也罢,够用!

2025年了,看到大家都在写总结,晒清单,立新年Flag,由衷佩服大家的行动力,这是身为一个博主应该拥有的积极人生态度啊,反观自己真的是弱爆了。我属于是佛系,博客更新频率低,写的东西也属于肤浅的记录。时间是有的,陪小朋友、玩游戏、刷手机是我工作时间以外最放松的时候,所以不想“浪费”在写博文上。偶尔打开Follow看看大家写了啥,说真的点开订阅也成为另一种心理负担,因为每次点开后这么多的未读文章,每篇都想点进去瞄一眼,这时间就刷刷走了~

给网站增加了 DIŸgöd 的 follow(Description 方式)

2024年9月9日 15:30

为什么我写了好几篇

为 follow 增加 claim 的方式有三种,我最初选择使用方式一,但增加 Content 后无效,经思考,估计方式一不支持 Atom 格式 Feed(个人猜测)。

为 follow 增加 claim 的方式

follow.is 是 DIYgod 的新产品,其中可以 Claim 一个 Feed 为自己的,据说为 follow 增加 claim 后可以支持打赏。

增加方式有三种:

  1. Content

    在 Feed 最新内容中增加如下文字:

    This message is used to verify that this feed (feedId:41342818708527123) belongs to me (userId:41447029693323264). Join me in enjoying RSS on the next generation information browser https://follow.is.
    
  2. Description

    在 Feed 的 xml 文件中,增加 Description 标签,内容如下:

    <description>feedId:41342818708527123+userId:41447029693323264</description>
    
  3. 在 Feed 中增加如下内容:

    <follow_challenge>
       <feedId>41342818708527123</feedId>
       <userId>41447029693323264</userId>
    </follow_challenge>
    

Pelican 增加 claim 的方式

由于 Pelican 实现 Feed 的方式是采用 Django 的 feedgenerator 工具库(依赖一个成熟项目的组件是非常聪明的做法)。经查看源码,发现 feedgenerator 支持新增节点,但不太支持修改 Feed 节点,于是,对于此场景较好的方式是手动搞定,搞定方式嘛,新增一个 Pelican Plugin 来处理或者新增一个后处理步骤(比如一个脚本),在其中处理一下 Feed 的 XML 文件内容即可,原理都差不多,采用 Pelican Plugin 方式的好处是可以较方便获取文件路径。

Pelican 实现 claim 插件源码

给网站增加最近评论功能

2024年6月17日 09:40

痛点

最近修改网站设置后,giscus 评论未显示。直到我进入了项目的 Discussion 才看到有一些最新留言,但这些留言未显示在文章下方。为不错过留言,我决定为网站增加最新评论功能。

分析

那么是否有一种方式,可实现在网站上显示最新评论呢,对此,所有的回答都是肯定的。

程序可以实现一切。如果是静态网站(SSG),实现方式稍一想,就有三种。

方式一、直接从 https 抓取所有的评论网页,解析出评论。缺点是依赖页面结构,可能会失效,需要随着 Github 页面结构的更新而更新。

方式二、使用 Github 提供的 API,需要查看 Github 文档,需要注意保护好授权 Token。

方式三、使用 Github Action 和 Webhook 实现在评论时维护一个 comments.json 文件,缺点是每次生成前需要拉取这个文件,增加了生成时间。

综合来看,如果官方支持,那选方式二是最佳选择。

实现

经过查阅文档和讨论,发现 Github 有 graphql 和 REST 两种形式的 API,未来有 REST API 迁移到 graphql 的趋势。且 Discussion 是一个较新的特性,获取 Discussion 目前只有 graphql API。

编程助手已经改变了编程,经过一个提问,一次复制,我就获得了代码结构,此时,基于我对 graphql 的入门理解,我直接修改了 query,几次尝试后,我就获得了需要数据。整个过程确实节省了不少时间。

至于 Token 保护,我还是选择了在 .gitignore 中增加 .env 文件,然后从 .env 读取的方式,而不是使用系统变量。PyCharm 或 IDEA 系,对系统变量的处理有点奇怪。系统变量更新了,你不通过搜索甚至不知道它什么时候更新,此时 .env 就没这问题,唯一要注意的是不要遗忘先添加 .gitignore 再添加 .env。

实现源码 ,然后在 jinja2 模板中循环展示,由于更新频率,此处只是简单实现以满足基本需求,并未严格按时间排序。

未来计划

对于评论功能,最开始使用的是 gitalk,后来有人反馈无法打开,于是增加了 giscus。这两者之间,gitalk 使用 issue,giscus 使用 discussion,相比来说,我认为 issue 会更基础一些。如果有一天未来要砍掉特性,discussion 必定在砍 issue 之前,当然了,砍特性这种事在公司还有现金流时,是不会发生的。

gitalk 和 giscus 的优点是免费,如果要说缺点,gitalk 和 giscus 的就是依赖一种并不是为此设计的用法,Github 可以处理掉这种不合适的用法,那是评论就会失效,迁移数据也许挺麻烦的。

所以,最好的方式是换自己支持评论的程序,或者依赖一些 serverless 的服务,将评论数据以开放的结构存放在可控的地方。

记一次网站故障及 CloudFlare Pages 的两种典型配置

2024年4月17日 09:40

基本概念

在尝试 Astro 的发布时,官方推荐的是 Netlify,但在个人经验上,国内环境 Netlify 服务可用性不如 Cloudflare。

毕竟 Cloudflare 是 今日市值 307.40 亿美元的公司,股价 91.04 美元,员工 3000 多人,而 Netlify 还在 C 轮,员工数量没有明确公开数据,约 244 人。

无论服务取啥名,构建个人网站,这里用到的服务主要有两种:一种是指 CDN,另一种是 ADS。

  • CDN 即 Content Delivery Network,将内容分发到全球的多个网络节点中,这样用户访问内容时,会从离用户近的节点返回内容,属于空间换时间。
  • ADS 即 Automated Deployment Services / System,即自动化发布服务/系统,可以触发发布编译调度服务,以自动地从源码构建并进行发布。
零信任网络

Cloudflare 自夸在全球网络标准类别获得 Forrester 报告中所有 SSE 供应商中的最高分,而 Netlify 体量相对小,但服务也算是不错。

这里的 SSE,以及 SASE,都是相对较新的词,是一套适配现代企业架构的安全边缘计算服务和产品。

听起来陌生,倒不是因为它们出来晚,而是因为这套服务成本不低,阿里云也有类似服务,但头部还是这些

怎么理解?通俗讲,这套服务就是疫情下的远程办公需求催生的。

原先,员工到达办公地点,从公司内的终端接入公司网络,访问内容和资源,就是说,只要员工在物理场所内,就获得了公司内公开内容的信任,以前出差的员工多采用 VPN。

而远程办公需求下,员工从全球接入公司网络,VPN 存在很多不必要的成本,比如:

  1. 访问其它公司的在线服务,没有必要走公司网络流量。
  2. 原先 VPN 的接入可以给与一定地域和 IP 限制,而对于全球企业来说,随时可能就几百几千员工在出差,由专人管理访问规则成本会太高,不如公司内部网络和应用对接入者都进行严格验证和授权。
  3. 公司可以不用管员工从哪里以及如何使用公司资源,这些资源都被相对封闭在浏览器沙盒和员工设备中,从而获得了办公的灵活性,也有日志可以事后审计。

Gartner 称 SSE = SASE - SD-WAN,原先想推广的是 SASE(Secure Access Service Edge),如 Cloudflare One 服务,但公司要迁移到这样的环境,除非是新公司,否则会困难重重,因此又推出了 SSE 这种更容易落地的服务。

这些设施和服务,其实都是为了简化小公司与 IT 有关的工作,借助 SSE 可以缩短 IT 基础设施建设周期,更轻便灵活的起步开创全球化业务,但从长远来看,自建这些设施和服务是无可回避的。

所有成功构建护城河的现代公司,必然都是 IT 中厂,这也是现代公司面临的窘境,最终有一环你的成本永远都不会比互联网公司低,若互联网公司欲涉足你的领域,你会不具备此竞争优势。

关于故障

网站出现故障是因我将 GitHub Pages 服务迁移到 Cloudflare Pages 构建,而 kaffa.im 的构建模式依赖本地服务。

在此,我又想到了那句—— 所编写的每一行代码都是成本

这里要实现 kaffa.im 的自动构建,需要去掉本地数据依赖,方式有:

  1. 将依赖的数据先本地 fetch 好,作为数据库或 json 上传。
  2. 将系统部署到云端。

我想我可能会选择没有成本的方式 1。

关于本地构建和远程构建

本地构建适合本地依赖多的场景,远程构建的前提是依赖标准化组件和服务。远程构建确实更方便,但要考虑的是,这种免费构建服务的生命周期有多长,犹其是内容价值非常高且服务中断成本非常高时。

本地构建的配置

  1. 将 DNS 指向 Cloudflare 的 DNS,这一步非必须的,按这样做可以简化后续设置域名。
  2. Pages 服务中,在 Settings 标签的 Builds & deployments 节下,如果你的静态内容是在目录下,则需要将:
    • Build output directory 设置为这个目录,比如 /disc 或 /docs 等。
    • Root directory Pages 的发布目录,默认为 / 即可。

远程构建的配置

可以使用 Cloudflare 的 Connect to Git 功能,也可以使用 Common Worker examples 开始。远程构建的优势是,你只管写内容和提交,其余的交给 Cloudflare,它会先从 Git 拉源码,再构建,再发布,勤勤恳恳的免费打工人。

增加 darkmode

2024年3月29日 01:00

Dark Mode

bulma.css 增加了 darkmode,于是为站点增加暗夜模式提供了便利。

这是一种感觉,事实是添加 darkmode 类似增加主题,对网站而言可谓伤筋动骨。

因为原有设计中,未考虑多主题的文字和背景搭配都需要重新考虑,原有正常的比如 has-text-grey 这种其实也是写死。

另外还有第三方组件,也未兼容 darkmode。

以上几点,花费了两个晚上修改,已经修改得飞快,这次修改将所有的写死的地方,全都修改为 var 变量。

完成暗夜模式后,晚上使用,LP就不会说太亮。

吐槽 bulma 1.0

bulma 这次升级可谓仓促,虽然有很多新功能,但其中还有一些破坏性升级,比如原先的 tile 组件,虽然有替代方案,但说白了就是废弃了。

另外,新增的 darkmode 也并未对所有组件仔细考虑,还有升级过程并不能做到像素级一致,许多地方需增加定义和自定义。

虽然做了小白鼠,但好在是自留地,不完美也不重要,重要的是完成了。

提示

bulma 0.94 在做充分评估前,不要冒然升级到 bulma 1.0,犹其是使用了 tile 或者希望增加 darkmode 的人。

❌
❌