Einleitung
In meiner Tätigkeit habe ich immer wieder das Vergnügen Kunden auf der Reise in die Microsoft Cloud zu begleiten. Während der Architektur Phase, in der wir uns grundsätzlich Gedanken über die Zielarchitektur in Azure machen, ist ein wichtiger Bestandteil die Erarbeitung eines Namenskonzeptes.
Während auch ich persönlich gerne gleich loslege, macht es hier klar Sinn inne zu halten und sich darüber Gedanken zu machen da eine Änderung an einem Namen einer Ressource im Nachgang nur schwer resp. gar nicht mehr möglich ist und dies dann nur noch über ein Redeployment machbar ist.
Azure Wizard / Marketplace
Während auch ich persönlich gerne gleich loslege, macht es hier klar Sinn inne zu halten und sich darüber Gedanken zu machen da eine Änderung an einem Namen einer Ressource im Nachgang nur schwer resp. gar nicht mehr möglich ist und dies dann nur noch über ein Redeployment machbar ist.
In Azure gibt es mehrere Möglichkeiten etwas zu deployen. Die meisten von Euch werden den «Wizard» kennen, also den Marketplace aufrufen und die geforderten Felder des Wizards abfüllen und dann zu deployen.
Sehen wir uns dies Mal Anhand eines Beispiels für eine neue virtuelle Maschine an.
Die Aufgabe des Wizards ist, uns die Arbeit möglichst einfach zu machen und daher auch nur die nötigsten Fragen zu stellen. Wir sehen hier, dass der Wizard im ersten Schritt nach folgenden Angaben fragt:
- Name der Ressource Gruppe
- Name der VM
- Benutzernamen für die VM
Wichtiger Hinweis
Dem aufmerksamen Leser ist vielleicht aufgefallen das der Name der VM «virtualmachine10» wie viele Zeichen hat? Genau, 16. Da dies eine Windows Maschine ist, sind jedoch nur 15 erlaubt, da NetBios nicht mehr handeln kann. Der Wizard wird hier nichts anmeckern, jedoch während dem Deployment den Namen auf 15 Zeichen kürzen! Daher bei Windows immer darauf achten das max. 15 Zeichen für den Hostnamen genutzt werden.
Bei der Disk wird nach gar keinem Namen gefragt.
Und bei den Netzwerk Komponenten wird automatisch ein neues Netzwerk vorgeschlagen inkl. öffentlicher IP.
Schauen wir uns mal an was der Wizard gemacht hat. Es ist unschwer zu erkennen, dass alle Ressourcen die so eine VM benötigt und für die wir keinen Namen vergeben haben, Azure hingeht und einen Namen generiert. Dies ist, insbesondere wenn man auf die Disk schaut, nicht gerade ein Highlight und in meinen Augen eher hässlich.
Es ist nicht so, dass wir nicht die Möglichkeit haben diese Angaben zu ändern, nur wird dies durch das Azure Template das als ARM Template vorliegt, einfach nicht abgefragt, also der Wizard fragt uns nicht wie wir die einzelnen Ressourcen denn nennen wollen, sondern erzeugt in der Laufzeit eigene Namen auf der Basis eines Namensgenerators der bestimmten Regeln folgt.
Wichtig auch hier- die Maschine wurde mit den 16 Zeichen deployt, sagt uns also so heisst die Maschine. Wenn wir uns jedoch auf die Maschine verbinden, sehen wir, dass der Namen gekürzt wurde.
Und nun?
Hier kann man nicht mehr viel machen, entweder so lassen und mit der Hässlichkeit leben oder dann löschen und es richtig machen.
Natürlich gibt es hier auch wieder verschiedene Wege dies anzugehen. Der gemeinsame Nenner aller Lösungen heisst jedoch einerseits eine Namenskonvention zu erstellen und anderseits alles in Azure über ein Deployment ausserhalb des Wizards zu lösen.
Mal abgesehen von der Hässlichkeit, skaliert der Wizard ja sowieso nicht, sprich ich möchte ja nicht für jede Ressource diesen Wizard durchgehen. Daher ist das Stichwort Automatisierung über das präferierte Werkzeugset. Dies könnten sein:
- Azure CLI
- Azure PowerShell
- ARM Templates, JSON
- Azure DevOps
- Github
- etc., etc., etc.
In diesem Artikel werde ich jedoch nicht auf diese Tools eingehen, dies wird ein anderer Artikel sein. Daher weiter mit der Namenskonvention.
Überlegungen
Es macht Sinn sich hier etwas Gedanken über die Anforderungen zu machen. Was benötige ich in einem Namen?
- Firmenname?
- Funktion?
- Dev? Prod? Test?
- Lokation?
Mein Team und ich gehen in der Regel vom Namen einer Windows VM aus. Wir haben hier die Limitierung von den 15 Zeichen und im Grundsatz versuchen wir diese Limite einzuhalten. Als Cloud Service Provider haben wir mit vielen verschiedenen Tenants zu tun und haben uns daher darauf geeinigt, dass wir obenstehenden Angaben alle im Namen wollen.
Ein Beispiel wie wir auf einen Namen für eine VM kommen:
tman-fs01-cwe
mit 14 Zeichen, also noch eines übrig. Die restlichen Ressourcen in Bezug auf diese VM erweitern wir dann entsprechend:
tman-fs01-cwe-rg für die Ressource Gruppe des Systems
tman-fs01-cwe-nic1 für die NIC 1 in dem System
tman-fs01-cwe-nic1-nsg für die NSG an der NIC1 in dem System
Fazit Azure Namenskonzept
Aufgrund des immer wiederkehrenden Aufbaus dieses Beispiels, ist es für jedermann ein leichtes am Namen zu erkennen was es ist und zu was es gehört. Dies ergibt einerseits eine besser lesbare Ansicht der Azure Ressourcen und anderseits eine Ordnung die nachvollziehbar ist.
Der Kunde und ihre Kollegen werden es Dir danken, wenn sie schnell erfassen können was in einem Tenant so vorliegt.
Diese Grundlage muss ausgebaut und am besten festgehalten werden, z.B. in einem Excel Dokument, wo alle möglichen eingesetzten Ressourcen aufgelistet sind und diese dann als Referenz gelten. So kann man dann auch einfach in die Automatisierung übergehen und in Scripten/Deployments von diesen Regeln ausgehen.