AWS ECS Fargate部署后Sidekiq出现ActiveModel::UnknownAttributeError求助

Rails应用层面优化 #

1. 关闭Sidekiq的Schema缓存 #

Sidekiq默认复用Rails的schema缓存文件，新增列后无法及时识别。可以直接在Sidekiq启动命令中禁用缓存：

bundle exec sidekiq --disable-schema-cache

或者在Sidekiq初始化文件（如config/initializers/sidekiq.rb）中添加配置：

Sidekiq.configure_server do |config|
  # 禁用schema缓存
  Rails.application.config.active_record.schema_cache_path = nil
  # 启动时强制刷新缓存
  ActiveRecord::Base.clear_cache!
end

2. 采用双阶段兼容部署 #

这是规避迁移兼容性问题的通用方案，分两步执行：

• 第一阶段：部署不依赖新列的代码。比如新增列但暂不用于业务逻辑，或在模型中提前声明新增属性做兼容：

  class YourModel < ApplicationRecord
    attribute :new_column, :string # 提前声明属性，避免UnknownAttributeError
  end
  

• 第二阶段：执行数据库迁移，确认完成后再部署使用新列的业务代码。这样Sidekiq在第一阶段的代码不会因新列报错，迁移完成后更新代码即可适配新schema。

3. 迁移后强制重启Sidekiq进程 #

在rails db:migrate执行完成后，主动重启Sidekiq服务，让它重新加载schema缓存。可以在迁移脚本末尾添加触发重启的逻辑，或在ECS部署流程中调用API重启Sidekiq任务。

AWS ECS层面调整部署流程 #

1. 用CodePipeline编排部署顺序 #

通过AWS CodePipeline创建部署流水线，设置以下步骤：

• 第一步：部署Web服务，配置部署成功条件（如目标组健康检查通过、迁移脚本执行完成）。可在Web服务启动命令中加入rails db:migrate，确保迁移成功后服务才标记为健康。
• 第二步：待Web服务部署完成且状态正常后，自动触发Sidekiq服务的部署。保证Sidekiq启动时，数据库迁移已完成，schema缓存能正确加载新列。

2. 将迁移作为独立ECS任务执行 #

把rails db:migrate拆分为单独的一次性ECS任务，部署流程调整为：

• 先运行迁移任务，通过CloudWatch日志或任务状态确认执行成功。
• 再同时部署Web和Sidekiq服务。这种方式能确保两个服务启动时，数据库schema已更新完成，不会出现缓存不一致问题。

3. 给Sidekiq设置部署前置检查 #

在Sidekiq服务的部署流程中添加前置检查：调用Web服务的自定义健康端点（如/health/migrate），该端点返回迁移完成状态，只有检查通过才允许Sidekiq新任务启动。

比如在Web服务控制器中添加：

class HealthController < ApplicationController
  def migrate_status
    pending_migrations = ActiveRecord::Migration.check_pending!
    if pending_migrations.empty?
      render json: { status: 'ok' }, status: :ok
    else
      render json: { status: 'pending' }, status: :service_unavailable
    end
  end
end

随后在ECS部署Sidekiq时，用Lambda或CodeBuild步骤先调用该端点，确认返回ok后再继续部署。

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