Condividi tramite

Introduzione alla modalità swarm

  • Articolo

Si applica a: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Che cos'è la "modalità swarm"?

La modalità Swarm è una funzionalità Docker che offre funzionalità di orchestrazione dei contenitori predefinite, tra cui il clustering nativo di host Docker e la pianificazione dei carichi di lavoro dei contenitori. Un gruppo di host Docker costituisce un cluster "swarm" quando i motori Docker vengono eseguiti insieme in modalità "swarm". Per un contesto aggiuntivo in modalità swarm, vedere il sito della documentazione principale di Docker.

Nodi di gestione e nodi di lavoro

Uno swarm è costituito da due tipi di host contenitore: nodi di gestione e nodi di lavoro. Ogni swarm viene inizializzato tramite un nodo di gestione e tutti i comandi dell'interfaccia della riga di comando di Docker per il controllo e il monitoraggio di uno swarm devono essere eseguiti da uno dei nodi di gestione. I nodi manager possono essere considerati "keeper" dello stato Swarm, insieme formano un gruppo di consenso che mantiene la consapevolezza dello stato dei servizi in esecuzione sullo swarm ed è il loro compito di garantire che lo stato effettivo dello swarm corrisponda sempre allo stato previsto, come definito dallo sviluppatore o dall'amministratore.

Nota

Qualsiasi swarm specificato può contenere più nodi di gestione, ma deve averne sempre almeno uno.

I nodi di lavoro vengono orchestrati da docker swarm tramite nodi di gestione. Per aggiungere uno swarm, un nodo di lavoro deve usare un "token di join" generato dal nodo di gestione quando lo swarm è stato inizializzato. I nodi di lavoro ricevono ed eseguono semplicemente attività dai nodi di gestione e quindi non richiedono (e possiedono) alcuna consapevolezza dello stato swarm.

Requisiti di sistema per la modalità Swarm

Almeno un sistema di computer fisico o virtuale (per usare la funzionalità completa di swarm almeno due nodi è consigliato) che esegue Windows 10 Creators Update o Windows Server 2016 con tutti gli aggiornamenti più recenti*, la configurazione come host contenitore (vedere l'argomento Contenitori windows in Contenitori Windows 10 o Windows in Windows Server per altre informazioni su come iniziare a usare i contenitori Docker in Windows 10).

* Nota: Docker Swarm in Windows Server 2016 richiede KB4015217

Motore Docker versione 1.13.0 o successive

Porte aperte: le porte seguenti devono essere disponibili in ogni host. In alcuni sistemi, queste porte sono aperte per impostazione predefinita.

  • Porta TCP 2377 per le comunicazioni di gestione del cluster
  • Porta TCP e UDP 7946 per la comunicazione tra nodi
  • Porta UDP 4789 per il traffico di rete sovrapposto

Inizializzazione di un cluster Swarm

Per inizializzare uno swarm, eseguire semplicemente il comando seguente da uno degli host contenitore (sostituendo <HOSTIPADDRESS> con l'indirizzo IPv4 locale del computer host):

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

Quando questo comando viene eseguito da un determinato host contenitore, il motore Docker in tale host inizia a essere eseguito in modalità swarm come nodo di gestione.

Aggiunta di nodi a uno swarm

Per usare le funzionalità della modalità swarm e della rete di sovrapposizione non sono richiesti più nodi. Tutte le funzionalità swarm/overlay possono essere usate con un singolo host in esecuzione in modalità swarm (ad esempio, un nodo di gestione, in modalità swarm con il docker swarm init comando ).

Aggiunta di ruoli di lavoro a uno swarm

Dopo l'inizializzazione di uno swarm da un nodo di gestione, è possibile aggiungere altri host allo swarm come ruoli di lavoro con un altro comando semplice:

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

In questo caso, <MANAGERIPADDRESS> è l'indirizzo IP locale di un nodo di gestione swarm e <WORKERJOINTOKEN> è il token di join del ruolo di lavoro fornito come output dal docker swarm init comando eseguito dal nodo di gestione. Il token di join può essere ottenuto anche eseguendo uno dei comandi seguenti dal nodo di gestione dopo l'inizializzazione dello swarm:

# 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

Aggiunta di manager a uno swarm

È possibile aggiungere nodi di gestione aggiuntivi a un cluster swarm con il comando seguente:

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

Anche in questo caso, <MANAGERIPADDRESS> è l'indirizzo IP locale di un nodo di gestione swarm. Il token <di join, MANAGERJOINTOKEN>, è un token di join del manager per lo swarm, che può essere ottenuto eseguendo uno dei comandi seguenti da un nodo di gestione esistente:

# 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

Creazione di una rete di sovrapposizione

Dopo aver configurato un cluster swarm, è possibile creare reti di sovrapposizione nello swarm. È possibile creare una rete di sovrapposizione eseguendo il comando seguente da un nodo di gestione swarm:

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

In questo caso, <NETWORKNAME> è il nome che si vuole assegnare alla rete.

Distribuzione di servizi in uno swarm

Dopo aver creato una rete di sovrapposizione, è possibile creare e collegare i servizi alla rete. Viene creato un servizio con la sintassi seguente:

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

In questo caso, <SERVICENAME> è il nome che si vuole assegnare al servizio. Questo è il nome che verrà usato per fare riferimento al servizio tramite l'individuazione dei servizi (che usa il server DNS nativo di Docker). <NETWORKNAME> è il nome della rete a cui collegare questo servizio (ad esempio "reteSovrapposizionePersonale"). <CONTAINERIMAGE> è il nome dell'immagine contenitore che definirà il servizio.

Nota

Il secondo argomento di questo comando, --endpoint-mode dnsrr, è necessario per specificare al motore Docker che si userà il criterio Round Robin DNS per bilanciare il traffico di rete tra gli endpoint dei contenitori del servizio. Attualmente, Round Robin DNS è l'unica strategia di bilanciamento del carico supportata in Windows Server 2016. La mesh di routing per gli host docker di Windows è supportata in Windows Server 2019 e versioni successive, ma non in Windows Server 2016. Gli utenti che stanno cercando una strategia di bilanciamento del carico alternativa in Windows Server 2016 ora possono configurare un bilanciamento del carico esterno (ad esempio NGINX) e usare la modalità della porta di pubblicazione dello swarm per esporre le porte dell'host contenitore tramite cui eseguire il bilanciamento del traffico.

Ridimensionamento di un servizio

Dopo aver distribuito un servizio in un cluster swarm, le istanze del contenitore che compongono il servizio vengono distribuite nel cluster. Per impostazione predefinita, il numero di istanze del contenitore che esegue il backup di un servizio, ovvero il numero di "repliche" o "attività" per un servizio, è uno. Tuttavia, un servizio può essere creato con più attività usando l'opzione --replicas per il docker service create comando o ridimensionando il servizio dopo la creazione.

La scalabilità del servizio è un vantaggio fondamentale offerto da Docker Swarm e può essere sfruttato anche con un singolo comando Docker:

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

In questo caso, <SERVICENAME> è il nome del servizio ridimensionato e <REPLICAS> è il numero di attività, o istanze di contenitore, a cui viene ridimensionato il servizio.

Visualizzazione dello stato dello swarm

Sono disponibili diversi comandi utili per visualizzare lo stato di uno swarm e i servizi in esecuzione nello swarm.

Elencare i nodi swarm

Usare il comando seguente per visualizzare un elenco dei nodi attualmente aggiunti a uno swarm, incluso informaiton sullo stato di ogni nodo. Questo comando deve essere eseguito da un nodo di gestione.

C:\> docker node ls

Nell'output di questo comando si noterà uno dei nodi contrassegnati con un asterisco (*); l'asterisco indica semplicemente il nodo corrente, ovvero il nodo da cui è stato eseguito il docker node ls comando.

Elencare le reti

Usare il comando seguente per visualizzare un elenco delle reti esistenti in un determinato nodo. Per visualizzare le reti sovrapposte, questo comando deve essere eseguito da un nodo di gestione in esecuzione in modalità swarm.

C:\> docker network ls

Elencare i servizi

Usare il comando seguente per visualizzare un elenco dei servizi attualmente in esecuzione in uno swarm, incluse le informazioni sul relativo stato.

C:\> docker service ls

Elencare le istanze del contenitore che definiscono un servizio

Usare il comando seguente per visualizzare i dettagli sulle istanze del contenitore in esecuzione per un determinato servizio. L'output per questo comando include gli ID e i nodi su cui è in esecuzione ogni contenitore, nonché l'infromation sullo stato dei contenitori.

C:\> docker service ps <SERVICENAME>

Cluster linux+windows con sistema operativo misto

Recentemente, un membro del nostro team ha pubblicato una breve demo in tre parti su come configurare un'applicazione windows+Linux mixed-OS usando Docker Swarm. È un ottimo posto per iniziare se non si ha familiarità con Docker Swarm o per usarlo per eseguire applicazioni con sistema operativo misto. Controllalo ora:

Inizializzazione di un cluster di sistemi operativi misti Linux+Windows

L'inizializzazione di un cluster swarm del sistema operativo misto è semplice, purché le regole del firewall siano configurate correttamente e gli host abbiano accesso l'uno all'altro, è sufficiente aggiungere un host Linux a uno swarm è il comando standard 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

Aggiunta di etichette ai nodi swarm

Per avviare un servizio Docker in un cluster swarm del sistema operativo misto, è necessario un modo per distinguere quali nodi swarm eseguono il sistema operativo per il quale è progettato il servizio e che non lo sono. Le etichette degli oggetti Docker offrono un modo utile per etichettare i nodi, in modo che i servizi possano essere creati e configurati per l'esecuzione solo nei nodi che corrispondono al sistema operativo.

Nota

Le etichette di oggetti Docker possono essere usate per applicare i metadati a un'ampia gamma di oggetti Docker, inclusi immagini di contenitore, contenitori, volumi e reti, e per diversi scopi (ad esempio, le etichette potrebbero essere usate per separare i componenti "front-end" e "back-end" di un'applicazione, consentendo ai microservizi front-end di essere programmati solo nei nodi etichettati "front-end" e ai microservizi back-end di essere programmati solo nei nodi etichettati "back-end"). In questo caso, vengono usate le etichette nei nodi per distinguere i nodi del sistema operativo Windows e i nodi del sistema operativo Linux.

Per etichettare i nodi swarm esistenti, usare la sintassi seguente:

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

In questo caso, <LABELNAME> è il nome dell'etichetta che si sta creando, ad esempio, in questo caso si distinguono i nodi in base al sistema operativo, quindi un nome logico per l'etichetta potrebbe essere "os". <LABELVALUE> è il valore dell'etichetta, in questo caso potresti usare i valori "windows" e "linux". (Naturalmente, è possibile effettuare qualsiasi scelta di denominazione per i valori di etichetta e etichetta, purché rimanga coerente). <NODENAME> è il nome del nodo che stai etichettando. Puoi ricordarti dei nomi dei nodi eseguendo docker node ls.

Ad esempio, se nel cluster sono presenti quattro nodi swarm, inclusi due nodi Windows e due nodi Linux, i comandi di aggiornamento delle etichette potrebbero essere simili al seguente:

# 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

Distribuzione di servizi in uno swarm del sistema operativo misto

Con le etichette per i nodi swarm, la distribuzione dei servizi nel cluster è semplice; è sufficiente usare l'opzione --constraint per il docker service create comando :

# 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…]

Ad esempio, usando l'etichetta e la classificazione dei valori dell'esempio precedente, un set di comandi di creazione del servizio, uno per un servizio basato su Windows e uno per un servizio basato su Linux, potrebbe essere simile al seguente:

# 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

Limiti

Attualmente, la modalità swarm in Windows presenta le limitazioni seguenti:

  • Crittografia del piano dati non supportata (ad esempio il traffico container-container usando l'opzione --opt encrypted )
  • La mesh di routing per gli host Docker di Windows non è supportata in Windows Server 2016, ma solo da Windows Server 2019 e versioni successive. Gli utenti che cercano una strategia di bilanciamento del carico alternativo oggi possono configurare un servizio di bilanciamento del carico esterno (ad esempio NGINX) e usare la modalità di porta di pubblicazione di Swarm per esporre le porte host del contenitore su cui bilanciare il carico. Altri dettagli su questo argomento di seguito.

Pubblicare porte per gli endpoint di servizio

Gli utenti che cercano di pubblicare le porte per i rispettivi endpoint del servizio possono farlo subito usando la modalità di pubblicazione porta o la funzionalità mesh di routing dello swarm di Docker.

Per fare in modo che le porte host vengano pubblicate per ogni attività o endpoint contenitore che definiscono un servizio, usare l'argomento --publish mode=host,target=<CONTAINERPORT> per il docker service create comando :

# 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…]

Ad esempio, il comando seguente crea un servizio , 's1', per cui ogni attività verrà esposta tramite la porta del contenitore 80 e una porta host selezionata in modo casuale.

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

Dopo aver creato un servizio usando la modalità di porta di pubblicazione, è possibile eseguire una query sul servizio per visualizzare il mapping delle porte per ogni attività del servizio:

C:\ > docker service ps <SERVICENAME>

Il comando precedente restituirà i dettagli su ogni istanza del contenitore in esecuzione per il servizio (in tutti gli host swarm). Una colonna dell'output, la colonna "porte", includerà le informazioni sulla porta per ogni host del modulo <HOSTPORT-CONTAINERPORT>><>/tcp. I valori di <HOSTPORT> saranno diversi per ogni istanza del contenitore, in quanto ogni contenitore è pubblicato nella propria porta host.

Suggerimenti e informazioni dettagliate

La rete trasparente esistente può bloccare l'inizializzazione di swarm e la creazione della rete overlay In Windows, sia la rete overlay che i driver di rete trasparente richiedono che un vSwitch esterno sia collegato a un adattatore di rete host (virtuale). Quando viene creata una rete di sovrapposizione, viene creato un nuovo commutatore collegato a una scheda di rete aperta. La modalità di rete trasparente usa anche una scheda di rete host. Allo stesso tempo, una determinata scheda di rete può essere associata a un solo commutatore alla volta, se un host dispone di una sola scheda di rete, può collegarsi a un solo vSwitch esterno alla volta, indipendentemente dal fatto che il vSwitch sia per una rete di sovrapposizione o per una rete trasparente.

Di conseguenza, se un host contenitore ha una sola scheda di rete, è possibile che si verifichi il problema di una creazione di rete trasparente che blocca la creazione di una rete sovrapposta (o viceversa), perché la rete trasparente occupa attualmente l'unica interfaccia di rete virtuale dell'host.

Esistono due modi per risolvere questo problema:

  • Opzione 1: eliminare una rete trasparente esistente: prima di inizializzare uno swarm, assicurarsi che non sia presente una rete trasparente esistente nell'host contenitore. Eliminare reti trasparenti per assicurarsi che nell'host sia presente una scheda di rete virtuale gratuita da usare per la creazione della rete sovrapposta.
  • Opzione 2: creare una scheda di rete aggiuntiva (virtuale) nell'host: invece di rimuovere qualsiasi rete trasparente presente nell'host, è possibile creare una scheda di rete aggiuntiva nell'host da usare per la creazione della rete di sovrapposizione. A tale scopo, è sufficiente creare una nuova scheda di rete esterna (usando PowerShell o La console di gestione di Hyper-V); con la nuova interfaccia, quando lo swarm viene inizializzato, il servizio di rete host lo riconoscerà automaticamente nell'host e lo userà per associare il vSwitch esterno per la creazione della rete di sovrapposizione.