Drift og overtagelse

Gør cloudopsætningen genskabelig med infrastruktur som kode

Koden kan ligge sikkert i Git, mens den udgivne app stadig afhænger af manuelle klik i Azure, Firebase, Google Cloud eller en anden platform. Infrastruktur som kode gør den ønskede cloudopsætning læsbar, versionsstyret og gentagelig. Det giver først ro, når eksisterende ressourcer er overtaget forsigtigt, ændringer bliver gennemgået, og et isoleret miljø faktisk kan oprettes igen.

Udgivet 20. september 2026 · Ca. 11 minutters læsetid

Infrastruktur som kode er ikke en kopi af hele appen

Infrastruktur som kode, ofte forkortet IaC, beskriver cloudressourcer og deres konfiguration i filer. Det kan være en webapp, funktioner, lager, databaseinstanser, køer, alarmer, netværk og adgangsroller. Et deklarativt værktøj sammenligner den beskrevne ønsketilstand med det eksisterende miljø og foreslår eller udfører ændringer.

Egner sig ofte til IaC

Ressourcetyper, region, kapacitet, forbindelser, adgangsroller, alarmer og ikke-hemmelige indstillinger, som platformens værktøj understøtter.

Kræver stadig en anden plan

Forretningsdata, uploadede filer, hemmelige værdier, domæneejerskab, manuelle godkendelser og indstillinger, som udbyderens API ikke kan administrere.

IaC erstatter derfor ikke backup, datamigrering, driftsdokumentation eller adgangsstyring. Det reducerer den del af driften, der ellers kun findes som skærmbilleder, klikrækkefølger og én persons hukommelse.

Kortlæg det miljø, der faktisk holder appen kørende

Begynd ikke med at vælge et værktøj. Lav først et ressourcekort over produktion og de miljøer, der bruges til test. For hver post bør I kunne se ejer, platform, miljø, region, afhængigheder, dataindhold, ændringsmetode og konsekvensen ved sletning.

Kørsel: Hosting, serverless functions, containere, planlagte jobs og baggrundsarbejdere.
Data: Databaseinstanser, tabeller eller collections, fillager, køer, cache, backup og retention.
Adgang: Projekter, abonnementer, serviceidentiteter, roller, grupper og forbindelsen fra deployment til cloud.
Trafik: Domæner, DNS, certifikater, redirects, CORS, netværksregler og offentlige endpoints.
Drift: Logs, målinger, alarmer, budgetter, dashboards og notifikationsmål.
Skjulte klik: Loginudbydere, webhookadresser, tilladte origins, emailafsender, indeks og andre konsolindstillinger.

Slet ikke for at “få en ren start”. En fungerende produktionsressource kan indeholde data, identiteter, faste adresser eller integrationer, som ikke kan genskabes uden afbrydelse. Kortlæg og importér kontrolleret, hvis værktøjet understøtter det.

Vælg omfang og værktøj efter den eksisterende stack

Målet er ikke flest mulige konfigurationsfiler. Målet er, at kritiske ressourcer kan forstås, ændres og genskabes uden skjulte manuelle trin. Vælg den mindste løsning, der dækker de største driftsrisici.

Azure: Bicep beskriver Azure-ressourcer deklarativt og bruger Azure Resource Manager. Azure gemmer tilstanden, så Bicep kræver ikke en separat state-fil.
Flere clouds eller bred leverandørdækning: Terraform bruger providers og en state til at forbinde konfiguration med virkelige ressourcer. Dækning og adfærd skal kontrolleres i den konkrete providers dokumentation.
Firebase og Google Cloud: Terraform kan administrere udvalgte Firebase- og Google Cloud-ressourcer. Firebase beskriver fortsat sin Terraform-understøttelse som preview, så kontrollér præcist hvilke produkter og felter der understøttes, før I gør den til eneste gendannelsesvej.
Mindre platforme: Et versionsstyret platformsmanifest, CLI-konfiguration eller en dokumenteret eksport kan være mere realistisk end et generelt IaC-værktøj.

Det er legitimt at lade enkelte indstillinger være manuelle, hvis det står tydeligt i systemkortet, har en ejer og kan efterprøves. En falsk påstand om “alt er kode” er farligere end en ærlig restliste.

Overtag eksisterende ressourcer uden at ændre dem ved et uheld

En eksisterende app skal normalt adopteres, ikke genoprettes. Terraform kan importere eksisterende ressourcer til sin state, men konfigurationen skal beskrive dem korrekt. HashiCorp advarer om, at manglende ikke-standardværdier kan få den efterfølgende plan til at foreslå ændringer. Samme forsigtighed gælder, når andre værktøjer kobles på et miljø, der allerede kører.

Afgræns én lavrisikoressource: Vælg noget, der kan observeres og gendannes, før I tager database eller identitet.
Beskriv den nuværende opsætning: Medtag de felter, der ændrer adfærd, adgang, region, netværk eller livscyklus.
Importér eller referér eksisterende: Følg værktøjets og providerens officielle metode; opret ikke en parallel ressource med næsten samme navn.
Kør preview gentagne gange: Justér konfigurationen, indtil der ikke står en uventet opdatering, erstatning eller sletning.
Aftal ændringsfrysning: Undgå samtidige konsolklik, mens den første overtagelse og verifikation foregår.
Gem beviset: Review, plan, godkendelse og smoke test skal kunne findes bagefter.

Læs previewet som en risikovurdering – ikke som en garanti

Terraform bruger arbejdsgangen write, plan og apply. Bicep har en what-if-funktion, som viser forventede oprettelser, ændringer og sletninger uden at udføre dem. Begge giver et vigtigt beslutningsgrundlag, men virkeligheden kan ændre sig efter previewet, og nogle værdier eller afhængigheder kan ikke analyseres fuldt ud.

Gennemgå særskilt ressourcer, der bliver slettet eller erstattet, og spørg hvad der sker med data, adresse og nedetid.
Kontrollér at previewet rammer den rigtige konto, subscription, projekt, region og miljø.
Kør den endelige plan mod den aktuelle tilstand tæt på udførelsen; en ældre plan kan være forældet efter manuelle ændringer.
Kræv en navngiven godkendelse ved produktion, især for database, lager, identitet, netværk og DNS.
Planlæg smoke test, overvågning og en sikker afbrydelse, hvis virkningen afviger fra forventningen.

Beskyt state, secrets og deployment-identiteten

Terraform-state kan indeholde følsomme attributter, også selv om værdier er markeret som sensitive i almindeligt output. State hører derfor ikke hjemme som en tilfældig fil i repository eller på en enkelt udviklers computer. Brug et egnet remote backend, begræns læse- og skriveadgang, krypter lagringen, og brug locking hvor backendet understøtter det.

Gem referencer til secrets i IaC, ikke hemmelige værdier direkte i konfiguration, state eller planfiler, når platformen giver et sikkert alternativ.
Giv deployment-identiteten kun de rettigheder, som den konkrete konfiguration kræver; adskil miljøer og højrisikoområder efter behov.
Brug kortlivede, fødererede credentials som OpenID Connect, når cloud og CI-platform understøtter det, frem for en langlivet cloudnøgle i repository-secrets.
Beskyt state-backup og planartefakter som følsomme driftsdata, og test hvem der faktisk kan hente dem.

Gør cloudændringer til en kontrolleret kodeændring

Når konfigurationen er versionsstyret, kan ændringen følge samme grundprincip som applikationskode: en afgrænset diff, automatisk validering, preview, review og en kontrolleret udførelse. Det betyder ikke, at alle ændringer skal være langsomme; det betyder, at hensigt og faktisk virkning kan sammenlignes.

Kør formattering, validering og preview i en pull request uden automatisk at ændre produktion.
Vis previewet sammen med kodediffen, og gør erstatninger, sletninger og adgangsændringer tydelige.
Udfør kun den gennemgåede ændring fra en beskyttet branch og en afgrænset identitet.
Efter en nødændring i konsollen: dokumentér hændelsen og før ændringen tilbage i kode, så næste deployment ikke ruller den tilbage ved en overraskelse.
Kør regelmæssigt et preview uden apply for at finde drift mellem beskrevet og faktisk opsætning.

Bevis genskabelighed i et isoleret miljø

Et grønt preview beviser ikke, at en ny person kan skabe et brugbart miljø. Lav en genskabelsestest i et separat projekt eller abonnement uden produktionsdata. Brug repository og driftsdokumentation som eneste udgangspunkt, og registrér hvert manuelt trin, manglende input og ukendt ejerskab.

Opret de beskrevne ressourcer med egne testnavne, domæner, secrets og mindst mulige testdata.
Deploy appen, og kør de kritiske smoke tests gennem frontend, backend, database, filer og integrationer.
Sammenlign adgang, region, alarmer, retention, backup og netværksregler med den godkendte baselinje.
Fjern testmiljøet med samme forsigtighed: gennemgå previewet, beskyt delte ressourcer, og kontrollér at intet produktionsmål rammes.
Opdatér kode og runbook, indtil en anden person kan gentage testen uden mundtlige genveje.

Typiske fejl

IaC vælges før inventaret: Værktøjet dækker flotte nye ressourcer, men appens kritiske klik og afhængigheder er stadig ukendte.
Produktion genoprettes for at komme i gang: Data, identiteter, URL'er eller integrationer går tabt, selv om ressourcen får samme navn.
Import ligestilles med sikker overtagelse: Den første efterfølgende plan vil ændre eller erstatte felter, som ikke blev beskrevet.
State bliver committed: Følsomme attributter og styringen af rigtige ressourcer ender i en ukontrolleret fil.
Preview bliver ikke læst: Et grønt job skjuler stadig en planlagt erstatning eller sletning.
Konsollen lever videre som hovedvej: Drift ophobes, og næste apply overskriver en vigtig manuel rettelse.
Kun tom infrastruktur testes: Appkode, secrets, migreringer, alarmer og smoke tests bliver aldrig koblet sammen.

Tjekliste til en genskabelig cloudopsætning

☐ Produktion og testmiljøer har et opdateret ressourcekort med ejer, region og konsekvens ved sletning.
☐ Kritiske manuelle indstillinger og områder uden værktøjsstøtte står på en synlig restliste.
☐ IaC-værktøj og omfang er valgt efter den eksisterende stack – ikke efter et universelt teknologikrav.
☐ Eksisterende ressourcer overtages én afgrænset del ad gangen uden uventede ændringer.
☐ Preview viser tydeligt oprettelser, ændringer, erstatninger og sletninger før produktion.
☐ State og planfiler opbevares sikkert, og state locking bruges hvor det understøttes.
☐ Secrets ligger ikke som klare værdier i repository, state eller delte planartefakter.
☐ Deployment-identiteten har mindst mulig adgang og bruger kortlivede credentials, hvor det er muligt.
☐ Cloudændringer har diff, preview, review, godkendelse, smoke test og overvågning.
☐ Manuelle nødændringer bliver efterfølgende afspejlet i kode og dokumentation.
☐ Et isoleret miljø er oprettet fra repository uden produktionsdata eller mundtlige genveje.
☐ Backup og gendannelse af forretningsdata er testet særskilt fra infrastrukturen.

Relaterede guides

Officielle kilder

De konkrete tekniske råd er kontrolleret mod aktuelle primærkilder. Kontrollér altid dokumentationen for den provider og de ressourcetyper, jeres løsning faktisk bruger.

Virker appen, men kan ingen genskabe dens cloudopsætning?

Startklar kan hjælpe med at kortlægge det miljø, appen allerede bruger, afgrænse et realistisk IaC-omfang og etablere review, dokumentation og genskabelsestest uden at satse produktionen.

Se Startklar-forløbet