Aan de slag met de swarm-modus
Van toepassing op: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016
Wat is 'zwermmodus'?
De Swarm-modus is een Docker-functie die ingebouwde mogelijkheden voor containerindeling biedt, waaronder systeemeigen clustering van Docker-hosts en het plannen van containerworkloads. Een groep Docker-hosts vormen een 'swarm'-cluster wanneer hun Docker-engines samen worden uitgevoerd in de 'swarm-modus'. Raadpleeg hoofddocumentatiesite van Dockervoor aanvullende context over de swarm-modus.
Beheerknooppunten en werkknooppunten
Een swarm bestaat uit twee typen containerhosts: managerknooppuntenen werkknooppunten. Elke swarm wordt geïnitialiseerd via een beheerknooppunt en alle Docker CLI-opdrachten voor het beheren en bewaken van een swarm moeten worden uitgevoerd vanaf een van de beheerknooppunten. Beheerknooppunten kunnen worden beschouwd als "keepers" van de Swarm-status. Samen vormen ze een consensusgroep die zich bewust is van de status van de services die op de swarm worden uitgevoerd. Het is hun taak om ervoor te zorgen dat de huidige status van de swarm altijd overeenkomt met de bedoelde status, zoals gedefinieerd door de ontwikkelaar of beheerder.
Notitie
Elke swarm kan meerdere beheerknooppunten hebben, maar moet altijd ten minste éénhebben.
Werkknooppunten worden georkestreerd door Docker Swarm via managernodes. Als u wilt deelnemen aan een swarm, moet een werkernode een 'join token' gebruiken dat is gegenereerd door het beheerknooppunt wanneer de swarm werd geïnitialiseerd. Werkknooppunten ontvangen en uitvoeren taken van beheerknooppunten, zodat ze geen bewustzijn van de swarmstatus vereisen (en bezitten).
Systeemvereisten voor Swarm-modus
Ten minste één fysiek of virtueel computersysteem (voor het gebruik van de volledige functionaliteit van swarm worden ten minste twee knooppunten aanbevolen) draait op Windows 10 Creators Update of Windows Server 2016met alle nieuwste updates*, ingericht als een containerhost (zie het onderwerp, Windows-containers op Windows 10 of Windows-containers op Windows Server voor meer informatie over hoe u aan de slag kunt met Docker-containers op Windows 10).
* Opmerking: Docker Swarm op Windows Server 2016 vereist KB4015217
Docker Engine v1.13.0 of hoger
Open poorten: de volgende poorten moeten beschikbaar zijn op elke host. Op sommige systemen zijn deze poorten standaard geopend.
- TCP-poort 2377 voor communicatie over clusterbeheer
- TCP- en UDP-poort 7946 voor communicatie tussen knooppunten
- UDP-poort 4789 voor overlaynetwerkverkeer
Een Swarm-cluster initialiseren
Als u een swarm wilt initialiseren, voert u de volgende opdracht uit vanaf een van uw containerhosts (waarbij u <HOSTIPADDRESS-> vervangt door het lokale IPv4-adres van uw hostcomputer):
# Initialize a swarm
C:\> docker swarm init --advertise-addr=<HOSTIPADDRESS> --listen-addr <HOSTIPADDRESS>:2377
Wanneer deze opdracht wordt uitgevoerd vanaf een bepaalde containerhost, wordt de Docker-engine op die host uitgevoerd in de swarm-modus als een beheerknooppunt.
Knooppunten toevoegen aan een swarm
Meerdere knooppunten zijn niet vereist om de swarm-modus en overlay-netwerkmodusfuncties te gebruiken. Alle swarm/overlay-functies kunnen worden gebruikt met één host die in de swarm-modus werkt (d.w.z. een beheerknooppunt dat in de swarm-modus is gezet met de opdracht docker swarm init).
Werknemers toevoegen aan een zwerm
Zodra een swarm is geïnitialiseerd vanuit een beheerknooppunt, kunnen andere hosts als werknodes aan de swarm worden toegevoegd met een andere eenvoudige opdracht.
C:\> docker swarm join --token <WORKERJOINTOKEN> <MANAGERIPADDRESS>
Hier is <MANAGERIPADDRESS> het lokale IP-adres van een swarm-beheerknooppunt en <WORKERJOINTOKEN> het worker join-token is dat is opgegeven als uitvoer door de docker swarm init opdracht die is uitgevoerd vanaf het beheerknooppunt. Het join-token kan ook worden verkregen door een van de volgende opdrachten uit te voeren vanaf het beheerknooppunt nadat de swarm is geïnitialiseerd:
# 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
Managers toevoegen aan een zwerm
Extra beheerknooppunten kunnen worden toegevoegd aan een swarm-cluster met de volgende opdracht:
C:\> docker swarm join --token <MANAGERJOINTOKEN> <MANAGERIPADDRESS>
Opnieuw is <MANAGERIPADDRESS> het lokale IP-adres van een swarm-beheerknooppunt. Het jointoken, <MANAGERJOINTOKEN>, is een manager join-token voor de swarm, die kan worden verkregen door een van de volgende opdrachten uit te voeren vanaf een bestaand beheerknooppunt:
# 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
Een overlaynetwerk maken
Zodra een swarm-cluster is geconfigureerd, kunnen overlay-netwerken worden gemaakt op de swarm. U kunt een overlaynetwerk maken door de volgende opdracht uit te voeren vanuit een swarm manager-knooppunt:
# Create an overlay network
C:\> docker network create --driver=overlay <NETWORKNAME>
Hier is <NETWORKNAME> de naam die u aan uw netwerk wilt geven.
Services implementeren in een swarm
Zodra een overlaynetwerk is gemaakt, kunnen services worden gemaakt en aan het netwerk worden gekoppeld. Er wordt een service gemaakt met de volgende syntaxis:
# Deploy a service to the swarm
C:\> docker service create --name=<SERVICENAME> --endpoint-mode dnsrr --network=<NETWORKNAME> <CONTAINERIMAGE> [COMMAND] [ARGS…]
Hier is <SERVICENAME> de naam die u aan de service wilt geven. Dit is de naam die u gebruikt om te verwijzen naar de service via servicedetectie (die gebruikmaakt van de systeemeigen DNS-server van Docker). <NETWORKNAME> is de naam van het netwerk waarmee u deze service wilt verbinden (bijvoorbeeld 'myOverlayNet'). <CONTAINERIMAGE> is de naam van de containerimage die de dienst zal definiëren.
Notitie
Het tweede argument voor deze opdracht, --endpoint-mode dnsrr, is vereist om op te geven aan de Docker-engine dat het DNS Round Robin-beleid wordt gebruikt om netwerkverkeer over servicecontainer-eindpunten te verdelen. Op dit moment is DNS-Round-Robin de enige strategie voor taakverdeling die wordt ondersteund in Windows Server 2016.Mesh- voor Windows Docker-hosts wordt ondersteund op Windows Server 2019 (en hoger), maar niet op Windows Server 2016. Gebruikers die op zoek zijn naar een alternatieve taakverdelingsstrategie in Windows Server 2016, kunnen tegenwoordig een externe load balancer (bijvoorbeeld NGINX) instellen en de publicatiepoortmodus van Swarm gebruiken om containerhostpoorten beschikbaar te maken om verkeer te verdelen.
Een service schalen
Zodra een service is uitgerold in een swarm-cluster, worden de containerinstanties die die service vormen, over het cluster uitgerold. Standaard is het aantal containerinstanties dat een service ondersteunt, het aantal replica's of 'taken' voor een service, één. Een service kan echter met meerdere taken worden gemaakt met behulp van de --replicas optie voor de opdracht docker service create of door de service te schalen nadat deze is gemaakt.
Schaalbaarheid van services is een belangrijk voordeel dat docker Swarm biedt en kan ook worden gebruikt met één Docker-opdracht:
C:\> docker service scale <SERVICENAME>=<REPLICAS>
Hier is <SERVICENAME> de naam van de service die wordt geschaald, en <REPLICAS> is het aantal taken of containerinstanties waarop de service wordt geschaald.
De swarmstatus weergeven
Er zijn verschillende nuttige opdrachten voor het weergeven van de status van een zwerm en de services die op de zwerm draaien.
Swarm-knooppunten weergeven
Gebruik de volgende opdracht om een lijst weer te geven van de knooppunten die momenteel zijn gekoppeld aan een swarm, inclusief informaiton over de status van elk knooppunt. Deze opdracht moet worden uitgevoerd vanaf een manager-knooppunt.
C:\> docker node ls
In de uitvoer van deze opdracht ziet u een van de knooppunten die zijn gemarkeerd met een sterretje (*); het sterretje geeft gewoon het huidige knooppunt aan, het knooppunt waaruit de docker node ls opdracht is uitgevoerd.
Netwerken vermelden
Gebruik de volgende opdracht om een lijst weer te geven van de netwerken die op een bepaald knooppunt aanwezig zijn. Als u overlaynetwerken wilt zien, moet deze opdracht worden uitgevoerd vanaf een managerknooppunt die in de zwermmodus draait.
C:\> docker network ls
Services vermelden
Gebruik de volgende opdracht om een lijst weer te geven van de services die momenteel worden uitgevoerd op een zwerm, inclusief informatie over hun status.
C:\> docker service ls
De containerinstanties weergeven die een service definiëren
Gebruik de volgende opdracht om details te bekijken over de containerinstanties die draaien voor een specifieke service. De uitvoer voor deze opdracht bevat de id's en knooppunten waarop elke container wordt uitgevoerd, evenals infromation over de status van de containers.
C:\> docker service ps <SERVICENAME>
clusters met een gemengde OS-configuratie van Linux en Windows
Onlangs heeft een lid van ons team een korte, driedelige demo gepubliceerd over het instellen van een Windows+Linux mixed-OS-toepassing met behulp van Docker Swarm. Het is een geweldige plek om aan de slag te gaan als u geen toegang hebt tot Docker Swarm of als u deze gebruikt om toepassingen met gemengde besturingssystemen uit te voeren. Bekijk het nu:
- Docker Swarm gebruiken om een containertoepassing met Windows+Linux (deel 1/3) uit te voeren
- Docker Swarm gebruiken om een in een Windows+Linux-container geplaatste toepassing (deel 2/3) uit te voeren
- Docker Swarm gebruiken om een containertoepassing met Windows+Linux (deel 3/3) uit te voeren
Een Linux+Windows-cluster met gemengd besturingssysteem initialiseren
Het initialiseren van een mixed-OS-swarm-cluster is eenvoudig, zolang uw firewallregels correct zijn geconfigureerd en uw hosts toegang hebben tot elkaar, hoeft u alleen maar een Linux-host toe te voegen aan een swarm. Dit is de standaardopdracht 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
Labels toevoegen aan swarm-knooppunten
Als u een Docker-service wilt starten naar een swarmcluster met gemengd besturingssysteem, moet er een manier zijn om te onderscheiden welke swarm-knooppunten het besturingssysteem uitvoeren waarvoor die service is ontworpen en die niet zijn. Docker-objectlabels een handige manier bieden om knooppunten te labelen, zodat services kunnen worden gemaakt en geconfigureerd om alleen te worden uitgevoerd op de knooppunten die overeenkomen met hun besturingssysteem.
Notitie
Docker-objectlabels kunnen worden gebruikt om metagegevens toe te passen op verschillende Docker-objecten (inclusief containerinstallatiekopieën, containers, volumes en netwerken) en voor verschillende doeleinden (bijvoorbeeld labels kunnen worden gebruikt om de onderdelen 'front-end' en 'back-end' van een toepassing te scheiden, doordat front-end microservices alleen op 'front-end'-gelabelde knooppunten en back-end mircoservices alleen op 'back-end'-gelabelde knooppunten kunnen worden gepland). In dit geval gebruiken we labels op knooppunten om Windows-besturingssysteemknooppunten en Linux-knooppunten te onderscheiden.
Gebruik de volgende syntaxis om uw bestaande swarm-knooppunten te labelen:
C:\> docker node update --label-add <LABELNAME>=<LABELVALUE> <NODENAME>
Hier is <LABELNAME> de naam van het label dat u maakt. In dit geval onderscheiden we bijvoorbeeld knooppunten door hun besturingssysteem, zodat een logische naam voor het label 'os' kan zijn.
<LABELVALUE> is de waarde van het label. In dit geval kunt u ervoor kiezen om de waarden 'windows' en 'linux' te gebruiken. (Natuurlijk kunt u eventuele naamgevingskeuzen maken voor uw label- en labelwaarden, zolang u consistent blijft).
<NODENAME> is de naam van het knooppunt dat u labelt; u kunt uzelf herinneren aan de namen van uw knooppunten door docker node lsuit te voeren.
Als ubijvoorbeeld vier swarm-knooppunten in uw cluster hebt, met inbegrip van twee Windows-knooppunten en twee Linux-knooppunten, kunnen de opdrachten voor het bijwerken van labels er als volgt uitzien:
# 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
Services implementeren in een Mixed-OS swarm
Met labels voor uw swarm-knooppunten is het implementeren van services in uw cluster eenvoudig; gebruik de --constraint-optie voor de opdracht 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…]
Als u bijvoorbeeld de naamgeving voor label- en labelwaarden uit het bovenstaande voorbeeld gebruikt, ziet een set opdrachten voor het maken van services- een voor een Windows-service en een voor een op Linux gebaseerde service er als volgt uit:
# 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
Beperkingen
Momenteel heeft de swarm-modus in Windows de volgende beperkingen:
- Versleuteling van het gegevensvlak wordt niet ondersteund (bijvoorbeeld container-containerverkeer met behulp van optie
--opt encrypted) - Routing mesh voor Docker-hosts op Windows wordt niet ondersteund op Windows Server 2016, maar alleen vanaf Windows Server 2019. Gebruikers die op zoek zijn naar een alternatieve strategie voor taakverdeling, kunnen vandaag een externe load balancer (bijvoorbeeld NGINX) instellen en de publicatiepoortmodus van Swarm gebruiken om hostpoorten voor containers weer te geven waarop de taakverdeling moet worden verdeeld. Meer informatie hierover hieronder.
Poorten voor service-eindpunten publiceren
Gebruikers die poorten willen publiceren voor hun service-eindpunten, kunnen dit vandaag doen met behulp van de publicatiepoortmodus of de functie van Docker Swarm routerings-mesh-.
Als u wilt dat hostpoorten worden gepubliceerd voor elk van de taken/containereindpunten die een service definiëren, gebruikt u het argument --publish mode=host,target=<CONTAINERPORT> voor de opdracht 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…]
Met de volgende opdracht maakt u bijvoorbeeld een service, 's1', waarvoor elke taak wordt weergegeven via containerpoort 80 en een willekeurig geselecteerde hostpoort.
C:\ > docker service create --name=s1 --publish mode=host,target=80 --endpoint-mode dnsrr web_1 powershell -command {echo sleep; sleep 360000;}
Nadat u een service hebt gemaakt met behulp van de publicatiepoortmodus, kan de service worden opgevraagd om de poorttoewijzing voor elke servicetaak weer te geven:
C:\ > docker service ps <SERVICENAME>
Het bovenstaande commando geeft details over elke containerinstantie die wordt uitgevoerd voor uw service (op al uw swarm-hosts). Eén kolom van de uitvoer, de kolom Poorten, bevat poortgegevens voor elke host van het formulier <HOSTPORT>-><CONTAINERPORT>/tcp. De waarden van <HOSTPORT-> verschillen voor elke containerinstantie, omdat elke container wordt gepubliceerd op een eigen hostpoort.
Tips & Inzichten
Bestaand transparant netwerk kan swarm-initialisatie/overlay-netwerkcreatie blokkeren. In Windows moeten zowel de overlay- als transparante netwerkstuurprogramma's een externe vSwitch koppelen aan een (virtuele) hostnetwerkadapter. Wanneer er een overlaynetwerk wordt gemaakt, wordt er een nieuwe switch gemaakt die vervolgens is gekoppeld aan een geopende netwerkadapter. De transparante netwerkmodus maakt ook gebruik van een hostnetwerkadapter. Tegelijkertijd kan een bepaalde netwerkadapter slechts aan één switch tegelijk worden gebonden, als een host slechts één netwerkadapter heeft die kan worden gekoppeld aan slechts één externe vSwitch tegelijk, ongeacht of die vSwitch voor een overlay-netwerk of voor een transparant netwerk is.
Als een containerhost slechts één netwerkadapter heeft, is het daarom mogelijk om het probleem op te lopen van een transparant netwerk dat het maken van een overlaynetwerk blokkeert (of omgekeerd), omdat het transparante netwerk momenteel de enige virtuele netwerkinterface van de host in beslag neemt.
Er zijn twee manieren om dit probleem te omzeilen:
- optie 1: verwijder bestaand transparant netwerk: Voordat u een zwerm initialiseert, moet u ervoor zorgen dat er geen bestaand transparant netwerk op uw containerhost is. Verwijder transparante netwerken om ervoor te zorgen dat er een gratis virtuele netwerkadapter op uw host is die moet worden gebruikt voor het maken van overlay-netwerken.
- optie 2: maak een extra (virtuele) netwerkadapter op uw host: In plaats van een transparant netwerk op uw host te verwijderen, kunt u een extra netwerkadapter op uw host maken die moet worden gebruikt voor het maken van overlay-netwerken. Hiervoor maakt u eenvoudigweg een nieuwe externe netwerkadapter aan (met behulp van PowerShell of Hyper-V Manager). Wanneer de nieuwe interface is ingesteld, zal de Host Network Service (HNS) deze automatisch herkennen op uw host zodra uw zwerm is geïnitieerd en gebruiken om de externe vSwitch te koppelen voor het creëren van een overlaynetwerk.