Dockyard 是更快的 Lazydocker，用 Rust 编写（因为当然是）
Source: Dev.to
我在使用 Lazy Docker 时感到非常满意。它能工作，稳定可靠，恰好完成了 Docker TUI 应该具备的所有功能。
随后，在摄入了大量咖啡因之后，我产生了一个没人需要我拥有的想法：
“如果用 Rust 来编写会更好。”
当时并没有需要解决的问题，也没有未满足的需求，更没有用户请求。但我还是照做了。
这就是 Dockyard。
没有人遇到的问题
Lazy Docker 是一个很好的工具，但如果你盯着它看得够久，就会说服自己它存在一些问题：
- 它是用 Go 编写的
- 冷启动大约需要 247 ms
- 它可能使用约 40 MB 的内存
- 二进制文件大小为 13 MB
这些都不算坏事，也并不重要。我仍然选择在意。
Dockyard
在与 borrow checker 争论了三周后，我得到了 Dockyard：一个 Docker 容器管理器，功能大约相当于 Lazy Docker 的 80 %，但它是用 Rust 编写的，启动速度明显更快。
启动时间
| 工具 | 冷启动 | 热启动 |
|---|---|---|
| Lazy Docker | ~247 ms | ~89 ms |
| Dockyard | ~31 ms | ~12 ms |
Dockyard 启动得足够快，以至于你会短暂怀疑它到底有没有真的做任何事。
实际影响：如果你一年每天打开 Docker TUI 十次，你大约可以节省 43 秒。这不足以改变你的生活，但感觉还是挺对的。
内存使用
- Lazy Docker: ~38–41 MB
- Dockyard: ~6–8 MB
大约 82 % 的降低。对现代机器来说意义不大，但我仍然会在有机会时提到它。
二进制大小
- Lazy Docker: ~13 MB
- Dockyard: ~2.7 MB（已剥离）
你的磁盘空间很大，所以这并不重要——但我花了三天时间让它变得重要。
确实重要的开发指标
| 指标 | Lazy Docker | Dockyard |
|---|---|---|
| 第一次成功构建的时间 | 几分钟 | 三周 |
| 生命周期注解写入的行数 | 0 | 847 |
| 随意提及 Rust 的能力 | 没有 | 过多 |
| 生活质量决策 | 合理 | 可疑 |
Dockyard 实际做的事情
- 列出容器、镜像和卷
- 启动、停止并删除容器
- 拉取并删除镜像
- 使用 bollard 直接与 Docker API 通信
- 启动快速，体积小巧，干净退出
- 在没有垃圾回收器的情况下实现内存安全
- 即使在未使用线程的情况下也保持线程安全
- 对尚未拥有的并发保持无畏
它目前还不具备的功能
- 指标图表
- 高级调试工具
- 除我之外的用户
Lazy Docker 对大多数人仍然是更好的工具。Dockyard 更快、更小，但功能不够完整。这些取舍是有意为之。Dockyard 的安装过程本身就提醒你已经选择了这条路。
为什么我真的构建了它
我最初用 Python 编写了一个 Docker TUI 供个人使用。随后我把它部署在一台小型 VPS 上，并决定学习 Rust 会比优化 Python 更容易。这个想法不太对，但却很有教育意义。
我学到了：
- 异步 Rust
- Docker API 的整体结构
- 终端 UI 布局
- Docker 暴露了令人惊讶的多种时间戳格式
我还发现，削减启动时间的毫秒数是一种极其有效的多巴胺来源。Dockyard 的存在是因为我想从头到尾理解这个问题，而不是因为生态系统需要另一个工具。
结论
Dockyard 比 Lazy Docker 更好吗？
不。
它更快吗？
是的，只是你可能感觉不到。
你应该使用它吗？
如果你喜欢小巧、快速的二进制文件，以及由过于用心的人写的 Rust 代码，或许可以。
这三周的投入值得吗？
客观来说，不。
我会再做一次吗？
可能会。