Docker Swarm su tre continenti: alta disponibilità progettata per il 100% di uptime

Un server in un data center è un singolo punto di guasto, per quanto buoni siano l'hardware e la rete. Se la sede va fuori servizio, per esempio per un guasto all'alimentazione o alla rete, o semplicemente per un errore durante una manutenzione, l'applicazione non è più raggiungibile. Docker Swarm su più data center risolve proprio questo problema: i container girano in tre sedi indipendenti, idealmente su tre continenti, e se una di esse va completamente fuori servizio, subentrano le altre due senza che gli utenti se ne accorgano.

Questo articolo mostra passo dopo passo come costruire un cluster Docker Swarm progettato per il 100% di uptime: un server in Nord America, uno in Europa e uno in Asia, una rete WireGuard cifrata tra i nodi, un quorum di manager che sopravvive alla perdita di un intero continente, un punto di ingresso per regione e un failover DNS che porta automaticamente gli utenti alla sede funzionante più vicina. Spieghiamo inoltre con onestà che cosa può guastarsi persino con questa architettura e come puoi coprire anche questi rischi.

Con Docker Swarm si può raggiungere il 100% di uptime?

Un Docker Swarm su tre continenti è progettato per il 100% di uptime: nessun singolo server, nessun singolo data center e nessun singolo continente può fermare da solo l'applicazione. Una disponibilità assoluta, però, non la può garantire nessuno, nemmeno i grandi provider cloud, i cui impegni più alti si collocano tra il 99,99 e il 99,999%. Il motivo non sono i data center, ma ciò che tutte le sedi hanno in comune. L'articolo tratta anche questi aspetti, così puoi avvicinarti al 100% quanto è tecnicamente possibile.

Che cosa significa la disponibilità in cifre

Il calcolo si basa su 8.760 ore all'anno e 730 ore al mese. Ogni nove in più riduce a un decimo il downtime consentito, ed è proprio qui che inizia il lavoro che un singolo server non è più in grado di svolgere.

Perché tre continenti fanno una differenza così grande

Dal punto di vista matematico, tre sedi indipendenti l'una dall'altra, ciascuna con il 99,9% di disponibilità, vanno fuori servizio insieme solo se tutte e tre hanno un problema nello stesso momento: 0,1% per 0,1% per 0,1% fa 0,0000001%. Più le sedi sono lontane tra loro, più sono davvero indipendenti: ognuna ha la propria rete elettrica, le proprie connessioni di rete, le proprie condizioni meteo e le proprie finestre di manutenzione. Per questo la distribuzione su Nord America, Europa e Asia è la forma più solida di tolleranza ai guasti che si possa costruire con dei server.

Che cosa può guastarsi anche con tre continenti

I rischi che restano sono le dipendenze comuni a tutte le sedi, e per ognuna esiste una contromisura:

• Un aggiornamento difettoso viene distribuito dal cluster a tutte le sedi con la stessa affidabilità di uno buono. Contromisura: health check e rollback automatico, più aggiornamenti una regione alla volta.
• Il DNS è l'unico punto da cui passano tutti gli utenti. Contromisura: un provider DNS con una rete distribuita in tutto il mondo e failover, TTL breve.
• Il database deve avere gli stessi dati in tutte le sedi. Contromisura: replica con commutazione automatica, vedi la sezione sui dati.
• Certificati e domini scaduti colpiscono tutte le sedi contemporaneamente. Contromisura: rinnovo automatico e monitoraggio delle date di scadenza.
• La commutazione stessa richiede tempo, finché health check e DNS non hanno reagito: di solito uno o due minuti, durante i quali singole richieste possono fallire. Contromisura: intervalli di controllo brevi, TTL breve e client che ripetono le richieste fallite.

L'architettura in sintesi

Un Docker Swarm su più continenti si compone di sei elementi. Ognuno elimina un preciso punto di guasto:

Quanti manager e dove?

I nodi manager di uno Swarm gestiscono lo stato del cluster con l'algoritmo di consenso Raft. Ogni modifica richiede l'approvazione della maggioranza dei manager, il cosiddetto quorum. Se la maggioranza viene meno, i container esistenti continuano sì a girare, ma il cluster non può più ripianificare, né compensare i guasti, né distribuire aggiornamenti.

Docker raccomanda un numero dispari di manager e la distribuzione su almeno tre zone: con tre manager in proporzione 1-1-1, con cinque in proporzione 2-2-1. Da qui deriva la regola più importante di questo articolo: due sedi non bastano. Con due sedi, in una delle due si trovano per forza più manager, e se cade proprio quella, la maggioranza è persa. Solo con tre sedi il quorum sopravvive al guasto di un data center qualsiasi, e quindi, con tre continenti, alla perdita di un intero continente.

Tre continenti o un solo continente: il compromesso

Ogni modifica al cluster, ogni deployment e ogni ripianificazione di un container attende la conferma della maggioranza dei manager. Tra Europa, Nord America e Asia ciascuna di queste conferme richiede un tempo di transito dei pacchetti compreso tra circa 80 e 250 millisecondi. Per gli utenti è irrilevante, perché le loro richieste ricevono risposta in locale; deployment e ripianificazioni richiedono però sensibilmente più tempo che in un cluster con percorsi brevi.

Per applicazioni con utenti su più continenti e con l'obiettivo della massima disponibilità possibile, la variante con tre continenti è quella giusta, ed è quella che costruiamo nella guida. Un punto importante è una regola che attraversa tutti i passi: ogni richiesta riceve risposta nella propria regione e non viaggia mai avanti e indietro tra i continenti.

Quali sedi KernelHost sono adatte

KernelHost gestisce server nel data center maincubes di Francoforte sul Meno e offre server virtuali in altre sedi in Europa, Nord America e Asia-Pacifico, tra cui tre sedi negli Stati Uniti, oltre a Canada, Londra, Strasburgo, Varsavia, Helsinki, Singapore, Giappone, Sydney e Mumbai. L'elenco completo con la mappa si trova nella pagina Sedi dei server. Per l'esempio di questo articolo prendiamo Francoforte sul Meno per l'Europa, la costa est degli Stati Uniti per il Nord America e Singapore per l'Asia.

Guida: costruire un Docker Swarm su tre continenti

L'esempio usa tre server: swarm-eu a Francoforte sul Meno, swarm-us sulla costa est degli Stati Uniti e swarm-asia a Singapore. Gli indirizzi pubblici provengono dalla rete di documentazione 203.0.113.0/24, la rete WireGuard usa 10.10.0.0/24. Sostituisci entrambi con i tuoi valori. Tutti e tre i nodi sono sia manager sia worker; per avere più prestazioni potrai aggiungere in seguito, in ogni regione, nodi esclusivamente worker.

Passo 1: attivare i server su tre continenti

Ordina tre server con Debian 12 o 13 in tre regioni e applica la messa in sicurezza di base: SSH solo con chiave, aggiornamenti di sicurezza automatici, utenti dedicati. La checklist per nuovi server root copre tutti questi punti. Assegna hostname descrittivi, così in docker node ls vedi subito quale nodo si trova dove.

hostnamectl set-hostname swarm-eu

Passo 2: installare Docker su tutti i nodi

Installa Docker Engine dal repository ufficiale di Docker su tutti e tre i server, come descritto nell'articolo Installare Docker su Debian e Ubuntu. Poi controlla la versione su ogni nodo; tutti e tre dovrebbero avere la stessa versione principale:

docker version --format '{{.Server.Version}}'

Passo 3: creare una rete WireGuard tra i continenti

I nodi comunicano tra loro attraverso l'Internet pubblico. Perché tutto il traffico del cluster sia cifrato e le porte di Swarm non siano mai raggiungibili pubblicamente, i tre server sono collegati da una rete WireGuard. Su ogni nodo genera prima una coppia di chiavi:

apt-get install -y wireguard
umask 077
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key

Poi ogni nodo riceve un file /etc/wireguard/wg0.conf. Su swarm-eu ha questo aspetto, mentre gli altri due nodi sono configurati in modo speculare:

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = CHIAVE_PRIVATA_DI_SWARM_EU
MTU = 1420

[Peer]
PublicKey = CHIAVE_PUBBLICA_DI_SWARM_US
Endpoint = 203.0.113.12:51820
AllowedIPs = 10.10.0.2/32
PersistentKeepalive = 25

[Peer]
PublicKey = CHIAVE_PUBBLICA_DI_SWARM_ASIA
Endpoint = 203.0.113.13:51820
AllowedIPs = 10.10.0.3/32
PersistentKeepalive = 25

systemctl enable --now wg-quick@wg0
ping -c 3 10.10.0.2

Se tutti i nodi rispondono sui propri indirizzi 10.10.0.x, la rete è pronta. PersistentKeepalive mantiene aperta la connessione anche dietro firewall stateful. I tempi che ping mostra ora tra i continenti sono esattamente l'attesa che ogni modifica al cluster comporta.

Passo 4: un firewall che lascia entrare solo i nodi Swarm

Tra i nodi, Docker Swarm ha bisogno della porta 2377/TCP per la gestione del cluster, della 7946/TCP e UDP per la comunicazione dei nodi tra loro e della 4789/UDP per la rete overlay. Consenti queste porte esclusivamente sull'interfaccia WireGuard; pubblicamente resta aperto solo WireGuard stesso, e soltanto per gli altri nodi. Con ufw, su swarm-eu il risultato è questo:

ufw allow from 203.0.113.12 to any port 51820 proto udp
ufw allow from 203.0.113.13 to any port 51820 proto udp
ufw allow in on wg0 to any port 2377 proto tcp
ufw allow in on wg0 to any port 7946
ufw allow in on wg0 to any port 4789 proto udp

Importante: le porte che Docker pubblica per i container aggirano ufw, perché Docker imposta regole iptables proprie. Pubblica quindi solo le porte del punto di ingresso (80 e 443) e mai porte di database o di amministrazione.

Passo 5: inizializzare lo Swarm e aggiungere i manager

Su swarm-eu inizializza lo Swarm e fai in modo che la gestione e il traffico dati passino attraverso WireGuard:

docker swarm init --advertise-addr 10.10.0.1 --data-path-addr 10.10.0.1
docker swarm join-token manager

Il secondo comando restituisce l'istruzione di join per altri manager. Eseguilo su swarm-us e swarm-asia, ognuno con il proprio indirizzo WireGuard; ecco la versione per swarm-us:

docker swarm join --token SWMTKN-1-... --advertise-addr 10.10.0.2 --data-path-addr 10.10.0.2 10.10.0.1:2377
docker node ls

A quel punto docker node ls mostra tre nodi, uno con lo stato Leader e gli altri due con Reachable. Il token di join è un segreto: chi lo conosce può infiltrare un proprio manager nel tuo cluster. Una volta terminata la configurazione, rinnovalo con docker swarm join-token --rotate manager.

Passo 6: attivare Autolock

I manager salvano lo stato del cluster, insieme alle chiavi con cui sono cifrati i log Raft, in /var/lib/docker/swarm/. Con Autolock queste chiavi vengono a loro volta cifrate, e un manager riavviato rientra nel cluster solo dopo l'inserimento di una chiave di sblocco:

docker swarm update --autolock=true
docker swarm unlock

Il primo comando restituisce la chiave di sblocco, da salvare in un password manager. Il secondo ti serve dopo ogni riavvio di un manager. Senza la chiave lo Swarm non si può ripristinare nemmeno da un backup, quindi conservala separata dai server.

Passo 7: etichettare i nodi per regione

Le label indicano allo scheduler dove si trova un nodo. Su di esse si basano i vincoli di posizionamento dei passi successivi:

docker node update --label-add region=eu swarm-eu
docker node update --label-add region=us swarm-us
docker node update --label-add region=asia swarm-asia

Passo 8: creare una rete overlay con la MTU giusta

I container in sedi diverse comunicano tra loro tramite una rete overlay. Poiché questa passa nel tunnel WireGuard, la sua MTU deve essere più piccola: WireGuard lavora con 1420 byte, la rete overlay (VXLAN) ne occupa 50 per le proprie intestazioni, e restano 1370 byte:

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1370 appnet

Una MTU troppo grande si manifesta in modo subdolo: le richieste piccole funzionano, le risposte grandi restano appese. Chi rinuncia a WireGuard può invece cifrare la rete overlay con --opt encrypted; in quel caso tra i nodi deve essere consentito anche il protocollo IP 50 (ESP), e Docker segnala espressamente un calo di prestazioni sensibile. Consigliamo WireGuard, perché copre tutto il traffico, gestione compresa.

Passo 9: eseguire l'applicazione in ogni regione

Un normale servizio Swarm distribuisce le richieste, tramite il proprio indirizzo di servizio, su tutte le repliche del cluster, quindi anche sugli altri continenti. Con tre continenti, una richiesta su due o su tre farebbe così mezzo giro del mondo. Per questo ogni regione riceve un proprio servizio, che un vincolo di posizionamento tiene nella sua regione. Le impostazioni di aggiornamento fanno sì che le nuove versioni vengano distribuite un container alla volta e annullate automaticamente in caso di errori:

for r in eu us asia; do
  docker service create --name web-$r --replicas 2 --network appnet \
    --constraint node.labels.region==$r \
    --update-parallelism 1 --update-delay 30s \
    --update-failure-action rollback \
    registry.example.com/web:1.0
done

Perché Swarm riconosca se un container lavora davvero e non si limita a essere in esecuzione, l'immagine deve contenere un health check, per esempio questa riga nel Dockerfile della tua applicazione:

HEALTHCHECK --interval=10s --timeout=3s --retries=3 CMD wget -qO- http://127.0.0.1:8080/health || exit 1

Un container il cui health check fallisce tre volte di fila viene sostituito, e durante un aggiornamento un health check fallito blocca la distribuzione.

Passo 10: un punto di ingresso per regione

Il punto di ingresso è un reverse proxy come Caddy, Traefik o nginx. Anche questo gira in ogni regione come servizio a sé e inoltra le richieste solo all'applicazione della propria regione. In modalità host pubblica le porte 80 e 443 direttamente sul server della sua regione. Basta una configurazione comune, perché Caddy legge la destinazione da una variabile d'ambiente:

example.com {
    reverse_proxy {$UPSTREAM}:80
}

docker config create caddyfile ./Caddyfile
for r in eu us asia; do
  docker service create --name edge-$r --network appnet \
    --constraint node.labels.region==$r \
    --env UPSTREAM=web-$r \
    --config source=caddyfile,target=/etc/caddy/Caddyfile \
    --publish mode=host,target=80,published=80 \
    --publish mode=host,target=443,published=443 \
    caddy:2
done

Tutte le regioni hanno bisogno di un certificato TLS per lo stesso dominio. Ottieni quindi i certificati tramite la challenge DNS, che funziona a prescindere dalla regione a cui punta in quel momento il record DNS; per farlo Caddy ha bisogno del modulo del tuo provider DNS. Le basi sul proxy sono nell'articolo Configurare nginx come reverse proxy.

Passo 11: configurare il Geo-DNS con failover

L'ultimo elemento porta gli utenti alla regione giusta. Un servizio DNS con geo-routing e health check manda gli utenti europei a Francoforte sul Meno, quelli americani sulla costa est degli Stati Uniti e quelli asiatici a Singapore. Se una regione va fuori servizio, l'health check se ne accorge in un tempo compreso tra 30 e 60 secondi e manda i suoi utenti alla regione funzionante più vicina. Imposta la durata di validità (TTL) dei record a 60 secondi, così i resolver recepiscono rapidamente un cambio. Più record A senza health check sono solo un ripiego: i browser spesso provano l'indirizzo successivo, ma non tutti i client lo fanno, e una regione fuori servizio resta nella risposta.

Fai i conti con onestà: tra il guasto e il cambio passano l'intervallo di controllo più il TTL, nell'esempio quindi uno o due minuti, durante i quali una parte degli utenti della regione colpita raggiunge ancora la sede fuori servizio. Le applicazioni e le app che ripetono le richieste fallite dopo una breve pausa coprono questo intervallo in modo quasi impercettibile.

Passo 12: testare il guasto di una regione

Un failover mai provato raramente funziona quando serve davvero. Simula il guasto di una regione togliendo dal servizio il suo nodo e osserva come reagiscono il cluster e il DNS:

docker node update --availability drain swarm-asia
docker node ls
docker service ls
docker node update --availability active swarm-asia

Poiché i servizi della regione sono legati al loro nodo da un vincolo di posizionamento, non si spostano ma restano in pausa; degli utenti della regione si occupa il failover DNS. In questo test verifica quindi soprattutto che l'health check tolga la regione dalle risposte e che la regione vicina regga il carico aggiuntivo. Per un test più severo scollega del tutto il nodo dalla rete, per esempio fermando WireGuard. Ripeti il test dopo modifiche importanti e almeno una volta ogni trimestre.

Dati: la parte più difficile dell'alta disponibilità

Docker Swarm replica i container, non i dati. Un volume si trova sempre sul nodo su cui gira il container. I servizi stateless come frontend web e API si possono quindi eseguire senza problemi in ogni regione; per tutto ciò che contiene dati ti serve una replica a parte.

Replicare i database tra continenti

I database hanno già una propria replica, ed è sempre preferibile a uno storage condiviso tra data center. Tra continenti si è dimostrato valido lo schema con un'istanza primaria in una regione e repliche asincrone nelle altre due: per PostgreSQL, per esempio, tramite streaming replication con uno strumento come Patroni per la commutazione automatica, per MariaDB e MySQL tramite la replica integrata. Ogni regione risponde così in locale alle richieste di lettura, mentre le scritture vanno all'istanza primaria. A dirla tutta, asincrona significa anche questo: se la regione primaria va fuori servizio, possono mancare gli ultimi secondi di scritture. Chi vuole scrivere in tutto il mondo senza perdere nulla sceglie database progettati per più regioni, come CockroachDB o YugabyteDB. Lega i nodi del database alla loro regione con un vincolo di posizionamento, così Swarm non li sposta mai senza i loro dati:

docker service create --name db-asia --constraint node.labels.region==asia ...

File e upload

I file caricati non vanno in un volume locale, ma in un object storage compatibile con S3 con replica in una seconda regione, oppure in un sistema di storage proprio e replicato. I file system di rete come NFS tra continenti sono lenti e rappresentano a loro volta un singolo punto di guasto.

Sessioni e cache

Se l'applicazione salva le sessioni nella memoria di un container, con la commutazione gli utenti perdono il login. Metti le sessioni in un database replicato o in una cache replicata come Redis, oppure usa token firmati che ogni regione può verificare da sola.

I backup restano obbligatori

La replica protegge dal guasto di una sede, ma non dagli errori: un record cancellato per sbaglio sparisce pochi secondi dopo da tutte le regioni. Per questo ogni architettura ad alta disponibilità deve prevedere backup regolari e testati in un luogo indipendente, come descritto nell'articolo Strategia di backup per server.

Gestione: aggiornamenti, manutenzione e monitoraggio

Aggiornamenti una regione alla volta

Non distribuire le nuove versioni in tutte le regioni contemporaneamente, ma una dopo l'altra, e osserva ogni regione per un breve periodo prima di passare alla successiva. Così un errore che nessun health check rileva raggiunge al massimo una regione, e le altre due continuano a servirne gli utenti:

for r in asia us eu; do
  docker service update --image registry.example.com/web:1.1 web-$r || break
  sleep 300
done

Se un aggiornamento fallisce, Swarm lo annulla automaticamente grazie alle impostazioni del passo 9, e || break interrompe il ciclo non appena il comando segnala un errore. Un aggiornamento i cui problemi emergono solo più tardi lo annulli a mano con docker service rollback web-asia.

Manutenzione di una regione

Se un server deve essere riavviato o aggiornato, toglilo dal servizio con docker node update --availability drain e lascia che prima il failover DNS ne reindirizzi gli utenti verso le regioni vicine. Dopo la manutenzione rimettilo in servizio con --availability active. Prima di passare al manager successivo, aspetta che docker node ls mostri di nuovo tutti e tre come raggiungibili, così non mancano mai due manager contemporaneamente.

Monitoraggio dall'esterno

Monitora ogni regione singolarmente e dall'esterno del cluster: raggiungibilità dei punti di ingresso, health check dei servizi, stato dei manager, ritardo di replica del database e date di scadenza di certificati e domini. Un allarme deve arrivare anche quando un'intera regione tace. Come impostare tutto questo per singoli server lo spiega l'articolo Configurare il monitoraggio del server.

Distribuire i segreti in modo sicuro

Password e chiavi non vanno nelle variabili d'ambiente o nei file Compose, ma in Docker Secrets. I segreti vengono salvati cifrati nel log Raft e consegnati solo ai servizi a cui li assegni esplicitamente:

printf '%s' 'LA_TUA_PASSWORD_DATABASE' | docker secret create db_password -
docker service update --secret-add db_password web-eu

Perché KernelHost per uno Swarm su più continenti

Un cluster su più continenti pone al provider requisiti diversi da quelli di un singolo server. In pratica sono questi i punti decisivi:

Nella pagina Noleggio server cloud trovi una panoramica di tutti i piani cloud con i prezzi e un confronto dei costi con i grandi provider cloud.

Errori frequenti e come evitarli

• Manager in due sole sedi. Se cade la sede con la maggioranza, il cluster si blocca. Soluzione: tre sedi, distribuzione 1-1-1 o 2-2-1.
• Numero pari di manager. Quattro manager non tollerano più guasti di tre, ma aumentano il lavoro di coordinamento. Soluzione: 3, 5 o 7.
• Richieste che viaggiano tra i continenti. Un unico indirizzo di servizio su tutte le regioni manda gli utenti a fare mezzo giro del mondo. Soluzione: un servizio e un punto di ingresso per regione.
• Porte di Swarm raggiungibili pubblicamente. La porta 2377 e la rete overlay non vanno mai esposte sull'Internet aperto. Soluzione: solo tramite WireGuard; pubblicamente solo 80, 443 e WireGuard per gli altri nodi.
• MTU dimenticata. Le risposte grandi restano appese, quelle piccole funzionano. Soluzione: MTU overlay 1370 con WireGuard a 1420.
• Affidarsi a ufw per le porte dei container. Docker aggira ufw per le porte pubblicate. Soluzione: pubblicare solo il punto di ingresso.
• Database in un volume senza replica. Se la regione va fuori servizio, i dati non sono raggiungibili. Soluzione: replica del database, posizionamento vincolato alla regione.
• Aggiornamento in tutte le regioni contemporaneamente. Un errore colpisce allora tutti gli utenti nel mondo. Soluzione: distribuire una regione alla volta.
• TTL DNS elevato. Con un TTL di un giorno il failover ha effetto solo il giorno dopo. Soluzione: 60 secondi.
• Replica al posto del backup. Un errore viene replicato esattamente come i dati buoni. Soluzione: in aggiunta, backup testati in un luogo indipendente.

In breve

• Un Docker Swarm su tre continenti è progettato per il 100% di uptime: un'intera sede o un intero continente può andare fuori servizio senza che l'applicazione si fermi.
• Nessuno può garantire una disponibilità in termini assoluti; i rischi che restano sono DNS, aggiornamenti difettosi, database e certificati, e per ognuno esiste una contromisura.
• Tre manager in tre sedi sono il minimo; due sedi non bastano per un quorum a prova di guasto.
• Ogni richiesta resta nella propria regione: un servizio e un punto di ingresso per regione, più Geo-DNS con health check e TTL breve.
• WireGuard cifra il traffico del cluster, le porte di Swarm restano invisibili, la MTU overlay scende a 1370.
• Swarm replica i container, non i dati: i database hanno bisogno di una replica propria, e i backup restano obbligatori.
• KernelHost offre sedi in Europa, Nord America e Asia-Pacifico, traffico illimitato, protezione DDoS in ogni sede e fatturazione PrePaid senza durata minima.