Next Level Azure IaC: Azure Verified Modules
Infrastructure as Code (IaC), särskilt med Terraform, är en väsentlig del av vår Azure Foundation och ett grundläggande element i varje molntransformation. En strukturerad användning av IaC snabbar upp adoptionen av molntjänster liksom utvecklingen av nya produkter. Här uppstår nu frågan: Hur börjar man bäst?

Azure Verified Modules - IaC enligt Microsoft Best Practices
Microsoft har tagit tag i frågan och med Azure Verified Modules (AVM) skapat ett ramverk för strukturerad distribution av resurser i Azure enligt best practices.
AVM finns i tre olika varianter:
- Resource Modules - distribution av en definierad molnresurs
- Pattern Modules - distribution av en definierad molnworkload
- Utility Modules - hjälpmoduler som används av Resource eller Pattern Modules
För att säkerställa en enhetlig standard har Microsoft fastställt en rad krav som varje ny AVM-resurs måste uppfylla. Detta gäller såväl Terraform som Microsoft Azures egna IaC-språk Bicep.
Varje AVM tilldelas en specifik medarbetare på Microsoft, som ansvarar för att skapa, vidareutveckla och åtgärda problem.
Samtliga tillgängliga moduler är tillgängliga som open source (MIT-licens) i publika GitHub-repositorier i den allmänna Azure GitHub-organisationen. Om en modul ställer till problem eller en ny parameter saknas har alla möjlighet att rapportera ett problem eller aktivt bidra till utvecklingen.
Hur börjar man med AVM?
AVM fungerar som alla andra moduler i Terraform eller Bicep; de anropas oberoende och tar emot samtliga nödvändiga parametrar. Kraven för att skapa AVM leder till att de nödvändiga parametrarna reduceras till ett minimum, för att säkerställa ett okomplicerat första steg.
Exempel Terraform: För att distribuera en virtuell maskin med en ytterligare data disk krävs minst följande resurser i Azure:
- azurerm_windows_virtual_machine eller azurerm_linux_virtual_machine
- azurerm_network_interface
- azurerm_managed_disk
- azurerm_virtual_machine_data_disk_attachment<
Var och en av dessa resurser har vissa nödvändiga parametrar som ofta återkommer, till exempel namnet på resursgruppen, målregionen eller beteckningen på själva resursen.
Med AVM förenklas anropet i den egna koden till en enda resurs med de nödvändiga parametrarna, som sedan bearbetas vidare i modulen. Eftersom AVM redan har de vanligaste Microsoft best practices inbyggda är många parametrar försedda med standardvärden, vilket gör att ytterligare konfiguration inte behövs. Ett exempel på detta är att många moduler anger TLS 1.2 som standardvärde eller blockerar publik åtkomst.
Vad gör jag om det ännu inte finns någon AVM för min resurs?
Open source-licensen för AVM gör det möjligt att på egen hand börja utveckla utifrån ramverket. Om en medarbetare på Microsoft vid ett senare tillfälle tar sig an att skapa en officiell AVM-resurs finns möjligheten att, helt i open source-anda, bidra genom det förarbete som redan har gjorts.
GKVM - glueckkanja ❤️ Open Source
Vi på glueckkanja följer just detta tillvägagångssätt och stöttar även våra kunder i utvecklingen av moduler som bygger på AVM-ramverket och därefter görs tillgängliga för allmänheten.
Vi kallar dessa moduler för GKVM (GlueckKanja Verified Modules), eftersom de inte bara tar hänsyn till kraven i AVM utan också låter våra personliga insikter från ett stort antal projekt flyta in.
GKVM Resource Modules:
GKVM Pattern Modules:
Vi uppskattar varje issue som hjälper till att bygga ut modulerna med fler funktioner!















