Dokumentacja

English · Polski

Docker Compose

Container Desktop uruchamia stacki docker-compose.yml na CLI container od Apple, które samo nie obsługuje compose. Aplikacja parsuje YAML i tłumaczy każdą usługę na zwykłe wywołanie container run — bez dodatkowego demona i ukrytego stanu. Otwórz przez Kontenery → Compose, wklej YAML i kliknij Uruchom.

Dla każdego projektu aplikacja:

tworzy sieć projektu o nazwie projektu (top-level name: albo pole w dialogu),
uruchamia usługi w kolejności depends_on, streamując ich wyjście na żywo,
etykietuje kontenery compose.project / compose.service, dzięki czemu na liście pojawiają się zgrupowane ze zbiorczym start / stop / usuń.

Obsługiwane klucze usług

Klucz	Uwagi
`image`	Wymagany. `build:` nie jest wspierany — wskaż gotowy obraz.
`container_name`	Nadpisuje domyślną nazwę `<projekt>-<usługa>`.
`command` / `entrypoint`	String lub lista. Wieloczłonowe entrypointy (np. `["dotnet", "dbmgr.dll"]`) są tłumaczone poprawnie.
`environment`	Forma mapy lub listy.
`ports`	Składnia krótka (`"8080:80"`, opcjonalnie `/udp`) i długa.
`volumes`	`źródło:cel[:ro]`; nazwane wolumeny muszą już istnieć.
`mem_limit` / `cpus`	Limity zasobów VM (także `deploy.resources.limits`). Domyślnie 1 GB — pamięciożerne zadania init (np. zasiewanie bazy) zwykle potrzebują `mem_limit: 4g`.
`depends_on`	Lista lub mapa (warunki inne niż service_started są ignorowane z ostrzeżeniem).
`x-init`	Rozszerzenie Container Desktop — zobacz Zadania x-init.

host.containers.internal

Użyj nazwy host.containers.internal w wartościach environment albo w command, aby z wnętrza kontenerów dotrzeć do Twojego Maca (odpowiednik dockerowego host.docker.internal).

environment:
  DB_SERVER: "host.containers.internal,1433"   # SQL Server działający na hoście

Dlaczego alias zamiast IP: każdy projekt compose dostaje własną sieć vmnet z własną podsiecią, więc adres bramy (hosta) różni się między projektami i może się zmienić po restarcie usługi container (np. 192.168.64.1 vs 192.168.65.1). Aplikacja odpytuje sieć projektu zaraz po utworzeniu i podmienia alias na właściwy adres bramy — mapowanie widać w logu postępu.

Usługa na hoście musi nasłuchiwać na wszystkich interfejsach (0.0.0.0), nie tylko na 127.0.0.1, żeby być osiągalna z podsieci vmnet. Porty publikowane przez inne projekty Container Desktop albo przez Docker Desktop na hoście są osiągalne tą samą drogą.

Nazwy usług (zszywanie /etc/hosts)

Usługi widzą się nawzajem po nazwie kontenera — np. przy domyślnym nazewnictwie usługa server w projekcie shop to shop-server:

environment:
  API_URL: "http://shop-server:22000"

container 1.0.0 ma wbudowany resolver DNS nazw kontenerów, ale ten nigdy nie trafia: nazwy rejestrowane są bez końcowej kropki FQDN, a zapytania DNS przychodzą skanonizowane — każde wyszukiwanie kończy się SERVFAIL. Container Desktop to obchodzi: po starcie każdej usługi aplikacja odczytuje jej IP i wymienia wpisy /etc/hosts między wszystkimi usługami projektu (log postępu pokazuje każde mapowanie).

Wpisy żyją wewnątrz kontenerów, więc obowiązują do odtworzenia kontenera. Jeśli ręcznie zatrzymasz i uruchomisz pojedynczy kontener i jego IP się zmieni, ponów compose z „Zastąp istniejące", by odświeżyć powiązania.

Zadania x-init

Oznacz usługę x-init: true, aby uruchomić ją jako zadanie jednorazowe — np. utworzenie bazy danych tym samym obrazem, ale innym entrypointem. Zadania init wykonują się przed wszystkimi zwykłymi usługami, sekwencyjnie i do końca; usługi startują dopiero, gdy każde zadanie init zakończy się sukcesem.

services:
  dbinit:
    image: registry.example.com/server:1.0
    x-init: true
    entrypoint: ["dotnet", "dbmgr.dll"]
    command: create mydb --sqlserver "host.containers.internal,1433" --recreate

  server:
    image: registry.example.com/server:1.0
    # startuje dopiero, gdy dbinit zakończy się kodem 0

Nieudane zadanie init przerywa cały przebieg; jego kontener jest zachowywany do wglądu w logi (kontenery udanych zadań init są sprzątane automatycznie).
Przełącznik „Pomiń zadania init" wznawia stack bez powtarzania konfiguracji — przydatne, gdy baza już istnieje.
Zadanie init może zależeć od innych zadań init, ale nie od zwykłych usług (init zawsze wykonują się pierwsze).

Ograniczenia

build: nie jest wspierany — najpierw zbuduj obraz (dialog Zbuduj w aplikacji) i wskaż go tagiem.
healthcheck, restart, profiles i inne nieobsługiwane klucze są ignorowane — każdy z ostrzeżeniem przy parsowaniu, nigdy po cichu.
depends_on czeka na start zależności, nie na jej gotowość. Jeśli usługa łączy się z zależnością przy starcie i nie ma retry, zrestartuj ją przyciskiem ↻.
Deklaracje top-level volumes: nie tworzą wolumenów automatycznie — utwórz nazwane wolumeny w zakładce Wolumeny.

Rozwiązywanie problemów

Usługa nie widzi hosta — sprawdź, czy proces na hoście słucha na 0.0.0.0 i czy używasz host.containers.internal zamiast localhost (w kontenerze localhost to sam kontener).
Nazwy przestały się rozwiązywać po restarcie kontenerów — ponów compose z „Zastąp istniejące", by odświeżyć wpisy /etc/hosts.
Bindowanie portu poniżej 1024 kończy się Permission denied — obrazy działające jako nie-root nie mogą bindować portów uprzywilejowanych; nasłuchuj na wysokim porcie (np. 8080) i publikuj 60000:8080.
Wszystko wisi na sieci projektu — helper vmnet mógł się zrestartować pod kontenerami; odtwórz stack („Zastąp istniejące"), a jeśli to za mało — zrestartuj usługę w zakładce System.
Logi usługi — zakładka System ma wbudowany podgląd logów usługi container (okna 5 min / 30 min / 1 h).

← Container Desktop · GitHub · MIT