2016-03-15 3 views
6

Ich bin gerade dabei, eine Django-Website von meinem eigenen gehosteten Server mit Ubuntu auf AWS Elastic Beanstalk zu migrieren.Einrichten eines geplanten/Cron-Jobs mit Django auf Elastic Beanstalk mit einer Worker-Ebene

Ich habe den Prozess bisher etwas geradlinig gefunden - bis ich versucht habe, einige geplante Jobs für meine App einzurichten. Von dem, was ich sammeln kann, möchte ich einen Cron-Job in einer Worker Tier-Umgebung mit einer cron.yaml Datei ausführen. Ich habe durch die Dokumentation zu lesen: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features-managing-env-tiers.html#worker-periodictasks

Und den Blog-Eintrag lesen: https://medium.com/@joelennon/running-cron-jobs-on-amazon-web-services-aws-elastic-beanstalk-a41d91d1c571#.mx7dq9ufo

Und verschiedene Stackoverflow Beiträge, aber ich fühle mich wie ich noch einige grundlegende Konzepte über fehlende bin, was meine Arbeiter tatsächlich macht Tier-Umgebung. Auf meinem eigenen Server konnte ich einfach einen Cron-Job einrichten, der genau auf dieses Bedürfnis zugeschnitten ist - daher ist dieses Konzept für mich ziemlich neu. Ich habe auch ein paar Django-Apps auf Heroku, die Web- und Worker-Dynas, Async-Verarbeitung, Redis und Sellerie und geplante Jobs verwenden, aber ich kann nicht herausfinden, wie man das in die Elastic Beanstalk-Welt übersetzt.

Grundsätzlich sind die Konzepte, die ich verstehen wollen, sind:

  1. Was ist eigentlich meine Arbeiter Tier-Umgebung so weit wie Code macht geht? Offensichtlich mehr als nur die cron.yaml-Datei. Ist das ein exakter Klon meiner Web-App, die auch in dieser Umgebung bereitgestellt wird? Oder kann das irgendwie den Code aus meiner Web-Umgebung referenzieren und so laufen?
  2. Oder ist die Worker-App insgesamt eine ganz neue App? Muss ich dafür eine eigene Django/Flask App erstellen?
  3. Wie kommuniziert meine Worker App physisch mit meiner Web App? Wie sollen die POST-Nachrichten in cron.yaml eigentlich dazu dienen, Jobs in der Web-App auszuführen? Wenn es sich um eine eigenständige App handelt, wie sind die Arbeitsumgebung und die Webumgebung tatsächlich verknüpft?

Ich möchte im Wesentlichen einige Django-Management-Befehle planen. Ich habe Methoden auch als POST-Endpunkte verfügbar gemacht, kann aber nicht herausfinden, wie die Worker-Umgebung dazu gebracht werden kann, mit der Web-App zu sprechen/sie auszuführen.

Entschuldigen Sie meine Naivität, ich würde wirklich jede Art von Rat und Richtung schätzen, wie dieses Konzept zusammenkommt.

Antwort

3

Also endete ich mit einem Freund, der mit den AWS-Diensten vertrauter ist. Er erklärte die Konzepte, und ich ließ die geplanten Jobs ausführen, indem ich die Arbeitsumgebung folgendermaßen konfigurierte:

  • Erstellte eine separate eigenständige Anwendung für die Webumgebung. Ich baute eine separate "Worker" Django App, aber das könnte Flask oder wirklich jedes andere Framework oder Sprache sein
  • Erstellt eine App namens "Cron", die Ansichten hatte, um POST-Nachrichten zu verschiedenen Endpunkten zu behandeln, die im Wesentlichen die geplanten Jobs I sind wollte ausführen. Diese Endpunkte sind, was die Jobs in meiner cron.yaml Datei direkt an
  • Da meine Jobs Datenbankänderungen an der Web-App vornehmen musste, richtete ich die Worker-App so ein, dass sie dieselbe Datenbank wie die Web-App verwendet. Dies war so einfach wie das Hinzufügen von RDS-Umgebungsvariablen zu meiner Konfiguration der Arbeitsumgebung. Z.B. Legen Sie RDS_DB_NAME, RDS_HOSTNAME und RDS_USERNAME so fest, dass sie auf die Webumgebungsdatenbank zeigen.
  • Et voila, die geplanten Aufträge werden planmäßig ausgeführt und die Datenbank wird entsprechend geändert.

    +1

    Eine andere Idee ist es, einen Cron-Endpunkt in Ihre Hauptanwendung für Web-/Nicht-Worker aufzunehmen, der die Verwaltung von [django-cron.readthedocs.io/en/latest/] Laufwerken ausführt Befehl programmgesteuert ausführen und einen Worker-App-Endpunkt erstellen, der den Endpunkt der Web-App anfordert. Ein beliebiger Schlüssel, der beiden Servern bekannt ist (von einem Mitarbeiter gesendet und von der Web-App validiert), verhindert, dass Benutzer Ihre Crons auslösen. Der Vorteil besteht nicht darin, das Rad mit Modellen, Datenbankverbindungen usw. am Arbeiter neu zu erfinden. Wenn die Crons jedoch ressourcenintensiv und/oder häufig sind, kann dies ein Problem auf dem Webserver sein. – jmq

    +0

    @jmq Ich mag deine Lösung tatsächlich viel besser. Meine Lösung erforderte das Klonen aller meiner Modelle in eine separate App und das Verbinden mit der gleichen Datenbank, was ein bisschen unordentlich ist. – benedwards44

    +0

    Nachdem ich dieses Problem erneut angegangen bin und es mehr bedacht habe, scheint mir jetzt das beste Szenario zu sein, einfach das 'cron.yaml' in Ihrem Hauptrepo zu entwickeln und ein Duplikat Ihrer Codebasis an den Worker-Server zu senden. Obwohl das in einer Hinsicht nicht sehr TROCKEN ist (dass Sie nur den vollen Code auf 2 Servern ausführen und ihre Zwecke unterschiedlich sind), entlädt es die eigentliche Arbeit der Cron-Aufgaben auf die Arbeitsebene, was der Punkt ist AWS bietet diese Stufe an. Es minimiert/eliminiert auch, dass neuer Code geschrieben werden muss (im Gegensatz zu meinem ersten Kommentar oben). – jmq