VMware Aria Automation Orchestrator ist ein sehr mächtiges Tool ist, das einerseits mit vielen fertigen Workflows ausgeliefert wird, es andererseits aber erlaubt, eigene Logik zu implementieren und andere Schnittstellen und Skripte aufzurufen. Mit dem Scriptable-Task etwa lässt sich eigene Logik in Form von Bash-, PowerShell- oder Batch-Skripten realisieren. Um Skripte an verschiedenen Stellen erneut einzusetzen, stellt Aria Automation Orchestrator Actions bereit. Diese lassen sich sehr einfach implementieren. Wir zeigen dies an einem Beispiel, wie Sie die Anzahl an vCPUs, die an eine VM gebunden sind, herausfinden können.

Dazu wechseln Sie in der Aria-Automation-Orchestrator-GUI auf die Seite "Library / Actions" und erzeugen eine neue Action. Als Erstes vergeben Sie einen Namen. Zusätzlich bedarf es eines Namens für ein Modul, das beim Anlegen der Action miterzeugt wird. Modulnamen sind ähnlich wie Package-Namen bei Java aufgebaut: Sie beginnen mit der Top-Level-Domäne und werden dann immer spezifischer. Beispielsweise könnten Sie "net.sclabs.vmware.vcenter" als Modulnamen heranziehen. Die Beschreibung ist optional. Anschließend wechseln Sie auf die Script-Registrierkarte. Wie bei Workflows auch, müssen Sie Input- und Output-Variablen definieren. Die Input-Variable benennen Sie "vm" und vergeben den Typ "VC:VirtualMachine", wobei das "VC" das Namenspräfix für allerlei Ressourcentypen im vCenter-Namespace ist. Als Return-Typ wählen Sie "number" aus:

return vm.config.hardware.numCPU

Anschließend klicken Sie auf "Create" und die Action ist erzeugt. In einem Workflow lassen sich Actions dann einfach per Drag-and-Drop von der Element-Liste auf der linken Seite in den Hauptbereich ziehen und dann das Action-Element entsprechend konfigurieren, sodass es auf das neue Element zeigt.

Logging und Fehlerbehandlung
Es ist wichtig, darauf zu achten, dass Workflows robust sind. Konkret bedeutet dies unter anderem, Fehlerbehandlung einzubauen, aber auch Logging zu betreiben, um im Problemfall mehr Informationen zur Verfügung zu haben. Zuerst zum Logging: Orchestrator bietet wie andere Software an, beim Logging verschiedene Log-Level zu nutzen. Dabei kennt Orchestrator die Level "Info", "Warning" und "Error" in der GUI als dedizierte Log-Elemente. Insgesamt sind die Level DEBUG, INFO, WARN, ERROR, TRACE und FATAL verfügbar.

Darüber hinaus unterscheidet Orchestrator beim Logging "System" und "Server". System-Logs liegen auf der Appliance im Dateisystem und Server-Logs in der Orchestrator-Datenbank. Letztere sind den Workflows zugeordnet und sollten bevorzugt Verwendung finden. Für das Logging gibt es spezielle Log-Elemente, die in der Elemente-Liste links in der Kategorie "Log" zu finden sind. Alternativ können Sie aus Code heraus loggen:

Server.log ("This is another log message");

Wichtig ist beim Loggen, dass Sie nicht aus Versehen sensitive Informationen protokollieren. Es gibt zwar einen Datentyp "SecureString", der sorgt aber nur dafür, dass entsprechende Werte nicht in der GUI erscheinen. Wollen Sie sicherstellen, dass derartige sensitive Daten gar nicht erst geloggt werden, müssen Sie sich etwas anderes überlegen. Eine Möglichkeit ist, sensitive Informationen wie Passwörter einfach zu ersetzen:

var username = "administrator";

var password = "P@ssw0rd";

System.log ("Username: " + username + " and Password: " + password.replace(password, "******");

Neben dem Logging ist die konkrete Fehlerbehandlung wichtig. Aus objektorientierten Sprachen ist das Konzept "Exceptions" bekannt, die Sie "werfen" und "fangen" können. Um einen Fehler in einem Scriptable-Task zu werfen, reicht:

throw ("An error has occurred!");

Wird eine Exception geworfen, aber nicht gefangen, bricht der Workflow ab und protokolliert die Fehlermeldung in der Datei "server.log" auf der Orchestrator-Appliance. Leider kennt JavaScript im Orchestrator kein entsprechendes Catch-Schlüsselwort. Dies bedeutet aber nicht, dass es keine Fehlerbehandlungsmöglichkeiten gibt – vielmehr können Sie dies in der Workflow-Logik selbst integrieren.

Dazu ist in jedem Element definierbar, was im Fehlerfall passieren soll. Bild 1 zeigt den leicht erweiterten Workflow aus dem Orchestrator-Einführungsartikel. So ist es möglich, für jedes Element ein weiteren Output-Pfad für den Fehlerfall zu definieren. Das Workflow-Element "Create simple virtual machine" bewirkt im Fehlerfall, dass der Workflow mit dem Element "Transient error?" fortfährt. Falls im Workflow ein unbehandelter Fehler auftrifft, lässt sich der globale Exception-Handler aufrufen.

ln/Dr. Guido Söldner

Im zweiten Teil der Workshopserie zeigen wir, wie Sie mithilfe des Guest Script Manager Skripte in einer VM ausführen.