在云原生和 AI 训练场景里，对象存储几乎是基础设施的"水电煤"——从镜像分发、模型权重到训练数据集，都离不开一个兼容 S3 协议、又能扛住高吞吐的存储服务。MinIO 一直是这个领域的明星，但如果你想要一个用 Rust 重写、内存占用更低、启动更快、原生支持多盘纠删码的替代品，RustFS 是一个值得重点关注的新选择。
本文基于一份可直接落地的 docker-compose.yml，完整演示 RustFS 单节点 4 盘部署：从快速启动、访问验证，到存储持久化、配置项解读、S3 客户端对接，再到生产环境加固，一次讲清楚。
在前两篇 bazel-remote 系列文章里，我们对比了 S3 后端与一致性哈希两种横向扩展方案，也给出过"分层缓存（L1 + L2）是最佳实践"的结论。但那个结论停留在架构层面——具体怎么配？数据到底怎么流动？性能如何保障？
本文就把这个"最佳实践"落到地面：剖析 bazel-remote 原生两级存储的工作原理，并给出可直接套用的命令行与 YAML 配置。
在上一篇《bazel-remote 多实例部署：两种横向扩展方案与性能对比》中，我们梳理了共享云存储与负载均衡+一致性哈希两种横向扩展思路。但留下了一个关键问题：当 S3 后端（这里用 RustFS）与 bazel-remote 部署在同一高速网络时，两种方案的延迟差距还大吗？
本文就聚焦这个真实场景，给出量化的延迟对比与选型建议。
从零开始部署 RustFS 高可用对象存储集群的全流程指南，涵盖架构设计、JBOD 磁盘配置、负载均衡、扩缩容操作及性能规划。
在分布式对象存储领域，MinIO 曾是许多团队的首选，但其 AGPL 协议对商业应用不太友好，且官方仓库已于 2026 年 2 月进入维护模式。在此背景下，RustFS 凭借 Apache-2.0 协议和卓越的性能表现，成为备受关注的新选择。
在开源代码托管平台的选择上，Gitea 凭借轻量、易部署的特性，一直是很多开发团队的首选。但近两年来，Forgejo 的出现和崛起，给这个领域带来了新的变量。
Gitea 和 Forgejo 到底是什么关系？它们的 CI/CD 能力有何差异？如何基于它们搭建现代化的 DevOps 流水线？又能否将 Kubernetes 作为 CI/CD 的执行环境？
这篇文章将基于我们团队的调研和实践，一次性讲清楚这些问题。
解决
libsubid.so.5缺失错误，并升级到最新版本的全过程记录。
在 Debian 12 (bookworm) 上执行 buildah -v 时遇到以下错误：
buildah: error while loading shared libraries: libsubid.so.5: cannot open shared object file: No such file or directory
用 ldd 检查依赖后发现三个缺失项：
| 缺失的库 | 原因 |
|---|---|
libsubid.so.5 |
Debian 12 只有旧版本，不兼容 |
libgpgme.so.45 |
Debian 12 只有 libgpgme.so.11 |
GLIBC_2.38 |
Debian 12 的 GLIBC 版本是 2.36 |
/usr/bin/buildah 二进制文件被替换成了针对较新系统（如 Debian 13/trixie 或 Ubuntu 24.04）编译的版本，与当前 Debian 12 系统不兼容。
在 Jenkins 容器中使用 buildah push 推送镜像时，设置登录认证主要有三种方式。将凭证硬编码在命令里会带来严重的安全风险，因此在实际的 CI/CD 实践中，更推荐采用"登录 (Login) + 配置文件 (Authfile)“的方式。
你有没有遇到过这种情况——凌晨 3 点，用户在群里反馈服务挂了，而你这边一个告警都没有？Prometheus 的 Alertmanager 安静如鸡，因为"没有流量就没有错误"。等客户把电话打到老板那里，你才知道负载均衡器早就挂了。
飞书文档和本地笔记能否打通？数据散落在飞书、Obsidian 各个平台，每个都是孤岛——想找一篇半年前写的东西，得在四个后台翻十分钟。
本文介绍 feishu-cli（
riba2534/feishu-cli），一个把飞书开放平台封装为命令行工具的开源项目，让内容在飞书和 Obsidian 之间双向流动。
「用心若镜，不将不迎，应而不藏，故能胜物而不伤。」 ——《庄子·应帝王》
心若能如明镜止水，物来则照，物去则空，不执着于过往，不期盼于未来，便可在纷繁世事中游刃有余而不被其所伤。