Sen vývojářského prostředí

Představte si: vývojář narazí na váš open-source projekt, klikne na „Otevřít v Dev Containeru“ a za pár vteřin má plně nastavené prostředí. Žádné instalace, žádné varování o certifikátech, žádné ladění proměnných. Žádné hádanky s obsazenými porty.

Tohle je síla kontejnerizovaného vývoje. Změní to hru. Ale za tou lesklou fasádou se skrývají těžké inženýrské volby.

Proč Dev Containery táhnou přispěvatele

Snadný start není jen pohodlí. Je to klíč k adopci. Čím rychleji se člověk dostane od „tohle vypadá zajímavě“ k „už to běží u mě“, tím víc lidí zůstane.

U složitých nástrojů, které napodobují Azure služby jako DNS, klíče, service busy nebo identitu, se ta brzda znásobí. Každý manuální krok je místo, kde lidi vzdají.

Architektura: Tři služby v jedné síti

Řešení? Docker Compose s promyšleným nastavením:

services:
  devcontainer:    # Pracovní prostor VS Code
  service-host:    # Hlavní app sidecar
  dns-resolver:    # Kouzelné wildcard DNS

Každá služba má svůj úkol:

• Workspace kontejner je místo pro psaní kódu a příkazy
• App sidecar běží služby na fixních portech
• DNS resolver zařizuje síťové triky pro *.yourdomain.local

Klíčem jsou fixní IP v bridge síti (172.28.0.0/16). Adresy se nemění po restartu, což DNS potřebuje.

DNS problém: Proč to není jednoduché

DNS v kontejneru bolí. Linux to řeší přes /etc/resolv.conf, ale ten soubor je křehký. Docker ho přepíše, host ho změní.

Přímo ho nehackujte – rychle to selže. Místo toho pusťte sidecar resolver (jako dnsmasq), který:

1. Běží na fixní IP v síti
2. Zpracovává *.yourdomain.local.dev
3. Předává zbytek na host DNS
4. Docker ho nastaví jako primární nameserver

Tak spolupracujete se systémem, ne proti němu.

Síť v Compose: Past s montováním

V Dev Containers s Compose se montování souborů mění. Workspace musí být dostupný, ale chování je jiné.

V compose.yml to vyřešte takto:

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

:cached zrychlí na macOS a Windows. Docker pak optimalizuje čtení před zápisem.

Certifikáty: TLS nemůžete ignorovat

Pro HTTPS potřebujete důvěryhodné certy. Self-signed varují a lámou API.

Funkční postup:

1. Vygenerujte lokální CA při build devcontaineru
2. Přidejte do trust store kontejneru
3. Sidecar používá certy z této CA
4. Sdílejte CA přes volume

Výsledek? Žádné varování, OS to důvěřuje.

Health check: Ověřte to celé

Nastavte to a otestujte:

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

Jeden příkaz testuje DNS, síť, TLS i app. Funguje? Devcontainer je ready.

Proč to stojí za to pro váš projekt

Každý odstraněný manuální krok otevírá dveře. Správný Compose setup škáluje na tým i komunitu.

Vrátí se to hned: rychlejší onboarding, méně „u mě to běží“, signál, že na DX záleží.

Fix IP, DNS sidecar, certy, volumy – to jsou detaily. Výhra je v plynulém startu.

Jak na to

Pro složité app v devcontaineru začněte tady:

• Docker Compose s bridge sítí a fix IP
• /etc/resolv.conf nedotýkejte
• Samostatný DNS pro wildcards
• Automatické lokální certy s trustem
• Testujte reálné requesty na hostname

Složitost je na začátku. Pak to jede samo – a každý vývojář poděkuje.