DevOps-værktøjer – et spadestik dybere

Hvilke værktøjer kan understøtte implementeringen af DevOps i organisationen?

Vi har tidligere overordnet gennemgået, hvad DevOps, GitOps og DevSecOps er. I denne artikel vil vi grave et spadestik dybere og beskrive forskellige DevOps-værktøjer, der kan implementeres for at understøtte metoden i praksis og sikre et succesfuldt udviklings- og driftsprojekt.

Artiklen er skrevet af Bjarne Dollerup, som er development-konsulent i Globeteam.

DevOps-”processen” kan brydes ned i følgende delopgaver:

• Håndtering af applikationskode, konfigurationsfiler og scripts.
• Struktureret test af applikationer/services.
• Belastnings- og ydelsestest af applikationer/services.
• Sikkerhedstjek af applikationer/services.
• Opsætning af infrastruktur (netværk, servere, applikationer, etc.)
• Godkendelsesproces omkring de forskellige stadier i udrulningen og opsætningen af applikationer og infrastruktur.

I det følgende vil se nærmere på, hvordan vi kan understøtte hver af disse opgaver med forskellige DevOps-værktøjer.

DevOps-værktøjer til håndtering af applikationskode, konfigurationsfiler og scripts

Den mest anvendte metodik til dette er “git”, som anvendes af langt de fleste DevOps-værktøjer og online tjenester, som f.eks. Azure DevOps og GitHub. Git er oprindeligt udviklet af Linus Torvalds til operativsystemet Linux.

Git er et såkaldt ”distribueret versionskontrolsystem” beregnet til tekstfiler som kode- og konfigurationsfiler. Fordelen ved et distribueret versionskontrolsystem er, at hver enkelt udvikler kan arbejde lokalt på sin del af en større kodebase, i stedet for at alle skal skiftes til at arbejde på én delt kodebase, som ligger centralt på en server. Ydermere behøver udviklerne ikke at sidde samme sted fysisk, men kan arbejde fra hver deres lokale, bygning eller sågar verdensdel.

Systemet holder styr på alle ændringer og hvem, der har foretaget dem. Ved hjælp af såkaldte “branches” kan forskellige grupper arbejde parallelt på forskellige versioner af koden. F.eks. kan en gruppe arbejde på en ”hovedversion” til den næste udrulning, mens andre samtidig kan arbejde på “hot-fixes” til den nuværende version. Git indeholder så en række funktioner til at godkende, konsolidere og/eller afvise ændringer.

Git er særdeles fleksibel og kræver ikke en speciel filstruktur og/eller en specifik opdeling i ”branches”. Det er helt op til teamet og organisationen. Der er dog en række best practices omkring dette.

Struktureret test af applikationer/services

For at man kan teste koden på en ensartet og struktureret måde, er det nødvendigt at kombinere anvendelsen af git med nogle faste regler og godkendelsesprocesser. Man kan i et projekt f.eks. sætte en regel op om, at udviklerne ikke kan tjekke nye ændringer ind, før de har testet, hvorledes disse ændringer påvirker servicen/applikationen. Her kan man så implementere en proces, hvor f.eks. Azure DevOps-værktøjet automatisk sætter et sæt af standardiserede virtuelle servere op (som gerne skal matche driftsplatformen), herefter rulles kode ud, og man kan nu køre en række tests.

En af de helt store fordele ved at anvende et værktøj som Azure DevOps er, at udviklerne ikke selv skal konfigurere testserverne, men at dette kan styres af driftsafdelingen. Dermed sikrer man, at en given applikation/service bliver testet i overensstemmelse med opsætningen i drift.

Ofte vil man have forskellige miljøer til test, f.eks. Development, test og QA/præ-produktion. I disse kan man så teste applikationer/services mere og mere – med mere og mere stringente godkendelsesforløb. Også her er der en række best practices for, hvordan man gør det.

Belastnings- og ydelsestest af applikationer/services

Som en del af overstående forløb eller som et separat stadie i forbindelse med udrulning kan man kombinere afviklingstests med belastnings- og ydelsestests. I Azure DevOps sættes  dette op én gang, og derefter vil man kunne måle en given virkning af enhver kodeændring, eller hver gang en ny version af applikationen rulles ud. Hvis belastningstesten ser fornuftigt ud, kan udrulningen så godkendelse til idriftsættelse.

Sikkerhedstjek af applikationer/services

Igennem hele forløbet skal man naturligvis sikre koden og de underliggende støttebiblioteker mod sårbarheder. Dette kan gøres ved hjælp af penetrationstests eller sårbarhedsscanninger. Også dette kan automatiseres, således at vi er sikre på at få tjekket alt – hver gang! Vi kan naturligvis også anvende kryptografi til at sikre vores kildekode samt udrulningsscripts og beskrivelser. Denne proces omtales ofte som DevSecOps eller SecDevOps.

De værktøjer, som kan tages i anvendelse her, vil vi gennemgå i en senere artikel om DevSecOps/SecDevOps.

Værktøjer til opsætning af infrastruktur (netværk, servere, applikationer, etc.)

Som nævnt tidligere kan opsætning af infrastruktur automatiseres som en del af et test flow, men automatisering kan også anvendes på og i forbindelse med andre opsætninger. Dette omtales ofte som ”GitOps” og/eller ”Infrastructure as Code (IaC)”.

Hvis man f.eks. skal sætte et kundestyringssystem op, og systemet kører på en række forskellige servere, der hver især skal konfigureres, kan det naturligvis gøres ved hjælp af scripts (bash og/eller PowerShell), men en bedre måde er at bruge et “Desired State Configuration (DSC)” værktøj.

Man beskriver, hvordan opsætningen skal være, og derefter vil værktøjet sikre, at dette sker. Fordelen er, at man undgår at skulle tage højde for svartider, småfejl etc. i et script. Hvis der sker en fejl, kan man blot køre værktøjet igen.

Der er en række forskellige værktøjer/services, som kan bruges her. F.eks.:

• Ansible
• Terraform
• Azure Resource Manager Templates (ARM)
• Bicep
• Chef
• Puppet

Disse værktøjer har forskellige styrker/svagheder og lidt forskellige typiske anvendelsesområder, som vi ikke vil komme nærmere ind på her,

Godkendelsesproces omkring de forskellige stadier i udrulningen og opsætningen af applikationer og infrastruktur

“Godkendelse” er et værdiladet ord – også i en DevOps sammenhæng. Det er derfor vigtigt at tage en dialog med sine stakeholders og sit team om, hvordan dette gøres. Hvor meget skal foretage manuelt, og hvor meget skal automatiseres?

F.eks. hvis alle tests i Development stadiet bliver fuldført uden fejl, kan applikationen blive automatisk godkendt til udrulning i en QA miljø, hvor f.eks. penetrationstests og belastningstests afvikles. Her kan man også med fordel placere en manuel inspektion (hvis der er brugersnitflader i applikationen).

Hvis alt så går som forventet, kan vi vælge at lade processen afvente en manuel godkendelse af alle de forudgående tests og tjek, hvorefter applikationen automatisk bliver rullet ud i produktionsmiljøet.

Afhængig af opsætningen kan fejl og belastningsudfordringer logges automatisk, og denne information kan sammen med telemetri afleveres automatisk til driftsfolk og udviklere, så alle har et fælles grundlag for at foretage rettelser i applikationen og dens underliggende infrastruktur.

Vi kan naturligvis vælge at have individuelle godkendelsesprocesser omkring mange forskellige dele af DevOps projektet/processen. Hvor og hvor mange afhænger af kompleksitet, og hvor kritisk en applikation eller service, der er tale om.

Konklusion

DevOps-værktøjer og metodikker giver os en lang række muligheder i forhold til at ensarte og styre, hvordan vi udvikler, tester og idriftsætter vores applikationer/services. Vi får også mulighed for at dele opgaverne op: F.eks. kan det være driftsafdelingen, der definerer, hvordan afviklingsmiljøet ser ud, mens sikkerhedsafdelingen definerer penetrations- og tjek for sårbarheder, og udviklerne bestemmer, hvorledes de generelle tests skal se ud.

Udfordringen er,  at der er rigtig mange DevOps-værktøjer og produkter, og det kan være komplekst at sætte op, så man kan drage fuld nytte af dem.

Der er også en række best practices omkring struktur og arbejdsform – men det kan ofte være vanskeligt at skille holdninger fra reelle best practices. Samtidig er der også indbygget en række potentielle konflikter mellem stakeholders, udviklere, driftsfolks og slutbrugere, og det er vigtigt at få disse afvæbnet så tidligt i forløbet som muligt.

Det fører mig til det sidste afsnit.