AWS/EBS Travaux en arrière-plan dans Rails

Question

J'ai une application sur AWS en utilisant Elastic Beanstalk/RDS/EC2/etc écrit en Rails.

L'application a certaines entrées de base de données qui doivent être supprimées après un certain temps, et pensait utiliser une gemme pour créer une tâche en arrière-plan. Cependant, tous les gems que je vois sont juste des moyens de créer par programme des tâches cron. Avec Elastic Beanstalk, l'instance de serveur utilisée sera mise à l'échelle/modifiée afin que les tâches cron soient perdues. Existe-t-il un autre moyen de configurer un travail d'arrière-plan dans Rails?

Answer 1

Je résout généralement ce problème en utilisant container_commands que vous pouvez configurer dans un fichier .config à l'intérieur du dossier .ebextensions dans votre application. 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). Utilisez un verrou Mutex distribué (redis-mutex ou base de données sauvegardée) pour bloquer tous les processus sauf un qui obtient le verrouillage.

#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 

Cron choisira ce, il suffit de mettre la définition dans le fichier crontab .ebextensions/cron_tasks.txt et également ajouter celui-ci à votre git.

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

Il est triste, mais il semble que l'équipe Amazon AWS ne toujours pas une solution appropriée, pratique pour les travaux d'arrière-plan de planification avec Rails dans des environnements Elastic Beanstalk. Leur niveau de travailleur exige que vous ajoutiez un point de terminaison dédié dans votre application qui écoute les messages de leur propre implémentation cron. Cela est mauvais car cela vous oblige à ajouter un code spécifique à l'hébergement à votre logique d'application principale (routes, contrôleurs) et nécessite l'exécution de plusieurs serveurs. Un autre inconvénient d'AWS par rapport aux plates-formes comme Heroku est le manque de support en un clic pour les systèmes de mise en file d'attente à support Redis comme Sidekiq et les opérateurs à la demande qui peuvent être générés via des planificateurs cron.