Opgradering af din kodebase med Infrastructure-as-code

Hvis dit team udfører manuel serveradministration, har du måske stødt på et eller flere af følgende problemer:

• Der bruges for meget tid på infrastrukturopgaver, og det er svært at vurdere opgaverne i forbindelse med forvaltningen af infrastrukturen.
• Den domænespecifikke viden om infrastrukturen for hvert projekt er ujævnt fordelt blandt teammedlemmerne, og der mangler dokumentation.
• Kun bestemte teammedlemmer har de nødvendige tilladelser til at foretage ændringer i infrastrukturen - det er ofte en systemadministrator eller en ledende udvikler.
• Ændringer i infrastrukturen skaber problemer for kodebaser, der anvender kontinuerlig levering, da infrastrukturen skal ændres manuelt og er afkoblet fra applikationens aktuelle tilstand.

I dette blogindlæg introduceres begrebet infrastructure-as-code - en proces til styring af servermiljøer og infrastruktur via maskinlæsbare definitionsfiler, der kan kildekontrolleres sammen med koden, i stedet for interaktive konfigurationsværktøjer som kommandolinjeværktøjer eller webgrænseflader. Vi vil beskrive Terraform som et basisværktøj til at opnå dette, men mange af de nævnte principper kan opnås ved hjælp af lignende værktøjer som Chef, Puppet eller Ansible.

‍

Et enkelt eksempel med Terraform

Terraform er et open source-softwareværktøj, der tager konfigurationsfiler skrevet i et sprog kaldet HCL og udfører handlinger i overensstemmelse hermed for at foretage ændringer i en serverarkitektur.

Her er et eksempel på brug case: Vi ønsker at distribuere et hello-world containerimage til Google Cloud Run. Dette kan opnås i Terraform ved hjælp af følgende kode:

‍

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "3.69.0"
    }
  }
}

provider "google" {
  project     = "my-project-id"
  region      = "europe-west3"
}

resource "google_cloud_run_service" "default" {
  name     = "cloudrun-srv"
  location = "europe-west3"

  template {
    spec {
      containers {
        image = "us-docker.pkg.dev/cloudrun/container/hello"
      }
    }
  }

  traffic {
    percent         = 100
    latest_revision = true
  }
}

‍

Du har måske bemærket, at disse konfigurationsfiler er skrevet i en deklarativ programmeringsstil. Den beskriver, hvilken infrastruktur vi ønsker, men ikke hvordan til at sætte den op. Terraform tager sig af den del og giver os samtidig en enkelt grænseflade i stedet for flere web-GUI'er og CLI'er.

Lad os se nærmere på dette kodestykke et øjeblik. De første to blokke beskriver nogle konfigurationsdetaljer for Terraform og er ikke særlig relevante for dette blogindlæg. Den tredje blok beskriver en ressource, som er et infrastrukturobjekt, der administreres af Terraform. Når du kører terraform apply, vil Terraform analysere forskellen mellem applikationens aktuelle tilstand og den tilstand, der er beskrevet i HCL-filen, og derefter udføre de tilsvarende migreringer. I denne case vil dette bestå i at oprette en Google Cloud Run-tjeneste kaldet "cloudrun-srv" ved hjælp af "hello"-aftrykket.

‍

Fordelene ved Infrastructure-as-code

Terraform er blot et eksempel på infrastruktur som kode-værktøj og har mange fordele i forhold til manuel infrastrukturstyring som f.eks.

• Terraform-filer kan versionskontrolleres og gemmes sammen med resten af kodebasen.
• Terraform-filsyntaksen kan kontrolleres statisk ved hvert push ved hjælp af terraform fmt og tørkørsel ved hjælp af terraform plan.
• Terraform kan bruges til automatisk at anvende ændringer i infrastrukturen som en del af en kontinuerlig leveringsrørledning, hvilket giver færre hovedpiner, når softwaresystemet skal migreres for at indføre nye funktioner.
• Ændringer i infrastrukturen kan valideres, gennemgås og diskuteres på samme niveau som kode, og de kan testes i forskellige miljøer, før de når frem til produktion.
• Alle teammedlemmer med tilstrækkelig skriveadgang til repositoriet kan bidrage til infrastrukturændringer.
• Infrastrukturen er selvdokumenterende. Ingen domæneviden om serveropsætningen er fanget i en enkelt udviklers hoved, og alle kan læse alt, hvad der er værd at vide om softwaresystemet.
• Terraform-kode kan opdeles i moduler, som kan genbruges senere, hvilket øger udviklingshastigheden.
  

Et ord om arbejdssoftware

Det tredje princip bag Agile Manifestet siger følgende:

Levere fungerende software ofte, fra et par uger til et par måneder, med en præference for den kortere tidshorisont.

Del af bygning arbejdssoftware er at opbygge den infrastruktur, som softwaren er afhængig af. En server, der er afhængig af en database, er ikke et fungerende software, hvis den ikke har en database at oprette forbindelse til. For at kunne levere fungerende software ofte skal man have tillid til integriteten af kodebasen og repositoriet, således at en gren altid kan skubbes til produktion og fortsat være fungerende software. Når et stykke kode ikke angiver sin infrastrukturtilstand korrekt, kan det ophøre med at være fungerende software, hvis infrastrukturen går i stykker.

Kontinuerlig levering af deklarativ infrastruktur delegerer integriteten til kodebasen, så man altid kan implementere en hvilken som helst gren og vide, at platformen, den kører på, vil migrere i overensstemmelse hermed. Dette giver udviklerne mulighed for at levere fungerende software oftere og øger projektets smidighed.

‍

Konklusion

Af ovennævnte grunde kan Terraform (og infrastruktur som kode generelt) være meget nyttige værktøjer til at levere fungerende software hurtigere, med bedre dokumentation, samarbejde og fleksibilitet. For at komme i gang med at integrere Terraform med din eksisterende infrastruktur kan vi anbefale at starte med den fremragende dokumentation lavet af HashiCorp, firmaet bag Terraform.

‍