Docker Swarm – wiele osób zastanawia się, co z nim dalej. Niektórzy uważają, że jest już martwy, choć wcale tak nie jest. Mimo wielu zalet Kubernetesa i de fakto bycia standardem na rynku – nadal są firmy dla których Swarm jest po prostu wygodny i przyjemny, a jego funkcjonalności zupełnie wystarczające.
Szczególnie czerpać z tego rozwiązania mogą “małe” klastry on-premise, gdzie chcemy chociaż minimalnie zapewnić wysoką dostępność aplikacjom. Znam nawet firmy, które w tym roku zdecydowały się na użycie Docker Swarma, ponieważ próg wejścia w Kubernetes dla nich jest zbyt wysoki.
Co dalej z Docker Swarm?
Jakiś czas temu zaintrygował mnie newsletter od firmy Mirantis (firma, która kupiła rozwiązanie Docker Enterprise) informujący, że będą nadal rozwijać Docker Swarm. Jedną z planowanych zmian było wprowadzenie Swarm CSI (Container Storage Interface). Wynika to z tego, iż rozwiązanie Docker Enterprise jest nadal wykorzystywane w wielu dużych firmach.

W dawnym produkcie Docker Enterprise (obecnie Mirantis Kubernetes Engine) istnieje możliwość wyboru orkiestratora – Swarm i Kubernetes. Migracja do Kubernetes nie jest czymś, co można zrobić “hop siup”. A w środowiskach korporacyjnych każda zmiana to duże przedsięwzięcie. Dlatego też wiele firm nadal korzysta z Docker Swarm na produkcji. Stąd Mirantis jako dostawca oprogramowania zobowiązuje się do utrzymywania i rozwoju Docker Swarm.
Odpowiadając na pytanie, czy Docker Swarm wciąż żyje – tak, żyje i dalej jest rozwijany. Jedną z wątpliwości społeczności dotyczących Docker Swarm było to, czy rozwój Docker Swarm przez Mirantis oznacza utrzymywanie projektu open-source. Wątpliwość ta została już rozwiana – to co dotychczas zostało zrobione w płatnym produkcie, jest też dostępne w wersji open-source.
Najnowsza wersja Docker Swarm
Początkiem 2023 roku wyszła wersja 23.0 Moby (framework open-source stworzony i wykorzystywany przez Dockera) oraz Mirantis Container Runtime, a wraz z nią SwarmKit CSI. Z wersją to przybyło jeszcze kilka innych istotnych zmian, o których przeczytasz w tym artykule.
Swarm Cluster Volumes
Jedną z ostatnich zmian jest dodanie Swarm Cluster Volumes. Wolumeny klastra Swarm wykorzystują istniejący ekosystem Container Storage Interface (CSI), aby zapewnić klastrowi Swarm trwałą pamięć masową.
Największą słabością Docker Swarm dotychczas było ograniczone wsparcie dla pamięci trwałej. Trwałe przechowywanie odnosi się do danych, które są zapisywane i pozostają na dysku. Docker Swarm opiera się głównie na podstawowej funkcjonalności wolumenów kontenerowych. Usługi są tworzone z odniesieniem do ścieżki lub nazwanego wolumenu na hoście. Jeśli wolumen nie istnieje, jest on tworzony podczas uruchamiania zadania na węźle.
Swarm został zaprojektowany tak, aby jego obsługa była jak najprostsza. Przez to ciężko porównywać go z Kubernetes. Jednak dużym wyzwaniem dla Swarm jest zapewnienie prostoty w obszarze trwałego przechowywania danych.
Głównym celem orkiestracji jest posiadanie wielu worker nodów (węzłów), które mogą być dowolnie zastąpione innymi na przestrzeni czasu. To kłóci się z naturą trwałego przechowywania, które nie jest zastąpywalne.
Baza danych straciłaby swoje zastosowanie, gdyby za każdym razem, gdy kontener zostaje przeniesiony, rozpoczynała działanie na pustych tabelach.
Słowo o Container Storage Interface (CSI)
Container Storage Interface jest jedną z wielu prób standaryzacji w przestrzeni orkiestracji kontenerowej. Celem jest dostarczenie jednego wspólnego API, które umożliwiłoby każdemu z CSI pluginów pracę z dowolnym orkiestratorem kontenerów w zakresie trwałego przechowywania danych.
Przypomnijmy, że przykładem orkiestratorów dla kontenerów są: Kubernetes i Docker Swarm.
API CSI oferuje różnorodny zestaw funkcji dostosowany do środowisk klastrowych. Ułatwia komunikację ważnych szczegółów, takich jak to, które węzły mogą uzyskać dostęp do wolumenu pamięci masowej i jak również, które kontenery mogą go współbieżnie wykorzystywać. CSI zapewnia rozwiązanie dla Swarm przenosząc trudność zarządzania pamięcią masową na autora pluginu (CSI plugin). Pluginy muszą jedynie określić, jak i gdzie wolumen pamięci masowej może być wykorzystany, pozwalając Swarmowi na odpowiednie zaplanowanie obciążeń (kontenerów). Wykorzystując siłę Container Storage Interface i jego przyjęcie przez producentów, Swarm może wprowadzić trwały storage dla całego klastra, jednocześnie trzymając się swojej filozofii prostoty.
Volumeny klastra Swarm
Pluginy Container Storage Interface (CSI) są podstawowym mechanizmem do zarządzania trwałym przechowywaniem danych w Swarm, ale same nie są podstawową funkcjonalnością. Swarm przedstawia użytkownikom dedykowany interfejs, który eksponuje niezbędne szczegóły dotyczące wolumenu pamięci masowej, jednocześnie abstrahując od technicznych zawiłości.
Wolumeny są nowym prymitywnym typem w Swarm, podobnie jak Secrets czy Networks. Zamiast tworzyć wolumeny na węźle na żądanie, podobnie jak w przypadku Secrets czy Networks, wolumeny są tworzone przez użytkownika z wyprzedzeniem. Może to przypominać Persistent Volumes, które znamy z Kubernetesa.
Proces ten w przejrzysty sposób wykorzystuje istniejące API Moby Volumes, ale z dodatkowymi flagami i opcjami specyficznymi dla wymagań klastra. Opcje te pozwalają użytkownikom na określenie dostępności między węzłami, trybów dostępu i innych szczegółowych konfiguracji.
Trwałe volumeny w Docker Swarm
Podczas używania wolumenów klastra, Swarm wykorzystuje istniejące API. Zamiast określać bind mounts lub volume jako typ podmontowywania pamięci masowej, użytkownicy mogą określić cluster jako typ podmontowania, aby wykorzystać wolumen klastrowy.
Swarm rozumie właściwości wolumenu i traktuje jego ograniczenia użytkowania podobnie jak ograniczenia lokowania zdefiniowane przez użytkownika, planując obciążenia tylko na węzłach, które obsługują żądane mocowania.
Na przykład, niektóre wolumeny mogą być używane na dowolnej liczbie węzłów i jednocześnie przez wiele kontenerów, ale ograniczone do jednego węzła w danym czasie. Swarm przypisuje pierwsze obciążenie, które wykorzystuje taki wolumen, do dowolnego odpowiedniego węzła, a kolejne obciążenia są planowane na tym samym węźle. To inteligentne zachowanie pozwala wolumenom klastrowym być “świadomymi klastra” w sposób, którego poprzednia obsługa wolumenów w Swarm nie mogła osiągnąć.
Obsługa wolumenów klastrowych jest dostępna w Swarm w wersji 23.0, ale należy podkreślić, że ta obsługa jest obecnie eksperymentalna.
Podsumowanie – czyli moja opinia na temat zmian w Docker Swarm
W internecie o śmierci Docker Swarma słyszymy od około 5 lat. Natomiast przypomnę, że rozwiązania Elastic Container Service w AWS jest bardzo zbliżone w działaniu do Docker Swarm i ma się dobrze. Wiele firm nie wybiera Kubernetes, lecz ECS ze względu na prostotę.
Podobnie sytuacja wygląda z Docker Swarm. Są firmy, które nie potrzebują wszystkich funkcjonalności Kubernetesa. Chcą tylko odejść od JEDNEGO serwera i zapewnić chociaż minimalne High Availability dla swoich aplikacji. Ruch użytkowników nie jest duży, ale wymagana jest odporność na awarie.
Widziałem przypadki klientów, którzy w ten sposób zaprojektowali swoją infrastrukturę i ma się ona dobrze.
Wprowadzenie Swarm Volumes może naprawdę ułatwić życie wielu firmom, dotychczas korzystającym ze Swarm. Nie sądzę, że przyczyni się to do nagłego skoku popularności – i nagłej migracji do Swarm, bardziej jest to rozwiązanie dla:
a) firm już korzystających ze Swarm,
b) małych projektów, gdzie: Kubernetes to armata na muchę, chcemy mieć kontenery, mamy on-prem, chcemy mieć HA.
Osobiście, bardzo czekam na rozwój sytuacji.