写在前面
我目前使用的书签导航工具的界面是这样的（马赛克掉了一部分链接内容）：
作为一个使用了十多年 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 来启动应用。
当应用启动完毕之后，还是访问相同的浏览器地址，你将看到类似下面的界面：
应用会在启动目录的 app 文件夹中生成默认的示例数据，方便你参考修改，数据文件格式为 yaml ，如果你不熟悉也没关系，参考文件内的内容格式进行调整，保证缩进一致即可。
当你编辑完 app/bookmarkd.yml 和 app/apps.yml 两个文件后，刷新浏览器，你的修改就生效了，不必进行应用重启。
其他
Flare 目前还处于比较早期的阶段，不过对于个人使用而言，或许已经足够了，和 Flame 一样漂亮的界面，更高效的资源使用，没有迁移负担的数据格式。
接下来，我会在慢慢更新这个小工具，在保证数据兼容、性能高效的前提下，慢慢将它的用户体验持续提升，如果你对这个项目感兴趣，或者在使用过程中遇到了问题，可以关注或者在这里反馈： https://github.com/soulteary/docker-flare 。
至于书签内容的离线管理，我将在后续文章中介绍另外一个工具，先按下不表。
最后
写到这里，两款书签导航软件的使用就介绍完啦。
浏览器书签是众多知识管理方式的其中一种，它和电子书库、电子笔记、桌面文件、云端文档等其他形式的工具一起构建了我们的知识体系。
接下来的文章里，我会逐步分享我在过程中的一些经验。希望能帮助到有同样需求的你。
到此这篇关于使用 Docker 搭建适用于 HomeLab 的书签导航的文章就介绍到这了,更多相关Docker 搭建HomeLab 书签导航内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网！
