Beispielnutzungsszenario

Alon möchte alle TurnKey Linux Appliances mit den neuesten Sicherheitsupdates aktualisieren.

Er schreibt ein Skript, das den Namen eines Appliance als Argument akzeptiert, die neueste Version von Sourceforge herunterlädt, das Root-Dateisystem extrahiert und die Sicherheit installiert. Updates, packt das Root-Dateisystem in ein Appliance ISO um und lädt eine neue Version des Appliance zurück zu Sourceforge.

Nachdem er das Skript auf seiner lokalen Ubuntu-Workstation getestet hat, bittet er den Hub, eine neue TurnKey Core-Instanz (88.1.2.3) zu starten, sein Skript zu übertragen und alle Abhängigkeiten zu installieren. Sobald alles getestet ist, um zu funktionieren, erstellt er ein neues TKLBAM-Backup mit dem Status seines Master-Worker-Servers.

Alon führt seinen ersten Cloudtask-Test durch:

echo core | cloudtask --workers=88.1.2.3 refresh-iso-security-updates

Sobald er bestätigt, dass dieser einzelne Testjob korrekt funktioniert hat, ist er bereit für den großen Batch-Job, der parallel auf 10 Servern ausgeführt wird.

Da es sich um eine Routineaufgabe handelt, die Alon regelmäßig wiederholen möchte, erstellt er dafür eine vorkonfigurierte Cloudtask-Vorlage in $HOME/Cloudtasks:

$ mkdir $HOME/cloudtasks
$ cd $HOME/cloudtasks

$ cat > refresh-iso << 'EOF'
from cloudtask import Task

class RefreshISO(Task):
    DESCRIPTION = "This task refreshes security updates on an ISO"
    BACKUP_ID = 123
    COMMAND = 'refresh-iso-security-updates'
    SPLIT = 10
    REPORT = 'mail: cloudtask@example.com alon@example.com liraz@example.com'

    HUB_APIKEY = 'BRDUKK3WDXY3CFQ'

RefreshISO.main()

EOF

$ chmod +x ./refresh-iso

$ cat $PATH_LIST_APPLIANCES | ./refresh-iso
About to launch 10 cloud servers to execute the following task:

  Parameter       Value
  ---------       -----

  jobs            40 (appengine .. zimbra)
  command         refresh-iso-security-updates
  hub-apikey      5YGVPEMHJHU5EA
  ec2-region      us-east-1
  ec2-size        m1.small
  ec2-type        s3
  user            root
  backup-id       123
  workers         -
  overlay         -
  post            -
  pre             -
  timeout         -
  report          mail: cloudtask@turnkeylinux.org liraz@turnkeylinux.org

Is this really what you want? [yes/no] yes

session 11 (pid 29709)
88.178.132.231 (29721): launched new worker
88.214.141.175 (29722): launched new worker
88.15.179.7 (29724): launched new worker
88.229.38.128 (29723): launched new worker

...

45 Minuten später erhält Alon eine E-Mail von cloudtask, dass der Job beendet ist. Im Textkörper befindet sich das Sitzungsprotokoll, in dem angegeben ist, ob Fehler bei einem Job erkannt wurden (z. B. Nicht-Null-Exitcode), wie lange die Sitzung dauerte, um zu laufen, usw.

Hätte er es gewollt, hätte Alon die Ausführung der Task-Jobs in Echtzeit verfolgen können, indem er die Worker-Logdateien mit einem Tailing versehen hätte:

tail -f ~/.cloudtask/11/workers/29721