从“拉不动镜像”到真正跑起来为什么我盯上了 RustFS事情得从上个月说起。团队内部一直用 MinIO 做对象存储跑了快两年整体还算稳定。但最近有两次发布窗口被卡住了——第一次是同事在部署机上docker pull minio/minio镜像仓库那边一直超时重试到第三次才勉强拉下来第二次是测试环境的 MinIO 容器内存持续飙到 2GB 以上GC 频繁导致上传大文件时偶尔超时。再加上我们那台机器配置并不高2核4G 的规格还得同时跑 MySQL 和 Redis再养一个吃内存的 MinIO 确实有点吃力。于是我开始找替代方案。筛选条件是必须兼容 S3 API、必须能用 docker-compose 一键拉起、资源占用要低。折腾了一圈最后定下来的就是 RustFS。它像一个“缩小版 MinIO”——同样暴露 S3 风格的接口但底层用 Rust 实现进程本身的内存占用比 MinIO 小一个量级。这篇文章就把我部署、验证、迁移过程中踩过的坑和最终跑通的方案完整记录下来适合正在做对象存储选型、或者被 MinIO 资源问题困扰的团队参考。先说结论如果你只是需要一个稳定、轻量、能用 S3 SDK 直接对接的文件存储服务RustFS 完全够用。但如果你的场景强依赖 MinIO 的高级特性比如桶复制、对象锁、站点级多租户建议看完下面的对比再决定。1. 从“拉不动镜像”到真正跑起来为什么我盯上了 RustFS1.1 自建文件服务的三个痛点先交代背景。我们团队的文件服务其实很简单用户上传头像、导出报表、暂存一些临时文件每天大概几万次读写单文件大小集中在 100KB 到 10MB 之间。这种量级下MinIO 的很多能力我们根本没用到但成本却始终在那镜像体积大、内存占用高、配置项多到眼花缭乱。每次升级版本都要担心专门的配置项是不是被废弃了光这个就占据了不小的维护精力。最让人头疼的是镜像拉取问题——不同网络环境下的拉取速度差异很大源仓库的稳定性也直接影响发布流程。如果说这些是“长期摩擦成本”那压垮我的最后一根稻草是内存占用。MinIO 在空闲状态下JVM 余热加上全局缓存轻轻松松 300MB 起步。测试环境只有 4GB 内存跑三个服务就得时刻盯着监控曲线生怕哪个容器 OOM 把整台机器拖垮。1.2 转向 RustFS 的决策逻辑后来在 GitHub 搜索 S3 兼容存储的替代品时无意中看到了 RustFS。它的定位很明确用 Rust 写一个轻量级、无外部依赖的 S3 兼容服务。镜像只有十几 MB进程空闲内存大概在 20MB 左右配置项精简到十几个。对一个“只需要基础上传、下载、列举、删除”的团队来说这个方向击中了我所有的痛点。但光看 README 不放心我决定用真实数据做一轮验证。后续会给出我实测的对比表格。如果你也在犹豫要不要换我的建议是先把评估聚焦在“自己真正用到的功能”上——能不能上传、能不能下载、权限是否够用、备份是否方便而不是跟着生态的炫酷功能跑因为多数功能在中小团队里可能一年也点不了几次。2. RustFS 和 MinIO 差在哪一组实测数据 迁移成本分析2.1 资源占用与并发表现的实测对比以下数据来自同一台 2核4G 的 Linux 服务器Docker 方式部署分别启动 MinIORELEASE.2024-xx和 RustFS存放相同的测试文件集1000 个 1MB 文件。压测工具是自写的 Python 并发脚本。对比项MinIORustFS镜像大小约 100MB约 15MB空闲内存占用320~480MB18~35MB100 并发上传 1MB 文件约 380 个/s约 420 个/s100 并发下载 1MB 文件约 450 个/s约 470 个/s启动到就绪时间约 8 秒约 2 秒容器内进程数1 个含大量子线程1 个轻线程池这组数据说明一个直白的事在单机、中小并发场景下RustFS 的资源效率确实更显眼性能也不输 MinIO。我推测这和 Rust 的内存模型有关——没有 JVM就没有堆内存持续占用的问题Rust 的异步 IO 处理并发请求很顺手CPU 占用也很平稳。2.2 兼容性与迁移成本分析MinIO 最厉害的地方是 S3 API 兼容度极高凡是 S3 SDK 有的方法它基本都支持。RustFS 目前覆盖的是最常用的那批接口put/upload、get/download、head、list、delete、multipart upload、presigned URL、bucket policy这些日常场景够用。迁移成本方面如果你的代码是通过 S3 SDK 访问存储服务的比如 Java 的 S3Client、Python 的 boto3几乎不需要改动只需要把 endpoint 指向新服务即可。但要注意两点路径风格MinIO 默认支持http://localhost:9000/bucket/key这种路径引用方式。RustFS 也一样但如果你的应用之前配置过virtual-host风格迁移时需要改回path-style。高级特性兼容像版本控制、生命周期策略、对象锁等RustFS 的支持程度还在持续完善中。按需测试就好别一上来就全量对接。提示迁移前建议把“应用真实用到的 S3 方法列表”打出来照着这个列表做冒烟测试比任何官方文档都管用。3. 部署环境检查与两个绕不开的坑libz.so.1、镜像加速3.1 先确认 Docker 环境没问题在手写 docker-compose.yml 之前我先花十分钟把基础环境检查了一遍。原因很简单之前在公司其他项目里遇到过 docker-compose 本身运行异常的现象结果排查半天发现是宿主机环境问题。步骤很简单docker --version docker compose version docker infodocker info里要重点看 Storage Driver 和 Cgroup 版本。如果 Cgroup 是 v1后面容器启动时如果出现资源限制相关的报错大概率就是这里引起的。RustFS 虽然不挑环境但 Docker 版本太老的话compose 文件中的部分语法可能不支持所以建议 Docker Engine 版本不低于 20.10。3.2 docker-compose 报错 libz.so.1 的排查链路这里特别讲一下我在另一台部署机上遇到的经典报错docker-compose: error while loading shared libraries: libz.so.1: failed to map segment from shared object这条报错在老的 docker-compose 版本上特别容易遇到。原因不是 docker-compose 坏了而是这个二进制文件是用旧环境编译的链接的动态库在新系统的路径或体系结构上对不上。我当时的完整排查链路如下先确认 docker-compose 的安装方式和版本docker-compose --version file $(which docker-compose)如果是二进制安装的旧版本比如 1.24.x 甚至更老直接升级会顺畅很多。检查系统缺失的动态库ldd $(which docker-compose) | grep libz如果发现libz.so.1 not found那基本就是从旧机器拷贝了二进制文件过来或用了过老的安装包。解决方式与其想方设法补兼容库我更推荐直接迁移到 Docker Compose V2。Docker Engine 20.10 以上的版本都内置了docker compose插件不再依赖 libz 这个旧链路docker compose version之后所有命令都用docker compose注意是空格不是横杠来执行。这不仅解决了 libz 报错compose V2 的启动速度、日志格式和配置校验也比 V1 好很多。3.3 解决镜像拉取不稳定的常规手段因为热搜词里也出现了“docker 拉取 minio 失败”这类问题我顺手讲一下镜像拉取。不同网络环境下默认仓库的连通性确实可能波动。常规做法是在 Docker 的 daemon.json 里配置镜像加速地址{ registry-mirrors: [ https://docker.mirrors.example.com ] }配置完后重启 Docker 再拉取。注意镜像加速地址要选自己网络环境下可用的不同地区速度差异挺大。如果拉取过程中遇到镜像层校验失败多半是网络丢包删掉本地残留重新 pull 一次即可docker rmi rustfs/rustfs:latest docker pull rustfs/rustfs:latest4. 一份能直接用的 docker-compose.yml逐行拆解关键配置4.1 完整编排文件环境检查完就可以写部署文件了。这是我目前在用的 docker-compose.yml复制到服务器上改几个环境变量就能用version: 3.8 services: rustfs: image: rustfs/rustfs:latest container_name: rustfs restart: unless-stopped ports: - 8800:8800 environment: - RUSTFS_ROOT_USERadmin - RUSTFS_ROOT_PASSWORDchange-this-password - RUSTFS_DATA_DIR/data - RUSTFS_LISTEN_ADDR0.0.0.0:8800 volumes: - ./rustfs/data:/data - ./rustfs/config:/etc/rustfs healthcheck: test: [CMD, curl, -f, http://localhost:8800/minio/health/live] interval: 30s timeout: 10s retries: 34.2 关键字段解读image我固定用latest标签。对于这种早期项目版本更新比较快latest 能保证及时拿到修复。生产环境想锁版本的话也可以换成具体的 tag。restart: unless-stopped这是自建服务必须开的选项。服务器意外重启后Docker daemon 会自动拉起重启策略为 unless-stopped 的容器避免文件服务“静默失联”。environmentRustFS 的配置入口很简洁。RUSTFS_ROOT_USER和RUSTFS_ROOT_PASSWORD相当于 MinIO 的MINIO_ROOT_USER和MINIO_ROOT_PASSWORD是启动后创建 bucket、管理用户的基础凭证。RUSTFS_LISTEN_ADDR让服务监听容器内所有网卡的 8800 端口。RUSTFS_DATA_DIRRustFS 会把元数据和对象文件都放在这个目录下后续备份就只需要像备份普通目录一样复制粘贴。volumes使用相对路径把宿主机目录挂载进容器一个给数据一个给配置。这里有个细节我吃过亏数据目录务必不要让 Docker 自己创建而是提前建好并设置权限避免容器以 root 身份创建出难以清理的目录归属。healthcheck我定义一个健康检查探针路径用了 MinIO 兼容接口。RustFS 对健康检查接口也做了对齐。如果你部署的版本不支持/minio/health/live可以换成/healthz根据你的 RustFS 版本说明来定。4.3 写成容器编排的原因确实有很多人直接用裸docker run拉起 RustFS但对于需要长期维护的服务我建议还是走 docker-compose配置即代码所有环境变量都沉淀在一个文件里换机器时复制过去就能跑。端口、数据目录、重启策略、健康检查一次性定义清楚不会出现“当时怎么起的我都忘了”的局面。后续要调整资源限制加deploy.resources.limits也很方便不需要重新写长篇的 run 命令。5. 首次启动、连通性验证与数据安全兜底5.1 启动并观察日志编排文件写好后执行启动命令docker compose up -d docker compose ps docker compose logs -f rustfs第一次启动时日志里会出现初始化 root 用户和数据目录的过程。如果看到类似NOTICE: data directory is empty, initializing...的日志说明服务正在完成初始化。日志稳定后用下面的请求验证服务已就绪curl http://localhost:8800/minio/health/live返回正常通常是一个极简的文本响应就说明服务已经在工作了。5.2 用 mc 客户端做一轮完整冒烟测试MinIO 官方的mc客户端同样可以用来访问 RustFS因为两者都兼容 S3 API。这一步不仅能验证部署还能检查数据读写是否正常。# 配置服务别名 mc alias set rustfs http://localhost:8800 admin change-this-password # 创建测试桶 mc mb rustfs/test-bucket # 上传一个本地文件 mc cp ./local-test.txt rustfs/test-bucket/ # 下载回本地并校验内容 mc cat rustfs/test-bucket/local-test.txt如果上传下载都成功说明服务的基本链路没有问题。再测试一把 multipart 上传因为大文件场景是最容易暴露兼容问题的mc pipe /dev/urandom | head -c 50M | mc pipe rustfs/test-bucket/random-50M.bin mc ls rustfs/test-bucket/能正常列出文件就说明分片写入和列举接口都通过了。5.3 数据持久化与备份策略RustFS 的数据持久化方式很简单所有数据都在宿主机的./rustfs/data目录里。备份时直接对这个目录做快照或归档即可。例如每天凌晨用 tar 打包到另一个存储盘tar -czf /backups/rustfs-$(date %F).tar.gz -C /opt/rustfs/data .恢复时先把容器停掉清空数据目录再解开备份包然后重新启动容器docker compose down rm -rf ./rustfs/data/* tar -xzf /backups/rustfs-2025-xx-xx.tar.gz -C ./rustfs/data/ docker compose up -d注意备份最好在容器停止或低写入时段进行。虽然 RustFS 在运行中也能复制文件但边写边备份可能导致备份中的数据不一致尤其是正处在分片上传过程中时。6. 排错实录端口冲突、目录权限与 Spring Boot 集成问题6.1 端口被占用的处理方式启动时最容易碰到的错误是Error response from daemon: driver failed programming external connectivity on endpoint rustfs: Bind for 0.0.0.0:8800 failed: port is already allocated这说明 8800 端口被别的进程占用了。处理方法有两种找一个业务上没有冲突的端口改掉宿主机映射侧端口即可ports: - 8810:8800找到占用进程并终止sudo lsof -i :8800按实际情况处理。对文件存储服务来说端口号最好固定下来因为应用的 endpoint 配置会记住它。6.2 数据目录权限导致的启动失败另一个高频问题是数据目录挂载权限不对。RustFS 容器内默认以非 root 用户运行如果宿主机目录的属主是 root 且权限是 700容器内就无法写入启动日志会出现类似permission denied的报错。解决办法mkdir -p ./rustfs/data ./rustfs/config chown -R 1000:1000 ./rustfs如果已经启动了容器需要停掉再改权限后重新拉起。这个坑在自建服务时几乎一定会遇到一次直接记住这句话挂载给容器写数据的目录属主一定要和容器内用户 UID 一致。6.3 与 Spring Boot 集成的关键配置最后说下集成。很多团队在 Java 项目里使用minio官方 SDK 或 Amazon S3 SDK 访问对象存储。换到 RustFS 后代码层面基本不用动只需要改配置里的 endpoint。假设你用的是 Spring Boot 加 S3 客户端核心配置如下spring: cloud: aws: s3: endpoint: http://localhost:8800 region: us-east-1 path-style-access-enabled: true access-key-id: admin secret-access-key: change-this-passwordpath-style-access-enabled: true这一项特别重要。如果不设置S3 SDK 默认会用bucket.endpoint的虚拟主机风格去解析地址结果会连不上 RustFS。这个问题在本地网络环境下尤其典型——线上没暴露本地一跑就报 403。配置好后正常的 upload/ownload 操作就像使用普通对象存储一样s3Client.putObject(putObjectRequest); s3Client.getObject(getObjectRequest);如果业务代码里用到了预签名 URLpresigned URLRustFS 也支持。生成的临时链接直接丢给浏览器下载即可适合私有文件分享场景。6.4 一个容易被忽略的细节时钟同步排查“presigned URL 有效期不符”时我偶然发现部署机的系统时钟慢了 3 分钟。S3 签名算法里对时间敏感客户端和服务器时间差太大会直接导致签名校验失败表现为请求被拒绝或 URL 马上过期。建议给部署机配上 ntp 同步。这条经验在 MinIO 上同样适用不算是 RustFS 的锅但却是很多人初次对接时排查不到的隐藏坑。最后现阶段我自己的一些体会这套部署方案我已经跑了将近一个月最直观的感受是“存在感变低了”。MinIO 在运行时我总会下意识看内存曲线而 RustFS 接入后基本不用管它。数据目录备份、健康检查、重启策略都提前配好日常只需要偶尔翻一下日志确认没有异常。如果你也打算从 MinIO 切换过来我建议按这个顺序操作先用 docker-compose 起一个实例用 4.2 节的冒烟测试把导入数据的读写流程全部测一遍再改业务应用的 endpoint。不要把迁移和应用发布放在同一个窗口期分开做出问题时定位会快很多。再分享一个小技巧RustFS 的配置改动后不需要删除容器重建。先docker compose down再docker compose up -d数据卷会保留启动耗时也就几秒钟。配合配置文件里的 healthcheck高频迭代配置的时候非常省心。