Azure Automation: So klappt der Einstieg in die Runbook-Automatisierung

Azure Automation: Ein Portal voller Möglichkeiten

Das Azure-Automation-Portal enthält eine vergleichsweise rudimentäre, jedoch von Iteration zu Iteration brauchbarere integrierte Entwicklungsumgebung zum Entwickeln, Testen und Veröffentlichen von Runbooks. Die Ausführung eines Runbooks kann bei Bedarf manuell oder regelmäßig nach Zeitplan erfolgen. Darüber hinaus kann man Runbooks über Webhook genannte URLs auslösen. Der Status der laufenden und die Ergebnisse bereits ausgeführter Runbooks sind ebenfalls im Portal einsehbar.

Azure Automation enthält einen Speicher für Objekte wie Variablen, Zeitpläne, Anmeldedaten (natürlich verschlüsselt), Zertifikate und Konnektoren zu anderen Management-Systemen oder Clouds. Runbook-Autoren können sich dieser Informationen bedienen und so auf hart-kodierte Angaben im Runbook-Quelltext verzichten. Der Funktionsumfang von Azure Automation ist über den Import von „normalen“ PowerShell-Modulen bedarfsgerecht erweiterbar. Bezogen auf die Microsoft-Plattform scheinen die Möglichkeiten also nahezu unendlich.

So funktionieren Runbooks mit Azure Automation

Ein Runbook „erledigt“ die Aufgabe(n) eines in Azure Automation automatisierten IT-Prozesses. Hierzu bedient es sich nicht nur der oben erwähnten wiederverwendbaren Objekte (Variablen, Anmeldedaten etc.), sondern in erster Linie der importierten PowerShell-Module sowie anderer Runbooks. Ein Beispiel für einen einfachen IT-Prozess ist das Starten einer virtuellen Maschine. Ein komplexerer IT-Prozess wäre beispielsweise das Onboarding eines neuen Mitarbeiters. In diesem Szenario könnte ein Runbook beispielsweise das Provisioning einer VM in Azure übernehmen (und das Runbook zum Starten einer VM sozusagen als Sub-Routine nutzen).

Azure Automation unterscheidet zwischen verschiedenen Runbook-Typen:

• PowerShell-Runbook: ein natives PowerShell-Skript;
• Grafisches Runbook: ein mithilfe des in Azure Automation integrierten grafischen Editors erstelltes Runbook (hinter den Kulissen natives PowerShell);
• PowerShell Workflow-Runbook: ein auf PowerShell Workflow basierendes Skript;
• Zukünftige Typen: Bash- und Phython-Runbooks.

So geht’s: erste Schritte der Azure Automation

Um Azure Automation in Betrieb zu nehmen, müssen Sie den SaaS-Dienst zunächst Ihrem Abonnement hinzufügen. Melden Sie sich hierzu im Portal (portal.azure.com) an und gehen Sie in den Marketplace in die Kategorie Monitoring + Management. Alternativ können Sie einfach nach Automation suchen:

Zum Hinzufügen von Azure Automation sind nur wenige Angaben erforderlich:

• Name,
• Auswahl des Abonnements (voreingestellt, bei mehreren Abos aufpassen),
• Auswahl der Ressourcengruppe (oder neue erstellen),
• Auswahl des Cloud-Standorts,
• Auswahl ob RunAs-Konten erstellt werden oder nicht (standardmäßig ausgewählt, um Runbooks zur Verwaltung von Ressourcen in Azure Resource Manager (ARM) oder Azure Service Management zu authentifizieren. Das Beispiel in diesem Artikel verwendet das RunAs-Konto.).

Nach wenigen Sekunden steht Azure Automation bereit und Ihr neues Automation-Konto öffnet sich automatisch. Darin finden Sie vier Demo- beziehungsweise Tutorial-Runbooks. Betrachten wir das Runbook AzureAutomationTutorial einmal etwas näher.

Nach der Auswahl des Runbooks erweitert sich das Portal und zeigt Informationen zum Runbook (zum Beispiel Status oder Runbook-Typ) sowie Optionen zu dessen Verwaltung an (zum Beispiel Starten, Ansicht, Bearbeiten, Einstellungen, Zeitplan).

Ein Klick auf Ansicht öffnet eine ausgegraute Nur-Lesen-Ansicht des Runbooks. Da es sich in diesem Fall um ein grafisches Runbook handelt, zeigt das Portal keinen Code, sondern nur ein Flussdiagramm:

In diesem Fall sind keine Programmier- beziehungsweise Scripting-Kenntnisse erforderlich, um den automatisierten Prozess zu erkennen: Das Runbook listet Namen und Typ aller derzeitigen Azure-Ressourcen im Abonnement auf.

Ein Klick auf Starten startet das Runbook beziehungsweise stellt dieses in die Warteschlange. Dort muss es warten, bis einer der in der Cloud-basierten Runbook-Worker das Runbook ausführt. Die Wartezeit ist abhängig vom Cloud-Standort und weiteren Faktoren.

Nach der Ausführung des Runbooks liefert das Portal alle Informationen zum Ergebnis. Im Beispiel konnte das Runbook erfolgreich die Ressourcen des Azure-Abonnements auflisten.

So wird ein Runbook für Azure Automation erstellt

Es gibt mehrere Möglichkeiten, wie Sie einem Automation-Konto eigene Runbooks hinzufügen können:

• Neue Runbooks erstellen (oft wird damit aber das Rad neu erfinden),
• Vorhandene Runbooks importieren (aus herkömmlicher .ps1-Datei oder einem zuvor exportiertem grafischen Runbook),
• Runbooks aus öffentlichen Katalog importieren. Quellen hierfür wären beispielsweise Microsoft TechNet Script Center oder PowerShell Gallery. In diesen durchsuchbaren, sortierbaren und filterbaren Katalogen sind hunderte von Runbooks zu finden. Ob diese brauchbar sind, darüber geben Indikatoren wie beispielsweise die durchschnittliche Bewertung der Nutzer und die Anzahl der Downloads Aufschluss.

Um Leerlaufkosten zu senken, möchten Sie vielleicht alle Azure-VMs in einer Ressourcengruppe bequem per Runbook herunterfahren. Natürlich können Sie hierzu bei Null anfangen und ein ganz neues Runbook entwickeln. Es lohnt sich allerdings, zuvor einen Blick in den Katalog zu werfen. Für standardmäßige Anwendungsfälle sind dort meistens Runbooks zu finden. In diesem Fall kommen sogar gleich drei Lösungen in Frage, von denen Anwender eine sogar mit fünf Sternen-bewertet haben:

Sobald man ein Runbook aus dem Katalog auswählt, zeigt das Portal weitere Details wie den Quelltext an und bietet zudem eine Import-Funktion an:

Klicken Sie auf Bearbeiten, um das Runbook in den Editor zu laden:

Im Quelltext des Runbooks findet sich ein Verweis auf ein Credential-Objekt namens DefaultAzureCredential. Das Runbook benötigt diese Information zur Authentifizierung in Azure per Add-AzureRmAccount:

Natürlich kann das Runbook nur funktionieren, wenn das entsprechende Credential-Objekt existiert. Der Editor bietet auf der linken Seite einen schnellen Zugriff auf die zur Verfügung stehenden Objekte. So stellen Sie mit wenigen Mausklicks fest, dass weder das referenzierte Credential-Objekt existiert, noch ein anderes in Frage kommt.

Was nun? Man könnte natürlich im betreffenden Abonnement einen Benutzer für Automatisierungszwecke und ein darauf referenzierendes Credential-Objekt mit dem passenden Namen erstellen. Einfacher ist es aber, eine RunAs-Verbindung anstelle eines Credential-Objekts zu nutzen. Azure Automation stellt einige RunAs automatisch bereit. Sie finden diese unter dem Objekt-Typ Verbindungen (siehe oben).Wie genau man das Runbook dazu bringt, die RunAs-Verbindung zu nutzen, verrät ein Blick in den Code des Runbooks AzureAutomationTutorialScript:

Schnell ist der relevante Code kopiert und in das aus dem Katalog importierte Runbook eingefügt:

Jetzt können Sie das Runbook mit einem Klick auf Testbereich testen. In diesem Zusammenhang ist der Begriff Test etwas irreführend, da auch der Test eines Runbooks den automatisierten Prozess tatsächlich mit all seinen erwünschten und durch eventuelle Bugs unerwünschten Konsequenzen ausführt. Das heißt in diesem Fall, dass gegebenenfalls laufende VMs tatsächlich heruntergefahren werden. Von daher ist es wichtig, Runbook-Tests grundsätzlich auf die Ressourcen einer Test-Umgebung beziehungsweise -Ressourcengruppe anzuwenden.

Die Ergebnisse des Runbook-Tests stellt das Portal in einer Art Konsolenfenster dar:

Da das Runbook erfolgreich abgeschlossen wurde (zwei virtuelle Maschinen wurden heruntergefahren), kann es nun veröffentlicht werden. Hierzu bietet der Editor eine entsprechende Funktion an:

Das veröffentlichte Runbook steht nun im Abonnement zur Verfügung und kann zum Beispiel per Zeitplan regelmäßig ausgeführt werden, um etwa VMs morgens zu starten und abends wieder herunterzufahren.

Das richtige Runbook-Design

Eine große Herausforderung bei Azure Automation, wie auch bei SMA, System Center Orchestrator oder den RBA-Suiten anderer Hersteller (zum Beispiel BMC, CA, HP, ServiceNow, Automic oder Ayehu), ist das Runbook-Design. In diesem Zusammenhang ist die Tatsache nicht zu unterschätzen, dass nur sauber definierte IT-Prozesse gut automatisierbar sind.

„In vielen Unternehmen ist die Automatisierung von IT-Infrastruktur noch eine Art Geheimwissenschaft, mit der sich nur wenige, manchmal sogar nur ein „Scripting Guy“ auskennen.“

Frank Peter Schultze, Fritz & Macziol

Somit ist auch die ITSM-Fraktion (IT Service Management) involviert. Vor allem bei umfangreicheren IT-Prozessen ist eine gut durchdachte Planung der Runbooks unverzichtbar. Eines der hilfreichsten Prinzipien lautet hierbei Teile und Herrsche, also die Zerlegung komplexer Aufgaben in einfache, tendenziell banale Teilaufgaben. Folgt man diesem Ansatz, besteht die Herausforderung darin, einen automatisierten IT-Prozess wie ein Puzzle mithilfe mehrerer wiederverwendbarer Teil-Lösungen zu realisieren. Bereits bei der Arbeit mit SMA hat sich eine Art Schichtenmodell zur Umsetzung komplexer Runbooks bewährt:

• Haupt-Runbook (geeigneter Runbooktyp: grafisches Runbook): Dieses Runbook repräsentiert die High-Level-Perspektive oder im weiteren Sinne die ITSM-/ITIL-Sicht (IT Infrastructure Library) auf den automatisierten IT-Prozess und die involvierten Teil-Prozesse. Das heißt das Haupt-Runbook steuert den definierten Workflow und nutzt zur Umsetzung der Einzelschritte weitestgehend Sub-Runbooks.
• Sub-Runbook (geeignete Runbooktypen: PowerShell-Runbook, PowerShell Workflow-Runbook): Dieses Runbook ist vergleichbar mit einer Sub-Routine und erledigt einen Teil-Prozess, nicht mehr. Hierzu bedient es sich weitestgehend der importierten PowerShell-Module beziehungsweise deren Cmdlets, Aktivitäten und Funktionen.
• PowerShell-Modul: Ein Modul bündelt thematisch zusammenhängende Funktionen, kapselt die damit verbundene Komplexität und gibt diese als Satz einfacher Befehle an den Nutzer des Modules (zum Beispiel ein Runbook) weiter.

Man sollte sich dabei keinesfalls nur auf den Import von Hersteller-Modulen beschränken. Auch der größte Teil des eigenen Codes sollte in Module ausgelagert sein, so dass er den Runbooks in vereinfachter und wiederverwendbarer Form zur Verfügung steht. Der Lohn der Mühe sind schlanke, robuste, wartungsarme Runbooks, während der erforderliche Wasserkopf an Code in Modulen schlummert.

IT-Automatisierung der Zukunft

In vielen Unternehmen ist die Automatisierung von IT-Infrastruktur noch eine Art Geheimwissenschaft, mit der sich nur wenige, manchmal sogar nur ein „Scripting Guy“ auskennen. Häufig ist das Wissen in reinen Skript-Sammlungen gebündelt und damit schwer zugänglich. RBA-Lösungen wie Azure Automation dagegen ermöglichen eine vergleichsweise einfache Verwaltung dieses Wissens, das wie oben beschrieben im Idealfall in PowerShell-Module zusammengefasst ist. Wo die Reise hingehen kann, zeigen Konzepte wie der Zugriff auf den Runbook-Katalog: Ziel ist es, eigene Lösungen anhand geteilter, wiederverwendbarer Automatisierungsartefakte zu realisieren.

Über den Autor:
Frank Peter Schultze ist Automatisierungsveteran mit zwanzig Jahren Erfahrung und PowerShell-Nutzer der ersten Stunde. Er plant, entwickelt und implementiert für die Kunden der Fritz & Macziol (künftig Axians IT Solutions) Lösungen zur Automatisierung und Orchestrierung ihrer IT-Infrastrukturen.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!