Im Cloud-nativen Umfeld ist es wichtig, Lösungen wiederholt in der Cloud auszurollen. Dabei gilt es zu gewährleisten, dass die zugrunde liegende „Infrastruktur als Code“ sich stets in einem zuverlässigen Zustand befindet.
In Rahmen der Migration in die Cloud führen viele Unternehmen agile Entwicklungsmethoden ein, z.B. um Releases in schnellen Iterationen bereitstellen zu können. Wird Infrastruktur Teil des iterativen Prozesses, verliert die Trennung zwischen Betrieb und Entwicklung an Bedeutung; Teams müssen Infrastruktur und Anwendungscode in einem einheitlichen Prozess verwalten.
Dazu ist es erforderlich, Bereitstellungen automatisiert im Rahmen der Infrastructure-as-Code-Methode verwenden zu können. Vergleichbar mit Hashicorps Terraform oder AWS Cloud Formation ist der Azure Resource Manager (ARM) der Bereitstellungs- und Verwaltungsdienst in der Microsoft-Cloud. Er stellt eine konsistente Verwaltungsebene dar, welche das automatisierbare und wiederholbare Erstellen, Aktualisieren und Löschen von Ressourcen in einem Azure-Konto ermöglicht.
Sobald ein Benutzer oder eine Applikation eine Anforderung mit Hilfe eines der Azure-Toolsets über eine der APIs oder SDKs sendet, wird diese vom Resource Manager aufgenommen. Diese authentifiziert und autorisiert die Anforderung und sendet sie dann an den zuständigen Azure-Dienst, welcher dann die angeforderte Aktion ausführt. Da ausnahmslos alle Anforderungen von der gleichen Resource-Manager-API verarbeitet werden, liefern auch alle Bereitstellungs-Tools konsistente Ergebnisse und Funktionen. So sind sämtliche Funktionen, die im Azure-Portal verfügbar sind, automatisch auch via PowerShell, Azure CLI, REST-APIs oder die Client-SDKs ansprechbar.
ARM-Konzepte
Unmittelbar mit dem Azure Resource Manager im Zusammenhang stehen die Begriffe und Konzepte „Ressource“ (ein in Azure verfügbare verwaltbares Element), „Ressourcengruppe“ (eine Art Container, der verwandte Ressourcen für eine Azure-Lösung gruppiert) und „Ressourcenanbieter“, der letztendlich den spezifischen Dienst darstellt, der eine Azure-Ressourcen bereitstellt.
Ressourcenanbieter gibt es Hunderte, von denen aber nur die wichtigsten (Compute, Network, Storage, Authorization usw.) per Default in Azure registriert sind. Sie finden sie im Azure Portal bei ausgewähltem Azure-Abonnement im Abschnitt „Einstellungen“ im Menü „Ressourcenanbieter“. Hier lassen sich bei Bedarf weitere Ressourcenanbieter registrieren.
ARM-Vorlagen
Schließlich gibt es die Resource-Manage-Templates. Hierbei handelt es sich ähnlich wie bei AWS Cloud Formation um eine JSON-Datei, mit deren Hilfe Sie eine oder mehrere Ressourcen im Rahmen der Bereitstellung in einer Ressourcengruppe deklarativ definieren können. Sie lässt sich dann zum konsistenten und wiederholten Bereitstellen der Ressourcen verwenden.
Die Struktur einer Ressource Manager Vorlage besteht aus den Abschnitten „Parameter“ (Werte, die erst im Laufe der Bereitstellung, angegeben werden und mit denen dieselbe Vorlage für verschiedene Umgebungen verwendet wird), „Variablen“ (Werte, die „in“ den Vorlagen wiederverwendet werden), optionalen „Benutzerdefinierten Funktionen“, den eigentlichen „Ressourcen“ und schließlich der „Ausgabe“-Sektion.
Vorlagen sind dabei ähnlich wie bei AWS schachtelbar und verknüpfbar, können Abhängigkeiten von Ressourcen definieren und Laufzeit-Hooks verarbeiten. Auf die Syntax und vielfältigen Möglichkeiten zur Ablaufsteuerung soll an dieser Stelle nicht näher eingegangen werden. Der Artikel widmet sich den Tools und Möglichkeiten, wie Sie vorlagenbasierte Deployments in Azure bereitstellen.
Vorlagen aus der GUI-Bereitstellung ableiten
Eine Azure-Ressource wie ein virtueller Computer lässt sich unter anderem im letzten Abschnitt des Bereitstellungs-Assistenten über die GUI bereitstellen. Hier besteht über den Reiter „Überprüfen und Erstellen“ die Möglichkeit, rechts unten auf den Link „Vorlage zur Automatisierung herunterladen“ zu klicken; so lässt sich der zuvor konfigurierte virtuelle Computer entweder optional vorlagenbasiert oder im Anschluss an die GUI-Bereitstellung (Klick auf „Erstellen“) automatisiert bereitstellen. Der Assistent zeigt dann die erzeugte Vorlage zunächst im Portal an.
Von hier aus lässt sich der konfigurierte Computer mit einem Klick auf „Bereitstellen“ in Azure bereitstellen oder die erstellte Vorlage mit einem Klick auf „Herunterladen“ auf dem eigenen Desktop archivieren. Der Download enthält ein ZIP-File mit dem Namen „Template“ und dieser wiederrum zwei Files „template.json“ und „parameter.json“. Beide haben Ihren Entsprechung in der im Azure-Portal generierten Version (siehe Abbildung).
Dabei erhöht es die Übersicht, dass das Template-File die eigentlichen Parameter im Abschnitt „parameters“ nur „benennt“, während die eigentlichen Werte in zugehörigen parameter-File referenziert sind. Während Sie nun die „Online“-Variante direkt im Azure-Portal bereitstellen könnten, lässt sich die Offline-Variante jederzeit wiederverwenden, um z. B. die betreffenden VM auch vom heimischen Arbeitsplatz aus bereitstellen zu können, ggf. mehrfach hintereinander mit geänderten Parametern.
Offline-Bereitstellung
Das können Sie wahlweise in der Powershell oder Powershell Core mit installiertem Azure-Az-Modul tun oder in der Azure-CLI, welche Sie wahlweise unter Windows, Mac OS oder Linux installieren können.
Bei der PowerShell-Variante müssen Sie sich zuerst mittels …
Connect-AzAccount… mit dem gewünschten Azure-Konto verbinden, wozu Sie auf ein Microsoft-Login-Fenster umgeleitet werden, um sich mit einem Microsoft-Organisationkonto anmelden zu können. Anschließend navigieren sie in das Verzeichnis, in dem Sie Ihre Deployment-Files entpackt haben. Nun könnten Sie wie folgt ein resourcegroup-basierendes Template-Deployment anstoßen:
New-AzResourceGroupDeployment `
-ResourceGroupName $rgName `
-TemplateFile <Path Template-File> `
-TemplateParameterFile <path Parameter-File>Allerdings müssen Sie zuvor noch einmal das Parameter-File für das Deployment anpassen, denn in den Zeilen 79 bis 81 steht momentan noch …
"adminPassword": {
"value": null
}
Der Grund ist der, dass aus manuell erstellten GUI-Deployments heraus aus Sicherheitsgründen keine eingegeben Passwörter übernommen werden. Hier ist nun entweder ein definierter Wert einzutragen oder der Parameter muss aus der Parameter-Datei entfernt und interaktiv übergeben werden. Zudem müssen Sie vorher die zu verwendende Ressourcengruppe anlegen (falls noch nicht geschehen) …