CINQby Victor Louisa
Wat ooit is begonnen als een hackathon bij DHL, één van onze klanten bij CINQ ICT, is nu een framework aan het worden om Azure resources aan te maken en te beheren. Het idee was om de Infrastructure as Code weg te abstraheren bij de ontwikkel teams, maar om de resources via configuratie files (bijv. YAML) aan te kunnen maken. Deze manier van werken zou ook een eerste stap kunnen zijn naar een vorm van self-service.
Terraform is een van de meest gebruikte tools om infrastructuur in te richten vanuit code (IaC). Het gebruikt hiervoor een taal genaamd HCL (Hashicorp Configuration Language). In deze blogpost onderzoeken we hoe we het aanmaken van resources kunnen configureren in YAML files en wat de voordelen hiervan zijn.
Een van de beste eigenschappen van YAML is de afwezigheid van “syntax overhead”. Hiermee kunt je key value pairs overzichtelijk opschrijven. Laten we eens kijken naar een vergelijking van bepaalde HCL-code en YAML.
HCL
YAML
Zoals je kunt zien, is het verschil in aantal regels behoorlijk groot. Natuurlijk zal dit veranderen zodra we wat HCL-code toevoegen om de YAML-configuratie te importeren, maar dit wordt snel groter als de infrastructuur groeit.
Het laden en converteren van een YAML-bestand naar HCL is heel eenvoudig. Je kunt het op één regel doen met behulp van de yamldecode en file functies:
Na het inlezen van alle yaml files is er een Terraform map beschikbaar met alle resource-types en de in de yaml geconfigureerde properties.
De "router" module is de orchestratie module en de spin in het web die meerdere resources en/of resources-typen aan kan maken. De router module leest alle yaml files in en roept voor iedere resource-type de betreffende resource module aan. Als er in de yaml file meerdere resources van hetzelfde type worden aangemaakt dan zal middels een for_each loop de resource module meerdere malen worden aangeroepen.
Om de resource module folder structuur te geven, gebruiken we het resource-type als folder naam.
De resource module zal de daadwerkelijk resource aanmaken en bevat alle validatie regels op de input parameters die noodzakelijk zijn. Verder zal de module verplichte parameters afdwingen en "waarden van gezond verstand" gebruiken voor niet verplichte niet opgegeven properties.
Ook zal de resource module best practices implementeren (denk bijv. aan privacy-by-design principes zoals private endpoints, encryptie, logging) zonder dat dat in de yaml files is aangegeven. De maker van de yaml file hoeft alleen maar de meest voor de hand liggende properties in te vullen zoals bijv. de naam van de resource en de uitvoering (SKU, pricing tier).
YAML-bestanden zijn eenvoudiger dan Terraform locals en/of tfvars-bestanden voor het beheren van niet-triviale Terraform-configuraties. Omdat development teams nu zelf YAML files kunnen aanmaken is dit een eerste voorzichtige stap naar een vorm van self-service.
Binnen de DevOps-unit van CINQ ICT gaan we dit jaar een Terraform hackathon organiseren om te kijken of we dit concept nog verder kunnen uitwerken. Zo heeft iedere resource module een scope van alleen zichzelf en heeft dus geen weet van het bestaan van meerdere en/of andere resource-typen.
Een belangrijk onderwerp van de hackathon zal dan ook zijn hoe we een integratie laag tussen de verschillende modulen kunnen realiseren. Denk daarbij bijv. aan hoe koppelen we een keyvault aan een Kubernetes namespace, of een storage account aan een Synapse Workspace, hoe gaan we om met firewall rules? Zonder daarbij de code in de modules heel complex te maken.