Исходные задания AWS/EBS в рельсах

Question

У меня есть приложение для AWS, использующее Elastic Beanstalk/RDS/EC2/etc, написанное в Rails.

Приложение имеет некоторые записи базы данных, которые необходимо удалить через определенное время, и думал о том, чтобы использовать драгоценный камень для создания фоновой задачи.

Однако все драгоценные камни, которые я вижу, - это просто способы программного создания задач cron. С помощью Elastic Beanstalk используемый экземпляр сервера будет масштабировать/изменять, поэтому задачи cron будут потеряны. Есть ли другой способ настроить фоновое задание в Rails?

Answer 1

Обычно я решаю эту проблему, используя container_commands, которую вы можете настроить в файле .config внутри папки .ebextensions в своем приложении. The idea is that the code is executed on so-called 'leader' instance in your webservers pool. It is not considered as a bulletproof solution but does the job and mostly works (it will fail when autoscaling comes into play though). Использование распределенной блокировки Mutex (redis-mutex или базы данных) для блокировки всех процессов, кроме тех, которые получают блокировку.

#create config file, use numbers/names that suit your needs: 
#.ebextensions/02_container_commands.config 
container_commands: 
    01_cron_tasks: 
    command: "cat .ebextensions/cron_tasks.txt > /etc/cron.d/yourapp && chmod 644 /etc/cron.d/yourapp" 
    leader_only: true 

хроны подберут это, просто поместить определение кронтаба в .ebextensions/cron_tasks.txt файле и добавить также эту к вашему Git репо.

0 5 * * * root bash -l -c "su -m webapp; cd /var/app/current && rake your_rake_task" 

Это печально, но это, кажется, что команда Amazon AWS до сих пор не придумала правильным, удобным решением для планирования фоновых заданий с Rails в среде Elastic Beanstalk. Их уровень рабочих требует, чтобы вы добавили в свое приложение конечную точку, которая прослушивает сообщения из своей собственной реализации cron. Это плохо, потому что это заставляет вас добавить код, ориентированный на хостинг, в вашу основную логику приложения (маршруты, контроллеры) и требует большего количества серверов.

Другим недостатком AWS в сравнении с такими платформами, как Heroku, является отсутствие поддержки одним кликом для систем резервирования Redis, таких как Sidekiq, и рабочих по требованию, которые могут быть созданы с помощью cron-подобных планировщиков.