Rails在ECS容器中复用AWS凭证时CarrierWave凭证过期问题咨询

结论 #

你当前每次在Uploader初始化时重写凭证的方案并不合理，存在冗余操作、维护成本高的问题，不过只要访问量不是极端高，暂时不会引发明显的内存问题，完全有更简洁可靠的优化方案。

现有方案的核心问题 #

• 重复冗余：每次实例化Uploader都会生成新的凭证配置哈希，高频上传场景下会产生不必要的临时对象，增加GC压力
• 维护成本高：如果项目中有多个Uploader，每个都需要重复添加初始化逻辑，漏写就会出现凭证失效问题
• 重复造轮子：你自己实现的提前刷新凭证逻辑，AWS官方SDK已经内置了更可靠的实现，不需要自行维护

最优解决方案 #

fog-aws（CarrierWave对接AWS S3的底层依赖）本身支持直接传入AWS SDK的凭证实例，且Aws::ECSCredentials自带自动刷新能力，你完全不需要自己处理凭证刷新逻辑，也不需要修改Uploader的初始化方法，只要修改全局CarrierWave初始化配置即可：

CarrierWave.configure do |config|
  config.fog_credentials = {
    provider: "AWS",
    # 直接传入ECSCredentials实例，SDK会自动处理凭证过期前的刷新逻辑
    credentials: Aws::ECSCredentials.new,
    region: Settings.amazon.region,
  }

  config.storage = :fog
  config.fog_directory  = Settings.amazon.attachments_bucket
  config.fog_public     = false
end

该方案的优势：

• 整个应用生命周期仅初始化一次凭证实例，内部刷新逻辑复用同一个对象，无额外垃圾对象产生，完全不会有内存问题
• 不需要自行维护凭证刷新定时器，AWS SDK会自动在凭证过期前拉取新凭证，可靠性远高于自定义实现
• 全局配置一次生效，所有Uploader共用同一套逻辑，不需要单独修改每个Uploader的代码

备选方案（若确实需要自行管理凭证） #

如果你有特殊需求必须自己控制凭证刷新逻辑，也不需要修改Uploader代码，只要在你自定义的刷新凭证逻辑中直接更新全局配置即可：

# 你的凭证刷新定时任务中执行这段即可，所有Uploader都会自动使用新凭证
new_creds = Aws::ECSCredentials.new
CarrierWave.config.fog_credentials.merge!(
  aws_access_key_id: new_creds.access_key_id,
  aws_secret_access_key: new_creds.secret_access_key,
  aws_session_token: new_creds.session_token
)

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