Infrastructure as Code
18. april 2024Hva er Infrastructure as Code?
Enkelt forklart er det å sette opp infrastruktur i skyen automatisk via kode, i motsetning til å sette opp manuelt. En måte å se det på er som regelbasert infrastruktur.
Hva menes med Infrastructure?
Når vi snakker om Infrastructure mener vi byggesteiner i skyen som webservere, databaseservere, lastbalanserere, nettverk, brannmur, virtuelle maskiner og så videre. Og ikke minst hvordan disse er koblet sammen.
Hva menes med Code?
Code er tekst som kan leses av både datamaskiner og mennesker. Denne teksten definerer de forskjellige delene i infrastrukturen. Teksten er ofte deklarativ, det vil si at koden beskriver hvordan infrastrukturen skal se ut, i motsetning til imperativ kode som beskriver hvordan infrastrukturen skal lages, steg for steg.
Koden er gjerne med i kodebasen sammen med resten av systemet, som gjør at alle endringer kan spores.
Hvorfor Infrastructure as Code?
Se for deg et utviklingsmiljø uten Infrastructure as Code, hvor utviklere setter opp infrastruktur manuelt. Over tid vil det bygge seg opp endringer i infrastrukturen, og det blir vanskelig å holde styr på hvordan den faktisk fungerer i forhold til hvordan den er dokumentert. Hvis den er dokumentert i det hele tatt.
Med Infrastructure as Code kan man si at selve definisjonen av infrastrukturen er dokumentasjonen, og det vil da ikke være mulig at det er forskjell på dokumentasjonen og virkeligheten, gitt at IaC-systemet fungerer som det skal.
I tillegg vil enkel tilbakerulling av endringer redusere frykt for å gjøre feil, og øke utviklingshastigheten.
Kode kan gjennomgås av automatiske systemer for å sikre at retningslinjer blir fulgt, for eksempel at databaseservere ikke skal være åpne for hele internett.
En annen fordel med Infrastructure as Code er reproduserbarhet. Et eksempel på det er hvis det blir et behov for et nytt environment, for eksempel for testing. Da kan man lett opprette et environment som er likt produksjons-environment, og da ha visshet om at testingen er treffende for potensielle feil i produksjon.
Forskjellige Infrastructure as Code systemer
Det er massevis av forskjellige IaC-systemer, med hver sin syntaks og fremgangsmåte.
Noen er proprietære og låst fast til en sky, mens andre kan brukes på flere skyer samtidig.
Som eksempel på multicloud har vi Terraform og Ansible. Disse kan brukes på både AWS, Azure og Google Cloud Platform.
Microsoft har sitt eget system kalt Azure Resource Manager, med ARM Templates og Bicep som definisjonsformat. Denne fungerer bare på Azure.
I eksempelet nedenfor ser vi Bicep-kode som beskriver en website:
Her har vi et tilsvarende eksempel på Terraform-kode:
Ulemper
Selv om Infrastructure as Code har mange fordeler, har det også noen ulemper. En ulempe med Infrastructure as Code er at man må lære seg nye systemer, ofte med egne filformater. Utfra hvor mye man definerer må man kanskje inn med noen skript, og dette kan føre til at det fort blir mye forskjellig å tenke på i deployment-pipelinen. For eksempel kan en middels kompleks pipeline involvere språkene Bicep, YAML, JSON, Dockerfile, Powershell og Bash, ofte nøstet inn i hverandre.
Det kan også være en utfordring med økt kobling mellom infrastrukturen og resten av systemet. Man vil gjerne at system skal kunne kjøre på forskjellige environments, og ikke være sensitivt for mindre endringer. Hvis man har IaC deploy og kode deploy i samme CI/CD pipeline som alltid kjører sammen, er det ikke noe der som stopper potensielt uheldige koblinger mellom environment og system.
Infrastructure as Code er også mer sensitivt for feilkonfigurasjon – en liten feil i en IaC template kan forårsake store feil i hele systemet. Dette retter seg spesielt mot feil som ikke umiddelbart blir fanget opp i testing – for eksempel sikkerhetshull hvor nettverk som er åpnet mer enn nødvendig, eller sammenblanding av utviklings- og produksjons-environment.
Å blande manuell prosess med Infrastructure as Code er ikke en god ide – man vil kanskje gjøre en rask endring på en server uten å involvere hele deployment-prosessen. Dette vil kanskje se ut til å fungere greit, helt til det blir gjort en ny deployment, og den manuelle endringen vil bli overskrevet.
Konklusjon
Med kontinuerlig utvikling av muligheter i skyen og stadig nye krav til løsninger er det viktig å ha oversikt over infrastrukturen, og enkelt kunne endre denne. Infrastructure as Code er et effektivt hjelpemiddel for dette, hvor automatisering, reproduserbarhet og dokumentering er noen av de viktigste nytteeffektene.
