在 Amazon Elastic Beanstalk 上部署 rails 项目时如何自动重启 delay_job? [英] How to automatically restart delayed_job when deploying a rails project on Amazon Elastic Beanstalk?

问题描述

我在 Amazon Elastic Beanstalk 上托管了一个 Rails 项目，我尝试配置一个容器命令 每次部署后在服务器上自动重启我的 delayed_job worker.

I'm hosting a rails project on Amazon Elastic Beanstalk and I try to configure a container command to automatically restart my delayed_job worker on the server after each deployment.

我试过这个:

container_commands:
  restartdelayedjob:
    command: "RAILS_ENV=production script/delayed_job --pid-dir=/home/ec2-user/pids start"
    cwd: /var/app/current

但是，似乎是在重新启动worker后部署了推送版本，因此worker无法处理作业.

But, it seems that the pushed version is deployed after the restarting of the worker so the jobs failed to be processed by the worker.

当我通过 ssh 连接到我的实例时，杀死工作进程并从部署的版本文件夹中重新启动一个新的，一切正常.

When I connect on my instance by ssh, kill the worker process and restart a new one from the deployed version folder, everything works fine.

你对我如何处理这件事有什么想法吗?

Do you have any ideas of how I can handle this?

谢谢

推荐答案

根据 container_commands 的亚马逊文档:

As per the Amazon documentation for container_commands:

它们在设置应用程序和 Web 服务器并提取应用程序版本文件之后运行，但在部署应用程序版本之前.

They run after the application and web server have been set up and the application version file has been extracted, but before the application version is deployed.

(强调我的)

这意味着在那个点 /var/app/current 您设置为命令的 cwd 仍然指向以前的版本.但是，默认情况下，再次从文档中，cwd:

This means at that point /var/app/current which you are setting as the cwd for your command is still pointing to the previous version. However by default, from the docs again, cwd:

是解压后的应用程序目录.

is the directory of the unzipped application.

这意味着如果您想从刚刚提取(但尚未部署)的应用程序目录中运行 delayed_job，请不要覆盖 cwd 和它应该为即将部署的应用启动 delay_job.

This means that if you want to run delayed_job from the directory of the app that just got extracted (but not yet deployed), don't override cwd and it should start the delayed_job for the app that's about to be deployed.

参考:http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html#customize-containers-format-container_commands

我现在自己设置了这个，发现通过标准的 container_commands 来做它有一些限制 - 基本上 delay_job 将在它仍然在 /var/app/ondeck 时启动 目录.通常这没问题，但我在某些作业上遇到了一些问题，因为该路径卡在它周围会导致错误，因为应用程序现在位于 /var/app/current 中.

I've now set this up myself and found there's limitations to doing it via the standard container_commands - basically delayed_job will be started while it is still in the /var/app/ondeck directory. Usually this is OK, but I had some issues with some jobs because that path had stuck around it would cause errors as the app was now in /var/app/current.

我发现了一种未记录的(所以警告！)方法，您可以添加脚本以在您的应用服务器重新启动后运行(并且您的新部署在 /var/app/current 中).

I found an undocumented (so warning!) approach that you can add scripts to be run AFTER your app server is restarted (and your new deploy is in /var/app/current).

基本上 Elastic Beanstalk 将在 Web 服务器重新启动后执行 /opt/elasticbeanstalk/hooks/appdeploy/post 中的任何脚本.这意味着如果你将 shell 脚本放到这个目录中，它们就会被运行.

Basically Elastic Beanstalk will execute any scripts in /opt/elasticbeanstalk/hooks/appdeploy/post after the web server is restarted. This means if you drop shell scripts in this directory they will be run.

我创建了一个这样的 shell 脚本:

I created a shell script like this:

#!/usr/bin/env bash
. /opt/elasticbeanstalk/support/envvars
cd $EB_CONFIG_APP_CURRENT
su -c "RAILS_ENV=production script/delayed_job --pid-dir=$EB_CONFIG_APP_SUPPORT/pids restart" $EB_CONFIG_APP_USER

我将此脚本上传到 S3 存储桶，并确保它是公开的".然后，您可以使用 .ebextensions 目录中的选项脚本(例如 99delayed_job.config)将此脚本部署为应用程序部署的一部分，请注意 post 目录可能不存在:

I uploaded this script to an S3 bucket, and made sure it was "public". You can then use an options script in your .ebextensions directory (eg. 99delayed_job.config) to deploy this script as part of your app deploy, taking note that the post directory might not exist:

commands:
  create_post_dir:
    command: "mkdir /opt/elasticbeanstalk/hooks/appdeploy/post"
    ignoreErrors: true
files:
  "/opt/elasticbeanstalk/hooks/appdeploy/post/99_restart_delayed_job.sh":
    mode: "000755"
    owner: root
    group: root
    source: http://YOUR_BUCKET.s3.amazonaws.com/99_restart_delayed_job.sh

当您部署时，您应该在 /var/log/eb-tools.log 中看到类似的内容:

When you deploy you should see something like this in your /var/log/eb-tools.log:

2013-05-16 01:20:53,759 [INFO] (6467 MainThread) [directoryHooksExecutor.py-29] [root directoryHooksExecutor info] Executing directory: /opt/elasticbeanstalk/hooks/appdeploy/post/
2013-05-16 01:20:53,760 [INFO] (6467 MainThread) [directoryHooksExecutor.py-29] [root directoryHooksExecutor info] Executing script: /opt/elasticbeanstalk/hooks/appdeploy/post/99_restart_delayed_job.sh
2013-05-16 01:21:02,619 [INFO] (6467 MainThread) [directoryHooksExecutor.py-29] [root directoryHooksExecutor info] Output from script: delayed_job: trying to stop process with pid 6139...
delayed_job: process with pid 6139 successfully stopped.

2013-05-16 01:21:02,620 [INFO] (6467 MainThread) [directoryHooksExecutor.py-29] [root directoryHooksExecutor info] Script succeeded.

正如我所说，将东西放在这个post"目录中是没有记录的 - 但希望亚马逊在某个时候为 .options 脚本添加实际支持以在部署后运行命令，在这种情况下你可以将其移至官方支持的方法.

As I said, putting stuff in this "post" directory is undocumented - but hopefully at some point Amazon add actual support to the .options scripts to run commands post-deploy, in that case you could move this to the officially supported approach.

这篇关于在 Amazon Elastic Beanstalk 上部署 rails 项目时如何自动重启 delay_job?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！