如何在Azure应用服务中实现Ruby On Rails Delayed Job

1. 基础代码配置 #

• 先在项目Gemfile中添加依赖：

# 用ActiveRecord作为任务存储后端（绝大多数Rails应用的选择）
gem 'delayed_job_active_record'
gem 'daemons'

• 执行依赖安装、生成任务表迁移并执行：

bundle install
rails generate delayed_job:active_record
rails db:migrate

• 新建Delayed Job初始化配置文件config/initializers/delayed_job_config.rb，按需调整参数：

Delayed::Worker.max_attempts = 3 # 任务失败最大重试次数
Delayed::Worker.max_run_time = 5.minutes # 单任务最长运行时长
Delayed::Worker.destroy_failed_jobs = false # 失败任务不自动删除，方便排查
Delayed::Worker.logger = Logger.new(File.join(Rails.root, 'log', 'delayed_job.log'))

• 纯Ruby（非Rails）应用直接在启动入口引入delayed_job_active_record即可，不需要执行Rails专属的生成命令，自行确保delayed_jobs表在数据库中创建完成。

2. Azure App Service 托管Worker配置（核心） #

Azure App Service 不支持脱离主进程树的守护进程运行，本地常用的script/delayed_job start daemon模式会被平台沙箱判定为孤儿进程直接回收，绝对不要用。推荐用平台原生的持续运行Web Job托管Worker进程，稳定性最高，崩溃自动重启。

推荐方案：持续运行Web Job托管Worker #

• 在项目bin目录下新建前台运行的Worker启动脚本bin/delayed_job_worker.rb，添加执行权限chmod +x bin/delayed_job_worker.rb，内容如下：

#!/usr/bin/env ruby
require_relative '../config/environment'
# 前台启动Worker，不做daemonize
Delayed::Worker.new.start

• 在项目根目录新建Web Job启动入口run_dj.sh，添加执行权限chmod +x run_dj.sh，内容如下：

#!/bin/bash
cd /home/site/wwwroot
bundle exec ruby bin/delayed_job_worker.rb

• 进入Azure Portal对应App Service实例，完成以下配置：
  • 侧边栏选择「配置」-「常规设置」，打开Always On开关（必须开，否则空闲时站点会被回收，Worker也会停止）
  • 侧边栏选择「Web Jobs」，添加新的持续运行任务：
    • 名称：delayed-job-worker
    • 类型：持续运行
    • 脚本路径：选择项目根目录的run_dj.sh（如果用CI/CD自动部署，直接在部署配置中映射脚本路径即可，不需要手动上传）

备选方案：自定义启动脚本同进程托管（适合低流量小站点） #

如果不想单独配置Web Job，可以通过自定义启动脚本同时拉起Web服务和Worker进程：

• 在项目根目录新建startup.sh，添加执行权限：

#!/bin/bash
cd /home/site/wwwroot
# 后台拉起Worker进程
bundle exec ruby bin/delayed_job_worker.rb &
# 启动主Web服务（根据你实际用的服务器改，默认Puma）
bundle exec puma -C config/puma.rb

• 在App Service「配置」-「常规设置」中，将启动命令设置为/home/site/wwwroot/startup.sh

注意：该方案下平台只会监控主Web进程，Worker进程崩溃后不会自动重启，仅适合测试或低流量场景使用。

3. 部署与运维注意事项 #

• 环境变量不需要单独配置：Web Job默认继承App Service上配置的所有应用设置、连接字符串，和主应用共用同一套数据库、缓存等资源配置。
• 部署后必须重启Worker：每次代码发布完成后，重启Delayed Job对应的Web Job，避免Worker加载旧版本代码执行任务。
• 日志排查：
  • Web Job的运行标准输出、错误输出可以直接在Portal对应Web Job的「日志」入口查看
  • Delayed Job本身的业务日志存放在站点log/delayed_job.log路径下，可以通过Kudu高级工具进入文件系统查看
• 横向扩展适配：如果App Service配置了多实例横向扩展，每个实例都会启动一个Delayed Job Worker，ActiveRecord后端自带任务行锁，不会出现多实例重复消费同一个任务的问题，无需额外改配置。如果需要控制Worker并发数，调整App Service实例数或者在Worker启动参数中指定队列即可。
• Windows栈适配：如果使用Windows版App Service，将Shell启动脚本替换为bat/ps1脚本即可，核心逻辑保持一致：直接前台执行bundle exec ruby bin/delayed_job_worker.rb，不要用daemon模式。

4. 常见问题排查 #

• Worker启动后几分钟就消失：检查是否开启Always On，是否错误使用了daemon模式启动Worker
• 任务频繁报超时：检查Delayed::Worker.max_run_time配置是否小于任务实际运行时长，后台任务不受App Service前端请求230秒超时限制，可以按需调大该参数
• 任务不消费：检查数据库连接配置是否正确，Worker日志中是否有数据库连接报错，确认delayed_jobs表已经成功创建

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