使用 Docker 搭建适用于 HomeLab 的书签导航应用

2024-04-02 19:55

短信预约 -IT技能 免费直播动态提醒

写在前面

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

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

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

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

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

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

在容器中使用 Flame

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

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

它的使用方式很简单，将下面的内容保存为 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 就能看到软件的默认界面啦。

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

这个项目地址在这里： 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， 一个轻量的、适合私有化部署，个人使用的导航工具 。

相比较 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 来启动应用。

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