Wat is Infrastructure as Code (IaC) in Azure?

Je beschrijft je Azure infrastructuur (denk aan virtuele machines, netwerken en storage) in templates. Maar het gaat verder dan alleen IaaS: je kunt bijna alles automatiseren in Azure.

Denk aan PaaS services en serverless resources zoals Azure Functions, Azure Logic Apps, of zelfs access control policies, databases en database objecten – alles kan.

Voordelen van Infrastructure as Code (IaC)

IaC betekent dat je compute infrastructuur beheert via definities in code – in plaats van fysiek klikken of tools gebruiken met een UI.

De voordelen:

• Consistentie: Deployments zijn altijd gelijk, ongeacht omgeving.
• Versiebeheer: Tools zoals Bicep en Terraform geven je controle via Git. Je ziet alle aanpassingen, kunt terugrollen en samenwerken terwijl je een historie van je infrastructuur opbouwt.
• Snellere deployments: Minder downtime en sneller herstel bij problemen.
• Herbruikbaarheid: Of het nou test, dev of productie is: je draait overal dezelfde configuratie.
• Schaalbaarheid: Templates maken het makkelijk om op te schalen – betrouwbaar en herhaalbaar.
• Automatisering: IaC regelt alles – van provisioning tot teardown – automatisch. Minder fouten, snellere uitrol, hogere efficiëntie.

Infrastructure as Code en Disaster Recovery (DR)

Wat als je geen werkende backups meer hebt? Als je alles opnieuw moet opbouwen – servers, software – dan ben je wel even bezig…

Maar met Infrastructure as Code kun je je hele omgeving snel opnieuw opbouwen. Super belangrijk als je snel weer up-and-running moet zijn.

Hoe werkt Azure IaC?

We beantwoorden die vraag door te kijken naar hoe een typische workflow eruitziet bij het bouwen van Infrastructure as Code in Microsoft Azure:

1. Een developer of operator schrijft eerst de infrastructuurdefinitie in code – met tools zoals Azure Bicep, ARM templates, Terraform (of een andere tool).
2. Die code wordt gecommit naar een Git-repository.
3. Daarna wordt de wijziging gereviewd en gevalideerd – om te checken of het geen kwaadaardige code bevat en doet wat het moet doen.
4. Na goedkeuring wordt de wijziging gemerged en gaat het door een CI/CD pipeline.
5. Die pipeline bestaat meestal uit een build fase (met tests en checks) en een release fase.
6. In de release fase worden de resources daadwerkelijk aangemaakt in Azure.

Laten we er wat verder op inzoomen, beginnend bij de build fase.

Build fase

• In de build pipeline schrijven developers code en tests. Die worden verpakt in een artefact dat je kunt deployen in meerdere omgevingen.
• De pipeline doet syntax checks en scant op secrets, credentials, misconfiguraties en kwetsbaarheden.

Als er iets mis is, faalt de pipeline meteen. Zo voorkom je dat onveilige assets doorgaan naar de release fase.

Release fase

In de release fase verbindt de pipeline met Azure via een service principal of managed identity. Secrets (zoals wachtwoorden, keys, certificaten, connection strings) worden opgehaald uit Azure Key Vault. Je slaat secrets dus niet meer op in files, maar veilig in Key Vault.

De meeste IaC tools werken goed samen met Key Vault. De pipeline haalt de secrets op tijdens runtime, zonder dat developers zelf toegang hebben. Daardoor verklein je de kans dat secrets worden misbruikt of per ongeluk gelekt.

Daarna voert de IaC tool de deployment commando’s uit en past de configuratie toe op de Azure omgeving. Azure vergelijkt de gewenste staat uit je code met de huidige infrastructuur.

Als er verschillen zijn, onderneemt de tool actie – hij maakt ontbrekende resources aan, past bestaande aan, of verwijdert wat niet meer nodig is.
Zo blijft je omgeving altijd overeenkomen met wat er in de code staat.

Azure IaC Tools

Er zijn veel tools voor Infrastructure as Code. Welke jij kiest, hangt af van je situatie (je behoefte, omgeving, resources, etc.).

Azure Bicep

Azure Bicep is de native IaC-taal van Microsoft. Het wordt actief ontwikkeld, is volledig ondersteund en integreert goed met alle Azure tooling.

param location string = ‘East US’
param storageAccountName string = ‘mystorageaccount’
resource storageAccount ‘Microsoft.Storage/storageAccounts@2022-09-01’ =
{
name: storageAccountName
location: location kind: ‘StorageV2’
sku: { name: ‘Standard_LRS’ } }

Werk je met Azure? Dan is Bicep een goede keuze.

Het is een domain-specific language (DSL) die het makkelijker maakt om ARM templates te schrijven. Bicep is declaratief – je geeft aan wat je wilt, en Azure regelt de rest.

Het is veel leesbaarder en eenvoudiger dan ruwe JSON-templates zoals ARM. Bicep past perfect in het Microsoft ecosysteem.

 

Azure Resource Manager (ARM) Templates

Azure Resource Manager (ARM) templates zijn JSON-bestanden waarmee je Azure resources declaratief beschrijft. Ze zijn diep geïntegreerd met Azure, maar vrij complex om met de hand te schrijven of te onderhouden.

Daarom is Bicep ontwikkeld – als abstractielaag boven ARM templates, zodat het gebruiksgemak toeneemt.

 {
“$schema”: “https://schema.management.azure.com/schemas/2019-04-
01/deploymentTemplate.json#”,
“contentVersion”: “1.0.0.0”,
“resources”: [
{
“type”: “Microsoft.Storage/storageAccounts”,
“apiVersion”: “2022-09-01”,
“name”: “mystorageaccount”,
“location”: “East US”,
“sku”: {
“name”: “Standard_LRS”
},
“kind”: “StorageV2”
}
]
}

 

Terraform

Terraform is cloud-agnostisch. Je kunt er infrastructuur mee deployen over meerdere providers, niet alleen Azure. Net als Bicep is het declaratief. De taal die je gebruikt is HashiCorp Configuration Language (HCL) en is makkelijk te leren.

Werk je in een multi-cloud omgeving of wil je dat later gaan doen? Dan is Terraform een sterke optie.

Voor sommige features heb je wel een licentie nodig. In dat geval is OpenTofu ook interessant: een open-source alternatief dat onder de Linux Foundation valt.

Onderstaand voorbeeld laat zien hoe je een storage account aanmaakt met Terraform.

provider “azurerm” {
features {}
}
resource “azurerm_storage_account” “storage” {
name = “mystorageaccount”
resource_group_name = “myResourceGroup”
location = “East US”
account_tier = “Standard”
account_replication_type = “LRS”
}

 

Pulumi

In tegenstelling tot Bicep en Terraform laat Pulumi je infrastructuur schrijven in gewone programmeertalen zoals Python, TypeScript of C#. Handig voor developers die liever imperatief programmeren.

Pulumi geeft je veel flexibiliteit, maar vereist wel wat meer programmeerkennis.

Hieronder een voorbeeld van een storage account deployment met Pulumi (TypeScript).

import * as azure from “@pulumi/azure”;
const storageAccount = new azure.storage.Account(“storage”, {
name: “mystorageaccount”,
resourceGroupName: “myResourceGroup”,
location: “East US”,
accountTier: “Standard”,
accountReplicationType: “LRS”,
});

Hoe kies je de juiste IaC tool?

Er zijn veel tools die je kunt gebruiken. Maar stel jezelf (en je team) eerst deze vragen:

• Hebben jullie al ervaring met een specifieke IaC tool?
• Welke programmeerskills zijn er in het team? (C#, Go, JSON, TypeScript – of geen?)
• Welke cloud provider gebruik je? Oftewel: waar deploy je je resources?
• Hoe ziet jullie deploymentproces eruit?
• Wat zijn de eisen binnen de organisatie? Zijn er compliance verplichtingen?
• Heb je een imperatieve of declaratieve aanpak nodig?
• Wie beheert de IaC templates en waar worden die opgeslagen?
• Beheer je ook configuratie of alleen provisioning?
• Gebeuren er aanpassingen buiten de templates om?

Check welke talen je omgeving ondersteunt

Voordat je een IaC-taal kiest, check eerst wat er in je omgeving ondersteund wordt.

Hoe je dat aanpakt:

• Check de officiële documentatie: Cloud providers updaten hun docs met ondersteunde tools. Azure ondersteunt bijvoorbeeld Bicep, Terraform, Pulumi en ARM templates.
• Bekijk policy en compliance eisen: Sommige organisaties eisen specifieke tools om security en governance te borgen.
• Kijk naar je huidige setup: Gebruikt je team al Terraform of ARM? Dan is het logisch om daarbij aan te sluiten.
• Probeer het uit in een testomgeving: Doe een simpele deployment met verschillende tools en kijk wat het beste werkt.

Kies de juiste taal

Je keuze hangt af van je cloud provider, werkomgeving en voorkeur. De juiste taal kiezen is stap één – het bepaalt hoe je werkt en hoe schaalbaar je setup wordt.

Dus eerst: check wat je omgeving ondersteunt. Dan kun je kiezen wat het beste past bij jouw situatie.

Kies op basis van je cloudprovider, organisatiebehoeften en voorkeur. Zoek uit hoe je ermee start en maak de overstap zo soepel mogelijk.

10 Azure IaC Best Practices

Beginnen lijkt misschien veel, maar als je het stap voor stap aanpakt valt het mee. Hier zijn 10 tips om goed van start te gaan:

1. Richt je ontwikkelomgeving in

• Installeer de tools en CLI voor je gekozen IaC-taal.
• Zorg dat je toegang hebt tot een Azure subscription.
• Gebruik een devomgeving zoals Visual Studio Code, met support voor IaC. Installeer de juiste extensions zoals de Bicep Extension, Terraform Extension of Pulumi Extension.
• Gebruik de PowerShell Terminal in VS Code om scripts te runnen en direct te deployen.

2. Leer via officiële bronnen

Microsoft heeft goede Bicep modules op Microsoft Learn. Voor Terraform en Pulumi is er ook uitgebreide documentatie en labs.

3. Begin met een simpele deployment

• Begin met kleine resources, zoals een storage account.
• Test je scripts eerst in een sandbox omgeving.
• Gebruik parameters en modulaire opbouw. Check ook Azure Verified Modules – die werken met Bicep en Terraform.

4. Gebruik version control

Sla je IaC bestanden op in GitHub, Azure DevOps of een andere Git-repo. Zo hou je een wijzigingsgeschiedenis bij en kun je terugrollen bij fouten. Ook kun je een 4-ogen principe afdwingen.

5. Test en valideer

Test je scripts regelmatig. Check of ze doen wat ze moeten doen vóór je ze in productie zet – dat voorkomt problemen.

6. Voorkom configuration drift

Laat alle changes via CI/CD gaan. Geen directe toegang tot resources. Zo blijft je code altijd de bron van waarheid en blijven je omgevingen consistent.

Lees meer over hoe je drift voorkomt met Azure IaC.

7. Automatiseer

Automatisering voorkomt handwerk, fouten en versnelt je processen. Gebruik CI/CD pipelines zoals Azure DevOps of GitHub Actions voor alle omgevingen (dev, test, staging, prod).

8. Gebruik parameters in je templates

Gebruik 1 template voor alle omgevingen en pas alleen de input parameters aan (zoals regio, schaal, SKU’s). Dat houdt alles consistent en voorkomt afwijkingen.

9. Beperk toegang tot productie

Als mensen handmatig dingen aanpassen in productie, kan je IaC stuk gaan – vooral bij scripts die uitgaan van een bekende staat. Beperk dus schrijfrechten tot het minimum.

Voor noodgevallen heb je twee opties:

• Gebruik Privileged Identity Management (PIM): tijdelijke toegang met logs en approvals.
• Gebruik een break glass account: Alleen voor echte noodgevallen. Staat veilig opgeslagen en wordt alleen onder strikte voorwaarden gebruikt.

10. Beheer secrets op de juiste plek

Stop nooit hardcoded secrets in je code. Gebruik Azure Key Vault om ze veilig en centraal op te slaan.

Conclusie

Met Infrastructure as Code beheer je je cloud resources efficiënter en veiliger. Door alles te automatiseren via code krijg je controle, snelheid én een solide basis voor disaster recovery.