Opgrader din kodebase med Infrastructure-as-Code

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

• Der bruges for meget tid på infrastrukturopgaver, og opgaver i forbindelse med forvaltning af infrastruktur er svære at estimere.
• Domænespecifik viden om infrastrukturen i hvert projekt er ujævnt fordelt blandt teammedlemmer, og dokumentation mangler.
• Kun specifikke teammedlemmer har de nødvendige tilladelser til at udføre ændringer i infrastrukturen - dette er ofte en sysadmin eller en lead developer.
• Ændringer i infrastrukturen skaber problemer for kodebaser ved hjælp af kontinuerlig levering, da infrastrukturen skal ændres manuelt og afkobles fra applikationens aktuelle tilstand.

Dette blogindlæg introducerer begrebet infrastruktur-som-kode - en proces til styring af servermiljøer og infrastruktur gennem maskinlæsbare definitionsfiler, der kan kildestyres sammen med koden snarere end 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 simpelt eksempel ved hjælp af Terraform

Terraform er et open source-softwareværktøj, der tager konfigurationsfiler skrevet på et sprog kaldet HCL og udfører handlinger i overensstemmelse hermed for at udføre ændringer i nogle serverarkitekturer.

Her er et eksempel på en brugsstil: Vi ønsker at implementere et hello-world containerbillede 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. Det beskriver hvad Infrastruktur, vi ønsker, men ikke hvorledes at sætte det op. Terraform tager sig af den del, mens den giver os en enkelt grænseflade i stedet for flere web-GUI'er og CLI'er.

Lad os inspicere dette kodestykke et øjeblik. De to første blokke beskriver nogle konfigurationsdetaljer for Terraform og er ikke særlig relevant for omfanget af dette blogindlæg. Den tredje blok beskriver en ressource, som er et infrastrukturobjekt, der administreres af Terraform. Når du løber terraform gælder , 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 dette tilfælde vil dette bestå i at oprette en Google Cloud Run-tjeneste kaldet „cloudrun-srv“ ved hjælp af „hej“ -billedet.

‍

Fordelene ved Infrastructure-as-Code

Terraform er blot et eksempel på infrastruktur-som-kode-værktøj og har mange fordele sammenlignet med manuel infrastrukturstyring såsom..

• Terraform-filer kan versionskontrolleres og gemmes sammen med resten af kodebasen.
• Terraform filsyntaks kan kontrolleres statisk på 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 til infrastruktur som en del af en kontinuerlig leveringspipeline, hvilket giver færre hovedpine, når du skal migrere softwaresystemet for at introducere nye funktioner.
• Ændringer i infrastruktur kan valideres, gennemgås og diskuteres på samme niveau som kode og kan testes i forskellige miljøer, inden de når produktion.
• Hvert teammedlem med tilstrækkelig skriveadgang til lageret kan bidrage med infrastrukturændringer.
• Infrastrukturen er selvdokumenterende. Ingen domæneviden om serveropsætningen er fanget inde i en enkelt udviklers hoved, og alle kan læse alt, hvad der er 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 Manifesto siger følgende:

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

En del af bygningen arbejdssoftware bygger den infrastruktur, som softwaren er afhængig af. En server med en databaseafhængighed fungerer ikke software, hvis den ikke har en database at oprette forbindelse til. For at kunne levere fungerende software ofte, skal man stole på integriteten af kodebasen og depotet, således at en filial altid kan skubbes til produktion og fortsætte med at arbejde med software. Når et stykke kode ikke erklærer sin infrastrukturtilstand korrekt, kan det ophøre med at fungere software, hvis infrastrukturen går i stykker.

Kontinuerlig levering af deklarativ infrastruktur delegerer integriteten til kodebasen, således at man altid kan implementere enhver gren og vide, at den platform, 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 ovenstående 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 smidighed. For at komme i gang med at integrere Terraform med din eksisterende infrastruktur, kan vi anbefale at starte med fremragende dokumentation lavet af HashiCorp, firmaet bag Terraform.

‍