Auf Los geht's los

von Thomas Drilling

Mit Azure Automation stellt Microsoft einen cloudbasierten Dienst für Automatisierungsaufgaben, das Verwalten von Updates für Betriebssysteme und die Konfigurationen für Azure- und Nicht-Azure-Umgebungen zur Verfügung. In Summe besteht der Dienst aus mehreren Toolsets, deren Zusammenspiel wir in diesem Workshop erläutern. Exemplarisch befassen wir uns dabei mit der VM-Updateverwaltung und dem VM-Neustart.

Azure Automation kümmert sich mitnichten nur um Automatisierungsaufgaben in und für Azure, sondern versteht sich als cloudbasierter Dienst, der Automatisierungsfunktionen für unterschiedlichste Szenarien bereitstellt. Diese lassen sich grob in drei grundlegende Bereiche einteilen. Alle drei nutzen eine Reihe von Funktionen von Azure Automation gemeinsam, wie zum Beispiel Zeitpläne, Module, Anmeldeinformationen oder Zertifikate.

Der erste Bereich umfasst das wiederholbare und konsistente Bereitstellen von Infrastruktur nach dem Infrastructure-as-Code-Prinzip. Azure Resource Manager Templates (ARM), Azure Bicep und Terraform sind drei populäre hierzu einsetzbare Technologien. Ein weiterer großer Sektor dreht sich um die ereignisbasierte Automatisierung, etwa zum Zweck der Problemdiagnose und -behebung.

Möglich ist auch eine automatische Bedrohungsanalyse im Zusammenhang mit dem automatisierten Erstellen von zugehörigen Incidents in einem SIEM-System (Security Information and Event Management) – etwa Microsoft Sentinel, das neben vielen Azure- und Microsoft-spezifischen auch weit über 100 Kollektoren für Drittanbietersysteme mitbringt.

Der dritte große Bereich betrifft die Orchestrierung und Integration einer Automatisierung in andere Azure-Dienste und Drittanbieterprodukte. Im Bereich der Integration ist wenig überraschend, dass zahlreiche Azure-Dienste bereits mit Azure Automation interagieren. Selbst wenn Sie sich also noch nicht aktiv mit Azure Automation befasst haben, dürften Sie indirekt schon das eine oder andere Mal mit dem Dienst in Berührung gekommen sein, etwa beim Erstellen einer virtuellen Maschine in Azure. Auch die Funktion "Automatisch herunterfahren" im Abschnitt "Vorgänge" jeder Azure-VM basiert auf Azure Automation. Im Folgenden zeigen wir weitere Anwendungsbeispiele auf.

Automatische Gastsystem-Patches

Im Bereitstellungsassistenten für eine neue VM im Azure-Portal haben Sie unter "Verwaltung" seit einiger Zeit die Möglichkeit, im Abschnitt "Updates für das Gastbetriebssystem" eine Reihe von Optionen für die Patchorchestrierung auszuwählen, zum Beispiel "Automatisch durch Betriebssystem (automatische Windows Updates)". Dies funktioniert allerdings nur für ausgewählte Betriebssysteme. Das sind zum Beispiel Windows Server 2008 R2 SP1, 2012 R2 Datacenter, 2016 Datacenter und 2019 Datacenter.

Im Wesentlichen unterstützt Azure automatische Gastsystem-Patches, die bedarfsgesteuerte Patchbewertung und bedarfsbasierte Patchinstallation lediglich für solche VMs, die Sie aus Images erstellen, die exakt die korrekte Kombination aus Herausgeber, Angebot und SKU (Stock Keeping Unit) innerhalb der Liste prinzipiell unterstützter Betriebssystemimages aufweisen. Damit fallen leider benutzerdefinierte Images oder andere Herausgeber-, Angebots- und SKU-Kombinationen aus dem Raster.

Außerdem muss die VM selbst eine ganze Reihe von Anforderungen erfüllen, damit Gastsystem-Patches funktionieren. So muss auf der betreffenden VM beispielsweise der Azure-VM-Agent für Windows oder Linux installiert sein. Ferner muss bei Windows-VMs der Windows-Update-Dienst für virtuelle Windows-Rechner ausgeführt werden. Selbstverständlich muss die VM auf die konfigurierten Update-Endpunkte zugreifen können, etwa wenn die VM für die Nutzung privater Repositories für Linux oder WSUS bei Windows-VMs konfiguriert ist. Natürlich können Sie das Gastsystem-Patching auch via PowerShell mittels

oder per Azure-CLI mit

beim Erstellen einer VM oder über die REST-API aktivieren.

Ist das Gastsystem-Patching aktiviert, sorgt die Automatisierung im Hintergrund (dazu später mehr) dafür, dass die verfügbaren kritischen und Sicherheitspatches heruntergeladen und automatisch auf die VM angewendet werden. Der Prozess startet automatisch jeden Monat oder wenn Microsoft neue Patches freigibt, wobei Patchbewertung und -installation automatisch erfolgen, was allerdings unter Umständen einen Neustart der VM erfordert. Um zu ermitteln, ob anwendbare Patches vorliegen, prüft der Mechanismus jede VM regelmäßig in einem Zeitraum von 30 Tagen.

Das Installieren selbst kann an einem beliebigen Tag, aber nicht zu Spitzenzeiten der VM passieren, wobei die automatische Bewertung dafür sorgt, den optimalen Zeitpunkt zu finden. Bei unterstützten Gastbetriebssystemen wie etwa Windows Server 2022 können Sie an dieser Stelle auch den Haken bei "Hotpatch aktivieren" setzen. Die Aktualisierung des Gastsystems läuft dann ohne Neustart der VM ab.

Beachten Sie aber: Definitionsupdates oder andere nicht als kritisch oder Security-relevant klassifizierte Patches kommen nicht automatisch durch die beschriebene Funktionalität des Guest-Patchings auf die Maschine. Hierfür oder wenn Sie Patches mit anderen Patcheinstufungen beziehungsweise in einem benutzerdefinierten Wartungsfenster installieren möchten, benötigen Sie die Updateverwaltung, die uns zum Dienst Azure Automation führt. Hierzu klicken Sie bei einer bestehenden Azure-VM im Abschnitt "Vorgänge" auf "Gast- und Hostupdates" und dort auf "Zu Updateverwaltung wechseln".

Updateverwaltung auch ohne Azure Automation

Die Updateverwaltung ist eine Funktion von Azure Automation und prinzipiell ein Dienst, der im Feature-Umfang jeder Azure-VM enthalten ist. Um den Dienst nutzen zu können, benötigen Sie einen Azure-Log-Analytics-Workspace und ein sogenanntes Automationskonto in Azure Automation. Die Kosten richten sich nach der Menge an Logdaten, die Sie in Log Analytics speichern. Der Dienst selbst kostet nichts. Wenn Sie noch keinen Automation-Account und keinen Log-Analytics-Arbeitsbereich haben, können Sie beide im Zuge der Bereitstellung der Aktualisierungsverwaltung anlegen. Dazu muss die VM eingeschaltet sein.

Wie die Updateverwaltung von Azure genau arbeitet, lässt sich Bild 2 entnehmen. Es zeigt, wie Windows-Server in Azure oder lokal über die Azure-Aktualisierungsverwaltung Updates beziehen. Dabei ist zu erkennen, dass der zu aktualisierende Server – das kann eine Azure-VM oder Nicht-Azure-VM sein – als Datenquelle mit einem Look-Analytics-Workspace verbunden ist. Trotzdem existiert eine Trennung zwischen dem oberen Teil, der Azure Automation betrifft, und dem unteren, der das eigentliche Patching mit WSUS oder Microsoft Updates Service illustriert.

Mit der Log-Analytics-Integration ist jeder Server prinzipiell dazu in der Lage, die entsprechenden Informationen in den Arbeitsbereich zu schreiben: über welche Updates er bereits verfügt beziehungsweise welche fehlen. Diese Zustände bringt er über seinen lokalen Windows-Update-Client in Erfahrung, weil er wahlweise mit Microsoft Update oder einem WSUS-Server kommuniziert. Für diese Informationen braucht er die Azure-Aktualisierungsverwaltung nicht zwingend und könnte Updates auch ohne Azure-Updatemanagement installieren.

Das Updatemanagement via Azure dient also in erster Linie dazu, den optimalen Zeitpunkt für das Patching zu ermitteln und den Server dann anzuweisen, den Patch einzuspielen. Das Azure-Updatemanagement dient also primär der effizienten Orchestrierung des Patchings. Die eigentliche Bereitstellung der Aktualisierungen erfolgt also über Microsoft Update oder WSUS. Achtung: Ist der Windows Update Agent (WUA) für das Senden von Meldungen an WSUS konfiguriert, differieren die Ergebnisse unter Umständen von den angezeigten Microsoft-Update-Ergebnissen, je nach dem, wann WSUS zuletzt mit Microsoft Update synchronisiert wurde. Azure Automation ist also selbst weder an der Bereitstellung noch an der Installation der Patches beteiligt.

Microsoft bringt Azure Automation im Wesentlichen mit OS-Updates in Zusammenhang. Mit der Aktualisierungsverwaltung lassen sich zum Beispiel im Zusammenhang mit WSUS aber alle Arten von Patches orchestrieren. Da das WSUS-Patching über Gruppenrichtlinien gesteuert wird, können Sie den Server also auch ohne einen Zeitplan in Azure Automation patchen und den Dienst lediglich für das Reporting in Log Analytics verwenden, Sie müssen Patches also nicht zwingend über Azure Automation verteilen.

Mehr Updatekomfort mit Azure Automation

Azure Automation bietet bei der Updateverwaltung jedoch deutlich mehr Komfort. Rufen Sie Azure Automation im Azure-Portal auf, finden Sie im Abschnitt "Updateverwaltung" alle Systeme, auf denen die Updateverwaltung konfiguriert ist. Hier lässt sich auch feststellen, ob auf dem überwachten System der Update-Agent bereit ist. Fehlen wichtige Updates, lautet der Status hier "nicht konform". Als Genehmigungsquelle nutzen wir in unserem Beispiel "Windows Update" und die "Einstellung für automatische Windows-Updates" ist "Scheduled Installation".

Um nun eine Bereitstellung zu planen, klicken Sie auf "Updatebereitstellung planen". Die Einstellungsmöglichkeiten für eine "Neue Updatebereitstellung" mit "zu aktualisierende Computer", "Updateklassifizierungen", "Zeitplaneinstellungen", "Wartungsfenster" et cetera sind weitgehend selbsterklärend. Bei den "Neustartoptionen" müssen Sie nach Bedarf entscheiden, ob Sie, sofern erforderlich, einen automatischen Neustart wünschen.

Statt die Updateverwaltung aus der VM heraus zu aktivieren, können Sie optional auch direkt von hier aus (Updateverwaltung) mit "+ Azure-VM hinzufügen" aktiv Azure-VMs hinzufügen. Auf den bereits erwähnten verknüpften Log-Analytics-Arbeitsbereich greifen Sie im Abschnitt "Verwandte Ressourcen / Verknüpfter Arbeitsbereich" zu.

Mit der Updateverwaltung von Azure Automation lassen sich nicht zuletzt die in Bild 2 aufgeführten Pre-Steps und Post-Steps als Azure-Automation-Runbooks zur Verfügung stellen. Deren Verarbeitung erzwingen Sie dann über den Automation-Zeitplan. Solche Skripte laufen immer auf der Azure-Plattform und nicht innerhalb der VM. Sie könnten sie zum Beispiel im Zusammenhang mit dem automatischen Start (und Stop) von Azure-VMs nutzen, um etwa VMs zu aktualisieren, die zum gewünschten Zeitpunkt normalerweise ausgeschaltet sind.

Möchten Sie, dass solche Automation-Runbooks auch Aktionen "innerhalb" der VM auslösen, muss auf der VM ein sogenannter "Hybrid Runbook Worker" laufen. Das erstmalige Aktivieren der Aktualisierungsverwaltung kann bis zu 15 Minuten in Anspruch nehmen.

Runbooks nutzen

Zurück zur VM selbst. Wer genau hinsieht, findet im Abschnitt "Vorgänge" auch die Funktion "Automatisch herunterfahren". Dieses Feature steht ebenso beim Neuerstellen einer VM im Abschnitt "Verwaltung" bereit und hilft insbesondere Einsteigern dabei, unnötige Kosten zu vermeiden, indem VMs zum Beispiel nach 18 Uhr herunterfahren. Das Feature macht sich die Prozessautomatisierung in Azure automatisch zunutze. Über einen Webhook oder eine E-Mail können Sie sich vom Herunterfahren benachrichtigen lassen.

Allerdings fehlt eine einfache Konfigurationsmöglichkeit zum automatischen Starten von VMs. Hier können Sie für Abhilfe sorgen, indem Sie in Azure Automation ein Runbook in Kombination mit einem passenden Zeitplan verwenden. Wechseln Sie dazu in Ihrem Automation-Account zum Abschnitt "Prozessautomatisierung", dann zu "Runbooks" und dort auf "+ Runbook erstellen". Wer sich schon mal mit PowerShell Runbooks oder auch Power Automate der Microsoft-Power-Plattform auseinandergesetzt hat, wird sich hier schnell zurechtfinden. Azure unterstützt Runbooks vom Typ "PowerShell", "PowerShell-Workflow", "PowerShell (grafisch)" und "Python".

Möchten Sie mit der Technik nicht bei null anfangen, bietet Microsoft mit einem Klick auf "Katalog durchsuchen" Zugriff auf eine umfangreiche Galerie fertiger Runbooks, von denen Sie sich inspirieren lassen können. Hier finden Sie zum Beispiel "Stop Start AzureVM (Scheduled VM Shutdown/Startup)", ein PowerShell-Workflow-Runbook. Es stellt mithilfe von Automation-Anmeldeinformationen eine Verbindung mit Microsoft Azure her und startet/stoppt parallel eine VM/eine Liste von VMs oder alle VMs in einem Abonnement.

Mit einem Klick auf "Auswählen" importieren Sie das Runbook über die gleichnamige Schaltfläche. Es erscheint dann im Runbook-Editor im Knoten "RUNBOOKS / Alle". Über den Menüpunkt "Testbereich" testen Sie das Runbook. Geben Sie dazu Ihre Azure-SubscriptionID, VM oder Liste der gewünschten VMs und die gewünschte Action (Start / Stop) als String-Parameter an. Mit "Starten" initiieren Sie dann den Testlauf. Allerdings müssen Sie zuvor noch Credentials festlegen, mit denen das Runbook laufen soll. Dies erledigen Sie in Azure Automation im Abschnitt "Freigegebene Ressouren / Anmel-deinformationen". Auf diese Weise müssen Sie keine Anmeldeinformationen in den Quellcode einbetten.

Nun sollten Sie das PowerShell-Workflow-Runbook zum automatischen VM-Start/Stop testen können, da die Credentials in dessen Code nur referenziert werden:

Mehr Flexibilität bieten jedoch PowerShell-Runbooks. Suchen Sie zum Beispiel im Runbook-Katalog nach dem PowerShell-Runbook "Stop / Start all or only tagged Azure VMs" und importieren es unter einem Namen ihrer Wahl. Das Runbook ist sogar kompatibel mit PowerShell Core und stellt mithilfe eines sogenannten "ausführenden Automations-Kontos" (Run-as-Account) eine Verbindung zu Azure her, ruft den Energiestatus der VMs ab (gestartet, gestoppt, de-allokiert) und schaltet die ein-/ausgeschalteten der Reihe nach aus/ein, wozu die betreffenden VMs optional sogar über ein passendes Tag verfügen dürfen.

Alternativ zu den oben eingesetzten Anmeldeinformationen müssen Sie nun unter "Kontoeinstellungen / Ausführende Konten" auch einen so genannten Run-As-Account erstellen, um diesen für die Authentifizierung im Runbook nutzen zu können. Der Run-As-Account verfügt dann über eine eigene Anwendungs-ID nebst Fingerabdruck. Die Run-As-Connection taucht zudem unter "Freigegebene Ressourcen / Verbindungen" auf. Der Listing-Kasten zeigt, wie Sie die Authentifizierung des Runbooks über einen Dienstprinzipal steuern.

Auch dieses Runbook sollten Sie zunächst testen. Es erwartet als Parameter eine Action (Start / Stop) sowie optional den gewünschten Tag-Name nebst Value. Das Skript lässt sich mit entsprechenden PowerShell-Kenntnissen beliebig ausbauen. So können Sie VMs nicht nur in einer Subskription oder einem Environment suchen, sondern zum Beispiel auch in der alten Azure-Deutschland-Cloud von T-Systems.

Verläuft der Test erfolgreich, veröffentlichen Sie das Runbook und können es anschließend verwenden. Um den Vorgang schließlich zu automatisieren, müssen Sie es nach der Veröffentlichung nur noch in einen Zeitplan einbinden. Dies erledigen Sie in Azure Automation im Abschnitt "Freigegebene Ressourcen / Zeitpläne" mit "+ Zeitplan hinzufügen". Natürlich können Sie das Runbook auch jederzeit manuell starten und sich bei Bedarf im Tab "Protokolle" die zugehörigen Logs ansehen.

Fazit

Azure Automation ist sehr leistungsfähig und umfasst zahlreiche Aspekte, die wir uns in diesem Beitrag nicht alle ansehen konnten. Andere Bereiche der Automatisierung im Rahmen der Infrastrukturbereitstellung oder des Konfigurationsmanagements hätten den Rahmen des Beitrags gesprengt. Da sich zum Beispiel mit einem PowerShell- oder Python-Runbook nahezu jede Art von Azure-Ressource erzeugen oder ansteuern lässt, sind der Fantasie ohnehin kaum Grenzen gesetzt.