Robocikowo>ROBOCIKOWO
Wdrożenie

Docker Compose

2014AktywnyOpublikowano: 1 października 2026Aktualizacja: 1 października 2026Opublikowany
Narzędzie Dockera do definiowania i uruchamiania wielokontenerowych aplikacji za pomocą jednego pliku YAML i jednej komendy.
Kluczowa innowacja
Sprowadził definicję i uruchomienie całej wielokontenerowej aplikacji do jednego deklaratywnego pliku YAML i jednej komendy (docker compose up), zastępując ręczne, rozsypane skrypty z wieloma wywołaniami docker run.
Kategoria
Wdrożenie
Poziom abstrakcji
System
Poziom operacji
WdrożenieUdostępnianieSystem
Zastosowania
Lokalne środowisko deweloperskie całego stosu aplikacji jedną komendąSelf-hosting stacków AI: serwowanie modelu + baza wektorowa + API/gatewayOdtwarzalne środowiska do testów integracyjnych i CIPrototypowanie i demo aplikacji agentowych i mikroserwisowychUruchamianie platform agentowych rozprowadzanych jako docker-composeProste, jednohostowe wdrożenia bez pełnego orkiestratora

Jak działa

Programista opisuje aplikację w pliku compose.yaml, używając elementów najwyższego poziomu: services (komponenty obliczeniowe aplikacji), networks (sposób komunikacji usług między sobą), volumes (trwałe dane współdzielone przez usługi) oraz opcjonalnie configs i secrets. Każda usługa wskazuje obraz do pobrania albo kontekst budowania, porty, zmienne środowiskowe, zależności (depends_on), healthchecki i podpięte wolumeny. Komenda docker compose up czyta plik, buduje lub pobiera obrazy, tworzy wspólną sieć, startuje kontenery we właściwej kolejności i spina je nazwami usług jako hostami DNS. Komendy pokrewne (down, ps, logs, exec, build) obejmują resztę cyklu życia. Compose V2 ignoruje przestarzały element version i interpretuje plik zgodnie z Compose Specification.

Rozwiązany problem

Uruchomienie realnej aplikacji wymaga zwykle kilku współpracujących kontenerów (API, baza danych, cache, kolejka, serwowanie modelu) połączonych w sieć i trzymających dane w wolumenach. Robienie tego ręcznie wieloma komendami docker run jest żmudne, niepowtarzalne i trudne do wersjonowania. Compose rozwiązuje to, opisując cały stos jako jeden plik w repozytorium i odtwarzając identyczne środowisko jedną komendą.

Komponenty

Plik Compose (compose.yaml)Deklaratywna definicja całego stosu aplikacji

Pojedynczy plik YAML (domyślnie compose.yaml, alternatywnie compose.yml) w katalogu roboczym, opisujący usługi, sieci, wolumeny oraz opcjonalnie configs i secrets. Jest źródłem prawdy o stosie i trafia do repozytorium.

Usługi (services)Komponenty obliczeniowe aplikacji

Każda usługa to kontener (lub ich zestaw) uruchamiany z określonego obrazu lub kontekstu budowania, z portami, zmiennymi środowiskowymi, zależnościami i healthcheckami. To główny budulec pliku Compose.

Sieci (networks)Komunikacja między usługami

Usługi komunikują się ze sobą przez sieci. Compose tworzy domyślną sieć dla projektu, dzięki czemu usługi adresują się nawzajem po nazwach jako hostach DNS; można też definiować dodatkowe, izolowane sieci.

Wolumeny (volumes)Trwałe, współdzielone dane

Usługi przechowują i współdzielą dane trwałe w wolumenach, które żyją niezależnie od cyklu życia kontenera. Typowo używane dla baz danych, indeksów wektorowych czy cache modeli.

Compose CLI (docker compose)Zarządzanie cyklem życia stosu

Wtyczka CLI (Compose V2, napisana w Go) wywoływana jako docker compose. Komendy up/down/ps/logs/exec/build pokrywają start, zatrzymanie, podgląd statusu, logi i polecenia jednorazowe. Starsza wersja v1 była osobnym narzędziem w Pythonie wywoływanym jako docker-compose.

Implementacja

Implementacje referencyjne
docker/compose
Go · Docker, Inc.
Oficjalna
Pułapki implementacyjne
Mylenie docker-compose (v1) z docker compose (V2)Średnia

Stare materiały używają komendy docker-compose (v1, Python), podczas gdy aktualny Compose V2 to wtyczka CLI wywoływana jako docker compose. Różnice obejmują m.in. ignorowanie elementu version w V2.

Rozwiązanie:Używaj Compose V2 (docker compose) i aktualnej Compose Specification; nie polegaj na elemencie version.
depends_on nie czeka na gotowość usługiWysoka

Domyślnie depends_on zapewnia tylko kolejność startu kontenerów, nie czeka aż usługa (np. baza danych) będzie faktycznie gotowa do przyjmowania połączeń.

Rozwiązanie:Zdefiniuj healthcheck i użyj depends_on z warunkiem condition: service_healthy; dodaj retry w aplikacji.
Nie zastępuje orkiestratora produkcyjnegoWysoka

Compose zarządza stosem zwykle na jednym hoście i nie zapewnia schedulingu wielowęzłowego, samonaprawy ani autoskalowania między maszynami — to zadania dla Kubernetes czy Swarm.

Rozwiązanie:Do produkcji w skali użyj orkiestratora (Kubernetes); Compose zostaw do dev/lokalnie i prostych wdrożeń.
Konflikty portów i uprawnień bind-mountówŚrednia

Publikowanie tych samych portów hosta przez kilka stosów powoduje konflikty, a bind-mounty katalogów hosta bywają źródłem problemów z uprawnieniami i wydajnością (szczególnie na macOS/Windows).

Rozwiązanie:Używaj nazwanych wolumenów zamiast bind-mountów tam, gdzie to możliwe, i rozdzielaj porty lub profile między stosami.

Ewolucja

2013
Pierwsza wersja beta (0.0.1)

Pierwsza publiczna wersja beta narzędzia (0.0.1) wg Wikipedii; projekt wywodzi się z wcześniejszego narzędzia Fig (poprzednik Compose).

2014
Compose v1 (Python, docker-compose)
Punkt przełomowy

Compose v1 wydany w 2014 r., napisany w Pythonie i wywoływany jako docker-compose; wersja produkcyjna 1.0 udostępniona 16 października 2014 r.

2016
Format pliku 2.x

Wprowadzenie formatu pliku Compose w wersji 2.x.

2017
Format pliku 3.x

Wprowadzenie formatu pliku Compose w wersji 3.x.

2020
Compose V2 (Go, wtyczka CLI, Compose Specification)
Punkt przełomowy

Compose V2 ogłoszony w 2020 r.: przepisany w Go, wywoływany jako docker compose (wtyczka CLI). Ignoruje element version i w całości opiera interpretację pliku na otwartej Compose Specification.

2025
Compose v5 (SDK w Go)

Compose v5 wydany w 2025 r., funkcjonalnie tożsamy z Compose V2, ale wprowadza oficjalny SDK w Go do programistycznej integracji.

Hiperparametry (konfigurowalne osie)

Definicje usługKrytyczna

Zestaw usług-kontenerów tworzących aplikację; podstawowy wymiar konfiguracji pliku Compose.

Obraz lub kontekst budowaniaWysoka

Dla każdej usługi: gotowy obraz do pobrania albo lokalny kontekst budowania (Dockerfile).

Mapowanie portówWysoka

Publikacja portów kontenera na hoście; częste źródło konfliktów przy wielu stosach.

Zmienne środowiskoweWysoka

Konfiguracja usług przez zmienne środowiskowe i pliki .env (np. klucze API, adresy modeli).

Zależności i gotowośćŚrednia

Kolejność startu usług oraz warunki gotowości; depends_on sam w sobie czeka tylko na start, nie na pełną gotowość.

ProfileNiska

Warunkowe włączanie podzbiorów usług (np. dev vs. pełny stos) w jednym pliku Compose.