gitlab对象存储

Question

gitlab是通过k8s部署起来的，通过svc暴露服务
gitlab配置如下

#external_url 'http://192.168.10.11'
 gitlab_rails['lfs_enabled'] = true
 gitlab_rails['lfs_object_store_enabled'] = true
 gitlab_rails['lfs_object_store_proxy_download'] = false
 gitlab_rails['lfs_object_store_remote_directory'] = "gitlab-lfs"
 gitlab_rails['lfs_object_store_connection'] = {
   'provider' => 'AWS',
   'region' => 'huhehaote1',
   'aws_access_key_id' => 'xx',
   'aws_secret_access_key' => 'xx',
   'endpoint' => 'eos-huhehaote-1.cmecloud.cn',
   'force_path_style' => true
 }


### GitLab uploads
 gitlab_rails['uploads_object_store_enabled'] = true
 gitlab_rails['uploads_object_store_proxy_download'] = false
 gitlab_rails['uploads_object_store_remote_directory'] = "gitlab-uploads"
 gitlab_rails['uploads_object_store_connection'] = {
   'provider' => 'AWS',
   'region' => 'huhehaote1',
   'aws_access_key_id' => 'xx',
   'aws_secret_access_key' => 'xx',
   'endpoint' => 'eos-huhehaote-1.cmecloud.cn',
   'force_path_style' => true
 }

测试结果如下

Loading production environment (Rails 7.0.8)
irb(main):001:1* lfs_connection = Aws::S3::Client.new(
irb(main):002:1*   access_key_id:     'xx',
irb(main):003:1*   secret_access_key: 'xx',
irb(main):004:1*   region:            'huhehaote',
irb(main):005:1*   endpoint:          'https://eos-huhehaote-1.cmecloud.cn',
irb(main):006:0>   force_path_style:  true )
=> #<Aws::S3::Client>
irb(main):007:0> s3_resource = Aws::S3::Resource.new(client: lfs_connection)
=> #<Aws::S3::Resource:0x00007efdfb2b8b58 @client=#<Aws::S3::Client>>
irb(main):008:0> bucket = s3_resource.bucket('gitlab-lfs')
irb(main):009:0> puts bucket.exists?
true
=> nil
irb(main):010:0> # 上传文件
=> nil
irb(main):011:0> bucket.object('test.txt').put(body: '测试内容')
irb(main):012:0* # 下载文件
irb(main):013:0> obj = bucket.object('test.txt')
irb(main):014:0> puts obj.get.body.read
测试内容
=> nil

通过客户端上传时返回的url地址不是携带对象存储认证的url地址而是gitlab的svc地址

Answer 1

中午好🌞🌞🌞
本答案参考通义千问

根据你的描述，GitLab 通过 Kubernetes 部署，并且配置了对象存储（LFS 和 uploads），但上传文件后返回的 URL 是 GitLab 的 SVC 地址，而不是对象存储的地址。这表明 GitLab 没有正确地将对象存储的 URL 返回给客户端，可能是由于以下原因：

---

问题分析

1. lfs_object_store_proxy_download 设置为 false

   • 如果设置为 false，GitLab 不会通过代理下载 LFS 文件，而是直接使用 GitLab 的地址。
   • 这会导致客户端获取到的是 GitLab 的 SVC 地址，而非对象存储的 URL。

2. external_url 配置错误或未设置

   • GitLab 依赖 external_url 来生成正确的 URL，如果未设置或设置不正确，可能会导致返回的 URL 错误。

3. 对象存储的 endpoint 配置不正确

   • 确保 endpoint 配置为对象存储服务的正确访问地址，例如 https://eos-huhehaote-1.cmecloud.cn。

4. 对象存储权限或策略问题

   • 即使上传成功，也可能因为权限不足，导致无法通过对象存储的 URL 访问文件。

---

解决方案

1. 修改 GitLab 配置文件

请检查并修改 /etc/gitlab/gitlab.rb 文件，确保以下配置项正确无误：

# 设置外部访问地址
external_url 'http://192.168.10.11'

# 启用 LFS 对象存储
gitlab_rails['lfs_enabled'] = true
gitlab_rails['lfs_object_store_enabled'] = true
gitlab_rails['lfs_object_store_proxy_download'] = true  # ✅ 改为 true

# LFS 对象存储配置
gitlab_rails['lfs_object_store_remote_directory'] = "gitlab-lfs"
gitlab_rails['lfs_object_store_connection'] = {
  'provider' => 'AWS',
  'region' => 'huhehaote1',
  'aws_access_key_id' => 'xx',
  'aws_secret_access_key' => 'xx',
  'endpoint' => 'https://eos-huhehaote-1.cmecloud.cn',
  'force_path_style' => true
}

# 上传对象存储配置
gitlab_rails['uploads_object_store_enabled'] = true
gitlab_rails['uploads_object_store_proxy_download'] = true  # ✅ 改为 true
gitlab_rails['uploads_object_store_remote_directory'] = "gitlab-uploads"
gitlab_rails['uploads_object_store_connection'] = {
  'provider' => 'AWS',
  'region' => 'huhehaote1',
  'aws_access_key_id' => 'xx',
  'aws_secret_access_key' => 'xx',
  'endpoint' => 'https://eos-huhehaote-1.cmecloud.cn',
  'force_path_style' => true
}

重点说明：
lfs_object_store_proxy_download 和 uploads_object_store_proxy_download 必须设为 true，否则 GitLab 不会返回对象存储的 URL。

---

2. 重新配置 GitLab

在修改完配置后，运行以下命令更新 GitLab 配置：

sudo gitlab-ctl reconfigure

---

3. 验证对象存储是否正常工作

你可以使用 Ruby 脚本验证对象存储是否能正确访问和下载文件：

require 'aws-sdk-s3'

# 初始化 S3 客户端
s3_client = Aws::S3::Client.new(
  access_key_id: 'xx',
  secret_access_key: 'xx',
  region: 'huhehaote1',
  endpoint: 'https://eos-huhehaote-1.cmecloud.cn',
  force_path_style: true
)

# 创建 S3 资源对象
s3_resource = Aws::S3::Resource.new(client: s3_client)

# 获取 bucket
bucket = s3_resource.bucket('gitlab-lfs')

# 上传文件
bucket.object('test.txt').put(body: '测试内容')

# 下载文件
obj = bucket.object('test.txt')
puts obj.get.body.read

若输出为 测试内容，表示对象存储配置正确。

---

4. 测试 GitLab 中的 LFS 文件链接

上传一个 LFS 文件到 GitLab 项目中，然后查看其下载链接：

• 打开项目 → 查看某个 LFS 文件 → 右键“复制链接”。
• 应该看到类似 https://eos-huhehaote-1.cmecloud.cn/... 的 URL，而不是 GitLab 的 SVC 地址。

---

5. 检查防火墙和网络策略

如果你使用的是云环境（如 CMECloud），请确认：

• 对象存储的 endpoint 是否可从 GitLab 实例访问。
• 是否允许从 GitLab 到对象存储的出站流量。

---

总结

| 问题 | 解决方案 | |------|----------| | 返回的 URL 是 GitLab 的 SVC 地址 | 将 lfs_object_store_proxy_download 和 uploads_object_store_proxy_download 设置为 true | | external_url 未设置或错误 | 确保 external_url 正确指向 GitLab 的公网地址 | | 对象存储 endpoint 配置错误 | 检查 endpoint 是否为对象存储的正确地址 | | 权限或策略限制 | 确保 GitLab 有权限访问对象存储 |

---

建议

• 如果你使用的是私有对象存储（如 CMECloud 的 EOS），建议使用 HTTPS 并确保 SSL 证书有效。
• 如果仍然无法解决问题，请提供 GitLab 的日志信息（/var/log/gitlab/gitlab-rails/production.log）以便进一步排查。

如有需要，我可以帮你生成完整的 GitLab 配置模板。