Kom igång med swarm-läge

Artikel
01/23/2025

Gäller för: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Vad är "swarm mode"?

Swarm-läge är en Docker-funktion som tillhandahåller inbyggda funktioner för containerorkestrering, inklusive intern klustring av Docker-värdar och schemaläggning av containerarbetsbelastningar. En grupp Docker-värdar bildar ett "swarm"-kluster när deras Docker-motorer körs tillsammans i "swarm-läge". För mer information om swarm-läge, se Dockers huvuddokumentationssida.

Manager-noder och arbetsnoder

En swarm består av två typer av containervärdar: manager-noderoch arbetsnoder. Varje swarm initieras via en chefsnod, och alla Docker CLI-kommandon för att kontrollera och övervaka en svärm måste köras från en av dess chefsnoder. Chefnoder kan betraktas som "keepers" av Swarm-tillståndet – tillsammans bildar de en konsensusgrupp som upprätthåller medvetenheten om tillståndet för tjänster som körs på svärmen, och det är deras jobb att se till att svärmens faktiska tillstånd alltid matchar dess avsedda tillstånd, enligt definitionen av utvecklaren eller administratören.

Obs

En viss svärm kan ha flera chefsnoder, men den måste alltid ha minst en.

Arbetsnoder orkestreras av Docker swarm via manager-noder. Om du vill ansluta till en svärm måste en arbetsnod använda en "kopplingstoken" som genererades av chefsnoden när svärmen initierades. Arbetsnoder tar helt enkelt emot och kör uppgifter från chefsnoder, så de kräver (och har) ingen medvetenhet om svärmtillståndet.

Systemkrav för Swarm-läge

Minst ett fysiskt eller virtuellt datorsystem (för att använda svärmens alla funktioner rekommenderas minst två noder) som kör antingen Windows 10 Creators Update eller Windows Server 2016med alla de senaste uppdateringarna*, konfigurerat som en containervärd (se avsnittet, Windows-containers på Windows 10 eller Windows-containers på Windows Server för mer information om hur du kommer igång med Docker-containrar i Windows 10).

* Obs: På Windows Server 2016 kräver Docker Swarm KB4015217

Docker Engine v1.13.0 eller senare

Öppna portar: Följande portar måste vara tillgängliga på varje värd. I vissa system är dessa portar öppna som standard.

TCP-port 2377 för klusterhanteringskommunikation
TCP- och UDP-port 7946 för kommunikation mellan noder
UDP-port 4789 för överläggsnätverkstrafik

Initiera ett Swarm-kluster

Om du vill initiera en swarm kör du helt enkelt följande kommando från en av dina containervärdar (ersätter <HOSTIPADDRESS-> med den lokala IPv4-adressen för värddatorn):

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

När det här kommandot körs från en viss containervärd börjar Docker-motorn på den värden köras i swarm-läge som en chefnod.

Lägga till noder i en svärm

Flera noder inte krävs för att utnyttja funktioner i swarm-läge och överläggsnätverksläge. Alla swarm-/overlay-funktioner kan användas med en enda värd som körs i swarm-läge (dvs. en managernod, satt i swarm-läge med kommandot docker swarm init).

Lägga till arbetare i en svärm

När en svärm har initierats från en chefsnod kan andra värdar läggas till i svärmen som arbetare med ett annat enkelt kommando:

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

Här är <MANAGERIPADDRESS> den lokala IP-adressen för en swarm manager-nod, och <WORKERJOINTOKEN> är arbetskopplingstoken som tillhandahålls som utdata från kommandot docker swarm init som kördes från chefnoden. Kopplingstoken kan också hämtas genom att köra något av följande kommandon från manager-noden efter att svärmen har initierats:

# 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

Lägga till chefer i en svärm

Ytterligare chefsnoder kan läggas till i ett swarm-kluster med följande kommando:

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

Återigen är <MANAGERIPADDRESS> den lokala IP-adressen för en swarm manager-nod. Anslutningstoken, <MANAGERJOINTOKEN>, är en manager kopplingstoken för swarmen, som kan hämtas genom att köra något av följande kommandon från en befintlig chefnod:

# 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

Skapa ett överläggsnätverk

När ett swarm-kluster har konfigurerats kan överläggsnätverk skapas i svärmen. Du kan skapa ett överläggsnätverk genom att köra följande kommando från en swarm manager-nod:

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

Här är <NETWORKNAME> det namn som du vill ge nätverket.

Distribuera tjänster till en svärm

När ett överläggsnätverk har skapats kan tjänster skapas och kopplas till nätverket. En tjänst skapas med följande syntax:

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

Här <SERVICENAME> är det namn som du vill ge tjänsten – det här är det namn som du använder för att referera till tjänsten via tjänstidentifiering (som använder Docker interna DNS-server). <NETWORKNAME> är namnet på nätverket som du vill ansluta tjänsten till (till exempel "myOverlayNet"). <CONTAINERIMAGE> är namnet på den containeravbildning som ska definiera tjänsten.

Obs

Det andra argumentet för det här kommandot, --endpoint-mode dnsrr, krävs för att ange att Docker-motorn ska använda DNS-round-robin-principen för att balansera nätverkstrafiken mellan tjänstcontainer-slutpunkter. För närvarande är DNS-Round-Robin den enda belastningsutjämningsstrategin som stöds i Windows Server 2016.Routningsnät för Windows Docker-värdar stöds på Windows Server 2019 (och senare), men inte på Windows Server 2016. Användare som söker en alternativ belastningsutjämningsstrategi i Windows Server 2016 kan i dag konfigurera en extern lastbalanserare (t.ex. NGINX) och använda Swarms publiceringsportläge för att exponera containervärdportar för att balansera trafiken.

Skala en tjänst

När en tjänst har distribuerats till ett swarm-kluster distribueras containerinstanserna som utgör den tjänsten i klustret. Som standard är antalet containerinstanser som stöder en tjänst – antalet "repliker" eller "uppgifter" för en tjänst – ett. En tjänst kan dock skapas med flera uppgifter med hjälp av alternativet --replicas till kommandot docker service create eller genom att skala tjänsten efter att den har skapats.

Tjänstens skalbarhet är en viktig fördel som erbjuds av Docker Swarm, och den kan också utnyttjas med ett enda Docker-kommando:

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

Här är <SERVICENAME-> namnet på den tjänst som skalas och <REPLIKER> är antalet uppgifter eller containerinstanser som tjänsten skalas till.

Visa svärmtillståndet

Det finns flera användbara kommandon för att visa tillståndet för en svärm och de tjänster som körs på svärmen.

Lista swarmernoder

Använd följande kommando för att se en lista över de noder som för närvarande är anslutna till en svärm, inklusive informaiton om tillståndet för varje nod. Det här kommandot måste köras från en manager-nod.

C:\> docker node ls

I utdata från det här kommandot ser du en av noderna som har markerats med en asterisk (*); asterisken anger helt enkelt den aktuella noden – noden som kommandot docker node ls kördes från.

Lista nätverk

Använd följande kommando för att se en lista över de nätverk som finns på en viss nod. Om du vill se överläggsnätverk måste det här kommandot köras från en manager-nod körs i swarm-läge.

C:\> docker network ls

Visa en lista över tjänster

Använd följande kommando för att se en lista över de tjänster som för närvarande körs på en svärm, inklusive information om deras tillstånd.

C:\> docker service ls

Lista de containerinstanser som definierar en tjänst

Använd följande kommando för att se information om containerinstanserna som körs för en viss tjänst. Utdata för det här kommandot innehåller de ID:n och noder som varje container körs på, samt infromation för containrarnas tillstånd.

C:\> docker service ps <SERVICENAME>

Linux+Windows mixed-OS-kluster

Nyligen publicerade en medlem i vårt team en kort demonstration i tre delar om hur du konfigurerar ett Windows+Linux mixed-OS-program med Docker Swarm. Det är ett bra ställe att komma igång om du är nybörjare på Docker Swarm eller om du använder det för att köra mixed-OS-program. Kolla in det nu:

Initiera ett Linux+Windows mixed-OS-kluster

Det är enkelt att initiera ett swarm-kluster med blandat operativsystem – så länge brandväggsreglerna är korrekt konfigurerade och värdarna har åtkomst till varandra behöver du bara lägga till en Linux-värd i en swarm är standardkommandot 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

Lägga till etiketter i swarm-noder

För att kunna starta en Docker-tjänst till ett swarm-kluster med blandat operativsystem måste det finnas ett sätt att skilja mellan vilka swarm-noder som kör operativsystemet som tjänsten är utformad för och som inte är det. Docker-objektetiketter ge ett användbart sätt att märka noder, så att tjänster kan skapas och konfigureras att endast köras på noderna som matchar deras operativsystem.

Obs

Docker-objektetiketter kan användas för att använda metadata för en mängd olika Docker-objekt (inklusive containeravbildningar, containrar, volymer och nätverk) och i olika syften (t.ex. kan etiketter användas för att separera komponenterna "klientdel" och "serverdel" i ett program, genom att tillåta att klientdelsmikrotjänster endast kan kopplas på "klientdelsmärkta noder och mircoservices på serverdelen" som endast ska schemaläggas på "serverdelsetiketterade noder"). I det här fallet använder vi etiketter på noder för att särskilja Windows OS-noder och Linux OS-noder.

Om du vill märka dina befintliga swarm-noder använder du följande syntax:

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

Här är <LABELNAME> namnet på den etikett som du skapar, till exempel i det här fallet särskiljer vi noder efter deras operativsystem, så ett logiskt namn för etiketten kan vara "os". <LABELVALUE> är värdet för etiketten – i det här fallet kan du välja att använda värdena "windows" och "linux". (Naturligtvis kan du göra vilka namngivningsval som helst för etikett och etikettvärden, så länge du förblir konsekvent). <NODENAME> är namnet på den nod som du etiketterar. du kan påminna dig själv om namnen på dina noder genom att köra docker node ls.

Om du till exempel, om du har fyra swarmnoder i klustret, inklusive två Windows-noder och två Linux-noder, kan dina etikettuppdateringskommandon se ut så här:

# 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

Distribuera tjänster till en Mixed-OS-svärm

Med etiketter för dina swarm-noder är det enkelt att distribuera tjänster till klustret. använd helt enkelt alternativet --constraint till kommandot 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…]

Om du till exempel använder nomenklaturen för etikett- och etikettvärde i exemplet ovan kan en uppsättning kommandon för att skapa tjänster – en för en Windows-baserad tjänst och en för en Linux-baserad tjänst – se ut så här:

# 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

Begränsningar

För närvarande har swarm-läget i Windows följande begränsningar:

Datalplans-kryptering stöds inte (dvs. container-till-containertrafik via alternativet --opt encrypted)
Routningsnät för Windows Docker-värdar stöds inte på Windows Server 2016, utan endast från Windows Server 2019 och senare. Användare som söker en alternativ strategi för belastningsutjämning i dag kan konfigurera en extern lastbalanserare (t.ex. NGINX) och använda Swarms publiceringsportläge för att exponera containervärdportar som ska lastbalanseras över. Mer information om detta nedan.

Publicera portar för tjänstslutpunkter

Användare som vill publicera portar för sina tjänstslutpunkter kan göra det idag med antingen publiceringsportläge eller Docker Swarms funktion för routing mesh.

Om du vill att värdportarna ska publiceras för var och en av de uppgifter/containerslutpunkter som definierar en tjänst använder du argumentet --publish mode=host,target=<CONTAINERPORT> till kommandot 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…]

Följande kommando skulle till exempel skapa en tjänst, "s1", för vilken varje uppgift exponeras via containerport 80 och en slumpmässigt vald värdport.

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

När du har skapat en tjänst med publiceringsportläge kan tjänsten frågas för att visa portmappningen för varje tjänstuppgift:

C:\ > docker service ps <SERVICENAME>

Kommandot ovan returnerar information om varje containerinstans som körs för din tjänst (över alla dina swarm-värdar). En kolumn i utdata, kolumnen "portar", innehåller portinformation för varje värd i formuläret <HOSTPORT->–><CONTAINERPORT>/tcp. Värdena för <HOSTPORT-> skiljer sig åt för varje containerinstans, eftersom varje container publiceras på sin egen värdport.

Tips & Insikter

Befintligt transparent nätverk kan blockera initiering av svärmar och skapande av överlagringsnätverk På Windows kräver både överlagrings- och transparenta nätverksdrivrutiner att en extern vSwitch är bunden till en (virtuell) nätverksadapter. När ett överläggsnätverk skapas skapas en ny växel och ansluts sedan till ett öppet nätverkskort. Det transparenta nätverksläget använder också ett värdnätverkskort. Samtidigt kan ett visst nätverkskort bara bindas till en växel i taget – om en värd bara har ett nätverkskort kan den bara ansluta till en extern vSwitch i taget, oavsett om den vSwitch är för ett överläggsnätverk eller för ett transparent nätverk.

Om en containervärd bara har ett nätverkskort är det därför möjligt att stöta på problemet med att ett transparent nätverk blockerar skapandet av ett överlappande nätverk (eller vice versa), eftersom det transparenta nätverket för närvarande tar värdens enda virtuella nätverksgränssnitt i anspråk.

Det finns två sätt att komma runt det här problemet:

Alternativ 1 – ta bort befintligt transparent nätverk: Innan du initierar en svärm kontrollerar du att det inte finns ett befintligt transparent nätverk på containervärden. Ta bort transparenta nätverk för att säkerställa att det finns ett kostnadsfritt virtuellt nätverkskort på värden som ska användas för att skapa överläggsnätverk.
Alternativ 2 – skapa ytterligare ett (virtuellt) nätverkskort på värden: I stället för att ta bort alla transparenta nätverk som finns på värden kan du skapa ytterligare ett nätverkskort på värden som ska användas för att skapa överläggsnätverk. För att göra detta, skapa helt enkelt en ny extern nätverksadapter (med PowerShell eller Hyper-V Manager); med det nya gränssnittet på plats, när din swarm initieras kommer Host Network Service (HNS) automatiskt att känna igen den på värddatorn och använda den för att binda den externa vSwitch för att skapa ett överläggsnätverk.

Dela via