在使用新私有化部署的书签导航应用一个月之后,我们来聊聊书签导航工具,以及介绍如何使用 Docker 在几分钟之内部署属于你自己的书签导航应用。

写在前面

我目前使用的书签导航工具的界面是这样的(马赛克掉了一部分链接内容):

我当前使用的书签导航工具界面

作为一个使用了十多年 Chrome 的用户,Chrome 书签管理器一直是我的主要的书签管理工具。在漫长的岁月里,我的 Chrome 书签管理器中,最多的时候存放了上千个书签链接。

但是 Chrome 的书签栏面积十分有限,随着折腾的东西越来越多,导致导航栏基本放不了多少东西,许多书签常常需要在书签二级目录甚至三级目录中查找,非常麻烦。当然,Chrome 地址栏和搜索栏二合一之后,浏览器支持从这个全能文本框中搜索某个书签以及历史搜索结果,但是在缺少提示的情况下,也时常出现 “茫茫人海,不知从何搜起”的状况,或者出现搜索结果中的书签会混杂在一堆历史浏览记录中的状况。

几个月前,我开始进行个人 PKM 重建。在过程中,我期待有更好的方式来使用书签,让我能够更多的使用“一次点击”来解决问题,减少大量翻箱倒柜式的“翻找”和“搜索”动作;同时,我也希望这些书签内容,可以在不同的浏览器和设备中共享,而不是仅限在 Chrome、Safari 或某个特定的产品中使用、甚至仅限在桌面浏览器环境中使用;我希望尽可能不使用在线的云服务,因为在过去的十年中,非常多的以云收藏夹为主营业务的公司都折戟在了互联网长河中;最后,我希望这些数据是能够使用比较友好的格式被妥善的存储,在未来某个时刻能够很方便的迁移到更先进的工具中。

基于上面的种种考虑,我在一众开源软件中找到了 Flame,在使用了一段时间后,我觉得 Flame 中的一些设计对于我而言比较多余,以及软件本身的性能效率并不是特别好,尤其是针对我这种拥有非常多书签的用户而言。所以,在借鉴 Flame 原有功能的基础上,我写了一套新的工具 Flare。关于 Flare 的制作和性能调优,感兴趣的同学可以围观之前的文章《Flare 制作记录:应用前后端性能优化》

虽然我制作了“改良版” Flare,但是 Flame 对于多数人而言,依旧是一款不错的软件。所以,接下来我会分别聊聊两款软件在容器下的使用,供我的读者按需选择。​

在容器中使用 Flame

相比较其他的要么功能纷繁复杂,要么界面陈旧落后的开源软件,功能相对简单,界面颜值也非常高的 Flame 很快进入我的视野。

在花费了一番功夫之后,我将 flame 封装成了 Docker 镜像,Flame 的镜像尺寸 50MB 多一点点。

Docker 化的 Flame

它的使用方式很简单,将下面的内容保存为 docker-compose.yml

version: '3.6'

services:
  flame:
    image: soulteary/flame:2.2.0
    container_name: flame
    volumes:
      - ./data:/app/data
      # 如果需要 Docker 集成,可选择开启
      # - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 5005:5005
    # 如果想使用 Docker Secrets,可选择开启
    # secrets:
    #   - password # optional but required for (1)
    environment:
      - NODE_ENV=production
      # 默认管理密码
      - PASSWORD=flame_password
      # 如果想使用 Docker Secrets,可选择开启
      # - PASSWORD_FILE=/run/secrets/password # optional but required for (1)
    restart: always

# 如果想使用 Docker Secrets,可选择开启
# secrets:
#   password:
#     file: /path/to/secrets/password

然后使用 docker-compose up -d 启动应用,接着访问浏览器中的 http://localhost:5005 就能看到软件的默认界面啦。

Flame 的 Web 界面

关于如何进行个性化调整,以及书签的添加等,同样非常简单,聪明的你可以自行探索,为了不“剧透”,这里就不过多赘述啦。

这个项目地址在这里:https://github.com/soulteary/docker-flame,其中的一些改动已经被合并到了 flame 官方仓库。

接下来聊聊为什么我要制作 Flare、以及 Flare 如何在容器环境下使用。

为什么要制作 Flare

随着深入使用 Flame,我发现了一些体验上的小问题:比如软件不支持搜索中文内容;比如软件获取天气数据需要使用经纬度(以及需要注册获取天气平台 API)非常麻烦;软件后台存在一些浪费性能的问题;软件前端的实现方式,在大量书签的场景下,性能表现比较糟糕,会出现卡顿;软件虽然功能简单,但是整体性能不够好,我希望用更少的资源运行这个服务。

而 Flame 原本的功能设计,对于我个人使用的场景而言,也显得稍微有一些多余:

  • 我不太需要软件本身的 Docker、K8S 集成功能,这两个功能的初衷是从 Docker Label、K8S Ingress 注解中提取链接信息,进行动态的链接添加和删除,但是我比较抵触 All In One,所以我的设备和服务多是分布式部署的,并且长期运行的服务非常固定,变动比较少;
  • 随着整理了越来越多的书签后,我发现我对于书签的写入频率其实不高,原本的书签编辑器的体验也不是很好,我希望有更好的方式来进行替换;
  • 以及作为私人使用的书签导航,我似乎也不需要用户功能;
  • Flame 使用 SQLite 进行数据存储,虽然比使用 PG、MySQL 要轻不少,但是在数据变化不大的场景下,或许结构化的明文保存会简单,也更利于未来的数据迁移。

在明确了上面的问题,以及我到底想要什么之后,我制作了 Flare,一个轻量的、适合私有化部署,个人使用的导航工具

Docker 化的 Flare

相比较 Flame 在裁剪功能后封装的容器镜像需要 50MB 的大小,Flare 只需要不到 10MB 的空间,以及远低于 Flame 的运行资源(通常情况下远小于 1% 的CPU占用、30M以内的内存)。

在这个基础上,Flare 除了可以运行在传统的 x86 主机上,比如你的笔记本、你的NAS、云服务器上,还可以运行在各种 ARM 设备上,甚至是很早之前分享过的成本不到 50 元的玩客云上。(感兴趣的同学可以阅读《玩客云折腾记录(一):编译 ArmBian 系统》

我们可以使用文本文件的方式来针对链接数据的管理,尤其是在链接数据非常少的情况下,简单的文本文件,配合任意你喜爱的编辑器,编辑体验远胜于各种简单引入的 Web IDE 或简陋的应用提交表单。而这些文件,也更容易保存、备份,以及在未来合适的时候,导入到更好的工具中。

在容器中使用 Flare

Flare 的使用同样也非常简单,你可以使用 docker 的一句话命令,快速启动一个 flare 应用:

docker run --rm -it -p 5005:5005 -v `pwd`/app:/app soulteary/flare:0.2.3

或者将下面的内容保存为 docker-compose.yml

version: '3.6'

services:
  flame:
    image: soulteary/flare:0.2.3
    restart: always
    command: flare
    ports:
      - 5005:5005
    volumes:
      - ./app:/app

然后使用 docker-compose up -d 来启动应用。

当应用启动完毕之后,还是访问相同的浏览器地址,你将看到类似下面的界面:

Flare 默认界面

应用会在启动目录的 app 文件夹中生成默认的示例数据,方便你参考修改,数据文件格式为 yaml,如果你不熟悉也没关系,参考文件内的内容格式进行调整,保证缩进一致即可。

Flare 的数据文件示例

当你编辑完 app/bookmarkd.ymlapp/apps.yml 两个文件后,刷新浏览器,你的修改就生效了,不必进行应用重启。

其他

Flare 目前还处于比较早期的阶段,不过对于个人使用而言,或许已经足够了,和 Flame 一样漂亮的界面,更高效的资源使用,没有迁移负担的数据格式。

接下来,我会在慢慢更新这个小工具,在保证数据兼容、性能高效的前提下,慢慢将它的用户体验持续提升,如果你对这个项目感兴趣,或者在使用过程中遇到了问题,可以关注或者在这里反馈:https://github.com/soulteary/docker-flare

至于书签内容的离线管理,我将在后续文章中介绍另外一个工具,先按下不表。

最后

写到这里,两款书签导航软件的使用就介绍完啦。

浏览器书签是众多知识管理方式的其中一种,它和电子书库、电子笔记、桌面文件、云端文档等其他形式的工具一起构建了我们的知识体系。

接下来的文章里,我会逐步分享我在过程中的一些经验。希望能帮助到有同样需求的你。

–EOF