DevOps med infrastruktur som kode

Infrastruktur som kode

Som konsulent i Sicra kommer jeg ofte til kunder med komplekse sammenhenger mellom programvare og infrastruktur, som har vokst frem over tid. Mange er utviklet over flere generasjoner og av forskjellige leverandører. Det å skulle gjøre endringer i en slik løsning er som regel forbundet med risiko. Det mangler som regel en fullstendig oversikt over avhengigheter og hvordan ting henger sammen.

Dette er bare en av flere utfordringer med dagens IT-løsninger som kan løses med å strukturere måten man utvikler, tester, produksjonssetter og drifter tjenester.

Med infrastruktur som kode bryter man hver enkelt komponent ned til en tekstfil som kan sammenlignes med en legokloss. Når man har nok legoklosser kan man bygge hva som helst, og ved å bruke anerkjente verktøy får man automatisk dokumentert både bygging og utrulling av sin løsning. Denne metoden kan benyttes til alt fra enkle applikasjoner til hele datasentre med server maskinvare, nettverk, lagring, og applikasjons- og database-tjenester.

DevOps

Det finnes flere definisjoner og bruksområder av begrepet DevOps (Wikipedia), men i denne artikkelen skal jeg fokusere overordnet på hvordan man kan redusere tidsforbruket og risikoen ved å gjøre endringer på systemer som er i produksjon.

Komponentene som inngår i en løsning defineres i mindre konfigurasjonsfiler som beskriver funksjon, konfigurasjon og avhengigheter. Hvis man for eksempel skal definere en applikasjon i Azure eller AWS, lager man én konfigurasjonsfil for nettverk, webserver, databaseserver, last-balanserer og sikkerhet. Avhengigheter mellom disse defineres slik at ting kjøres opp i riktig rekkefølge. Konfigurasjonsfilene gjøres gjennom en pipeline som automatisk tar deg til ønsket tilstand, eller det man kaller desired state. Dersom det er en egenutviklet applikasjon vil det være naturlig at bygging og testing av kildekoden er en del av din DevOps pipeline.

Eksempel på Continuous Deployment (CD) pipeline

Sentral kilde for data

En av de fundamentale byggeklossene i en DevOps-modell er å etablere repository hvor all konfigurasjon og eventuell kildekode lagres. Det mest brukte er Github, men det finnes andre som Bitbucket, GitLab og Azure DevOps. Sistnevnte kan være praktisk dersom man allerede bruker Microsoft Azure til andre ting.

Bruk og frigjør ressurser

De fleste større organisasjoner vet at man gjerne skulle hatt separate miljøer for utvikling, testing, kvalitetskontroll og produksjon. Dette blir ofte nedprioritert på grunn av kompleksitet og kostnader. Ved å etablere infrastruktur som kode kan man raskt og enkelt kjøre opp komplette, identiske og isolerte miljøer når man skal utvikle ny funksjonalitet, og kvalitetssikre disse før produksjonssetting. Når endringen er verifisert og satt i produksjon kan man like enkelt rive ned infrastrukturen.

Endringslogg

Ved å bruke en git-basert repository (Azure DevOps Repositories er også basert på git) får man automatisk versjonskontroll på alle endringer som gjøres og det gjør at man kan spore hvem som har gjort endringer, hva som er endret, når det ble gjort, og forhåpentligvis hvorfor det er endret. De fleste systemer åpner for en arbeidsflyt og arkiv-log rundt godkjenning av endringer før de kan sjekkes inn i sentralt repository.

Rulle tilbake endringer eller lage en hotfix

I en ideell verden klarer man å teste 100% før ting slippes til produksjon, men av og til glipper det og svakheter oppdages først etter løsningen er tatt i bruk. I slike tilfeller må det vurderes om man kan rulle systemet tilbake til slik det var, eller om man heller skal fokusere på å raskt fikse problemet. Uansett hvilket alternativ man velger vil prosessen kunne gjøres raskt og med høy grad av kvalitet og sikkerhet dersom man har etablert infrastruktur som kode.

Sikker oppbevaring av hemmeligheter

En annen viktig komponent i infrastruktur som kode er hvor man oppbevarer hemmelig informasjon som passord, api-nøkler, sertifikater og lignende. De er nødvendig for å få automasjonen til rulle. Det er viktig at disse hemmelighetene ikke lagres i klartekst i konfigurasjonsfilene. Dessverre finner vi ofte slik informasjon liggende både i kildekode, script- og konfigurasjon-filer. Det krever ikke mye ekstra innsats å legge slik informasjon kryptert i f.eks. Azure Key Vault eller Terraform Enterprise-databasen.