Marzenie developera: idealne środowisko bez bólu głowy

Wyobraź sobie: deweloper trafia na twój open-source projekt, klika "Otwórz w Dev Container" i po chwili ma gotowe środowisko do kodowania. Bez instalowania paczek. Bez błędów z certyfikatami. Bez kombinowania z portami czy zmiennymi środowiskowymi.

To magia konteneryzowanych workflowów deweloperskich. Rewolucja w praktyce. Ale pod tą prostotą kryje się masa sprytnych decyzji technicznych.

Dlaczego Dev Containers to klucz do contributorów

Szybki start to nie fanaberia – to lej konwersji. Im krótsza droga od "znalazłem repo" do "już działa u mnie", tym więcej osób dołączy. Najwięcej projektów umiera na etapie setupu.

Gdy twój tool symuluje usługi Azure – jak DNS, zarządzanie kluczami, service busy czy identity – każdy krok instalacyjny to pułapka. Jeden błąd i delikwent odchodzi.

Architektura: trzy serwisy w jednej sieci

Rozwiązanie? Docker Compose z precyzyjnym składem:

services:
  devcontainer:    # Miejsce na kod i komendy
  service-host:    # Główna apka z sidecarem
  dns-resolver:    # Czar wildcard DNS

Każdy ma rolę:

• Kontener workspace – tu developer koduje i testuje.
• Sidecar apki – usługi na stałych portach.
• Resolver DNS – obsługa *.twojadomena.local.

Stałe IP w sieci bridge (172.28.0.0/16) to podstawa. Adresy nie skaczą po restarcie, DNS wie, gdzie celować.

DNS w kontenerze: dlaczego to wyzwanie

DNS w Linuxie to pole minowe. Plik /etc/res resolv.conf rządzi, ale Docker go nadpisuje, host miesza, konfiguracja leci w diabły.

Na początku próbowałem edytować plik ręcznie – lipa, nietrwałe. System kasuje zmiany przy starcie sieci.

Lepsze: sidecar z dnsmasq jako osobny serwis:

1. Na stałym IP w sieci kontenerów.
2. Obsługuje wildcards (*.twojadomena.local.dev).
3. Reszta idzie do DNS hosta.
4. Ustawiony jako primary nameserver w Dockerze.

Nie walczysz z systemem – współpracujesz. DNS to pełnoprawny gracz.

Sieć w Compose: haczyk z montowaniem

W Dev Containers z Compose montowanie plików działa inaczej. Workspace musi być dostępny, ale tryb Compose ma swoje reguły.

Klucz w compose.yml:

services:
  devcontainer:
    volumes:
      - ..:/workspaces/nazwa-projektu:cached
      - /var/run/docker.sock:/var/run/docker.sock

Flaga :cached ratuje perf na macOS i Windows. Kontener czyta szybciej, bo Docker optymalizuje.

Certyfikaty: TLS bez ostrzeżeń

Dev z HTTPS wymaga zaufanych certów. Self-signed to błędy i zepsute API.

Wzór, który działa:

1. Buduj lokalny CA przy starcie devcontainer.
2. Dodaj do trust store w kontenerze.
3. Sidecar używa certów z tego CA.
4. Udostępnij CA przez volume – narzędzia ufają.

Zero warningów. System kontenera traktuje certy serio.

Health check: sprawdź całość

Na koniec test:

$ curl https://nazwa-apki.twojadomena.local.dev:8899/health
{"status":"healthy","uptime":"2m34s"}

Jeden curl wali po DNS, sieci, TLS i apce. Działa? Setup idealny.

Po co to komu w projekcie

Każdy usunięty krok manualny to mniej barier. Dobre Compose to infrastruktura dla teamu i community.

Zwrot z inwestycji? Szybki onboarding, mniej "u mnie działa", sygnał: dbamy o dev experience.

Szczegóły – IP, sidecar DNS, certy, volumes – to technika. Wygrana to zero tarć.

Jak zacząć

Budujesz devcontainer dla złożonej apki? Stosuj:

• Docker Compose z bridge i stałymi IP.
• Zero zaufania do /etc/resolv.conf.
• Dedykowany resolver dla wildcardów.
• Automatyczne lokalne certy z zaufaniem.
• Testuj end-to-end po hostname'ach.

Kompleksowość jednorazowa. Potem każdy developer korzysta na zawsze.