De ideale developer-ervaring

Stel je voor: een developer stuit op je open-source project, klikt op 'Open in Dev Container' en even later draait alles perfect. Geen gedoe met installaties. Geen SSL-waarschuwingen. Geen gepruts met variabelen of poorten.

Dit is de kracht van containerized development. Het klinkt magisch, maar er zit slimme engineering achter.

Waarom dev containers contributors aantrekken

Snelle onboarding is geen luxe – het is key voor adoptie. Hoe makkelijker van 'interessant' naar 'ik draai het lokaal', hoe meer mensen blijven hangen. Vooral bij complexe tools die Azure-diensten nabootsen, zoals DNS, key management of service buses, stapelt de frustratie zich op. Elke extra stap is een drop-off risico.

De opzet: drie services op één netwerk

Docker Compose maakt het mogelijk, met een strakke configuratie:

services:
  devcontainer:    # Je VS Code werkplek
  service-host:    # De hoofdapplicatie
  dns-resolver:    # Slimme wildcard DNS

Elke service doet één ding goed:

• Devcontainer: code schrijven en commando's draaien
• Service-host: applicaties op vaste poorten
• DNS-resolver: wildcard domeinen zoals *.yourdomain.local

Gebruik een bridge network met vaste IP's (bijv. 172.28.0.0/16). Zo blijven adressen stabiel, zelfs na restarts – essentieel voor DNS.

DNS in containers: lastiger dan je denkt

DNS fixen in een container is tricky. Linux leunt op /etc/resolv.conf, maar Docker en de host overschrijven dit zomaar.

Direct knutselen aan dat bestand? Slecht idee, het breekt snel. Beter: een dnsmasq sidecar op een vaste IP.

1. Draait als eigen service
2. Regelt *.yourdomain.local.dev
3. Vallback naar host DNS
4. Primary nameserver via Docker network

Zo werk je mét het systeem, niet ertegen.

Networking in Compose: pas op met mounts

Bij VS Code Dev Containers in Compose mode verandert file mounting. De workspace moet bereikbaar zijn, maar het werkt anders.

Fix dit in compose.yml:

services:
  devcontainer:
    volumes:
      - ..:/workspaces/project-name:cached
      - /var/run/docker.sock:/var/run/docker.sock

De :cached optie boost performance op macOS en Windows. Het optimaliseert voor veel lezen, weinig schrijven.

SSL-trust: geen waarschuwingen meer

Lokale HTTPS vraagt vertrouwde certs. Self-signed certs breken tools.

Werkende flow:

1. Bouw een lokale CA tijdens devcontainer build
2. Voeg toe aan container trust store
3. Service-host gebruikt CA-signed certs
4. Deel CA via volume mount

Resultaat: geen warnings, alles trusted door het OS.

Health check: alles testen

Controleer met één commando:

$ curl https://app-name.yourdomain.local.dev:8899/health
{"status":"healthy","uptime":"2m34s"}

Dit checkt DNS, netwerk, TLS en de app. Groen licht? Alles werkt.

Waarom je dit moet doen

Minder handmatige stappen = meer contributors. Een goede devcontainer scheelt supportvragen en 'bij mij werkt het' drama's. Het toont dat DX prioriteit heeft.

Details als vaste IP's, DNS sidecars en certs zijn tactics. De winst: seamless onboarding.

Aan de slag

Voor complexe apps:

• Docker Compose met bridge network en vaste IP's
• Geen /etc/resolv.conf hacks
• Eigen DNS service voor wildcards
• Automatische lokale certs
• E2E testen met echte hostnames

Het kost effort upfront, maar betaalt zich uit. Eén keer goed, en iedereen profiteert.