Mit den Grundlagen von ARM-Templates haben wir uns bereits vertraut gemacht. Um einen noch höheren Grad der Automatisierung zu erreichen, schauen wir uns an, was wir sonst noch mit ARM-Templates anstellen können.
Ergänzend zum vorherigen Teil über den Azure Resource Manager sei zunächst darauf hingewiesen, dass Microsoft mit den Azure Quickstarts ein umfangreiches GitHub-Repository mit ARM-Vorlagen öffentlich zu Verfügung stellt, das derzeit rund 1000 Vorlagen für IaaS- und PaaS-Bereitstellungen in Azure bereithält.
Diese Templates lässt sich gut als Quelle und Inspiration für eigenen Entwicklungen nutzen oder mehr oder unverändert direkt in Azure bereitstellen. Da ein Großteil der Vorlagen aber nicht von Microsoft selbst stammt und das Repository zudem öffentlich zugänglich ist, sollte jedes Template vor der Bereitstellung in einem produktiven Konto grundlegend überprüft werden.
Das Azure-Quickstart-Repository. (Bild: Drilling / Microsoft)Nehmen wir ein einfaches Beispiel und suchen nach einer Einzel-Linux-VM mit Ubuntu und grafischer Oberfläche. Hier findet sich z. B. „Ubuntu Gnome Desktop, VS Code, Azure CLI and RDP Support“ von Lee Scott. Folgt man dem Link, werden zunächst alle im Template definierten Parameter angezeigt. Oberhalb davon gibt es zwei Schaltflächen.
Mit „Deploy to Azure“ lässt sich das Template direkt in Azure-Portal bereitstellen. Mit „Auf GitHub suchen“ können die Deployment-Templates direkt auf GiHub angezeigt oder für eine Offline-Modifikation und Bereitstellung heruntergeladen werden. Beginnen wir mit dem Bereitstellen in Azure. Nach dem Klick auf die gleichnamige Schaltfläche landen Sie im Dialog für eine „vorlagenbasierte Bereitstellung“ im Azure-Portal und müssen nur noch die verbleibenden Parameter ausfüllen.
Optional hat man auch hier – wie schon im Teil 1 erläutert – noch einmal die Möglichkeit, entweder die Vorlage zu bearbeiten (Link „Vorlage bearbeiten“) oder das Parameter-File („Parameter bearbeiten“). Mit einem Klick auf „Überprüfen und erstellen“ ist die VM nach wenigen Minuten einsatzbereit und man kann sich mit einem beliebigen RDP-Client mit der Linux-VM verbinden, z. B. der mstsc.
Man beachte im Deployment den vorletzten Parameter „_artifacts Location“ mit dem Wert „[deployment().properties.templateLink.uri]“. Hierbei handelt es sich um den Basis-URI, in dem sich die von dieser Vorlage benötigten Artefakte befinden. Wenn die Vorlage mithilfe der begleitenden Skripts bereitgestellt wird, wird ein privater Speicherort im Abonnement verwendet und dieser Wert automatisch generiert.Alternativ hätte man die VM auch von der Quickstart-Seite aus auch direkt in PowerShell oder Azure CLI bereitstellen können, wahlweise aus der Cloud Shell oder von einem lokalen Rechner aus. Die entsprechenden Kommandos finden sich auf der Quickstart-Seite direkt unterhalb der Parameterliste.
PowerShell:
New-AzResourceGroupDeployment -ResourceGroupName <resource-group-name> -TemplateUri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/demos/ubuntu-desktop-gnome-rdp/azuredeploy.jsonAzure-CLI:
az group deployment create --resource-group <my-resource-group> --template-uri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/demos/ubuntu-desktop-gnome-rdp/azuredeploy.json
New-AzResourceGroupDeployment `
-locaton <location>
-ResourceGroupName <Resource-Group>
-TemplateFile <Pfad zum Template-File>
-TemplateParameterFile <Pfad zum Parameter-File>Azure-CLI:
az group deployment create -g <Resource-Group> --template-file azuredeploy.json \
--parameters "{ \"location\": { \"value\": \"<location>\" } }"Deployment skripten
Der Vorteil der Kommandozeile – egal ob PowerShell oder Azure CLI – besteht natürlich darin, dass sich Deployments auch hervorragend skripten lassen. Generell ist es egal, ob Sie das lieber in einem Bash- oder PowerShell-Kontext tun. Letztere zeichnet sich aber durch ihre objektorientierten Eigenschaften aus.
In der PowerShell kann man mit den entsprechenden PowerShell-Modulen im Übrigen nicht nur den Azure Resource Manager abfragen kann, sondern z. B. auch das Azure AD oder den Azure Resource Graph oder Log Analytics, welche Beide die Kusto Query Langue verwenden (KQL) ein Thema, dem wir uns in den nächsten Artikeln zuwenden wollen.
Nun aber zum programmgesteuerten Erzeugen von Ressourcen: Gehen wir davon aus, wir wollen fünf neuen VMs mit fünf unterschiedlichen Namen auf Basis der gleichen Konfiguration erzeugen; dann muss man natürlich nicht fünf Mal das gleiche Skript modifizieren und fünf Mal hintereinander ausführen. Vielmehr gibt man einfach die Namen der entsprechenden Parameter als Liste mit in die Schleife zur Erzeugung der VMs mit.
Das können abschließend z. B. so aussehen:
Das können abschließend z. B. so aussehen:
#Resource Group
$locationName = "westeurope"
$ResourceGroupName = "AZ-RG-DEMO"#Virtual Network
$networkName = "AZ-VNET"
$nicName = "NIC-"
$vnet = Get-AzVirtualNetwork -Name $NetworkName `
-ResourceGroupName $ResourceGroupName#Virtual Machines
$computerNames = @("VM01","VM02",”VM03","VM04","VM05")
$vmSize = "Standard_B2s"
$publisherName = "MicrosoftWindowsServer"
$offer = "WindowsServer"
$skus = "2019-Datacenter"$credential = Get-CredentialUnd dann die eigentliche Deployment-Schleife:
for($i = 0; $i -le $ComputerName.count -1; $i++) {
$NIC = New-AzNetworkInterface
-Name ($NICName+$ComputerName[$i]) `
-ResourceGroupName $ResourceGroupName `
-Location $LocationName `
-SubnetId $Vnet.Subnets[0].Id $VirtualMachine = New-AzVMConfig
-VMName $ComputerName[$i] `
-VMSize $VMSize $VirtualMachine = Set-AzVMOperatingSystem
-VM $VirtualMachine `
-Windows `
-ComputerName $ComputerName[$i] `
-Credential $Credential `
-ProvisionVMAgent `
-EnableAutoUpdate $VirtualMachine = Add-AzVMNetworkInterface
-VM $VirtualMachine `
-Id $NIC.Id $VirtualMachine = Set-AzVMSourceImage
-VM $VirtualMachine `
-PublisherName $publisherName `
-Offer $offer `
-Skus $skus `
-Version latest New-AzVM -ResourceGroupName $ResourceGroupName `
-Location $LocationName `
-VM $VirtualMachine `
-Verbose
}