Generator stacku Docker Swarm

Generator stacku Docker Swarm — manifest gotowy do przeglądu

Generator stacku Docker Swarm tworzy plik stack.yml dla jednej replikowanej usługi. Podajesz obraz z jawnym tagiem lub digestem, porty i ograniczenia węzłów, a narzędzie składa sekcję deploy, rolling update z rollbackiem, zasoby, sekrety zewnętrzne oraz opcjonalną sieć overlay.

Stack korzysta ze składni Compose 3.8, ponieważ polecenie docker stack deploy nadal obsługuje starszy format Compose v3. Nie jest to plik do lokalnego docker compose up: Swarm interpretuje deploy.replicas, placement i routing mesh na poziomie klastra. Jeśli potrzebujesz środowiska deweloperskiego, lepszym punktem startu jest generator Docker Compose.

Co trafia do wygenerowanego YAML

Obraz, tag i użytkownik non-root

docker stack deploy nie buduje obrazu z pola build. Najpierw zbuduj go w CI, wyślij do rejestru i wpisz pełną nazwę, np. registry.example.com/api:1.4.2. Generator odrzuca brak tagu, latest, białe znaki i próby dopisania kolejnej linii YAML. Dla niezmiennych wdrożeń po testach zamień tag na @sha256:….

Manifest Swarm nie ustawia dyrektywy USER; robi to Dockerfile. Proces w obrazie powinien działać jako konto bez uprawnień roota, a kopiowane artefakty muszą należeć do tego konta. Bezpieczny szablon obrazu przygotujesz w generatorze Dockerfile.

Wdrożenie stacku krok po kroku

1. Oznacz węzły, których używasz w constraints, np. docker node update --label-add env=production worker-1.
2. Utwórz sekrety o nazwach pokazanych na końcu YAML. Nie zapisuj plików z hasłami w repozytorium.
3. Zaloguj węzły do prywatnego rejestru lub podczas deployu użyj --with-registry-auth.
4. Zapisz wynik jako stack.yml i sprawdź wcięcia w walidatorze YAML.
5. Uruchom docker stack deploy --with-registry-auth -c stack.yml myapp, potem sprawdź docker stack services myapp oraz docker service ps myapp_myapp.

Port ingress, overlay i usługa bez portu publicznego

Port publikowany większy od zera tworzy wpis long syntax z trybem ingress. Routing mesh przyjmuje ruch na każdym węźle i kieruje go do dostępnej repliki. Wartość zero całkowicie pomija sekcję ports; nie dodaje pozornego expose, bo w Swarm usługi tej samej sieci i tak komunikują się po porcie kontenera.

Sieć overlay łączy zadania uruchomione na różnych hostach. Generator nie ustawia attachable, więc samodzielny kontener nie dołączy do niej bez potrzeby. Przy większym systemie dodaj kolejne usługi i osobne sieci frontend/backend, zamiast umieszczać wszystko w jednej domenie komunikacji.

Healthcheck, rolling update i rollback

Próba zdrowia wywołuje wget na 127.0.0.1 i ścieżce /health. Zmień ją, jeśli aplikacja używa innego endpointu, albo wyłącz opcję dla workera i bazy. Sam poprawny YAML nie gwarantuje poprawnej próby — polecenie musi istnieć w obrazie, a endpoint nie może zależeć od zewnętrznej usługi.

Aktualizacja startuje jedną nową replikę naraz, obserwuje ją przez 30 sekund i przy pierwszym błędzie przechodzi do rollbacku. Tryb start-first chwilowo wymaga miejsca na starą i nową replikę. Rezerwacje pomagają schedulerowi, a limity zatrzymują pojedynczy kontener przed zajęciem całego hosta.

Bezpieczeństwo sekretów i ograniczeń węzłów

Generator deklaruje sekrety jako external: true. Nie umieszcza ich wartości w environment, etykietach ani historii warstw obrazu. Aplikacja powinna czytać odpowiedni plik z /run/secrets/<nazwa>. Zmiana sekretu wymaga utworzenia nowej wersjonowanej nazwy i aktualizacji usługi, bo obiektu secret nie edytuje się w miejscu.

Każde constraint musi mieć pojedynczą postać klucz == wartość albo klucz != wartość. Narzędzie cytuje wpisy w YAML i odrzuca dodatkowe instrukcje. Constraints nie zastępują monitoringu pojemności: zbyt ścisły zestaw etykiet pozostawi zadania w stanie pending. Jeśli porównujesz orkiestratory, zobacz też generator deploymentu Kubernetes.

Najczęściej zadawane pytania