Kiedy Docker Swarm nadal ma sens, a kiedy zaczyna kosztować za dużo

Co kilka miesięcy ktoś pyta mnie, dlaczego nie przenosimy wszystkiego na Kubernetesa. Pytanie jest uczciwe. Odpowiedź brzmi: bo na razie by się nie zwróciło. Poniżej opisuję, jak dochodzę do tego wniosku i co musiałoby się zmienić, żebym zmienił zdanie.

Od czego zaczynam: kto będzie to utrzymywał

Pierwsze pytanie nie dotyczy narzędzia. Dotyczy ludzi. Ile osób w zespole rozumie infrastrukturę na tyle, żeby samodzielnie zdiagnozować awarię? Jeśli odpowiedź brzmi „jedna, może dwie”, to każda warstwa abstrakcji, którą dokładam, jest długiem zaciągniętym na ich nazwisko.

Swarm jest wbudowany w Docker Engine. Kto zna docker compose, w jedno popołudnie zrozumie docker stack deploy. Kubernetes daje znacznie więcej, ale wymaga też znacznie więcej: własnego modelu obiektów, własnych narzędzi, własnego sposobu myślenia o sieci i konfiguracji.

Gdzie Swarm sprawdza się dobrze

Z mojego doświadczenia Swarm jest rozsądnym wyborem, gdy spełnione są trzy warunki:

• Ruch jest przewidywalny. Wiesz mniej więcej, ile replik potrzebuje każda usługa, i nie musisz ich dokładać automatycznie co kilka minut.
• Usług jest kilka lub kilkanaście, a nie kilkaset. Plik stacka da się jeszcze przeczytać w całości.
• Zespół jest mały i woli prostotę od pełnej kontroli.

W takim układzie dostajesz to, czego naprawdę potrzebujesz: rolling update z automatycznym wycofaniem, sekrety, sieci overlay, healthchecki i prosty routing przez Traefika na etykietach.

services:
  api:
    image: registry.example.com/api:1.42.0
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
        order: start-first
        failure_action: rollback
      restart_policy:
        condition: on-failure
      labels:
        - traefik.enable=true
        - traefik.http.routers.api.rule=Host(`api.example.com`)
        - traefik.http.services.api.loadbalancer.server.port=8080
    healthcheck:
      test: ['CMD', 'wget', '-qO-', 'http://localhost:8080/health']
      interval: 10s
      timeout: 3s
      retries: 3
    secrets:
      - db_password

secrets:
  db_password:
    external: true

Najważniejsze są tu dwie linijki: order: start-first i failure_action: rollback. Nowa replika startuje, zanim stara zostanie zatrzymana, a jeśli healthcheck nie przejdzie, Swarm sam wraca do poprzedniej wersji. Dla większości aplikacji webowych to wystarcza, żeby wdrożenia przestały być wydarzeniem.

Gdzie zaczyna boleć

Swarm ma swoje granice i warto je znać, zanim się w nie uderzy.

Brak autoskalowania. Nie ma odpowiednika Horizontal Pod Autoscalera. Da się to obejść skryptem, który czyta metryki i zmienia liczbę replik, ale wtedy utrzymujesz własny autoscaler.

Mniejszy ekosystem. Wiele narzędzi powstaje dziś z myślą o Kubernetesie: operatory baz danych, gotowe charty Helm, integracje z systemami obserwowalności. Przy Swarmie częściej składasz rzeczy samodzielnie.

Stanowe usługi. Bazy danych w Swarmie da się uruchomić, ale wymaga to dyscypliny: przypięcia do konkretnych węzłów, przemyślanych wolumenów i kopii zapasowych. Ja zwykle trzymam je poza klastrem.

Jak zapisuję taką decyzję

Każdą decyzję tego typu zapisuję w jednym miejscu, razem z warunkami, w których przestaje obowiązywać. Dzięki temu za rok nie dyskutujemy od zera, tylko sprawdzamy, czy warunki się zmieniły.

Ramka decyzji

Decyzja

Zostajemy przy Docker Swarm na kolejne 12 miesięcy.

Dlaczego

Mały zespół, przewidywalny ruch, kilkanaście usług. Swarm pokrywa nasze potrzeby, a każda osoba w zespole rozumie, jak działa.

Koszty

Brak autoskalowania i mniej gotowych narzędzi. Część rzeczy (np. backupy usług stanowych) składamy samodzielnie.

Wracam, gdy

potrzebne będzie autoskalowanie per usługa, wejdziemy w kilka regionów albo liczba usług przestanie mieścić się w jednym pliku stacka.

Co z tego wynika

Nie twierdzę, że Swarm jest lepszy od Kubernetesa. Twierdzę, że dla wielu małych zespołów jest wystarczający, a różnica w koszcie utrzymania jest większa, niż sugerują porównania funkcji.

Jeśli zastanawiasz się nad tym samym wyborem, zacznij od trzech pytań: kto będzie to naprawiał, jak bardzo zmienia się Twój ruch i ile usług będziesz mieć za rok. Odpowiedzi zwykle rozstrzygają sprawę szybciej niż tabela funkcji.