Azure Resource Manager (ARM) – Teil 1


Das neue Azure-Portal (Codename Ibiza) ist ja seit kurzem verfügbar (also jetzt offiziell und nicht mehr nur als “Vorschau-Portal”). Damit steht auch eine neue Art der Bereitstellung zur Verfügung, nämlich ARM, der Azure Resource Manager. Höchste Zeit, sich etwas intensiver damit zu beschäftigen. Nur zur Abgrenzung: Dies wird kein Lehrgang zu “Wie bediene ich das neue Portal?”, mit etwas Beschäftigung geht das fast von alleine. Vielmehr möchte ich auf die neuen Möglichkeiten eingehen, die sich mit ARM ergeben.

ARM ist ein neuer “Deployment Manager” zur Bereitstellung von Ressourcen in Azure. Er basiert auf dem Konzept von Ressourcengruppen (RG), die wiederum verschiedene Ressourcen (quasi die kleinste Einheit in Azure) beinhalten. VMs, VNet, Storage sind alles Beispiele für Ressourcen. (Ganz nebenbei ein grammatikalischer Hinweis: Im Deutschen schreibt man Ressourcen mit Doppel-“s”, im Englischen nur mit einem “s”, daher die unterschiedliche Schreibweise hier im Artikel…).

ARM hat zwei große Vorteile gegenüber der klassischen Art, Services zu managen. Zum einen erlaubt es uns, komplette Umgebungen genau zu beschreiben, bevor auch nur ein einziges Byte erzeugt wurde. “Desired-State Deployment” nennt sich das genauer gesagt, und man verwendet dazu sogenannte Templates. Zum anderen können wesentlich feiner Berechtigungen zugewiesen werden, als immer gleich mit der großen Keule den Co-Admin verwenden zu müssen. Man spricht dabei von RBAC, also Role Based Access Control, auch das sehen wir uns noch genauer an.

Am besten fangen wir mal an und melden uns einfach mal im neuen Portal an, um unserer erste RG zu erstellen. So mit der Oberfläche geht das etwas anschaulicher als nur mit Codezeilen. Ziemlich oben in der (linken) Liste steht “Ressourcengruppen” (ich verwende hier wie üblich die deutschen Bezeichnungen, man kann das im Portal über das Settings-Zahnrad einstellen). Einfach mal drauf klicken. Es erscheint eine Liste mit bereits vorhandenen RGs, die vordefiniert oder aus Inhalten des alten Portals generiert wurden. Wir ignorieren die erst mal und klicken oben auf “Hinzufügen”. Name vergeben und unten auf “Erstellen” klicken, und schon haben wir eine angelegt. Wen der Haken bei “An Dashboard anheften” gesetzt war, dann erscheint die RG später direkt auf unserer (personalisierbaren) Startseite.

Ziemlich einfach bis hierher, aber die RG ist ja auch noch leer… Also füllen, bitte! RG auswählen (bzw. sie geht automatisch auf), und erneut auf “Hinzufügen”. Wir wählen mal für den Anfang einen virtuellen Server, dazu einfach lostippen (in der Suchleiste “Windows Server” eingeben) und auswählen. Unten am Rand der nächsten Spalte kommt ein “Bereitstellungsmodell auswählen”, und da wählen wir natürlich nicht “Klassisch”, sondern “Ressourcen-Manager”. Dann einfach die notwendigen Schritte der Reihe nach erledigen:

  1. Grundlagen: Ein Name für die VM, und ein Admin-Konto samt Passwort. Die aktuelle Ressourcengruppe sollte da stehen, ansonsten auf den Pfeil nach rechts und auswählen.
  2. Größe: Hier findet sich eine Liste der empfohlenen Größen samt geschätzter Preisinfo. Es lassen sich aber auch alle anzeigen (rechts oben).
  3. Einstellungen: Hier kommen ganz viele Einstellungen, die wir fast alle einfach lassen. Vielleicht den Datenträgertyp auf “Standard” ändern und die Überwachung deaktivieren, wir testen ja bloß.
  4. Übersicht: Fasst noch einmal alles zusammen, und mit dem Klick auf “OK” geht’s los mit der Bereitstellung.

Nach mehr oder weniger Wartezeit finden wir eine neue Kachel auf unserer Portalstartseite, eben unsere Ressourcengruppe. Solange die Bereitstellung noch nicht abgeschlossen ist, führt uns diese Kachel zu Informationen über den Status, danach kommen wir direkt zu der Übersicht der RG. Wir können aber auch schon vorher über den Menüpunkt Ressourcengruppen (wie vorhin) unsere neue RG auswählen.

Wenn wir diese Gruppe öffnen, sehen wir auf einen Blick all diejenigen Ressourcen, die für den Betrieb der VM (das war ja unser Ausgangspunkt) notwendig sind. Bei mir sind das

  • ein virtueller Computer
  • eine Netzwerkschnittstelle
  • eine Netzwerksicherheitsgruppe 
  • eine öffentliche IP-Adresse 
  • ein virtuelles Netzwerk
  • ein Speicherkonto

Alles schön übersichtlich zusammengestellt, oder? Jede Ressource lässt sich direkt von hier editieren, da klappt dann rechts ein oder mehrere Menüseiten heraus, und unten drunter steht auch gleich Events, Alarme und die Kosten. Einfach mal testweise auf die VM und die anderen Ressourcen klicken und staunen…

Und jetzt mal ehrlich: Ist das nicht viel übersichtlicher, wenn ich die direkte Zuordnung sehen kann? Wenn man viele kleine Dinge in Azure ausprobiert hat, dann lungern da irgendwelche Speicherkonten rum oder VMs, von denen man nicht mehr so genau weiß, wo sie dazu gehören. Klar hat man das rausbekommen, in dem man an verschiedenen Stellen Informationen zusammen gesucht hat. Aber das war schon umständlich, oder? Da sind diese neuen Ressourcengruppen ein wahrer Segen, man sieht alles sofort an einer Stelle, man kann Rechte vergeben darauf, und man kann das – auch nicht zu unterschätzen – genauso einfach wieder alles löschen Smiley.

Noch ein Wort zum Bereitstellungsmodell von vorhin: Man kann da auch “Klassisch” auswählen, dann besteht die resultierende RG nur aus VM, VNet, Speicher und Clouddienst, eben ganz klassisch. Solche RGs sind dann auch – im Gegensatz zu den “Ressource-Manager”-RGs – im alten Portal sichtbar, aber eben wie von damals gewohnt nur als Einzel-Komponenten und nicht als Gruppe. Die neuen RGs sind im alten Portal nicht sichtbar. Ich würde dennoch wärmstens empfehlen, nur noch “Ressourcen-Manager” zu verwenden.

Im nächsten Blog werden wir uns mal ein Template zur Bereitstellung anschauen, und in weiteren Beiträgen dann auf PowerShell und sogar auf Visual Studio (o-ho!) zur Bereitstellung von RGs eingehen.

Stay tuned!

Comments (0)

Skip to main content