应用迁移“翻新”

Cover


早几年前,就有过更换博客框架的想法,但总会因为一些原因搁置。春节后,有了一些时间,于是一颗“邪心”又开始蠢蠢欲动,打起了更换博客框架的想法。过程中因为博客评论系统了解到一些关于 Serverless 和 PaaS 的信息,然后就开始了 RSSHub、 Tiny Tiny RSS、 Wallabag 等应用迁移与部署之一去不回头之路,哪能想到原来这是牵一发而动全身的事情,怪我意志不够坚定咯。

说说更换博客框架的原因,当初搭建博客并没有参考太多的信息,就是那么一下在 GitHub 发现了一个博客模板的仓库,就突发奇想,动手也搞一个自己的博客。你所想不到的是,那就是一个模板,只有一个 html 的静态模板,所有样式、脚本、文章等,全在那一个页面上。复杂、易错、杂乱,导致在尝新之后其实很少更新内容。

Serverless & Pass & Others

Serverless computing is a cloud computing execution model in which the cloud provider allocates machine resources on demand, taking care of the servers on behalf of their customers. “Serverless” is a misnomer in the sense that servers are still used by cloud service providers to execute code for developers. However, developers of serverless applications are not concerned with capacity planning, configuration, management, maintenance, fault tolerance, or scaling of containers, VMs, or physical servers. Serverless computing does not hold resources in volatile memory; computing is rather done in short bursts with the results persisted to storage. When an app is not in use, there are no computing resources allocated to the app. Pricing is based on the actual amount of resources consumed by an application. It can be a form of utility computing.

Serverless computing can simplify the process of deploying code into production. Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices or monoliths. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all. This should not be confused with computing or networking models that do not require an actual server to function, such as peer-to-peer (P2P).

Serverless computing – Wikipedia


Platform as a service (PaaS) or application platform as a service (aPaaS) or platform-based service is a category of cloud computing services that allows customers to provision, instantiate, run, and manage a modular bundle comprising a computing platform and one or more applications, without the complexity of building and maintaining the infrastructure typically associated with developing and launching the application(s), and to allow developers to create, develop, and package such software bundles.

Platform as a service – Wikipedia

为什么先说这些,因为它们算是我开启新世界大门的罪魁祸首。

在搭建博客前,选择了 Waline 作为博客的评论系统,而部署 Waline 的容器,各个面都指向了 Vercel。在初识 Vercel 时,无非就让我关注到了两点:
1、还有哪些类似的服务
2、它能部署一些什么

说到类似的服务,真是寻觅了一圈又一圈,尝试了一轮又一轮:

  • Vercel
  • Render
  • Deta Space
  • Surge
  • Netlify
  • RunKit
  • Fly.io
  • Glitch
  • Koyeb

Vercel

认识下来,算是一个应用很广泛的 Serverless,在国内使用的缺点就不再赘述。就个人对其需求不大。

目前在 Vercel 部署的服务就两项:

  • RSSHub
  • Excalidraw

Render

目前个人使用最多的 PaaS。在 Render 上,基本都是以 Docker 部署应用, 对免费计划而言,限制还是挺多的:

  • 所有应用每月总共 750 小时在线时长
  • 无持久化存储
  • 15分钟内无访问休眠

目前在 Render 部署的应用:

  • Tiny Tiny RSS
  • Wallabag
  • Gotify
  • AList
  • Uptime Kuma
  • Cloudreve
  • Zfile

Deta Space

在使用前,其实对 Deta Space 抱有很大的期望,可能真的是希望越大,失落越大,失落的是没有申请到开发者权限,故失去了很多自定义的乐趣。

目前在 Deta Space 部署的应用:

  • Waline
  • WebCrate
  • Snapdrop

Surge

目前博客就部署在 Surge 上,Surge 算是比较出名的静态站点托管平台,不像其他大多数平台,它没有每月流量限制,但最近通过 Uptime Kuma 监控访问发现,Surge 的服务器很不稳,不知只是最近的问题,还是长期都存在的问题,如果长期不稳,会考虑将博客迁出。

目前在 Surge 部署的应用:

  • Hexo Blog

Netlify

也是一个出名的静态站点部署平台,但目前对其需求不大。

目前在 Netlify 部署的应用:

  • Acme-h5
  • Webp2jpg

RunKit

尝试了下,但目前没有使用场景,也观察了下,算是很多人都喜欢的一个 Serverless 平台。

Fly.io

风评很好的 PaaS, 但部署需要绑定信用卡,它在限制我将它发扬光大。

Glitch

尝试部署了几个项目,算是一个好玩的 PaaS,除了会休眠,它的机制玩法,也会让我觉得只能玩玩。

Koyeb

怎么说呢,它也算是一款知名的 PaaS,本来申请 Koyeb 是用来作为备用或备选,但是它的校验机制特别逆天,反正目前我仍被它拒绝中,考虑删号走人。

Application

Hexo & NexT & Waline

之前博客模板采用单一 html 的形式部署,每次新增、修改都有可能导致页面错乱。且长期更新之后,内容叠加,使得单一页面内容以较为复杂,所以一直有更换博客框架的想法。

其实在早前,已经了解过 Hexo,但人生最悲哀的事情莫过于人懒,所以迟迟未动。

正所谓好事不出门,“坏事”传千里,Hexo 作为博客搭建框架应算是人尽皆知的。选定 Hexo 作为博客框架,又选了 NexT 主题,要问为啥,因为好看、便捷、使用量高,其实还是人懒,深究不了。为方便考虑,选择了 Waline 作为评论应用。

目前博客部署于 Surge,Waline 部署于 Deta Space(没错,它没有部署在 Vercel)。

Memos

img

一款类私人微博应用,方便记录、备忘,主要用于随感随记。

部署 Memos 时,稍微折腾了一段时间,最初是想尝试下,所以将其部署到 Render 上,为避免 Render 因免费计划未持久化存储,导致数据清除,所以选择了 SQLPub 作为 MySQL 数据库平台存储数据。但在使用几天后,效果并不理想,一是因为远程连接数据库,导致操作及页面加载过慢;二是因为考虑到数据安全及隐私问题,所以最终放弃了在 Render 上部署。

目前 Memos 部署于云服务器。

Tiny Tiny RSS

一款 RSS 订阅应用,主要订阅一些个人平时关注的文章及新闻,如 One 一个小众软件 等。

Tiny Tiny RSS 早前一直部署在我的爱机 Pixel2 上,但由于目前 Pixel2 上部署的应用越来越多,且磁盘空间有限,遂将其迁移到 Render 上,但还是因为连接远程数据库的原因,其实效率相比之前有所降低。

目前 TTRSS 部署于 Render。

RSSHub

提到了 Tiny Tiny RSS,也不得不提 RSSHub,一款 RSS Feed 生成器,主要是把一些网站内容转换成 RSS 格式,然后订阅到 Tiny Tiny RSS 中。

RSSHub 之前也部署在爱机 Pixel2 上,由于同上类似的原因,将其另行迁移。

目前 RSSHub 部署于 Vercel。

Wallabag

记得 Pocket 作为稍后阅读的元老级产品,刚推出时,便吸引了一大堆我认为我有时间,我认为我爱阅读的一大批人。当然,我也是那批人中的一个,管你产品是不是稍后阅读,到我这儿,就只有稍后,没有了阅读。

每次打开 Pocket 总会看到推荐订阅付费计划,其实让我感官不是很舒服。我有点时间看看零碎收藏,你就让我首先看这?于是乎便有了 Pocket 的私人部署替代 Wallabag。

Wallabag 之前同样部署在爱机 Pixel2 上。问:为什么要部署那么多应用到 Pixel2 上?答:因为是爱机…当然现在已经迁移了。

目前 Wallabag 部署于 Render。

Gotify

本人手机在使用过 iPhone6s Plus 后,便投入了 Andorid 的怀抱,不是 iPhone 不好,是我不够好。

话还是说回 Gotify,一款安卓平台的消息实时推送应用。Gotify Server 早前部署在家里的 NAS 上,然后想想,NAS 主要是运行 Nextcloud、Emby、Calibre-Web 那些资源大项上的,Gotify 嘛,动动嘛,所以动动就动动。

目前 Gotify 部署于 Render。

Uptime Kuma

img

Uptime Kuma 是类 Uptime Robot 的网站及服务器监控应用。使用它的目的在于:

  1. 监控已部署应用并通过调用 Gotify API 进行通知。
  2. 定时访问 Render 部署应用,解决其机制性休眠。

目前 Uptime Kuma 部署于 Render(以子之矛,攻子之盾?)。

AList

A file list program that supports multiple storage, and supports web browsing and webdav, powered by gin and Solidjs.

AList – AList Docs

如其描述那样,将你能想到,不能想到的网盘、WebDAV 聚合到 AList 中,实在是方便,而且其花活也多,自行研究。

AList 在 NAS、个人常用笔记本中都有部署,然后配置了已在使用的所有网盘。也是因为配置了所有网盘,所以仅在家里的网络和本机使用。同时也在云服务器上部署过配置部分网盘的 AList,但由于流量及硬件限制,在使用上一直不怎么理想,所以也在考虑如何迁出。

目前 AList 部署于 Render。

Render 部署 AList 期间,发现要么其 Docker 镜像不能部署,要么部署的 Docker 镜像在一段时间后会被 Render 自动删除,应该是其 Docker 镜像被 Render 官方注意并加入黑名单。目前部署的 AList Docker 镜像是下载 AList 官方仓库后自行构建上传的,截至当前仍然使用正常,后续仍需监控,且行且珍惜,对,说的就是你 Render,要珍惜我。

Others

其他应用的部署算是实验性的,使用频率并不会如以上应用那么高,所以也不过多献丑。

最后,本文算是近期为自己应用迁移做一个小结。