Häufig gestellte Fragen

Was ist ein Task Job?

Jeder Job ist im Wesentlichen nur ein Shell-Befehl, den Cloudtask durch Anfügen des Task-Befehls an die Job-Eingabeargumente erzeugt. Betrachten Sie zum Beispiel die folgende Cloudtask:

seq 3 | cloudtask echo

seq 3 druckt eine Folge von Zahlen von 1 bis 3 aus, jeweils auf einer separaten Zeile, die Cloudtask an die Echo Erstellt drei Befehle:

echo 1
echo 2
echo 3

Jeder Job-Befehl sollte unabhängig sein, was bedeutet, dass er sich nicht darauf verlassen sollte, dass ein anderer Job-Befehl vor oder nach einem bestimmten Mitarbeiter ausgeführt wird. Die Ausführungsreihenfolge und Verteilung der Jobbefehle ist bis zu cloudtask. Wenn eine Aufgabe auf mehrere Worker aufgeteilt ist (z. B. --split=3), wird jeder Jobbefehl wahrscheinlich auf einem anderen Server ausgeführt.

Job-Befehle erfordern möglicherweise keine Benutzerinteraktion. Cloudtask kann nicht mit Job-Befehlen interagieren, so dass jeder Versuch einer Benutzerinteraktion (z. B. ein Bestätigungsdialog) den Job hängt, bis der konfigurierte Job --timeout verstreicht (1 Stunde) Standardmäßig.

Wie bereite ich einen Arbeitnehmer auf einen Job vor?

Auf einer neuen TurnKey Core-Bereitstellung installieren und testen Sie alle Software (z. B. Pakete, benutzerdefinierte Skripte usw.), von der Ihr Jobbefehl abhängt.

Backup des Masters mit TKLBAM, und geben Sie seine Backup-ID an cloudtask weiter, damit es dieses Backup auf jedem Worker wiederherstellen kann, den es automatisch startet.

Sie können eine TKLBAM-Wiederherstellung durch den Befehl --pre ersetzen oder ergänzen (z. B. um ein Paket zu installieren) und/oder ein --overlay auf das Dateisystem des Workers anwenden.

Wie stelle ich Job-Kommandos mit den erforderlichen Eingabedaten zur Verfügung?

Kleine Mengen an Eingabedaten können im TKLBAM-Backup gespeichert oder an den Worker im Overlay übertragen werden.

Für größere Mengen an Eingabedaten wird empfohlen, Daten über das Netzwerk zu ziehen (z. B. von einem Dateiserver oder Amazon S3).

Wo speichere ich die nützlichen Endprodukte eines Job-Kommandos?

Jobs sollten nützliche Endprodukte wie Dateien in einer externen Speicherressource im Netzwerk verdrängen.

Jeder Festplattenspeicherplatz auf dem Worker sollte als vorübergehend betrachtet werden, da jeder automatisch gestartete Worker am Ende der Aufgabe zusammen mit dem Inhalt des Workflows zerstört wird. seinen Zwischenspeicherraum.

Wenn ein Job beispielsweise Dateien im lokalen Dateisystem erstellt, gehen diese verloren, wenn der Worker zerstört wird, es sei denn, sie werden zuerst über das Netzwerk auf einen Dateiserver hochgeladen. oder zu Amazon S3, etc.

Jede Konsolenausgabe (z. B. Druckanweisungen) eines Auftrags wird automatisch von Cloudtask protokolliert.

Was passiert, wenn ein Job scheitert?

Ein Job gilt als fehlgeschlagen, wenn der Jobbefehl einen Nicht-Null-Ausgangscode zurückgibt. Sie werden einfach protokolliert und die Gesamtzahl der Fehlschläge am Ende der Sitzung gemeldet. Der Arbeitnehmer führt dann den nächsten Job weiter aus.

Sind die Arbeitsplätze gleichmäßig unter den Arbeitnehmern aufgeteilt?

Nicht unbedingt. Arbeiter ziehen Jobbefehle aus einer Schlange von Jobs auf einer First-Come-First-Served-Basis. Ein Mitarbeiter wird den nächsten Job aus der Warteschlange holen, sobald er mit dem vorherigen Job fertig ist. Ein schneller Arbeiter oder ein Arbeiter, der kürzere Jobs erhalten hat, kann mehr Jobs ausführen als ein langsamer Arbeiter oder ein Arbeiter, der längere Jobs erhalten hat.

Wie authentifiziert sich Cloudtask gegenüber Mitarbeitern?

Cloudtask meldet sich über SSH bei Remote-Servern an. Es geht davon aus, dass es dies ohne Passwort mit SSH-Schlüssel-Authentifizierung tun kann (z. B. wurde Ihr SSH-Schlüssel zu den autorisierten Schlüsseln des Mitarbeiters hinzugefügt). Die Passwort-Authentifizierung wird nicht unterstützt.

Im Abschnitt Benutzerprofil können Sie mit dem Hub einen oder mehrere öffentliche SSH-Schlüssel konfigurieren, die zu den autorisierten Schlüsseln eines beliebigen gestarteten Cloud-Servers hinzugefügt werden.

Also muss ich meinen privaten SSH-Schlüssel auf einen Remote-Server legen, auf dem ich Cloudtask ausführe?

Eine andere, sicherere Alternative wäre die Verwendung von SSH Agent Forwarding, um sich beim Remote-Server anzumelden:

ssh -A remote-server

Durch die Weiterleitung des lokalen SSH-Agenten können Remote-Server Ihre SSH-Schlüssel authentifizieren, ohne dass sie jemals die Sicherheit Ihres PCs verlassen.

Was ist, wenn ein Arbeiter scheitert?

Cloudtask ist nicht von der Zuverlässigkeit eines einzelnen Mitarbeiters abhängig: Wenn ein Mitarbeiter versagt, während er einen Job führt, wird der Job an einen der verbleibenden Mitarbeiter umgeleitet.

Ein Worker gilt als fehlgeschlagen, wenn cloudtask feststellt, dass er nicht mehr in der Lage ist, Befehle über SSH auszuführen (d.h. Cloudtask-Pings, die Worker regelmäßig angreifen).

Es spielt keine Rolle, ob dies auf ein Netzwerk-Routing-Problem zurückzuführen ist, das den Mitarbeiter unerreichbar macht, auf ein Softwareproblem (z. B. Kernel-Panik) oder auf ein kritisches Leistungsproblem wie Als der Arbeiter aus dem Speicher läuft und so schlecht in Swap, dass es nicht einmal Befehle über SSH akzeptieren kann.

Wie üblich übernimmt Cloudtask die Verantwortung für die Zerstörung der Arbeiter, die es startet. Ein Arbeiter, der versagt hat, wird sofort zerstört.

Muss ich den Hub nutzen, um Arbeiter zu starten?

Nein, das ist nur der einfachste Weg, dies zu tun. Cloudtask kann eine beliebige Liste von Worker-IP-Adressen über die --workers-Option akzeptieren.

Kann ich vorgefertigte Worker mit automatisch gestarteten Workern mischen?

Ja. Wenn der --split größer ist als die Anzahl der vorab gestarteten Worker, die Sie über die --workers-Option bereitstellen, dann wird Cloudtask zusätzliche Worker starten, um die konfigurierten Worker zu erfüllen. geteilt.

Wenn Sie beispielsweise eine Liste mit 5 vorab gestarteten Worker-IP-Adressen angeben und eine Aufgabenaufteilung von 15 angeben, startet Cloudtask automatisch weitere 10 Worker.

Wann werden die Arbeiter automatisch vernichtet?

Um die Nutzungsgebühren für Cloud-Server zu minimieren, zerstört Cloudtask die von ihm gestarteten Mitarbeiter, sobald ihnen die Arbeit ausgeht.

Cloudtask übernimmt jedoch nur die Verantwortung für die Zerstörung von Arbeitern, die es automatisch startet. Sie können Worker auch per Hand mit dem Befehl cloudtask-launch-workers starten und mit der Option --workers an cloudtask übergeben. In diesem Fall sind Sie für die Zerstörung von Arbeitern verantwortlich (z. B. mit dem Befehl cloudtask-destroy-workers).

Wie kann ich eine Aufgabe abbrechen?

Sie können eine Aufgabe jederzeit sicher abbrechen, indem Sie entweder:

1. Drücken von CTRL-C auf der Konsole, in der Cloudtask ausgeführt wird.
2. Verwenden Sie kill, um das TERM-Signal an cloudtask session pid zu senden.

Was passiert, wenn ich eine Aufgabe abbrechen?

Die Ausführung aller aktuell laufenden Jobs wird sofort abgebrochen. Jede Worker-Instanz, die automatisch von cloudtask gestartet wurde, wird so schnell wie möglich zerstört.

Um eine abgebrochene Sitzung später wieder aufnehmen zu können, wird der aktuelle Zustand der Aufgabe in der Aufgabensitzung gespeichert. Der Staat beschreibt, welche Jobs fertig ausgeführt wurden und welche Jobs noch im anhängigen Zustand sind.

Wenn die Aufgabe wieder aufgenommen wird, werden abgebrochene Jobs zusammen mit den anderen ausstehenden Jobs wieder ausgeführt.

Der Abbruch einer Aufgabe ist nicht sofort, da es zwischen wenigen Sekunden und einigen Minuten dauern kann, um eine Aufgabe sicher herunterzufahren. Zum Beispiel können EC2-Instanzen im ausstehenden Zustand nicht zerstört werden, so dass Cloudtask warten muss, bis sie zuerst den laufenden Zustand erreichen.