Fra “Det virker på min maskine” til rigtig produktion

De fleste udviklere har prøvet det: appen kører perfekt lokalt i Docker. Man pakker den ind i containere, starter en Kubernetes-klynge – og så er den “deployet”. Chefen er glad, og teamet fejrer sejren.

Så rammer virkeligheden.

Den Kubernetes-opsætning, der fik appen til at køre, er ikke den samme som den, der kan holde til rigtige brugere, rigtige data og problemer kl. 3 om natten.

Hvorfor “kører på Kubernetes” sjældent er produktionsklar

En udviklingsopsætning og en produktionsopsætning har sjældent andet til fælles end selve container-styringen.

I udvikling ser det typisk sådan ud:

• Minikube eller lignende lokale klynger
• Selv-signerede certifikater, der kun fungerer på din maskine
• Falske domæner som *.127.0.0.1.nip.io
• Hardkodede secrets i miljøvariabler
• Manuelle helm install-kommandoer
• Monitoring, der skal sættes op “senere”
• Backups, som ingen har testet

I produktion skal man derimod kunne svare på helt andre spørgsmål:

• Kan vi deploye uden at nogen skal trykke på knapper?
• Hvor lever secrets, og hvem har adgang?
• Hvad sker der, når storage fejler?
• Kan vi genskabe data efter et nedbrud?
• Lever vi op til sikkerhedskravene?
• Ved vi, når noget er ved at gå galt, før brugerne opdager det?

Disse ting er ikke pynt – de er forskellen mellem et hobbyprojekt og noget, virksomheden er anvist på.

Den rigtige rute: fem faser til modenhed

Flytningen fra “det virker på min machine” til “teamet kan drive systemet” følger en fast rækkefølge. Det handler ikke om nye funktioner – det handler om operational maturity.

Fase 1: Grundlaget skal arbejde

Først skal de basale komponenter spille sammen i en realistisk setting:

• Brug rigtige domæner i stedet for test-domæner
• Integrer en ordentlig identity provider (OIDC eller SAML)
• Flyt data ud af klyngen – databaser og object storage skal have deres eget miljø
• Sæt secrets management op, der ikke bygger på YAML-filer i Git

Denne fase er næsten usynlig. Men uden den er alt, der kommer efter, fragile.

Fase 2: Appen skal virke på den rigtige infrastruktur

Nu hvor infrastrukturen er stabil, skal produktet selv arbejde med den:

• Brugerlogin skal køre end-to-end
• Fil-uploads skal lande på holdbart storage
• Caching skal være stabil og uden timeouts
• Ingress skal håndtere real traffic

Her oplever man ofte, at udviklingsopsætningen har gjort antagelser, der brækker i produktion.

Fase 3: Ændringer skal styres

Manuelle Helm-kommandoer bliver nu en risiko. Man skal have:

• GitOps: klyngens tilstand ligger i Git, ikke i en persons kubectl-historik
• Automatisk validation før hver deploy
• Sporbarhed af, hvem gjorde hvad og når
• Mulighed for rollback, når noget går galt

GitOps er ikke kun om convenience – det er om safety. Hver ændring skal være reviewable, testable og reversible.

Fase 4: Gendannelse skal være mulig

De fleste teams overser denne fase. De antager, at backups eksisterer – og fortsætter.

Backups er dog kun værdifulde, hvis man har testet gendannelsen.

Rigtig produktionsklarhed kræder:

• Automatiske backup-planer for databaser, persistent volumes og konfiguration
• Testede restore-procedurer (ikke kun testet én gang, og ikke kun manuelt)
• Klare RTO/RPO-mål – hvordan hurtigt kan du genvinde arbejdet, how much data er you willing to lose?
• Dokumenterede procedurer, der ikke afhænger på en enkelt persons memory

Fase 5: Operations skal være visible

Nu skal man være able to know, at der er noget happening:

• Metrics på performance, resource usage og error rates
• Dashboards der viser health at a glance
• Alerting der vækker den rette person, når noget er at gå galt
• Logs der er searchable og retained long nok for at debug problems