在使用新私有化部署的书签导航应用一个月之后，我们来聊聊书签导航工具，以及介绍如何使用 Docker 在几分钟之内部署属于你自己的书签导航应用。
写在前面
我目前使用的书签导航工具的界面是这样的（马赛克掉了一部分链接内容）：
作为一个使用了十多年 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。
至于书签内容的离线管理，我将在后续文章中介绍另外一个工具，先按下不表。
最后
写到这里，两款书签导航软件的使用就介绍完啦。
浏览器书签是众多知识管理方式的其中一种，它和电子书库、电子笔记、桌面文件、云端文档等其他形式的工具一起构建了我们的知识体系。
接下来的文章里，我会逐步分享我在过程中的一些经验。希望能帮助到有同样需求的你。
–EOF