Azure: Export & Import von Ressourcengruppen (Preview-Status)

14. April 2016
Am 30. März 2016 stellte Microsoft Azure ein neues Feature zur Verfügung, welches bereits von vielen Nutzern gewünscht wurde: Die Möglichkeit, komplette Ressourcengruppen inkl. deren Konfigurationen zu ex- und wieder zu importieren.
 

Einstieg in die neue Exportfunktion

Der Export wird im Azure Preview-Portal vorgenommen und ist denkbar einfach:
 
 
In den Einstellungen der Ressourcengruppe existiert nun ein Button namens „Export template“ – hier wird das generierte template im JSON-Format angezeigt.
 
Es stehen nun drei Optionen zur Verfügung: Download, Save und Deploy. Über Deploy kann das Template bereits in einer dem Nutzer zugewiesenen Subscription deployt werden. Mit anderen Worten: Es lässt sich eine komplette Kopie einer Ressourcengruppe mit nur einem Klick erzeugen!
 
Ein userfreundliches Feature stellt auch die Option „Save Template“ dar: Nicht nur, dass man hier den aktuellen Stand der Ressourcengruppe sichern kann, was eine Art Backup darstellt, sodass man auf eine frühere Konfiguration zurückrollen kann – man kann darüber hinaus dieses template auch sharen:
 
 
Das Sharen funktioniert genauso, wie einen Nutzer auf eine Ressource oder Ressourcengruppe zu berechtigen.
 
Im Anschluss daran hat dieser Nutzer Zugriff auf das template und kann es sogleich unter seiner Subscription deployen.

Anpassungen

Anpassbar sind in diesem Fall jedoch nur die definierten Parameter. Möchte man das Deployment-Script noch weiter customizen (was zum jetzigen Zeitpunkt in vielen Fällen erforderlich ist, da es noch einige „Macken“ gibt), so steht das Template auch zum Download bereit.
 
Beim Herunterladen werden vier Dateien gespeichert: 
  • deploy.ps1
  • deploy.sh
  • parameters.json
  • template.json
Die beiden deploy-Dateien sind unabhängig voneinander. Je nachdem, ob man das Deployment mittels PowerShell oder Command Line ausführen will, kann man eine der beiden Script-Dateien verwenden.
 
Diese Script-Dateien erwarten einige grundlegende Parameter:
  • Subscription-ID
    • Die Subscription-ID, unter der das Deployment stattfinden soll
  • Ressourcengruppen-Name
    • Name der Ressourcengruppe, in welche die Ressourcen deployed werden sollen. 
    • Existiert die Ressourcengruppe bereits, so werden die Ressourcen in diese  deployed
    • Existiert die Ressourcengruppe noch nicht, so wird die Ressourcengruppe neu erstellt
  • Deploymentname
    • Der Deploymentname. Bisher noch ohne jegliche Verwendung, aber dennoch obligatorisch
  • RessourcengruppenLoaction [optional]
    • Existiert die Ressourcengruppe noch nicht, so wird eine Location für die Erstellung benötigt
 
Aktuell existiert noch ein Bug im Deploymentscript:
    if(!resourceGroupLocation) {

        $resourceGroupLocation = Read-Host "resourceGroupLocation";

    }
Wenn die Ressourcengruppe nicht existiert, so erfolgt eine if-Abfrage in welcher geprüft wird, ob die Ressourcengruppen-Location gesetzt ist – und hier ist auch der Fehler enthalten: Ein einfacher Typo-Fehler, bei dem das „$“ vor „resourceGroupLocation“ vergessen wurde. Die Zeile muss also korrekterweise lauten:
if(!$resourceGroupLocation) {
Hat man diesen Fehler manuell gefixt und in der parameters.json sämtliche Parameter mit den gewünschten Werten gefüllt, kann man das Template deployen:
.\deploy.ps1 –subscriptionID abcde-fghij-klmno-pqrst –resourceGroupName testRG –resourceGroupLocation westeurope –deploymentName myDeployment
Zu Beginn des Scripts erfolgt noch die Azure-übliche Authentifizierung per Popup-Loginfenster.
 
Soviel zum Einstieg in das neue Feature. Der interessantere Teil ist aber die Anpassung der parameters.json und template.json sowie der Hinweis auf einige Einschränkungen und Bugs, die zum jetzigen Zeitpunkt noch bestehen.
 
Prinzipiell werden sämtliche Ressourcen und deren Konfigurationen in der template.json definiert. Einige Parameter können vom template nicht übernommen werden und müssen neu vergeben werden. Dieser Teil ist für meine Begriffe noch ziemlich undurchsichtig: Es werden einige Parameter aufgelistet, die zwecks besserer Übersichtlichkeit und Aufwandseinsparung auch hätten weggelassen werden können. Dies betrifft beispielsweise die Standard Alert rule „CPUHigh appplan“, für welche man entscheiden kann, ob sie wirklich den Namen „CPUHigh appplan“ tragen soll oder man dies customizen möchte. Merkwürdigerweise ist die Vergabe eines individuellen alertrule-Namens an dieser Stelle möglich, wohingegen dies im Portal bei der „manuellen“ Erstellung nicht zur Auswahl steht. Ein anderes Beispiel ist der Name für die Firewallregeln eines SQL-Servers: Hier lässt sich zwar der Name der Regel, nicht aber die IP-Adresse über die parameters.json customizen. 
 
Wollte man tatsächlich sämtliche Konfigurationen über die parameters.json einstellen, dann müsste dies konsequenterweise auch für Locations, Skalierungen usw. gelten, was aber nicht der Fall ist.
 
Unverständlicherweise gibt es bei einer WebApp zwar die Möglichkeit, der neuen WebApp einen neuen Namen zu vergeben, dieser Parameter wird jedoch nur an einigen Stellen im Script herangezogen – an anderen Stellen wiederum nicht, obwohl er dort zwingend erforderlich wäre – aus diesem Grund ist auch die Erstellung einer WebApp über ein template aktuell nicht möglich: Es wird beim Erstellvorgang eine Exception geworfen, die besagt, dass der Hostname bereits existiert. Dieser muss also auf jeden Fall über die parameters.json veränderbar sein – das muss Microsoft unbedingt noch nachziehen.
 
Wer sich jedoch etwas mit dem JSON-Format und Azure auskennt, kann das template seinen Vorstellungen entsprechend anpassen – jedoch ist dies eigentlich nicht Sinn der Sache, da Microsoft bestrebt sein sollte, den Import so einfach wie möglich zu halten. Hier bietet sich also noch eine Menge Optimierungsbedarf seitens Azure an.

Problembehebungen

Das Problem mit der WebApp lässt sich folgendermaßen beheben:
 
In der template.json findet sich im Bereich des Ressourcentypes "Microsoft.Web/sites" ein Eintrag, welcher in etwa so aussieht:
"properties": {

                "name": "[parameters('sites_meineapp_name')]",

                "hostNames": [

                    "meineapp.azurewebsites.net"

                ],

                "enabledHostNames": [

                    "meineapp.azurewebsites.net",

                    "meineapp.scm.azurewebsites.net"

                ],
„meineapp.azurewebsites.net“ ist der angesprochene Hostname, welcher nicht über einen Parameter gebildet wird. Die drei Zeilen, die den Hostnamen enthalten, müssen also manuell auf den neuen, gewünschten Hostnamen angepasst werden.
 
Wenig überraschend ist zudem die Tatsache, dass sich lediglich Ressourcen, die über die neue ARM (Azure Ressource Manager) Schnittstelle erstellt wurden, als template exportieren lassen. Für alle anderen Ressourcen ist es daher fraglich, ob die Export-Funktion in Zukunft noch unterstützt wird.

Fazit

Zusammenfassend möchte ich, entgegen der großen Kritikpunkte, aber ein positives Fazit ziehen: Die Exportfunktion von Azure ist ein Feature, auf welches viele Entwickler schon lange gewartet haben. Es werden zwar noch nicht alle Ressourcen unterstützt und bei einigen Ressourcen ist eine eigenständige Konfiguration des templates notwendig, damit es überhaupt verwendet werden kann, aber erfahrene Azure Nutzer sollten damit nicht viele Probleme haben. Zudem stimmt der erste Eindruck positiv: Nach einigem Bugfixing, Erweiterung und Optimierungen seitens Azure ist hoffentlich bald eine bequeme Methode zum schnellen und einfachen ex- und importieren von Ressourcengruppen vorhanden.
 
Links:

Neuen Kommentar schreiben