Drømmeudgaven af developeroplevelsen

Tænk dig det her: En udvikler finder dit open-source-projekt, klikker på "Open in Dev Container", og sekunder efter kører alt et fuldt opsat udviklingsmiljø. Ingen installationsscripts. Ingen certifikatadvarsler. Ingen jagt på miljøvariabler. Ingen fejl om optagede porte.

Det er containerbaserede dev-workflows i praksis – og det ændrer spillet. Men bag den glatte overflade gemmer sig en masse tekniske valg.

Hvorfor dev containers booster adoption

Let onboarding er ikke kun bekvemmelighed. Det er en direkte vej til flere bidragydere. Jo hurtigere fra "interessant projekt" til "kører lokalt", jo bedre. Momentum dør ofte i setup-fasen.

Særligt ved komplekse værktøjer, der efterligner Azure-tjenester som DNS, key management, service buses og identity. Hver manuel trin er en risiko for dropout.

Opsætningen: Tre services på ét netværk

Docker Compose løser det med en præcis orkestrering:

services:
  devcontainer:    # VS Code-arbejdsområdet
  service-host:    # Hovedapplikationen som sidecar
  dns-resolver:    # Wildcard-DNS-tricket

Hver service har sin rolle:

• Workspace-containeren er til kode og kommandoer
• Sidecar'en kører services på faste porte
• DNS-resolveren fikser netværksmagi som *.ditdomæne.local

Fast IP på bridge-netværket (172.28.0.0/16) er nøglen. Adresser må ikke skifte ved restart – DNS kræver forudsigelighed.

DNS-udfordringen: Det er sværere end det lyder

DNS i containere er tricky. Linux' /etc/resolv.conf styrer resolution, men den er ustabil – Docker eller host overskriver den let.

Direkte redigering af filen? Logisk, men skrøbeligt. Systemet tager over.

Bedre: En dnsmasq-sidecar, der:

1. Kører på fast IP i netværket
2. Håndterer wildcard som *.ditdomæne.local.dev
3. Fallback til host-DNS
4. Sættes som primær nameserver via Docker-netværk

Nu arbejder du med systemet, ikke imod det.

Netværk i Compose: Mount-fælden

Med VS Code Dev Containers i Compose-mode ændres filmontering. Workspace skal være tilgængelig, men det kræver præcis volume-opsætning:

services:
  devcontainer:
    volumes:
      - ..:/workspaces/projekt-navn:cached
      - /var/run/docker.sock:/var/run/docker.sock

:cached er essentielt på macOS/Windows – det optimerer fil-I/O, hvor container læser mere end den skriver.

Certifikater: TLS uden besvær

HTTPS-dev kræver betroede certs. Self-signed giver advarsler og bryder API-kald.

Løsningen:

1. Generer lokal CA under build
2. Tilføj til containerens trust store
3. Lad sidecar bruge CA-signerede certs
4. Del CA via volume, så værktøjer stoler på det

Pludselig er sikkerhed transparent – ingen advarsler overhovedet.

Health check: Test det hele

Bekræft med et simpelt kald:

$ curl https://app.ditdomæne.local.dev:8899/health
{"status":"healthy","uptime":"2m34s"}

Det tester DNS, netværk, TLS og app på én gang. Virker det? Alt er godt.

Hvad det betyder for dit projekt

Hvert fjernet setup-trin er en barriere ned. En solid Compose-opsætning skalerer til team og community.

Investeringen giver hurtig værdi: Nemmere onboarding, færre "virker kun hos mig"-problemer og signal om, at DX betyder noget.

Teknik som faste IP'er, DNS-sidecars, cert-kæder og mounts er detaljer. Gevinsten er den gnidningsfrie start.

Kom i gang

Bygger du dev container til kompleks app? Følg disse principper:

• Docker Compose med bridge og faste IP'er
• Glem /etc/resolv.conf alene
• Kør dedikeret DNS-service til wildcards
• Automatiser lokal cert-generering og trust
• Test end-to-end med hostname-kald

Kompleksiteten er foran – bagefter nyder alle udviklere det evigt.