Udostępnij za pośrednictwem

Rozpocznij korzystanie z trybu roju

  • Artykuł

Dotyczy: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Co to jest "tryb roju"?

Tryb Swarm to funkcja platformy Docker, która zapewnia wbudowane funkcje orkiestracji kontenerów, w tym natywne klastrowanie hostów platformy Docker i planowanie obciążeń kontenerów. Grupa hostów platformy Docker tworzy klaster „swarm”, gdy ich silniki Docker działają razem w trybie „swarm”. Aby uzyskać dodatkowy kontekst dotyczący trybu roju, zapoznaj się z główną stroną dokumentacji Docker .

Węzły menedżera i węzły robocze

Roj składa się z dwóch typów hostów kontenerów: węzły zarządzające i węzły robocze . Każdy swarm jest inicjowany za pośrednictwem węzła menedżera, a wszystkie polecenia interfejsu wiersza polecenia platformy Docker do kontrolowania i monitorowania roju muszą być wykonywane z jednego z węzłów menedżera. Węzły menedżera mogą być uważane za "opiekunów" stanu Swarm — razem tworzą grupę konsensusu, która utrzymuje świadomość stanu usług uruchomionych na roju, i ich zadaniem jest upewnienie się, że rzeczywisty stan roju zawsze odpowiada zamierzonemu stanowi, zgodnie z tym, jak zostało zdefiniowane przez dewelopera lub administratora.

Notatka

Każdy dany roj może mieć wiele węzłów menedżera, ale zawsze musi mieć co najmniej jeden.

Węzły robocze są orkiestrowane przez Docker Swarm za pomocą węzłów menedżera. Aby dołączyć do roju, węzeł roboczy musi użyć "tokenu dołączenia", który został wygenerowany przez węzeł menedżera, gdy rój został zainicjowany. Węzły pracownicze po prostu odbierają i wykonują zadania z węzłów menedżerskich, dlatego nie wymagają (i nie posiadają) świadomości stanu klastra.

Wymagania systemowe trybu Swarm

Co najmniej jeden system fizyczny lub wirtualny (do korzystania z pełnej funkcjonalności roju co najmniej dwa węzły są zalecane) z systemem Windows 10 Creators Update lub Windows Server 2016ze wszystkimi najnowszymi aktualizacjami*, skonfigurowany jako host kontenera (zobacz temat, kontenery systemu Windows w systemie Windows 10 lub kontenery systemu Windows w systemie Windows Server, aby uzyskać więcej informacji na temat rozpoczynania pracy z kontenerami Docker w systemie Windows 10).

* Uwaga: Docker Swarm w systemie Windows Server 2016 wymaga KB4015217

Silnik Docker w wersji 1.13.0 lub nowszej

Otwarte porty: następujące porty muszą być dostępne na każdym hoście. W niektórych systemach te porty są domyślnie otwarte.

  • Port TCP 2377 na potrzeby komunikacji z zarządzaniem klastrem
  • Port TCP i UDP 7946 na potrzeby komunikacji między węzłami
  • Port UDP 4789 dla ruchu w sieci nakładkowej

Inicjowanie klastra Swarm

Aby zainicjować roj, wystarczy uruchomić następujące polecenie z jednego z hostów kontenera (zastępując <HOSTIPADDRESS> lokalnym adresem IPv4 maszyny hosta):

# Initialize a swarm
C:\> docker swarm init --advertise-addr=<HOSTIPADDRESS> --listen-addr <HOSTIPADDRESS>:2377

Po uruchomieniu tego polecenia z danego hosta kontenera silnik Docker na tym hoście zaczyna działać w trybie klastra jako węzeł menedżera.

Dodawanie węzłów do roju

Wiele węzłów nie jest wymagane do wykorzystania funkcji trybu roju i trybu sieci nakładki. Wszystkie funkcje swarm/overlay mogą być używane z jednym hostem działającym w trybie swarm (tj. węzłem menedżera, który zostaje uruchomiony w trybie swarm za pomocą polecenia docker swarm init).

Dodawanie pracowników do roju

Po zainicjowaniu roju z węzła menedżera można dodać inne hosty do roju jako pracowników za pomocą innego prostego polecenia.

C:\> docker swarm join --token <WORKERJOINTOKEN> <MANAGERIPADDRESS>

W tym miejscu <MANAGERIPADDRESS> jest lokalnym adresem IP węzła menedżera rojenia, a <WORKERJOINTOKEN> jest tokenem dołączenia pracownika dostarczonym jako dane wyjściowe przez polecenie docker swarm init, które zostało uruchomione z węzła menedżera. Token dołączenia można również uzyskać, uruchamiając jedno z następujących poleceń z węzła menedżera po zainicjowaniu roju.

# Get the full command required to join a worker node to the swarm
C:\> docker swarm join-token worker

# Get only the join-token needed to join a worker node to the swarm
C:\> docker swarm join-token worker -q

Dodawanie menedżerów do roju

Dodatkowe węzły menedżera można dodać do klastra Swarm, używając następującego polecenia:

C:\> docker swarm join --token <MANAGERJOINTOKEN> <MANAGERIPADDRESS>

Ponownie, <MANAGERIPADDRESS> jest lokalnym adresem IP węzła menedżera swarmu. Token sprzężenia, <MANAGERJOINTOKEN>, jest menedżerem join-token dla roju, które można uzyskać, uruchamiając jedno z następujących poleceń z istniejącego węzła menedżera:

# Get the full command required to join a **manager** node to the swarm
C:\> docker swarm join-token manager

# Get only the join-token needed to join a **manager** node to the swarm
C:\> docker swarm join-token manager -q

Tworzenie sieci nakładki

Po skonfigurowaniu klastra Swarm można utworzyć sieci nakładkowe na Swarm. Sieć nakładki można utworzyć, uruchamiając następujące polecenie na węźle zarządzającym rojem.

# Create an overlay network
C:\> docker network create --driver=overlay <NETWORKNAME>

W tym miejscu <NETWORKNAME> to nazwa, którą chcesz nadać sieci.

Wdrażanie usług do klastra Docker Swarm

Po utworzeniu sieci nakładki można tworzyć usługi oraz dołączać je do sieci. Usługa jest tworzona przy użyciu następującej składni:

# Deploy a service to the swarm
C:\> docker service create --name=<SERVICENAME> --endpoint-mode dnsrr --network=<NETWORKNAME> <CONTAINERIMAGE> [COMMAND] [ARGS…]

W tym miejscu <SERVICENAME> jest nazwą, którą chcesz nadać usłudze — jest to nazwa używana do odwoływania się do usługi za pośrednictwem odnajdywania usługi (która używa natywnego serwera DNS platformy Docker). <NETWORKNAME> to nazwa sieci, z którą chcesz połączyć tę usługę (na przykład "myOverlayNet"). <CONTAINERIMAGE> to nazwa obrazu kontenera, który będzie definiował usługę.

Notatka

Drugi argument tego polecenia, --endpoint-mode dnsrr, jest wymagany do określenia silnika Docker, że polityka Round Robin DNS będzie używana do równoważenia ruchu sieciowego między punktami końcowymi kontenera usługi. Obecnie Round-Robin DNS jest jedyną strategią równoważenia obciążenia obsługiwaną w systemie Windows Server 2016.siatka routingu dla hostów platformy Docker systemu Windows jest obsługiwana w systemie Windows Server 2019 (i nowszych), ale nie w systemie Windows Server 2016. Użytkownicy poszukujący alternatywnej strategii równoważenia obciążenia w systemie Windows Server 2016 mogą obecnie skonfigurować zewnętrzny moduł równoważenia obciążenia (np. NGINX) i użyć tryb publikowania portu Swarm uwidocznić porty hosta kontenera, za pomocą których można równoważyć ruch.

Skalowanie usługi

Po wdrożeniu usługi w klastrze roju, instancje kontenerów tworzące tę usługę są wdrażane na całym klastrze. Domyślnie liczba wystąpień kontenera obsługujących usługę — liczba "replik" lub "zadań" dla usługi — wynosi jeden. Można jednak utworzyć usługę z wieloma zadaniami przy użyciu opcji --replicas polecenia docker service create lub przez skalowanie usługi po jej utworzeniu.

Skalowalność usługi to kluczowa korzyść oferowana przez usługę Docker Swarm, a także można ją wykorzystać za pomocą jednego polecenia platformy Docker:

C:\> docker service scale <SERVICENAME>=<REPLICAS>

W tym miejscu <SERVICENAME> jest nazwą skalowanej usługi, a <REPLICAS> jest liczbą zadań lub wystąpień kontenera, do których jest skalowana usługa.

Wyświetlanie stanu roju

Istnieje kilka przydatnych poleceń do wyświetlania stanu roju i usług uruchomionych na roju.

Lista węzłów swarm

Użyj następującego polecenia, aby wyświetlić listę węzłów aktualnie dołączonych do roju, w tym informacje o stanie każdego węzła. To polecenie należy uruchomić z węzła menedżera .

C:\> docker node ls

W danych wyjściowych tego polecenia zauważysz jeden z węzłów oznaczonych gwiazdką (*); gwiazdka po prostu wskazuje bieżący węzeł — węzeł, z którego uruchomiono polecenie docker node ls.

Wymień sieci

Użyj następującego polecenia, aby wyświetlić listę sieci, które istnieją w danym węźle. Aby wyświetlić sieci nakładki, to polecenie musi zostać uruchomione z węzła zarządzającego uruchomionego w trybie grupowym.

C:\> docker network ls

Wyświetlanie listy usług

Użyj następującego polecenia, aby wyświetlić listę usług aktualnie uruchomionych w roju, w tym informacje o ich stanie.

C:\> docker service ls

Lista wystąpień kontenera, które definiują usługę

Użyj następującego polecenia, aby wyświetlić szczegółowe informacje dotyczące instancji kontenera uruchomionych dla danej usługi. Dane wyjściowe tego polecenia obejmują identyfikatory i węzły, na których działa każdy kontener, a także informacje o stanie kontenerów.

C:\> docker service ps <SERVICENAME>

Klastry mieszane systemu operacyjnego Linux+Windows

Niedawno członek naszego zespołu opublikował krótkie, trzyczęściowe pokazy dotyczące sposobu konfigurowania aplikacji mieszanej systemu operacyjnego Windows+Linux przy użyciu platformy Docker Swarm. To doskonałe miejsce, aby rozpocząć pracę, jeśli dopiero zaczynasz pracę z platformą Docker Swarm lub używasz jej do uruchamiania aplikacji mieszanego systemu operacyjnego. Sprawdź teraz:

Inicjowanie klastra mieszanego systemu operacyjnego Linux+Windows

Inicjowanie klastra roju z mieszanymi systemami operacyjnymi jest łatwe, o ile reguły zapory są prawidłowo skonfigurowane i hosty mają dostęp do siebie nawzajem. Aby dodać hosta z systemem Linux do roju, użyj standardowego polecenia docker swarm join.

C:\> docker swarm join --token <JOINTOKEN> <MANAGERIPADDRESS>

```powershell
You can also initialize a swarm from a Linux host using the same command that you would run if initializing the swarm from a Windows host:

```powershell
# Initialize a swarm
C:\> docker swarm init --advertise-addr=<HOSTIPADDRESS> --listen-addr <HOSTIPADDRESS>:2377

Dodawanie etykiet do węzłów roju

Aby można było uruchomić usługę Docker Service w klastrze mieszanym systemu operacyjnego, musi istnieć sposób odróżnienia węzłów roju, dla których jest przeznaczona ta usługa, a które nie. etykiety obiektów platformy Docker zapewniają przydatny sposób etykietowania węzłów, dzięki czemu usługi można tworzyć i konfigurować do uruchamiania tylko w węzłach, które pasują do ich systemu operacyjnego.

Notatka

Etykiety obiektów Docker można użyć do stosowania metadanych do różnych obiektów Docker (w tym obrazów kontenerów, kontenerów, woluminów i sieci) oraz do różnych celów (np. etykiety mogą służyć do oddzielania komponentów "front-end" i "back-end" aplikacji, umożliwiając planowanie mikrousług front-endu tylko na węzłach oznaczonych etykietą "front-end" i mikrousług back-endu tylko na węzłach oznaczonych etykietą "back-end"). W tym przypadku używamy etykiet w węzłach, aby odróżnić węzły systemu operacyjnego Windows i węzły systemu operacyjnego Linux.

Aby oznaczyć istniejące węzły roju, użyj następującej składni:

C:\> docker node update --label-add <LABELNAME>=<LABELVALUE> <NODENAME>

W tym przypadku <LABELNAME> jest nazwą tworzonej etykiety — w tym przypadku rozróżniamy węzły według ich systemu operacyjnego, więc logiczną nazwą etykiety może być "os". <LABELVALUE> jest wartością etykiety — w tym przypadku możesz użyć wartości "windows" i "linux". (Oczywiście możesz dokonać dowolnych wyborów nazewnictwa dla etykiety i jej wartości, pod warunkiem, że pozostaniesz spójny). <NODENAME> to nazwa węzła, który etykietujesz; Możesz przypomnieć sobie nazwy węzłów, uruchamiając docker node ls.

Na przykład, jeśli masz cztery węzły roju w klastrze, w tym dwa węzły systemu Windows i dwa węzły systemu Linux, polecenia aktualizacji etykiety mogą wyglądać następująco:

# Example -- labeling 2 Windows nodes and 2 Linux nodes in a cluster...
C:\> docker node update --label-add os=windows Windows-SwarmMaster
C:\> docker node update --label-add os=windows Windows-SwarmWorker1
C:\> docker node update --label-add os=linux Linux-SwarmNode1
C:\> docker node update --label-add os=linux Linux-SwarmNode2

Wdrażanie usług w roju Mixed-OS

Dzięki etykietom dla węzłów roju wdrażanie usług w klastrze jest łatwe; wystarczy użyć opcji --constraint do polecenia docker service create:

# Deploy a service with swarm node constraint
C:\> docker service create --name=<SERVICENAME> --endpoint-mode dnsrr --network=<NETWORKNAME> --constraint node.labels.<LABELNAME>=<LABELVALUE> <CONTAINERIMAGE> [COMMAND] [ARGS…]

Na przykład przy użyciu nomenklatury etykiet i wartości etykiet z powyższego przykładu, zestaw poleceń tworzenia usług — jeden dla usługi opartej na systemie Windows i jeden dla usługi opartej na systemie Linux — może wyglądać następująco:

# Example -- using the 'os' label and 'windows'/'linux' label values, service creation commands might look like these...

# A Windows service
C:\> docker service create --name=win_s1 --endpoint-mode dnsrr --network testoverlay --constraint 'node.labels.os==windows' microsoft/nanoserver:latest powershell -command { sleep 3600 }

# A Linux service
C:\> docker service create --name=linux_s1 --endpoint-mode dnsrr --network testoverlay --constraint 'node.labels.os==linux' redis

Ograniczenia

Obecnie tryb roju w systemie Windows ma następujące ograniczenia:

  • Szyfrowanie płaszczyzny danych nie jest obsługiwane (tj. ruch między kontenerami przy użyciu opcji --opt encrypted)
  • siatka routingu dla hostów Docker systemu Windows nie jest obsługiwana w systemie Windows Server 2016, ale dopiero od Windows Server 2019. Użytkownicy, którzy szukają obecnie alternatywnej strategii równoważenia obciążenia, mogą skonfigurować zewnętrzny moduł równoważenia obciążenia (np. NGINX) i użyć trybu publikowania i publikowania Swarm uwidaczniać porty hosta kontenera, za pomocą których można równoważyć obciążenie. Więcej szczegółów na ten temat znajduje się poniżej.

Publikowanie portów dla punktów końcowych usługi

Użytkownicy, którzy chcą publikować porty dla swoich punktów końcowych usługi, mogą to zrobić dzisiaj przy użyciu trybu publikowania lub siatki routingu platformy Docker Swarm funkcji.

Aby spowodować opublikowanie portów hosta dla każdego z zadań/punktów końcowych kontenera definiujących usługę, użyj argumentu --publish mode=host,target=<CONTAINERPORT> do polecenia docker service create:

# Create a service for which tasks are exposed via host port
C:\ > docker service create --name=<SERVICENAME> --publish mode=host,target=<CONTAINERPORT> --endpoint-mode dnsrr --network=<NETWORKNAME> <CONTAINERIMAGE> [COMMAND] [ARGS…]

Na przykład następujące polecenie utworzy usługę "s1", dla której każde zadanie zostanie uwidocznione za pośrednictwem portu kontenera 80 i losowo wybranego portu hosta.

C:\ > docker service create --name=s1 --publish mode=host,target=80 --endpoint-mode dnsrr web_1 powershell -command {echo sleep; sleep 360000;}

Po utworzeniu usługi przy użyciu trybu publikowania portu można wykonać zapytanie dotyczące usługi w celu wyświetlenia mapowania portów dla każdego zadania usługi:

C:\ > docker service ps <SERVICENAME>

Powyższe polecenie zwróci szczegółowe informacje dotyczące każdego wystąpienia kontenera uruchomionego dla usługi (we wszystkich hostach klastra). Jedna kolumna danych wyjściowych , kolumna "porty" będzie zawierać informacje o porcie dla każdego hosta formularza <HOSTPORT>-><CONTAINERPORT>/tcp. Wartości <HOSTPORT> będą różne dla każdego wystąpienia kontenera, ponieważ każdy kontener korzysta z własnego portu hosta.

Porady & Wglądy

Istniejąca sieć przezroczysta może blokować inicjowanie klastrów/nakładanie się sieci. W systemie Windows, zarówno sterowniki sieci nakładkowej, jak i przezroczystej wymagają powiązania zewnętrznych wirtualnych przełączników (vSwitch'y) z kartą sieciową hosta (wirtualnego). Po utworzeniu sieci nakładkowej powstaje nowy przełącznik, który następnie jest podłączany do otwartego adaptera sieciowego. Tryb sieci przezroczystej także korzysta z karty sieciowej hosta. Jednocześnie każda dana karta sieciowa może być powiązana tylko z jednym przełącznikiem na raz — jeśli host ma tylko jedną kartę sieciową, może dołączyć ją tylko do jednego zewnętrznego przełącznika wirtualnego, niezależnie od tego, czy przełącznik wirtualny jest przeznaczony dla sieci nakładki, czy dla sieci przezroczystej.

W związku z tym, jeśli host kontenera ma tylko jedną kartę sieciową, można napotkać problem polegający na tym, że sieć przezroczysta blokuje tworzenie sieci nakładki (lub odwrotnie), ponieważ sieć przezroczysta obecnie zajmuje jedyny wirtualny interfejs sieciowy hosta.

Istnieją dwa sposoby obejścia tego problemu:

  • opcja 1 — usuń istniejącą przezroczystą sieć: Przed zainicjowaniem roju upewnij się, że na hoście kontenera nie istnieje przezroczysta sieć. Usuń przezroczyste sieci, aby upewnić się, że na hoście jest wolna wirtualna karta sieciowa do tworzenia sieci nakładowej.
  • opcja 2 — utwórz dodatkową (wirtualną) kartę sieciową na hoście: Zamiast usuwać dowolną przezroczystą sieć, która znajduje się na hoście, możesz utworzyć dodatkową kartę sieciową na hoście, która będzie używana do tworzenia sieci nakładki. Aby to zrobić, wystarczy utworzyć nową zewnętrzną kartę sieciową (przy użyciu programu PowerShell lub narzędzia Hyper-V Manager); kiedy swarm zostanie zainicjowany, przy nowym interfejsie, usługa sieciowa hosta (HNS) automatycznie rozpozna go na hoście i wykorzysta do powiązania zewnętrznego wirtualnego przełącznika (vSwitch) w celu stworzenia sieci nakładkowej.