Servere, I kan bygge op fra bunden igen

Situation. Engineer ApS driver sit eget miljø — en webtilstedeværelse, en git‑forge, en database, sikkerhedskopier, mailtransport og DNS — og der var ingen at overdrage driften til. Et enmandsfirma har de samme fejltilstande som et stort, men ingen redundans, hvilket gør det sædvanlige svar — en person, der husker, hvordan værten blev sat op — til den mulighed, der er allersværest at få fat i.

Opgave. Hele miljøet skulle beskrives i et repository og ikke i nogens hoved, og i en form, der konvergerer en rigtig vært i stedet for blot at dokumentere den.

Handling. Det, der voksede ud af det, er 19 playbooks og 34 roller fordelt på 12.065 linjer YAML. Formen betyder mere end størrelsen. Sammensætningen er data og ikke flag: en vært ligger i en tier‑gruppe, hvis variabler erklærer, hvilke roller den kører, så provisionering uden argumenter konvergerer hver vært til dens erklærede tilstand. Idempotens er en kontrakt, ikke en ambition — en konvergeret vært rapporterer nul ændringer, og et play, der ikke kan sige det, er ikke færdigt. Fire kommandonavnerum holder løfterne adskilt: en kontrol, der ikke rører nogen vært, rapporter, der læser en vært og aldrig ændrer den, provisionering, der ændrer en vært, så den matcher repositoryet, og verifikation, der bevidst ændrer en vært og returnerer en dom.

Resultat. Miljøet kan reproduceres fra repositoryet, og de dele af det, der kun var sande, fordi nogen huskede dem, er nu assertions, der får en kørsel til at fejle. Prisen er reel: hver ændring tager længere tid end at redigere en fil direkte på serveren, og en konvergering, der kun bliver halvt gennemført, er værre end en, der nægter, og derfor blev der senere sat et preflight‑play foran den. Den afvejning blev truffet bevidst, og den har holdt.