Azure Standard Test Deployments (Teil 1)

Es kommt immer wieder vor, dass ich eine einfach Azure Testumgebung brauche, die meistens aus ein paar VMs und einem Netzwerk besteht. Dazu hab‘ ich mir mal ein paar Gedanken gemacht, wie man das automatisiert und standardisiert aufsetzen kann. Und daran wollte ich euch teilhaben lassen…

Vorbemerkung

Welche Probleme treten immer wieder auf, wenn man eine Testumgebung erzeugt?

• Die Namensgebung ist verschieden. Mal heißt die Netzwerkkarte „nic“, mal „nic1“.
• Die Zusammengehörigkeit ist unklar. Die VM heißt zum Beispiel „linux01“, die öffentliche IP Adresse dazu „ubuntu1“. Ein Namensschema hilf auch hier.
• Wird das noch gebraucht oder kann das weg? Hier bieten sich Tags an.
• Die Wiederverwendbarkeit. Zweimal durch das Portal klicken endet selten mit einem identischen Ergebnis. Stichwort Templates.
• Flexibilität. Ich brauche nicht für jedes Szenario ein Template, sondern kleine Bausteine, die sich sinnvoll kombinieren lassen.
• Komplexität. Wenn man in 2 Wochen nicht mehr weiß, wie das ging, dann fängt man von vorne an.

Gesucht war also etwas, das diese Punkte adressiert. Packen wir das mal Schritt für Schritt an. Damit das in einem einzigen Artikel nicht zu lange wird, habe ich das in mehrere Artikel aufgeteilt:

• Teil 1 (dieser hier) legt die Namenskonvention fest.
• Teil 2 behandelt Ressourcengruppen, VNet und NSG
• Teil 3 handelt von der VM und zugehörigen Ressourcen
• Teil 4 fasst das alles in einem PowerShell Skript zusammen
• Teil 5 macht noch ein paar Bemerkungen dazu.

Namenskonvention

Für eine Namenskonvention ist es hilfreich, sich zu überlegen, welche Teile einer klassischen Infrastruktur in Azure normalerweise benötigt werden, und dann zu entscheiden, wie man sie benennt. Meistens werden wohl zusammengesetzte Namen verwendet werden, und da gibt es die „Dashies“, die „Camels“, und „Nonies“. Nur damit man mal davon gehört hat:

• Dashies trennen einzelne Bestandteile durch einen Bindestrich („-„), einen Dash eben. win1-nic1 zum Beispiel.
• Camels verwenden Groß- und Kleinschreibung. Win1Nic1. Das Auf und Ab erinnert an Kamelhöcker, weshalb das auch „Camel Notation“ genannt wird.
• Nonies machen keine Unterschiede zwischen den Wortteilen (none eben). win1nic1 dann logischerweise.

Ich bin ein Verfechter der Camel Notation, wenn es um Benennung von Variablen geht, bei der Benennung von Ressourcen bin ich ein „Nonie“. Azure unterscheidet die Ressourcen nicht anhand Groß- und Kleinschreibung, Win1Nic1 ist die selbe NIC wie win1nic1 (oder WIn1nIC1). Und ein Bindestich ist ein vergeudetes Zeichen…

Und noch ein Wort zu angehängten Zahlen: Auch wenn jetzt schon absehbar wäre, dass diverse Ressourcen in Stückzahlen größer 9 verwendet werden, würde ich immer noch nicht auf „01“ statt „1“ gehen. Auch wenn die Sortierung dann schöner wäre. Ist aber Geschmackssache…

Ressourcengruppe

Alle Ressourcen sollten in einer gemeinsamen Ressourcengruppe liegen, das verdeutlicht die Zusammengehörigkeit. Ich hatte früher mal alle mit dem Prefix „rg“ benannt, bis ich gemerkt habe, dass das eigentlich keine Rolle spielt. Daher hab‘ ich es wieder weggelassen. Wichtig finde ich, dass man den Zweck der Gruppe rein bringt.

Geeignete Namen:

• adkundexy
• subnetrouting
• vlanpeering
• dockerdemoignite17

Eher ungeeignet und daher möglichst zu vermeiden sind Namen wie:

• test1
• adtest
• demo
• ralf23

Hier weiß in 2 Wochen kein Mensch mehr (den Ersteller eingeschlossen), ob das noch benötigt wird.

Auf jeden Fall biete es sich an, Tags für Ressourcengruppen zu verwenden. Ich hatte da mal einen Artikel dazu geschrieben. Ich verwende zum Beispiel den Tag „delete“ und setze ein (Verfalls)Datum von heute + 7 Tage rein. Ein kleiner Script läuft ab und zu durch und löscht alle Ressourcengruppen, deren Verfallsdatum abgelaufen ist…

Für diese Demo hier verwenden wir als Beispielname blogdemo.

Ressourcen

Virtual Network (VNet)

Bei den meisten Testumgebungen wird es das VNet nur einmal geben, für Tests wie VNetPeering oder Routing können aber durchaus mehrere notwendig sein. Daher ist eine Nummerierung zweckmäßig. Da sich meistens mehrere VMs im gleichen VNet aufhalten, und in der Hierarchie das VNet sich an der Ressourcengruppe orientiert (VM in VNet in Ressourcengruppe), nehme ich als Basisname für das VNet den Namen der Ressourcengruppe und hänge „vnet“ und eine Zahl an. Beispielsweise heißt das erste VNet in der Ressourcengruppe blogdemo folglich blogdemovnet1.

Subnet

Das Subnet oder die Subnets sind immer in einem VNet, daher bietet es sich an, den Namen des VNet zu übernehmen, gefolgt von „sub“ und einer Zahl. Das erste Subnet in obigem VNet wäre also blogdemovnet1sub1.

Network Security Group (NSG)

Bitte kein Deployment ohne NSG. Ich verteile immer gleich eine Standard-NSG pro Ressourcengruppe und binde die auch an das VNet und nicht an jede einzelne VM. In dieser NSG modifiziere ich dann immer per PowerShell die erlaubte eingehende IP Adresse auf meine gerade aktuelle IP und fühl mich gut dabei (siehe auch meinen früheren Blogartikel). Diese NSG heißt demzufolge blogdemonsg1.

Virtual Machines (VM)

Viele weitere Ressourcen drehen sich um diese VM herum, daher ist dieser Name besonders wichtig. Es wird wahrscheinlich mehrere davon geben, also sollten wir mit Zahlen  arbeiten, und auch hier den Zweck nicht vergessen. „dc1“ und „ms1“ ist wesentlich hilfreicher als „win1“ und „win2“. Eine Wiederholung der Ressourcengruppe ist nicht notwendig, die VM wird durch die Kombination von Gruppe und Name eindeutig. Der Name der VM selbst folgt dann keiner weiteren Konvention, das bleibt dem Ersteller überlassen. Manche bevorzugen es, den OS Typ oder die VM Größe noch mit rein zu bringen, bin ich nicht so der Fan. Das sind alles Infos, die nur einen Befehl entfernt sind… Wir bleiben für unser Beispiel hier mal bei dc1.

Disks

Der Name der Disk sollte sich am Namen der VM orientieren. Ob man jetzt zwischen „OSDisk“ und „Disk“ unterschieden muss – hm. Ich verwende einfach die „1“ für die OS Disk. Damit ergibt sich für die VM mit dem Namen „dc1“ die Disk dc1disk1.

Network Interface

Auch hier gilt das gleiche wie bei Disks, der Name der VM ist ausschlaggebend. Damit ergibt sich folgerichtig dc1nic1.

Public IP Adresse

Eine öffentliche IP Adresse (PIP, public IP) vergebe ich immer auch gleich, meistens will ich mich ja einloggen. Wir können es kurz machen: dc1pip1.

Zusammenfassung

Aus all dem ergibt sich folgende Benennung der Ressourcen für die Ressourcengruppe blogdemo und die VM dc1:

Ressource	nach Gruppe	nach VM
VNet	blogdemovnet1
Subnet	blogdemovnet1sub1
NSG	blogdemonsg1
Disk		dc1disk1
Nic		dc1nic1
PublicIP		dc1pip1

Weiter geht’s im nächsten Teil mit den ersten Deployments.