Generator docker-compose

Złóż plik docker-compose.yml dla swojego stacku

Bezpieczne (SSL)

Przetwarzanie Lokalne

100% Darmowe

Przejdź do narzędzia

Instrukcja

1

Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku.
2

Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce.
3

Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.

                                                function runTool() {

                                                  return "Wynik gotowy w 0.1s";

                                                }

Usługi w stacku

Aplikacja (PHP-FPM)

Nginx

MySQL / MariaDB

PostgreSQL

Redis

MailHog

Port HTTP

Wersja bazy danych

Zaznacz usługi i kliknij „Generuj docker-compose.yml”.

Oceń to narzędzie:

Powiązane narzędzia

Inne narzędzia, które mogą Ci się przydać

Generator docker-compose.yml — cały stack webowy w jednym pliku

Generator docker-compose.yml składa plik dla lokalnego środowiska webowego z sześciu klocków: kontenera aplikacji PHP-FPM, Nginksa, MySQL lub MariaDB, PostgreSQL, Redisa i MailHoga. Zaznacz usługi, ustaw port HTTP i wersję bazy, a dostaniesz YAML z healthcheckami, nazwanymi wolumenami i hasłami w zmiennych środowiskowych.

Co narzędzie wstawia do pliku

Każda zaznaczona usługa to jeden blok w sekcji services. Pola version: generator nie pisze — Compose Specification traktuje je jako przedawnione.

Usługa	Obraz	Port na hoście	Wolumen
Aplikacja (PHP-FPM)	`build: .`	brak	bind mount
Nginx	`nginx:1.27-alpine`	wybrany port HTTP	bind mount
MySQL / MariaDB	`mysql:8.0`, `mysql:8.4`, `mariadb:10.11`	127.0.0.1:3306	`db_data`
PostgreSQL	`postgres:16-alpine`	127.0.0.1:5432	`pg_data`
Redis	`redis:7-alpine`	127.0.0.1:6379	`redis_data`
MailHog	`mailhog/mailhog:v1.0.1`	127.0.0.1:1025 i 8025	—

Kontener aplikacji dostaje zmienne z danymi dostępowymi: DB_HOST to db albo postgres, REDIS_HOST to redis. Przy dwóch bazach naraz zmienne DB_* opisują MySQL.

Jak uruchomić wygenerowany stack

Zaznacz usługi, wpisz port HTTP i wybierz wersję bazy. Przycisk Przykład ustawia typowy zestaw: aplikacja, Nginx, MySQL 8.0 i Redis na porcie 8080.
Skopiuj wynik i zapisz jako docker-compose.yml w katalogu projektu.
Obok utwórz .env z wpisami DB_PASSWORD i DB_ROOT_PASSWORD.
Przy kontenerze aplikacji dołóż Dockerfile — pomoże generator Dockerfile.
Dla Nginksa przygotuj docker/nginx/default.conf; blok location złożysz w konfiguratorze bloków location Nginx.
Uruchom docker compose up -d, stan sprawdź przez docker compose ps, a logi przez docker compose logs -f.

Hasła nie są wpisane w plik

W miejscu hasła generator wstawia ${DB_PASSWORD:?set DB_PASSWORD in .env}. Zapis :? oznacza zmienną wymaganą: bez niej Compose przerwie start i powie, czego brakuje, zamiast podnieść bazę z hasłem znanym każdemu, kto widział ten szablon.

Plik compose trafia do repozytorium, plik .env nie. Ten sam YAML obsługuje wtedy maszynę każdego programisty i środowisko CI, a poświadczenia zostają poza Gitem. Gdy lista zmiennych rośnie, przyda się sorter zmiennych pliku .env.

Dlaczego samo depends_on nie wystarcza

Krótka forma depends_on: [db] pilnuje tylko kolejności uruchamiania. Kontener bazy jest „wystartowany” po kilkuset milisekundach, ale MySQL potrzebuje kilkunastu sekund na inicjalizację katalogu danych — aplikacja zdąży w tym czasie polec na odmowie połączenia. Dlatego każda baza i Redis dostają sekcję healthcheck, a usługa aplikacji formę długą:

depends_on:
  db:
    condition: service_healthy

Nginx czeka na aplikację przez condition: service_started, bo kontener PHP-FPM nie ma healthchecka i warunek zdrowia zablokowałby start stacku.

Wolumeny, porty i sieć

Dane baz lądują w nazwanych wolumenach. Taki wolumen przetrwa docker compose down i nie zależy od uprawnień katalogu na hoście; usuwa go dopiero docker compose down -v. Katalog projektu jest bind mountem, bo w pracy chcesz widzieć zmiany w kodzie bez przebudowy obrazu.

Porty baz i cache generator publikuje na 127.0.0.1. Zapis 3306:3306 nasłuchuje na wszystkich interfejsach, więc na laptopie w publicznej sieci Wi-Fi wystawia bazę na zewnątrz. Kontenery i tak widzą się po nazwach usług w sieci Compose — hostem bazy jest db albo postgres, nigdy localhost.

Zanim przeniesiesz plik na produkcję

Ten szablon opisuje środowisko deweloperskie: kod montowany z hosta, port bazy na localhoście, MailHog przechwytujący pocztę. Na produkcji kod wchodzi do obrazu, portów baz nie publikuje się wcale, a wiadomości wysyła prawdziwy dostawca. Dla klastra potrzebne są manifesty z generatora deploymentu Kubernetes, a sam plik warto przepuścić przez walidator YAML — tu jedna spacja za dużo zmienia sens struktury.

Najczęściej zadawane pytania

Czym różni się Dockerfile od docker-compose.yml?

Dockerfile to przepis na jeden obraz: bazowy system, zależności, kod, komenda startowa. Plik docker-compose.yml nie buduje niczego sam — opisuje, które obrazy uruchomić razem, jak połączyć je siecią i w jakiej kolejności podnieść. W usłudze aplikacji widać to we wpisie build: ., który odsyła do Twojego Dockerfile.

Dlaczego aplikacja nie widzi bazy danych?

Prawie zawsze dlatego, że w konfiguracji został localhost. Wewnątrz kontenera localhost oznacza ten sam kontener, nie hosta. W sieci Compose adresem bazy jest nazwa usługi: db dla MySQL i MariaDB, postgres dla PostgreSQL. Drugi typowy powód to zbyt szybki start aplikacji — na to jest healthcheck z warunkiem service_healthy.

Czy dane bazy przetrwają usunięcie kontenera?

Tak, trzyma je nazwany wolumen db_data, pg_data lub redis_data z sekcji volumes na końcu pliku. Skasuje go wyłącznie jawne docker compose down -v albo docker volume rm.

Dlaczego w pliku nie ma pola version?

Bo od czasu Compose Specification jest zbędne. Wersja w stylu version: "3.8" pochodzi z czasów, gdy Compose miał kilka niekompatybilnych schematów pliku. Dzisiejsze docker compose wykrywa schemat sam, a napotkane pole zgłasza jako przedawnione.

MailHog nie jest już rozwijany, co zamiast niego?

Następcą jest Mailpit, zgodny z MailHogiem pod względem SMTP na porcie 1025 i interfejsu web na 8025. Generator wstawia MailHoga w przypiętej wersji v1.0.1, więc obraz nie zmieni się pod ręką. Jeśli wolisz Mailpit, podmień samą linię image na axllent/mailpit:latest.