AWS/EBS Hintergrundjobs in Rails

Question

Ich habe eine App auf AWS mit Elastic Beanstalk/RDS/EC2/etc in Rails geschrieben.

Die App hat einige Datenbankeinträge, die nach einer bestimmten Zeit gelöscht werden müssen, und dachte darüber nach, einen Edelstein zu verwenden, um eine Hintergrundaufgabe zu erstellen.

Alle Edelsteine, die ich sehe, sind jedoch nur Möglichkeiten zum programmatischen Erstellen von Cron-Aufgaben. Mit Elastic Beanstalk wird die verwendete Serverinstanz skaliert/geändert, sodass Cron-Tasks verloren gehen. Gibt es eine andere Möglichkeit, einen Hintergrundjob in Rails einzurichten?

Answer 1

Normalerweise lösen ich dieses Problem, indem Sie container_commands verwenden, die Sie in einer .config-Datei in .ebextensions Ordner in Ihrer App konfigurieren können. 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). Verwenden Sie die verteilte Mutex-Sperre (redis-mutex oder database-backed), um alle Prozesse bis auf einen zu blockieren, der die Sperre erhält.

#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 wird diese holen, einfach die crontab Definition in .ebextensions/cron_tasks.txt Datei und fügen Sie auch diesen Ihren Git Repo.

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

Es ist traurig, aber es scheint, dass noch Amazon AWS-Team nicht mit einer richtigen, komfortable Lösung für die Planung von Hintergrundjobs mit Rails in Elastic Beanstalk-Umgebungen hat kommen. Ihre Worker-Ebene erfordert, dass Sie in Ihrer App einen dedizierten Endpunkt hinzufügen, der Nachrichten von ihrer eigenen Cron-Implementierung abhört. Das ist schlecht, da Sie gezwungen sind, Ihrer Kernanwendungslogik (Routen, Controller) einen hostspezifischen Code hinzuzufügen und mehr Server erforderlich sind. Ein weiterer Nachteil von AWS beim Vergleich mit Plattformen wie Heroku ist die fehlende Ein-Klick-Unterstützung für Redis-gestützte Warteschlangensysteme wie Sidekiq und On-Demand-Mitarbeiter, die über cron-ähnliche Scheduler generiert werden können.