Co to jest docker-compose.yml, w jednym akapicie
service to jeden kontener, a plik `docker-compose.yml` to lista usług, które mają działać razem (Twoja aplikacja, baza, czasem cache i reverse proxy). Jedno polecenie, `docker compose up`, uruchamia cały stos, a `docker compose down` zwija go z powrotem do zera. To standardowy sposób na uruchamianie aplikacji wielokontenerowych na jednej maszynie: laptop developerski, jednowęzłowy serwer produkcyjny, runner CI.
Ten kreator pisze ten plik za Ciebie. Wybierz preset (WordPress + MySQL, Node + Postgres + Redis, Nginx + PHP-FPM + MariaDB, sam Redis, ClickHouse jednowęzłowy), edytuj usługi w prostych formularzach, a prawa kolumna pokaże dokładny YAML gotowy do wklejenia w `docker-compose.yml`. Każda opcja ma podpowiedź zwykłym językiem.
Wszystko działa w przeglądarce. Nic się nigdzie nie wysyła, nie potrzebujesz konta, żaden kontener tu nie startuje - wynikiem jest ten sam tekst, który napisałbyś ręcznie.
Jak używać
- Wybierz preset u góry (WordPress + MySQL, Node + Postgres + Redis, Nginx + PHP-FPM + MariaDB, sam Redis, ClickHouse jednowęzłowy). Formularz wypełni sensowne wartości, które potem zmienisz.
- Wpisz nazwę projektu na górze. Wyląduje jako pole `name:` w pliku i prefiks dla nazw kontenerów (koniec z losowymi `myapp_web_1`).
- Dla każdej service ustaw: image (np. `nginx:alpine`), ports (host:kontener, można dodać wiele), volumes (z przełącznikiem read-only) i zmienne environment.
- Wybierz restart policy: `no`, `always`, `on-failure` albo `unless-stopped`. Dla serwerów produkcyjnych zwykle pasuje `unless-stopped`.
- Użyj depends_on, żeby powiedzieć „odpal bazę przed aplikacją". Dodaj healthcheck na bazie, żeby inne usługi mogły poczekać na gotowość, a nie tylko na start.
- Zdefiniuj networks na poziomie głównym i przypisz każdą usługę do jednej lub kilku. Usługi w tej samej sieci dochodzą do siebie po nazwie (np. `db:5432`).
- Kliknij Kopiuj w panelu podglądu albo Pobierz, żeby zapisać jako `docker-compose.yml`. Potem w tym samym katalogu uruchom `docker compose up -d`. To cały flow.
Kiedy się przydaje
Siedem konkretnych sytuacji, w których docker-compose realnie ułatwia życie:
- Laptop developerski potrzebujący Postgresa, Redisa i Twojej aplikacji Node. Jeden plik, jedno `docker compose up` i cały stos jest online. Bez Homebrew, bez apt-get, bez różnic wersji w zespole.
- Mały VPS hostujący jedną albo dwie aplikacje. Compose to najprostsza droga: napisz plik, `docker compose up -d`, postaw nginx z przodu, gotowe. Kubernetes to przerost na jedną maszynę.
- Lokalna kopia produkcji. Jeśli prod ma Postgres 16, Redis 7 i Node 20, ten sam plik compose pinuje te wersje na każdej maszynie deweloperskiej. „Działa u mnie na laptopie" zamienia się w „działa na każdym laptopie".
- Pipeline CI wymagający prawdziwych usług. Compose wstaje z prawdziwym Postgresem dla testów integracyjnych w kilka sekund i zwija go po teście. Dużo bliżej prod niż mocki czy sqlite.
- Self-hosting aplikacji trzecich: WordPress, Ghost, Mastodon, NextCloud, Plausible, Gitea, n8n. Oficjalny plik compose to zwykle udokumentowana ścieżka instalacji.
- Postawienie stosu na demo. Wysyłasz jedno repo z jednym plikiem, a recenzent wpisuje jedno polecenie. Bez „najpierw zainstaluj Postgresa 14 z tymi rozszerzeniami".
- Sprawdzenie nowej bazy. Chcesz pobawić się ClickHouse, MongoDB albo DuckDB bez globalnej instalacji? `docker compose up` na pięć minut, potem `docker compose down -v` i maszyna jest znowu czysta.