gitlab lfs 大文件对象存储

Question

gitlab 配置对象存储 使用的是移动云的云产品，gitlab 版本为：16.9.5

对象存储配置如下

gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
'provider' => 'AWS',
'aws_access_key_id' => '', # AccessKey
'aws_secret_access_key' => '', # SecretKey
'region' => 'huhehaote1',
'endpoint' => 'https://eos-huhehaote-1.cmecloud.cn',
'path_style' => true,
'force_path_style' => true,
'connect_timeout' => 600,
'read_timeout' => 600,
'write_timeout' => 600,
'retry_limit' => 5,
'http_open_timeout' => 300,
'http_read_timeout' => 300
}

配置 Uploads（附件）使用对象存
gitlab_rails['uploads_object_store_enabled'] = true
gitlab_rails['uploads_object_store_remote_directory'] = 'gitlab-uploads'
gitlab_rails['lfs_object_store_proxy_download'] = false # 直接从对象存储下载

配置 LFS 使用对象存储
gitlab_rails['lfs_object_store_enabled'] = true
gitlab_rails['lfs_object_store_remote_directory'] = 'gitlab-lfs'
gitlab_rails['uploads_object_store_proxy_download'] = false # 直接从对象存储下载

报错如下：

* sidekiq['max_concurrency'] has been deprecated since 16.9 and will be removed in 17.0. Starting with GitLab 17.0, `sidekiq['max_concurrency']` will be removed. Please follow https://docs.gitlab.com/ee/administration/sidekiq/extra_sidekiq_processes.html#manage-thread-counts-explicitly to use `sidekiq['concurrency']` instead.

[2025-11-18T08:14:44+00:00] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/cinc-stacktrace.out
[2025-11-18T08:14:44+00:00] FATAL: --------------------------------------------------------------------------------
[2025-11-18T08:14:44+00:00] FATAL: PLEASE PROVIDE THE CONTENTS OF THE stacktrace.out FILE (above) IF YOU FILE A BUG REPORT
[2025-11-18T08:14:44+00:00] FATAL: --------------------------------------------------------------------------------
[2025-11-18T08:14:44+00:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: execute[clear the gitlab-rails cache] (gitlab::gitlab-rails line 562) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /opt/gitlab/bin/gitlab-rake cache:clear ----
STDOUT:
STDERR: rake aborted!
GitlabSettings::MissingSetting: option 'provider' not defined
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab_settings/options.rb:159:in `method_missing'
/opt/gitlab/embedded/service/gitlab-rails/config/initializers/direct_upload_support.rb:16:in `verify!'
/opt/gitlab/embedded/service/gitlab-rails/config/initializers/direct_upload_support.rb:45:in `block (2 levels) in <top (required)>'
/opt/gitlab/embedded/service/gitlab-rails/config/initializers/direct_upload_support.rb:44:in `each'
/opt/gitlab/embedded/service/gitlab-rails/config/initializers/direct_upload_support.rb:44:in `block in <top (required)>'
<internal:kernel>:90:in `tap'
/opt/gitlab/embedded/service/gitlab-rails/config/initializers/direct_upload_support.rb:37:in `<top (required)>'
/opt/gitlab/embedded/service/gitlab-rails/config/environment.rb:7:in `<top (required)>'
<internal:/opt/gitlab/embedded/lib/ruby/site_ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
<internal:/opt/gitlab/embedded/lib/ruby/site_ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
/opt/gitlab/embedded/bin/bundle:25:in `load'
/opt/gitlab/embedded/bin/bundle:25:in `<main>'
Tasks: TOP => cache:clear => cache:clear:redis => environment
(See full trace by running task with --trace)
---- End output of /opt/gitlab/bin/gitlab-rake cache:clear ----
Ran /opt/gitlab/bin/gitlab-rake cache:clear returned 1

Running handlers:
[2025-11-18T08:14:44+00:00] ERROR: Running exception handlers
There was an error running gitlab-ctl reconfigure:

execute[clear the gitlab-rails cache] (gitlab::gitlab-rails line 562) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /opt/gitlab/bin/gitlab-rake cache:clear ----
STDOUT:
STDERR: rake aborted!
GitlabSettings::MissingSetting: option 'provider' not defined
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab_settings/options.rb:159:in `method_missing'
/opt/gitlab/embedded/service/gitlab-rails/config/initializers/direct_upload_support.rb:16:in `verify!'
/opt/gitlab/embedded/service/gitlab-rails/config/initializers/direct_upload_support.rb:45:in `block (2 levels) in <top (required)>'
/opt/gitlab/embedded/service/gitlab-rails/config/initializers/direct_upload_support.rb:44:in `each'
/opt/gitlab/embedded/service/gitlab-rails/config/initializers/direct_upload_support.rb:44:in `block in <top (required)>'
<internal:kernel>:90:in `tap'
/opt/gitlab/embedded/service/gitlab-rails/config/initializers/direct_upload_support.rb:37:in `<top (required)>'
/opt/gitlab/embedded/service/gitlab-rails/config/environment.rb:7:in `<top (required)>'
<internal:/opt/gitlab/embedded/lib/ruby/site_ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
<internal:/opt/gitlab/embedded/lib/ruby/site_ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:37:in `require'
/opt/gitlab/embedded/bin/bundle:25:in `load'
/opt/gitlab/embedded/bin/bundle:25:in `<main>'
Tasks: TOP => cache:clear => cache:clear:redis => environment
(See full trace by running task with --trace)
---- End output of /opt/gitlab/bin/gitlab-rake cache:clear ----
Ran /opt/gitlab/bin/gitlab-rake cache:clear returned 1

执行gitlab-ctl reconfigure时失败，根源是 GitLab 对象存储配置中缺少 “provider”（对象存储服务商类型）的定义，导致缓存清理任务执行异常。

请问各位有啥好解决办法吗

Answer 1

上午好☀️☀️☀️️
本答案参考通义千问

你遇到的错误信息是：

GitlabSettings::MissingSetting: option 'provider' not defined

这表明 GitLab 在初始化时尝试访问一个未定义的配置项 provider，而该配置项在你的对象存储配置中没有被正确设置。这个错误通常出现在 LFS 或上传对象存储的配置不完整或格式不正确 的情况下。

---

✅ 问题分析

1. 配置项缺失

你在配置 LFS 和 Uploads 对象存储时，只设置了 object_store 的连接参数，但没有为 lfs_object_store 和 uploads_object_store 设置对应的 provider 字段。

GitLab 要求每个对象存储（如 LFS、Uploads）都需要明确指定其 provider 类型，即使它们使用的是相同的 AWS 兼容服务。

---

✅ 解决方案

第一步：确保所有对象存储配置都包含 provider 字段

你需要为以下两个部分添加 provider 配置：

• gitlab_rails['lfs_object_store']
• gitlab_rails['uploads_object_store']

第二步：修改 GitLab 配置文件（通常是 /etc/gitlab/gitlab.rb）

以下是完整的配置示例，包括所有必要的字段：

# 启用对象存储
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'aws_access_key_id' => 'your-access-key-id', # 替换为实际 AccessKey
  'aws_secret_access_key' => 'your-secret-access-key', # 替换为实际 SecretKey
  'region' => 'huhehaote1',
  'endpoint' => 'https://eos-huhehaote-1.cmecloud.cn',
  'path_style' => true,
  'force_path_style' => true,
  'connect_timeout' => 600,
  'read_timeout' => 600,
  'write_timeout' => 600,
  'retry_limit' => 5,
  'http_open_timeout' => 300,
  'http_read_timeout' => 300
}

# 配置 uploads 使用对象存储
gitlab_rails['uploads_object_store_enabled'] = true
gitlab_rails['uploads_object_store_remote_directory'] = 'gitlab-uploads'
gitlab_rails['uploads_object_store'] = {
  'provider' => 'AWS',
  'aws_access_key_id' => 'your-access-key-id',
  'aws_secret_access_key' => 'your-secret-access-key',
  'region' => 'huhehaote1',
  'endpoint' => 'https://eos-huhehaote-1.cmecloud.cn',
  'path_style' => true,
  'force_path_style' => true
}
gitlab_rails['uploads_object_store_proxy_download'] = false

# 配置 LFS 使用对象存储
gitlab_rails['lfs_object_store_enabled'] = true
gitlab_rails['lfs_object_store_remote_directory'] = 'gitlab-lfs'
gitlab_rails['lfs_object_store'] = {
  'provider' => 'AWS',
  'aws_access_key_id' => 'your-access-key-id',
  'aws_secret_access_key' => 'your-secret-access-key',
  'region' => 'huhehaote1',
  'endpoint' => 'https://eos-huhehaote-1.cmecloud.cn',
  'path_style' => true,
  'force_path_style' => true
}
gitlab_rails['lfs_object_store_proxy_download'] = false

⚠️ 注意：请务必将 your-access-key-id 和 your-secret-access-key 替换为真实的 AccessKey 和 SecretKey。

---

✅ 第三步：重新配置 GitLab

执行以下命令使配置生效：

sudo gitlab-ctl reconfigure

---

✅ 第四步：验证配置是否成功

你可以通过以下方式验证：

1. 查看日志：

   sudo tail -f /var/log/gitlab/gitlab-rails/production.log
   

2. 检查对象存储是否可用：

   • 登录 GitLab 管理后台，进入 Admin > Settings > Repository。
   • 查看 Object storage 部分是否有提示“Connected to object storage”。

---

✅ 可能的其他问题排查

| 问题 | 原因 | 解决方案 | |------|------|----------| | option 'provider' not defined | 没有为 LFS 或 uploads 设置 provider | 按照上述步骤补充配置 | | Connection refused | Endpoint 或网络配置错误 | 检查防火墙、DNS 解析、Endpoint 地址是否正确 | | Access Denied | AccessKey 或 SecretKey 错误 | 检查密钥有效性 |

---

✅ 总结

关键点如下：

1. 必须为 LFS 和 uploads 对象存储分别配置 provider 字段。
2. 确保所有字段与主对象存储配置一致，尤其是 aws_access_key_id 和 aws_secret_access_key。
3. 重新运行 gitlab-ctl reconfigure 以应用更改。
4. 检查日志确认配置是否成功加载。

如果你还有其他报错，请提供完整的日志内容，我可以进一步帮助你定位问题。