GitLab CE对接AWS对象存储失败问题排查求助

潜在配置错误 #

你的配置中手动指定了host: 's3.amazonaws.com'，这可能是导致S3存储未生效的核心原因。对于AWS标准S3服务，GitLab的fog-aws驱动会根据你设置的region自动生成对应区域的专属端点（比如eu-west-1的正确端点是s3.eu-west-1.amazonaws.com），手动指定通用端点会干扰驱动的正常逻辑，导致GitLab未触发S3存储流程。

排查步骤 #

• 移除冗余的host配置：删除配置中的'host' => 's3.amazonaws.com'行，然后重载GitLab配置（Omnibus镜像执行gitlab-ctl reconfigure，或直接重启Docker容器）。
• 验证配置加载状态：进入GitLab容器，启动rails控制台：

  docker exec -it <gitlab-container-name> gitlab-rails console
  

  在控制台中执行以下命令，确认对象存储配置已正确启用：

  puts Gitlab.config.object_store.enabled?
  puts Gitlab.config.object_store.objects['uploads'].bucket
  

  正常输出应为true和你配置的bucket名称。
• 直接测试S3连接：在rails控制台中执行代码测试S3交互，明确是否存在权限或连接问题：

  require 'fog/aws'
  begin
    client = Fog::Storage.new(
      provider: 'AWS',
      aws_access_key_id: 'xxxx',
      aws_secret_access_key: 'xxxx',
      region: 'eu-west-1'
    )
    # 替换为你的某个bucket名称，测试能否获取bucket信息
    bucket = client.directories.get('xxx-gitlab-uploads')
    puts "Bucket found: #{bucket.key}"
  rescue => e
    puts "Connection error: #{e.message}"
  end
  

  如果报错，会直接显示具体原因（如权限不足、签名错误等）。
• 检查日志细节：
  • 查看/var/log/gitlab/gitlab-rails/production.log，搜索s3或object_store关键词，排查是否有隐藏的错误日志。
  • 查看/var/log/gitlab/gitlab-workhorse.log，文件上传由workhorse处理，可能存在相关的存储路由日志。
• 明确对象存储的作用范围：GitLab对象存储默认仅处理特定类型文件（LFS对象、CI制品、上传附件、包仓库等），普通Git仓库的代码文件（.git目录内容）默认仍存储在本地卷中。如果你的测试是上传普通仓库代码，这属于正常行为，需要额外配置Gitaly远程存储才能将代码仓库迁移到S3。
• 确认IAM权限：确保配置的AWS账号拥有对应S3 bucket的以下权限：
  • s3:ListBucket
  • s3:PutObject
  • s3:GetObject
  • s3:DeleteObject
    即使测试连接能通，缺少写入权限也会导致GitLab fallback到本地存储。
• 确认配置重载生效：修改配置后，必须执行gitlab-ctl reconfigure（Omnibus镜像）或重启Docker容器，确保新配置被加载。

内容的提问来源于stack exchange，提问作者Gaspode