Infrastructure-as-Code (IaC), insbesondere mit Terraform, ist ein wesentlicher Bestandteil unserer Azure Foundation und ein grundlegendes Element jeder Cloud-Transformation. Ein strukturierter Einsatz von IaC beschleunigt die Adaption von Cloudservices sowie die Entwicklung neuer Produkte. Hier stellt sich nun die Frage: Wie fängt man am besten an?

Next Level Azure IaC: Azure Verified Modules

Azure Verified Module - IaC nach Microsoft Best Practices

Microsoft hat sich das Thema zur Brust genommen und mit den Azure Verified Modules (AVM) ein Framework zum strukturierten Deployment von Ressourcen in Azure nach Best Practices geschaffen.

AVM gibt es in drei verschiedenen Varianten:

  • Resource Modules - Deployment einer definierten Cloud Ressource
  • Pattern Modules - Deployment eines definierten Cloud Workloads
  • Utility Modules - Hilfsmodule, welche von Resource oder Pattern Modules verwendet werden

Um einen einheitlichen Standard sicherzustellen, hat Microsoft eine Reihe von Vorgaben festgelegt, die jede neue AVM-Ressource einhalten muss. Diese Aussage trifft sowohl auf Terraform als auch auf die eigene IaC-Sprache Bicep von Microsoft Azure zu.

Jedem AVM ist ein spezifischer Mitarbeiter von Microsoft zugewiesen, der für die Erstellung, Weiterentwicklung und Bearbeitung von Problemen verantwortlich ist.

Sämtliche verfügbaren Module sind als Open Source (MIT-Lizenz) in öffentlichen GitHub-Repositories der allgemeinen Azure GitHub Organisation ugänglich. Falls ein Modul Schwierigkeiten bereitet oder ein neuer Parameter nicht vorhanden ist, hat jeder die Möglichkeit, ein Problem zu melden oder aktiv an der Entwicklung mitzuwirken.

Wie fängt man mit AVM an?

AVM funktionieren wie alle anderen Module in Terraform oder Bicep; sie werden unabhängig aufgerufen und erhalten sämtliche erforderlichen Parameter. Die Vorgaben zur Erstellung von AVMs führen dazu, dass die notwendigen Parameter auf ein Minimum reduziert werden, um einen unkomplizierten Einstieg zu gewährleisten.

Beispiel Terraform: Für das Deployment einer virtuellen Maschine mit zusätzlicher Data Disk werden mindestens folgende Ressourcen in Azure benötigt:

  • azurerm_windows_virtual_machine oder azurerm_linux_virtual_machine
  • azurerm_network_interface
  • azurerm_managed_disk
  • azurerm_virtual_machine_data_disk_attachment<

Jede dieser Ressourcen hat gewisse erforderliche Parameter, die oft wiederkehren, wie beispielsweise der Name der Ressourcengruppe, die Zielregion der die Bezeichnung der eigentlichen Ressource.

Mit AVM wird der Aufruf im eigenen Code auf eine einzige Ressource mit den erforderlichen Parametern vereinfacht, die anschließend im Modul weiterverarbeitet werden. Da AVM die häufigsten Microsoft Best Practices bereits integriert, sind zahlreiche Parameter mit Standardwerten versehen, wodurch eine zusätzliche Konfiguration entfällt. Ein Beispiel hierfür ist bei vielen Modulen die Festlegung von TLS 1.2 als Standardwert oder die Blockierung des öffentlichen Zugriffs.

Was mache ich, wenn es noch kein AVM für meine Ressource gibt?

Die Open Source Lizenz von AVM ermöglicht es, auf Grundlage des Frameworks eigenständig mit der Entwicklung zu beginnen. Falls ein Mitarbeiter von Microsoft zu einem späteren Zeitpunkt die Erstellung einer offiziellen AVM-Ressource in Angriff nimmt, besteht die Möglichkeit, ganz im Sinne von Open Source, durch die bereits geleistete Vorarbeit zu unterstützen.

GKVM - glueckkanja ❤️ Open Source

Wir bei glueckkanja folgen genau diesem Ansatz und unterstützen unsere Kunden auch bei der Entwicklung von Modulen, die auf dem AVM-Framework basieren und anschließend der Öffentlichkeit zugänglich gemacht werden.

Wir bezeichnen diese Module als GKVM (GlueckKanja Verified Modules), weil sie nicht nur die Vorgaben der AVM berücksichtigen, sondern auch unsere persönlichen Erkenntnisse aus zahlreichen Projekten einfließen lassen.

GKVM Resouce Modules:

GKVM Pattern Modules:

Wir freuen uns über jedes Issue, das hilft, die Module mit weiteren Funktionen auszubauen!

Weiterführende Ressourcen