TURNKEYGNU / LINUX
Deutsch

Dokumentation

Entwurfsübersicht

Hintergrund

Viele Batch-Aufgaben können leicht in Arbeitseinheiten unterteilt werden, die parallel ausgeführt werden können. Bei Cloud-Diensten wie Amazon EC2 kostet der Betrieb eines einzelnen Servers für 100 Stunden genauso viel wie der Betrieb von 100 Servern für 1 Stunde. Mit anderen Worten, für Probleme, die parallelisiert werden können, ist es vorteilhaft, den Batch auf so viele Cloud-Server zu verteilen, wie erforderlich sind, um die Ausführung des Auftrags in knapp eine Stunde. Um diese Wirtschaftlichkeit voll auszuschöpfen, ist ein einfach zu bedienendes, automatisches System zum zuverlässigen Starten und Zerstören von Serverinstanzen auf Abruf und zur Verteilung von Arbeit unter ihnen erforderlich.

Begriffe und Begriffsbestimmungen

  • Job: ein Shell-Befehl, der eine atomare Arbeitseinheit darstellt
  • Aufgabe: eine Abfolge von Jobs
  • Aufgabenvorlage: eine vorkonfigurierte Aufgabe
  • Sitzung: der Status einer zu einem bestimmten Zeitpunkt ausgeführten Aufgabe, einschließlich der Aufgabenkonfiguration, des Status der Aufträge, die abgeschlossen wurden, und einer Liste der noch ausstehenden Aufträge.
  • Splitter: die Anzahl der Arbeitnehmer, auf die die Aufgabenjobs der Aufgabe aufgeteilt sind.
  • Arbeitnehmer: ein Server, auf dem SSH ausgeführt wird, auf dem wir Jobs ausführen. Dies kann ein persistenter Server oder eine dynamisch zugewiesene EC2-Cloud-Server-Instanz sein.
  • TurnKey Hub: a Webdienst dass cloudtask möglicherweise zum Starten und Zerstören von TurnKey-Servern verwendet wird, die für die Ausführung einer bestimmten Aufgabe vorkonfiguriert sind.

Merkmale

  • Jobs sind nur einfache Shell-Befehle, die remote ausgeführt werdenShell-Befehle sind gut verstanden, sprachunabhängig und leicht zu testen und zu entwickeln.

  • Ad-hoc Aufgabenkonfiguration über Kommandozeilenoptionen / UmgebungCloudtask kann direkt von der Befehlszeile aus verwendet werden, was für einmalige Aufgaben oder zum Experimentieren / Debuggen einer neuen Routineaufgabe nützlich ist.

  • Vorkonfigurierte Task Templates: Die Konfigurationsparameter für Routineaufgaben können in eine vorkonfigurierte Taskvorlage eingebettet werden, die selbst wie Cloudtask ausführbar ist und ihre Schnittstelle erbt.

    Unter der Haube wird eine Task-Vorlage implementiert, indem eine Python-Klasse definiert wird, die Task erbt:

#!/usr/bin/python
from cloudtask import Task

class HelloWorld(Task):
    DESCRIPTION = "This is a hello world cloudtask template"
    COMMAND = 'echo hello world'
    SPLIT = 2
    REPORT = 'mail: cloudtask@example.com liraz@example.com'

HelloWorld.main()

  • Transparente Ausführung mit Echtzeit-LoggingCloudtask bietet Echtzeit-Protokollierung, um es dem Benutzer zu erleichtern, den Fortschritt einer Aufgabe zu verfolgen. Zum Beispiel kann der Fortschritt eines über SSH ausgeführten Befehls durch das Tailing des Sitzungsprotokolls des Workers verfolgt werden:

cd ~/.cloudtask/$session_id/workers/
tail -f 1234

  • FehlertoleranzCloudTask wurde entwickelt, um mehrere Arten von Fehlern zuverlässig zu überstehen.

    • Worker-Server werden ständig auf Fehler überwacht, so dass ein Auftrag, der auf einem ausgefallenen Server ausgeführt wird, zu einem Arbeitsserver umgeleitet werden kann. Eine Aufgabe wird weiter ausgeführt, solange ein einzelner Arbeiter überlebt.
    • Der benutzer kann einen timeout pro job angeben, so dass jobs, die aus irgendeinem grund einfrieren, anmutig ausfallen, ohne den arbeitnehmer auf unbestimmte zeit zu blockieren.
    • Im Falle eines Hub API-Ausfalls wartet Cloudtask einige Sekunden und versucht es erneut.

  • Abbruch und Wiederaufnahme der Fähigkeit: Eine Aufgabe kann jederzeit abgebrochen werden, indem Sie Strg-C drücken oder das TERM-Signal an den Hauptprozess senden. Nachdem alle automatisch gestarteten Serverinstanzen zerstört wurden, wird der Status der Sitzung gespeichert, so dass er später wieder aufgenommen werden kann, wo er aufgehört hat.

  • Meldehaken: Wenn die Ausführung einer Sitzung abgeschlossen ist, kann ein Reporting-Hook konfiguriert werden, um eine beliebige Aktion auszuführen (z. B. das Senden einer Benachrichtigungs-E-Mail, das Aktualisieren einer Datenbank usw.). Drei Arten von Reporting Handlern werden derzeit unterstützt:

    1. Postsendung: Senden Sie eine E-Mail mit dem Sitzungsprotokoll an einen oder mehrere Empfänger.
    2. Scheide: Ausführen eines Shell-Befehls. Das aktuelle Arbeitsverzeichnis wird auf den Sitzungspfad gesetzt und die Umgebung mit dem Sitzungskontext bevölkert.
    3. py: Ausführen eines beliebigen Python-Code-Snippets. Die Sitzung und die Aufgabenkonfiguration sind als lokale Variablen zugänglich.

Wie es funktioniert

Wenn der Benutzer eine Aufgabe ausführt, werden die folgenden Schritte ausgeführt:

  1. Es wird ein temporärer SSH-Sitzungsschlüssel erstellt.

    Die Erstauthentifizierung für Worker setzt voraus, dass Sie einen SSH-Agenten oder ein gleichwertiges Tool eingerichtet haben (Cloudtask unterstützt keine Passwort-Authentifizierung).

    Der temporäre Sitzungsschlüssel wird für die Dauer des Task-Laufs zu den autorisierten Schlüsseln des Mitarbeiters hinzugefügt und dann entfernt. Wir müssen einen temporären Sitzungsschlüssel autorisieren, um den Zugriff auf die Mitarbeiter zu gewährleisten, ohne auf den SSH-Agenten angewiesen zu sein.

  2. Die Arbeitnehmer werden zugeteilt.

    Worker-Cloud-Server werden automatisch von cloudtask gestartet, um die gewünschte Aufteilung zu erfüllen, es sei denn, über die --workers-Option werden genügend vorab zugewiesene Worker bereitgestellt.

    Eine TKLBAM-Backup-ID kann bereitgestellt werden, um die erforderlichen Auftragsausführungsabhängigkeiten (z. B. Skripte, Pakete usw.) auf TurnKey Core zu installieren.

  3. Einrichtung der Arbeiter.

    Nachdem die Arbeitnehmer zugeteilt wurden, werden sie eingerichtet. Der temporäre Sitzungsschlüssel wird den autorisierten Schlüsseln hinzugefügt, das Overlay wird auf das Root-Dateisystem angewendet (wenn der Benutzer ein Overlay konfiguriert hat) und der Vorbefehl ausgeführt (wenn der Benutzer einen Vorbefehl konfiguriert hat).

  4. Ausführung von Aufträgen.

    CloudTask füttert eine Liste aller Jobs, aus denen die Aufgabe besteht, in eine Jobwarteschlange. Jeder Remote-Worker hat einen lokalen Supervisor-Prozess, der einen Job-Befehl aus der Warteschlange liest und über SSH auf dem Worker ausführt.

    Der Job kann eine Zeit ausfallen, bevor er abgeschlossen ist, wenn ein --timeout konfiguriert wurde.

    Während der Auftrag ausgeführt wird, wird der Überwachungsprozess regelmäßig überprüfen, ob der Mitarbeiter alle 30 Sekunden noch am Leben ist, wenn der Auftrag keine Konsolenausgabe generiert. Ist ein Worker nicht mehr erreichbar, wird er zerstört und der abgebrochene Job wird wieder in die Jobwarteschlange zur Ausführung durch einen anderen Worker gesetzt.

  5. Arbeiterbereinigung

    Wenn in der Eingabewarteschlange keine Jobbefehle mehr vorhanden sind, um einen Worker bereitzustellen, wird dieser durch Ausführen des Post-Befehls bereinigt, wobei der temporäre Sitzungsschlüssel aus dem autorisierten Befehl entfernt wird. Schlüssel.

    Wenn cloudtask den worker startet, wird es ihn auch an dieser stelle zerstören, um inkrementelle nutzungsgebühren zu stoppen.

  6. Sitzungsbericht

    Es kann ein Reporting-Hook konfiguriert werden, der eine Aktion ausführt, sobald die Sitzung abgeschlossen ist. 3 Arten von Reporting-Hooks werden unterstützt:

    1. mail: verwendet /usr/sbin/sendmail, um eine einfache unverschlüsselte E-Mail mit dem Sitzungsprotokoll im Body zu senden.

    2. sh: führt einen Shell-Befehl aus, wobei die Task-Konfiguration in die Umgebung eingebettet ist und das aktuelle Arbeitsverzeichnis auf den Sitzungspfad eingestellt ist. Sie können den Ausführungskontext wie folgt testen:

      --report='sh: env && pwd'

    3. py: führt einen Python-Code-Snippet aus, dessen Sitzungswerte als lokale Variablen festgelegt sind.

      --report='py: import pprint; pprint.pprint(locals())'