GitLab Artifacts上传至AWS S3报500内部服务器错误求助

问题场景 #

GitLab 使用本地存储 Artifacts 时运行正常，切换为 AWS S3 存储后，流水线任务上传 Artifacts 时返回500 Internal Server Error，最终任务失败。已确认 GitLab 服务器及 CI/CD Runner 均具备 S3 桶写入权限，但简化后的测试流水线仍无法成功，且未找到相关报错日志。

相关配置（/etc/gitlab/gitlab.rb） #

## Job Artifacts
gitlab_rails['artifacts_enabled'] = true
####! Job artifacts Object Store
gitlab_rails['artifacts_object_store_enabled'] = true
gitlab_rails['artifacts_object_store_proxy_download'] = false
gitlab_rails['artifacts_object_store_remote_directory'] = "s3-bucket-name"
gitlab_rails['artifacts_object_store_connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-cenral-1',
  'use_iam_profile' => true
}

排查及修复步骤 #

• 修正配置拼写错误
  配置中region字段值为eu-cenral-1，正确的欧盟中部区域代码应为eu-central-1（缺失字母t）。拼写错误会导致GitLab无法正常连接S3服务，触发500错误。修正后执行以下命令生效：

  gitlab-ctl reconfigure
  gitlab-ctl restart
  

• 定向收集关键日志
  即使未找到日志，可通过以下命令实时监控核心服务日志，重新触发流水线后观察报错细节：

  • 查看GitLab Rails业务日志：

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

  • 查看GitLab Workhorse上传处理日志：

    tail -f /var/log/gitlab/gitlab-workhorse/current
    

• 验证S3桶配置
  确认S3桶的CORS规则允许GitLab服务器访问，同时检查桶的生命周期规则，避免存在自动清理未完成上传分片的设置，防止上传过程中文件被删除。

• 检查Workhorse服务状态
  Workhorse是处理Artifacts上传的核心服务，执行以下命令确认服务状态：

  gitlab-ctl status gitlab-workhorse
  

  若服务异常，重启服务：

  gitlab-ctl restart gitlab-workhorse
  

• 直接测试Rails与S3的连接
  进入GitLab Rails控制台，执行代码测试S3连接及写入权限：

  gitlab-rails console
  

  在控制台中运行：

  s3 = Aws::S3::Resource.new(region: 'eu-central-1', credentials: Aws::InstanceProfileCredentials.new)
  bucket = s3.bucket('s3-bucket-name')
  obj = bucket.object('test-artifact.txt')
  obj.put(body: 'test content')
  puts obj.exists?
  

  若执行失败，控制台会返回具体错误信息，直接定位问题根源。

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