Rozwijanie wdrażania oprogramowania — samouczek Docker Swarm

O ile nie mieszkałeś w kontenerze transportowym, prawdopodobnie słyszałeś o kontenerach. Branża wyraźnie odchodzi od trwałej do efemerycznej infrastruktury, a kontenery są kwadratowe w środku tego ruchu. Powód jest dość prosty: chociaż kontenery z pewnością pomagają zespołom programistów w szybkim uruchomieniu i uruchomieniu, mają jeszcze większy potencjał, aby całkowicie zmienić oblicze operacji.

Ale jak to dokładnie wygląda? Co się stanie, gdy będziesz gotowy, aby przeskoczyć uruchamianie kontenerów lokalnie lub ręcznie na kilku serwerach? W idealnym świecie chcesz po prostu wrzucić swoją aplikację do klastra serwerów i powiedzieć „uruchom to!”

Na szczęście tak właśnie dzisiaj jesteśmy.

W tym artykule przyjrzymy się, czym jest Docker Swarm, wraz z niektórymi wspaniałymi funkcjami, jakie ma do zaoferowania. Następnie przyjrzymy się, jak faktycznie wygląda korzystanie z trybu roju i wdrażanie do roju, a także podsumujemy kilka przykładów tego, jak wyglądają codzienne operacje z wdrożonym rojem. Zdecydowanie zalecana jest podstawowa znajomość platformy Docker i kontenerów, ale jeśli dopiero zaczynasz korzystać z kontenerów, możesz najpierw zapoznać się z tym doskonałym wpisem na blogu.

Co to jest rój Dockerów?

Zanim zagłębimy się w tworzenie i wdrażanie w naszym pierwszym roju, warto wiedzieć, czym jest Docker Swarm. Sam Docker istnieje od lat i większość ludzi myśli o nim jako o środowisku uruchomieniowym kontenera. W rzeczywistości jednak Docker składa się z wielu różnych elementów, które współpracują ze sobą. Na przykład ta część środowiska uruchomieniowego kontenera jest obsługiwana przez dwa mniejsze komponenty, zwane runC i containerd. Wraz z ewolucją platformy Docker i oddaniem jej do społeczności odkryli, że tworzenie tych mniejszych komponentów jest najlepszym sposobem na rozwój i szybkie dodawanie funkcji. W związku z tym mamy teraz SwarmKit i tryb Swarm, który jest wbudowany bezpośrednio w Dockera.

Docker Swarm to silnik orkiestracji kontenerów. Na wysokim poziomie wymaga wielu silników Dockera działających na różnych hostach i pozwala używać ich razem. Użycie jest proste: zadeklaruj swoje aplikacje jako stosy usług i pozwól Dockerowi zająć się resztą. Usługami może być wszystko, od instancji aplikacji po bazy danych lub narzędzia, takie jak Redis lub RabbitMQ. Powinno to brzmieć znajomo, jeśli kiedykolwiek pracowałeś z docker-compose podczas tworzenia, ponieważ jest to dokładnie ta sama koncepcja. W rzeczywistości deklaracja stosu jest dosłownie plikiem docker-compose.yml ze składnią wersji 3.1. Oznacza to, że możesz użyć podobnej (iw wielu przypadkach identycznej) konfiguracji Compose do wdrażania programowania i roju, ale tutaj nieco wyprzedzam siebie. Co się dzieje, gdy masz instancje Dockera w trybie Swarm?

Nie spadaj z tratwy

W świecie Swarm mamy dwa rodzaje węzłów (serwerów): menedżerów i pracowników. Ważne jest, aby pamiętać, że menedżerowie są również pracownikami, po prostu ponoszą dodatkową odpowiedzialność za utrzymanie sprawnego działania. Każdy rój zaczyna się od jednego węzła menedżera wyznaczonego jako lider. Stamtąd wystarczy uruchomić jedno polecenie, aby bezpiecznie dodać węzły do ​​roju.

Swarm jest wysoce dostępny dzięki implementacji algorytmu Raft. Nie będę wdawał się zbyt szczegółowo w Raft, ponieważ jest już świetny samouczek na temat tego, jak to działa, ale oto ogólna idea: Węzeł lidera stale sprawdza z innymi węzłami menedżera i synchronizuje ich stany. Aby zmiana stanu została „zaakceptowana”, węzły zarządzające w dużym stopniu osiągają konsensus, co ma miejsce, gdy większość węzłów potwierdza zmianę stanu.

Piękno tego polega na tym, że węzły menedżerów mogą sporadycznie odpadać bez narażania konsensusu roju. Jeśli zmiana stanu osiągnie konsensus, wiemy, że na pewno będzie istnieć w większości węzłów menedżera i będzie trwała, nawet jeśli obecny lider zawiedzie.

Załóżmy, że mamy trzy węzły menedżera o nazwach A, B i C. Oczywiście A jest naszym nieustraszonym liderem. Cóż, pewnego dnia przejściowy błąd sieci powoduje wyłączenie A, pozostawiając B i C same. Nie mając wiadomości od A od dłuższego czasu (kilkaset milisekund), B i C czekają losowo wygenerowany okres czasu, zanim wystawią się na wybory i powiadomią drugą osobę. Oczywiście w tym przypadku zostanie wybrany ten, który jako pierwszy wystartuje w wyborach. W tym przykładzie B zostaje nowym przywódcą i przywracane jest kworum. Ale potem zwrot akcji: co się stanie, gdy A wróci do sieci? Pomyśli, że nadal jest liderem, prawda? Z każdym wyborem jest powiązany termin, więc A został wybrany w pierwszym semestrze. Gdy tylko A wróci do trybu online i zacznie porządkować B i C, uprzejmie poinformują go, że B jest liderem w drugim semestrze, a Wola ustąpi.

Oczywiście ten sam proces działa na znacznie większą skalę. Możesz mieć więcej niż trzy węzły menedżera. Dodam jeszcze jedną krótką notatkę. Każdy rój może ponieść tylko określoną liczbę strat menedżera. Rój składający się z n węzłów menedżerów może stracić (n-1)/2 menedżerów bez utraty kworum. Oznacza to, że w roju trzech menedżerów można stracić jednego, w przypadku pięciu można stracić dwóch itd. Podstawowy powód tego stanu rzeczy powraca do idei konsensusu większości i jest to zdecydowanie coś, o czym należy pamiętać, przechodząc do produkcji.

Planowanie zadań i uzgadnianie

Jak dotąd ustaliliśmy, że nasi menedżerowie są naprawdę dobrzy w utrzymywaniu synchronizacji. Świetnie! Ale co oni właściwie robią? Pamiętasz, jak powiedziałem, że wdrażasz stos usług dla Swarm? Deklarując swoje usługi, przekazujesz Swarm ważne informacje o tym, jak faktycznie chcesz, aby Twoje usługi działały. Obejmuje to parametry, takie jak liczba żądanych replik każdej usługi, sposób dystrybucji replik, czy powinny być uruchamiane tylko w określonych węzłach i nie tylko.

Po wdrożeniu usługi zadaniem menedżerów jest zapewnienie, że wszystkie ustawione przez Ciebie wymagania dotyczące wdrożenia będą nadal spełniane. Załóżmy, że wdrażasz usługę Nginx i określasz, że powinny istnieć trzy repliki. Menedżerowie zobaczą, że żadne kontenery nie są uruchomione i równomiernie rozmieszczą trzy kontenery w dostępnych węzłach.

Jeszcze fajniejsze jest to, że jeśli kontener ulegnie awarii (lub cały węzeł przejdzie w tryb offline), rój automatycznie utworzy kontenery na pozostałych węzłach, aby zrekompensować różnicę. Jeśli powiesz, że chcesz uruchomić trzy kontenery, będziesz mieć uruchomione trzy kontenery, podczas gdy Swarm zajmie się wszystkimi szczegółami. Dodatkowo — i to jest duży plus — skalowanie w górę lub w dół jest tak proste, jak nadanie Swarmowi nowego ustawienia replikacji.

Wykrywanie usług i równoważenie obciążenia

Chcę zwrócić uwagę na ważny, ale subtelny szczegół z ostatniego przykładu: jeśli Swarm inteligentnie uruchamia kontenery na wybranych przez siebie węzłach, niekoniecznie wiemy, gdzie te kontenery będą działać. Na początku może to zabrzmieć przerażająco, ale w rzeczywistości jest to jedna z najpotężniejszych funkcji Swarm.

Kontynuując ten sam przykład Nginx, wyobraź sobie, że powiedzieliśmy Dockerowi, że te kontenery powinny uwidaczniać port 80. Jeśli wskażesz w przeglądarce węzeł uruchamiający ten kontener na porcie 80, zobaczysz zawartość tego kontenera. Nie ma w tym niespodzianki. Zaskakujące może być jednak to, że jeśli wyślesz żądanie do węzła, który nie obsługuje tego kontenera, nadal zobaczysz tę samą zawartość! Co tu się dzieje?

Swarm w rzeczywistości używa sieci przychodzącej, aby wysłać żądanie do dostępnego węzła, na którym działa ten kontener, i jednocześnie równoważy obciążenie. Więc jeśli wyślesz trzy żądania do tego samego węzła, prawdopodobnie trafisz do trzech różnych kontenerów. Dopóki znasz adres IP pojedynczego węzła w roju, możesz uzyskać dostęp do wszystkiego, co w nim działa. I odwrotnie, pozwala to na skierowanie modułu równoważenia obciążenia (takiego jak ELB) na wszystkie węzły w roju bez konieczności martwienia się o to, co gdzie działa.

Nie kończy się na połączeniach zewnętrznych. Usługi działające na tym samym stosie mają sieć nakładkową, która pozwala im komunikować się ze sobą. Zamiast na stałe kodować adresy IP w kodzie, możesz po prostu użyć nazwy usługi jako nazwy hosta, z którym chcesz się połączyć. Na przykład, jeśli Twoja aplikacja musi komunikować się z usługą Redis o nazwie „redis”, może po prostu użyć „redis” jako nazwy hosta, a Swarm przekieruje swoje żądanie do odpowiedniego kontenera. A ponieważ działa to bezproblemowo w programowaniu za pomocą docker-compose i w produkcji za pomocą Docker Swarm, podczas wdrażania aplikacji jest to jedna rzecz mniej, o którą trzeba się martwić.

Aktualizacje kroczące

Jeśli jesteś w operacjach, prawdopodobnie doświadczyłeś ataku paniki, gdy aktualizacja produkcyjna pójdzie nie tak. Może to być zła aktualizacja kodu, a nawet błąd konfiguracji, ale nagle produkcja przestaje działać! Szanse są takie, że szef nie będzie się tym przejmował. Po prostu będą wiedzieć, że to twoja wina. Cóż, nie martw się, Rój też się do tego kładzie.

Aktualizując usługę, możesz określić, ile kontenerów powinno być aktualizowanych jednocześnie i co powinno się stać, jeśli nowe kontenery zaczną zawodzić. Po pewnym progu Swarm może zatrzymać aktualizację lub (od Docker 17.04) przywrócić kontenery do poprzedniego obrazu i ustawień. Nie martw się, że jutro rano będziesz musiał przynieść szefowi kawę.

Bezpieczeństwo

Wreszcie, ale nigdzie nie mniej, Docker Swarm ma świetne funkcje bezpieczeństwa po wyjęciu z pudełka. Kiedy węzeł dołącza do roju, używa tokena, który nie tylko weryfikuje sam siebie, ale także weryfikuje, czy dołącza do roju, o którym myślisz. Od tego momentu cała komunikacja między węzłami odbywa się za pomocą wzajemnego szyfrowania TLS. Szyfrowanie jest dostarczane i zarządzane automatycznie przez rój, więc nie musisz się martwić o odnawianie certyfikatów i inne typowe problemy z bezpieczeństwem. I oczywiście, jeśli chcesz wymusić rotację klawiszy, jest do tego polecenie.

Najnowsza wersja Docker Swarm zawiera również wbudowane zarządzanie sekretami. Umożliwia to bezpieczne wdrażanie tajnych kluczy, takich jak klucze i hasła, do usług, które ich potrzebują, i tylko do usług, które ich potrzebują. Gdy udostępniasz usługę z kluczem tajnym, kontenery dla tej usługi będą miały w swoim systemie plików zamontowany specjalny plik, który zawiera wartość klucza tajnego. To oczywiste, ale jest to znacznie bezpieczniejsze niż używanie zmiennych środowiskowych, które były tradycyjnym podejściem.

Nurkowanie w roju

Jeśli jesteś podobny do mnie, masz ochotę wskoczyć i wziąć wszystkie te funkcje na przejażdżkę! Więc bez zbędnych ceregieli, zanurzmy się!

Przykładowa aplikacja Docker Swarm

Stworzyłem bardzo podstawową aplikację Flask, aby zademonstrować moc i łatwość korzystania z Docker Swarm. Aplikacja internetowa po prostu wyświetla stronę, która informuje, który kontener obsłużył Twoje żądanie, ile wszystkich żądań zostało obsłużonych i jakie jest „tajne” hasło do bazy danych.

Jest podzielony na trzy usługi: rzeczywistą aplikację Flask, zwrotny serwer proxy Nginx i magazyn kluczy Redis. Przy każdym żądaniu aplikacja zwiększa klucz num_requests w Redis, więc niezależnie od tego, w którą instancję Flask klikasz, zobaczysz odpowiednią liczbę żądań.

Cały kod źródłowy jest dostępny na GitHub, jeśli chcesz „sprawdzić”, co się dzieje.

Graj z Dockerem!

Korzystając z tego samouczka, możesz swobodnie korzystać z własnych serwerów, ale gorąco polecam korzystanie z play-with-docker.com, jeśli chcesz po prostu wskoczyć. Jest to witryna prowadzona przez kilku programistów Dockera, która pozwala na uruchomienie kilku sieci węzły, które mają wstępnie zainstalowaną platformę Docker. Zostaną wyłączone po czterech godzinach, ale to wystarczy na ten przykład!

Tworzenie roju

W porządku, zaczynamy! Śmiało, stwórz trzy instancje w PWD (play-with-docker) lub rozkręć trzy serwery w swojej ulubionej usłudze VPS (virtual private server) i zainstaluj na nich silnik Docker. Pamiętaj, że zawsze możesz utworzyć obraz i użyć go ponownie, dodając węzły w przyszłości. Pod względem oprogramowania nie ma różnicy między węzłem menedżera a węzłem roboczym, więc nie musisz utrzymywać dwóch różnych obrazów.

Nadal się rozkręca? Nie martw się, poczekam. OK, teraz utworzymy nasz pierwszy węzeł menedżera i lidera. W pierwszej instancji zainicjuj rój:

 docker swarm init --advertise-addr <node ip here>

Zastąp <node_ip_here> adresem IP swojego węzła. W PWD adres IP jest wyświetlany u góry, a jeśli korzystasz z własnego VPS, możesz używać prywatnego adresu IP swojego serwera, o ile jest on dostępny z innych węzłów w Twojej sieci.

Masz teraz rój! Jest to jednak dość nudny rój, ponieważ ma tylko jeden węzeł. Przejdźmy dalej i dodajmy inne węzły. Zauważysz, że po uruchomieniu init wyświetlał długi komunikat wyjaśniający, jak używać tokena dołączenia. Nie użyjemy tego, ponieważ spowoduje to, że inne węzły będą działać, a my chcemy, aby byli menedżerami. Zdobądźmy token przyłączenia dla menedżera, uruchamiając to na pierwszym węźle:

 docker swarm join-token manager

Skopiuj wynikowe polecenie i uruchom je na drugim i trzecim węźle. Oto rój trzech węzłów! Sprawdźmy, czy wszystkie nasze węzły naprawdę istnieją. Polecenie docker node ls wyświetli listę wszystkich węzłów w naszym roju. Powinieneś zobaczyć coś takiego:

 $ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS su1bgh1uxqsikf1129tjhg5r8 * node1 Ready Active Leader t1tgnq38wb0cehsry2pdku10h node3 Ready Active Reachable wxie5wf65akdug7sfr9uuleui node2 Ready Active Reachable

Zwróć uwagę, że nasz pierwszy węzeł ma gwiazdkę obok identyfikatora. To po prostu mówi nam, że jest to węzeł, z którym jesteśmy aktualnie połączeni. Widzimy również, że ten węzeł jest obecnie Liderem, a pozostałe węzły są osiągalne, gdyby coś się z nim stało.

Poświęć chwilę, aby docenić, jakie to było łatwe, i wdróżmy naszą pierwszą aplikację!

Wyślij to!

Właśnie w tym momencie zespół ds. rozwoju biznesu obiecał klientowi, że jego nowa aplikacja zostanie wdrożona i gotowa w ciągu godziny! Typowe, wiem. Ale nie obawiaj się, nie będziemy potrzebować prawie tyle czasu, ponieważ został zbudowany przy użyciu Dockera! Deweloperzy byli na tyle uprzejmi, że pożyczyli nam swój plik docker-compose :

 version: '3.1' services: web: image: lsapan/docker-swarm-demo-web command: gunicorn --bind 0.0.0.0:5000 wsgi:app deploy: replicas: 2 secrets: - db_password nginx: image: lsapan/docker-swarm-demo-nginx ports: - 8000:80 deploy: mode: global redis: image: redis deploy: replicas: 1 secrets: db_password: external: true

Za chwilę to wyjaśnimy, ale na to jeszcze nie ma czasu. Zróbmy to wdrożone! Śmiało i utwórz plik na swoim pierwszym węźle o nazwie docker-compose.yml i wypełnij go powyższą konfiguracją. Możesz to łatwo zrobić za pomocą echo "<pasted contents here>" > docker-compose.yml .

Zwykle moglibyśmy to po prostu wdrożyć, ale nasza konfiguracja wspomina, że ​​używamy sekretu o nazwie db_password , więc szybko utwórzmy ten sekret:

 echo "supersecretpassword" | docker secret create db_password -

Świetnie! Teraz wszystko, co musimy zrobić, to powiedzieć Dockerowi, aby użył naszej konfiguracji:

 docker stack deploy -c docker-compose.yml demo

Po uruchomieniu tego polecenia zobaczysz, że Docker tworzy trzy zdefiniowane przez nas usługi: web , nginx i redis . Jednak ponieważ nazwaliśmy nasz stos demo, nasze usługi noszą w rzeczywistości nazwy demo_web , demo_nginx i demo_redis . Możemy spojrzeć na nasze uruchomione usługi, uruchamiając polecenie docker service ls , które powinno pokazać coś takiego:

 $ docker service ls ID NAME MODE REPLICAS IMAGE PORTS cih6u1t88vx7 demo_web replicated 2/2 lsapan/docker-swarm-demo-web:latest u0p1gd6tykvu demo_nginx global 3/3 lsapan/docker-swarm-demo-nginx:latest *:8000->80/ tcp wa1gz80ker2g demo_redis replicated 1/1 redis:latest

Voila! Docker pobrał nasze obrazy do odpowiednich węzłów i utworzył kontenery dla naszych usług. Jeśli Twoje repliki nie są jeszcze w pełni wykorzystane, poczekaj chwilę i sprawdź ponownie. Docker prawdopodobnie nadal pobiera obrazy.

Zobaczyć to uwierzyć

Nie wierz jednak na moje słowo (lub słowo Dockera). Spróbujmy połączyć się z naszą aplikacją. Nasza konfiguracja usługi mówi Dockerowi, aby ujawnił NGINX na porcie 8000. Jeśli korzystasz z PWD, u góry strony powinien znajdować się niebieski link z napisem „8000”. PWD faktycznie automatycznie wykryło, że mamy uruchomioną usługę na tym porcie! Kliknij to, a przekieruje cię do wybranego węzła na porcie 8000. Jeśli rzuciłeś własne serwery, po prostu przejdź do jednego z adresów IP swoich serwerów na porcie 8000.

Zostaniesz przywitany pięknym, stylizowanym ekranem z podstawowymi informacjami:

Zanotuj, który kontener obsługiwał Twoje żądanie, a następnie odśwież stronę. Szanse się zmieniły. Ale dlaczego? Cóż, powiedzieliśmy Dockerowi, aby utworzył dwie repliki naszej aplikacji Flask i rozsyła żądania do obu tych instancji. Właśnie zdarzyło ci się uderzyć drugi raz w drugi pojemnik. Zauważysz również, że liczba żądań wzrosła, ponieważ oba kontenery Flask komunikują się z jedną określoną przez nas instancją Redis.

Możesz spróbować trafić na port 8000 z dowolnego węzła. Nadal będziesz prawidłowo kierowany do aplikacji.

Demistyfikacja magii

W tym momencie wszystko działa i miejmy nadzieję, że proces jest bezbolesny! Przyjrzyjmy się bliżej temu plikowi docker-compose.yml i zobaczmy, co faktycznie powiedzieliśmy Dockerowi. Na wysokim poziomie widzimy, że zdefiniowaliśmy trzy usługi: web , nginx i redis . Podobnie jak w przypadku normalnego pliku tworzenia, udostępniliśmy Dockerowi obraz do użycia dla każdej usługi, a także polecenie do uruchomienia. W przypadku nginx również, że port 8000 na hoście powinien być mapowany na port 80 w kontenerze. Wszystko to jak dotąd jest standardową składnią komponowania.

Nowością są tutaj klucze wdrażania i tajne. Te klucze są ignorowane przez docker-compose , więc nie będą miały wpływu na środowisko programistyczne, ale są używane przez docker stack . Spójrzmy na usługę sieciową. Dość proste, mówimy Dockerowi, że chcielibyśmy uruchomić dwie repliki naszej aplikacji Flask. Informujemy również platformę Docker, że usługa sieci Web wymaga klucza tajnego db_password . To zapewnia, że ​​kontener będzie miał plik o nazwie /run/secrets/db_password zawierający wartość sekretu.

Przechodząc do Nginx, widzimy, że tryb wdrażania jest ustawiony na global . Wartość domyślna (która jest niejawnie używana w sieci) jest replicated , co oznacza, że ​​określimy liczbę żądanych replik. Kiedy określamy global , mówi Dockerowi, że każdy węzeł w roju powinien uruchamiać dokładnie jedną instancję usługi. Uruchom ponownie docker service ls , zauważysz, że nginx ma trzy repliki, po jednej dla każdego węzła w naszym roju.

Na koniec poinstruowaliśmy Dockera, aby uruchomił pojedynczą instancję Redis gdzieś w roju. Nie ma znaczenia gdzie, ponieważ nasze kontenery internetowe są automatycznie do niego kierowane, gdy żądają hosta Redis.

Korzystanie z roju z dnia na dzień

Gratulujemy wdrożenia Twojej pierwszej aplikacji w roju Docker! Poświęćmy chwilę na omówienie kilku typowych poleceń, których będziesz używać.

Inspekcja swojego roju

Chcesz sprawdzić swoje usługi? Wypróbuj docker service ls i docker service ps <service name> . Pierwsza pokazuje ogólny przegląd każdej usługi, a druga dostarcza informacji o każdym kontenerze uruchomionym dla określonej usługi. Jest to szczególnie przydatne, gdy chcesz zobaczyć, które węzły obsługują usługę.

Aktualizacje kroczące

A co, kiedy będziesz gotowy do zaktualizowania aplikacji? Cóż, fajną rzeczą we docker stack deploy jest to, że faktycznie zastosuje aktualizacje również do istniejącego stosu. Załóżmy, że przesłałeś nowy obraz platformy Docker do swojego repozytorium. Możesz po prostu uruchomić to samo polecenie wdrażania, którego użyłeś za pierwszym razem, a Twój rój pobierze i wdroży nowy obraz.

Oczywiście nie zawsze możesz chcieć aktualizować każdą usługę w swoim stosie. Aktualizacje możemy wykonać również na poziomie usługi. Załóżmy, że niedawno zaktualizowałem obraz dla mojego serwisu internetowego. Mogę wydać to polecenie, aby zaktualizować wszystkie moje kontenery internetowe:

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ demo_web

Dodatkową korzyścią tego polecenia jest to, że zastosuje aktualizację kroczącą, jeśli określiłeś, że powinna w oryginalnej konfiguracji. A nawet jeśli tego nie zrobiłeś, możesz przekazać flagi do aktualizacji, które poinstruują go, aby wykonać aktualizację kroczącą, jak na przykład:

 docker service update \ --image lsapan/docker-swarm-demo-web:latest \ --update-parallelism 1 --update-delay 30s \ demo_web

To zaktualizuje jeden kontener na raz, czekając 30 sekund między aktualizacjami.

Skalowanie usług w górę lub w dół

Posiadanie dwóch kontenerów internetowych jest świetne, ale wiesz, co jest lepsze? Mając dziesięć! Skalowanie usług w górę iw dół w roju jest tak proste, jak:

 docker service scale demo_web=10

Uruchom to polecenie i sprawdź dane wyjściowe docker service ps demo_web . Zobaczysz, że mamy teraz dziesięć kontenerów, a osiem z nich zostało uruchomionych przed chwilą. Jeśli jesteś zainteresowany, możesz również wrócić do aplikacji internetowej i kilka razy odświeżyć stronę, aby zobaczyć, że teraz otrzymujesz więcej niż oryginalne dwa identyfikatory kontenerów.

Usuwanie stosów i usług

Twoje stosy i usługi są wdrażane i skalowane, super! Ale teraz chcesz je wyłączyć. Można to zrobić za pomocą odpowiedniego polecenia rm . Aby usunąć nasz stos demonstracyjny, uruchom polecenie:

 docker stack rm demo

Lub, jeśli wolisz po prostu usunąć jedną usługę, po prostu użyj:

 docker service rm demo_web

Węzły opróżniające

Pamiętasz, kiedy wcześniej uruchomiliśmy docker node ls , aby sprawdzić węzły w naszym roju? Dostarczał garść informacji o każdym węźle, w tym o jego dostępności . Domyślnie węzły są Active , co oznacza, że ​​można w nich uruchamiać kontenery. Jednak zdarzają się sytuacje, w których konieczne może być tymczasowe przełączenie węzła w tryb offline w celu wykonania konserwacji. Jasne, możesz po prostu go wyłączyć, a rój by się zregenerował, ale miło jest dać trochę uwagi Moby'emu (wielorybowi Docker).

W tym miejscu pojawia się opróżnianie węzłów. Po oznaczeniu węzła jako Drain , Docker Swarm deleguje wszystkie działające na nim kontenery do innych węzłów i nie uruchomi żadnych kontenerów w węźle, dopóki nie zmienisz jego dostępności z powrotem na Active .

Załóżmy, że chcemy opróżnić node1 . Możemy uruchomić:

 docker node update --availability drain node1

Łatwo! Kiedy będziesz gotowy, aby przywrócić go do pracy:

 docker node update --availability active node1

Zawijanie

Jak widzieliśmy, Docker w połączeniu z trybem Swarm umożliwia nam wdrażanie aplikacji bardziej wydajnie i niezawodnie niż kiedykolwiek wcześniej. Warto wspomnieć, że Docker Swarm nie jest bynajmniej jedynym dostępnym silnikiem orkiestracji kontenerów. W rzeczywistości to jeden z młodszych. Kubernetes istnieje już dłużej i jest zdecydowanie używany w większej liczbie aplikacji produkcyjnych. To powiedziawszy, Swarm jest oficjalnie opracowanym przez Dockera i każdego dnia pracują nad dodawaniem jeszcze większej liczby funkcji. Niezależnie od tego, z której opcji zdecydujesz się skorzystać, zachowaj pojemniki!