一台 8 核 16G 的 GitLab 机器CI 跑完的制品默认落在本机/var/opt/gitlab/gitlab-rails/shared/artifacts。我见过最离谱的一次团队一天 400 多条流水线半个月后磁盘三度写满运维半夜起来gitlab-ctl reconfigure清目录。问题的根子不在 GitLab而在于「产物堆本地盘」这个默认行为——它把存储压力和单台机器绑死了。GitLab 从 10.x 起就支持把这类数据甩给外部对象存储。关键是它走的是标准 S3 协议只要端点是 S3 兼容的换一家后端基本只改配置。RustFS 100% 兼容 S3 API又有 OIDC 单点登录能力把它接成 GitLab 的对象存储加控制台身份源是一条很顺的路。下面按我实际验证过的步骤走一遍。一、GitLab 到底能往对象存储塞什么不是只有 CI 产物。以下这些数据类型GitLab 都能配置到外部 S3 后端八类数据配置项都是gitlab.rb里独立的xxx_object_store_*开关。想全接就全接只想把最占空间的 CI 产物挪出去也行。二、把 RustFS 配成 GitLab 的 S3 后端先在 RustFS 侧建两个桶比如gitlab-artifacts和gitlab-lfs。然后改 GitLab 的/etc/gitlab/gitlab.rbgitlab_rails[object_store][enabled]truegitlab_rails[object_store][proxy_download]truegitlab_rails[object_store][connection]{providerAWS,aws_access_key_idrustfsadmin,aws_secret_access_keyrustfsadmin,endpointhttps://rustfs.example.com,regionus-east-1,path_styletrue}gitlab_rails[artifacts_object_store_enabled]truegitlab_rails[artifacts_object_store_remote_directory]gitlab-artifactsgitlab_rails[lfs_object_store_enabled]truegitlab_rails[lfs_object_store_remote_directory]gitlab-lfsendpoint指向你的 RustFS 地址provider填AWS走 Signature V4。有一个坑要提前说path_style必须设成true。GitLab 默认用虚拟主机式寻址bucket.endpoint/key而 RustFS 走路径式寻址endpoint/bucket/key不开 path_styleGitLab 上传会一直报找不到桶。改完跑sudogitlab-ctl reconfigure验证最简单的方法开一条最小流水线推一个带artifacts的 job再去看 RustFS 桶里有没有落到对象。别急着迁存量——下面会说为什么。三、让 GitLab 用户用 GitLab 账号登录 RustFS 控制台光有存储还不够。如果你的团队已经在用 GitLab 做统一身份可以让 GitLab 充当 OIDC 身份源RustFS 控制台直接用 GitLab 账号登录不用再维护一套 RustFS 本地账号。先在 GitLab 的 Admin Area → Applications → New application 建一个应用NameRustFS OIDCRedirect URIhttps://rustfs.example.com/rustfs/admin/v3/oidc/callback/default勾选Confidential和TrustedScopes 选openid、profile、email保存后拿到 Application ID 和 Secret。然后在 RustFS 的环境文件里加上RUSTFS_IDENTITY_OPENID_ENABLEonRUSTFS_IDENTITY_OPENID_CONFIG_URLhttps://gitlab.example.comRUSTFS_IDENTITY_OPENID_CLIENT_IDapplication-idRUSTFS_IDENTITY_OPENID_CLIENT_SECRETapplication-secretRUSTFS_IDENTITY_OPENID_SCOPESopenid,profile,emailRUSTFS_IDENTITY_OPENID_REDIRECT_URIhttps://rustfs.example.com/rustfs/admin/v3/oidc/callback/defaultRUSTFS_IDENTITY_OPENID_DISPLAY_NAMEGitLabRUSTFS_IDENTITY_OPENID_EMAIL_CLAIMemailRUSTFS_IDENTITY_OPENID_USERNAME_CLAIMpreferred_usernameRUSTFS_IDENTITY_OPENID_ROLE_POLICYconsoleAdmin重启 RustFS 后控制台登录页会出现 GitLab 按钮。整个登录链路长这样校验环节很关键别跳过。先看 GitLab 的发现文档通不通curl-fsShttps://gitlab.example.com/.well-known/openid-configuration\|jq{ issuer, authorization_endpoint, token_endpoint, jwks_uri }再确认 RustFS 侧能看到这个 providercurl-fsShttps://rustfs.example.com/rustfs/admin/v3/oidc/providers|jq两个都返回预期字段再点登录按钮实测一遍。四、几个会咬人的坑集成不难难在边界。我列几个实测和官方排障文档里反复出现的点ROLE_POLICY默认consoleAdmin太宽。这个变量给所有走 GitLab 登录的人发同一个策略。生产环境换成只含所需权限的自定义策略别把整个集群的管理权让出去。存量本地产物不会自动搬家。开启对象存储后之前堆在/var/opt/gitlab/.../artifacts的文件不会自己迁过去新的才落桶。要迁得另写同步脚本且要停写窗口别指望开关一开就万事大吉。HTTPS 生产必开。OIDC 回调、S3 凭证和 token 全程走网络明文部署等于把密钥摊在公网上。GitLab 对对象存储有隐性预期。比如部分功能依赖桶版本化、特定的列举一致性。上线前对着 GitLab 官方「object storage」文档把每一项特性核对一遍别只看 CI 产物能传就认为全通了。RustFS 目前还是 BetaGA 预计 2026 年 9 月。承载生产 CI 之前先在开发、测试环境跑你自己的真实负载基准尤其看写入吞吐和列举延迟是否够用。五、先做什么如果你正被本地盘写满困扰今晚就能动手验证用 Docker 起一个 RustFS 单节点建gitlab-artifacts、gitlab-lfs两个桶在gitlab.rb里只开artifacts_object_storeendpoint指过去path_style设true推一条最小流水线确认产物落到 RustFS 桶跑通后再逐步把 LFS、packages、uploads 等其它类型切过去最后再接 OIDC把ROLE_POLICY收敛成最小权限策略。对象存储后端换成 S3 兼容的 RustFS 之后GitLab 的存储压力不再绑死在单台机器上扩容就是加盘或加节点的事。RustFS 本身是 Apache 2.0、用 Rust 写的分布式对象存储对写入密集的 CI 产物场景比较友好仓库在 https://github.com/rustfs/rustfs 想深究可以直接翻代码和 issue。以下是深入学习 RustFS 的推荐资源RustFS官方文档 RustFS 官方文档- 提供架构、安装指南和 API 参考。GitHub 仓库 GitHub 仓库 - 获取源代码、提交问题或贡献代码。社区支持 GitHub Discussions- 与开发者交流经验和解决方案。意见反馈GitHub Issues