Docker Swarm en tres continentes: alta disponibilidad diseñada para un 100 % de uptime

Un servidor en un centro de datos es un punto único de fallo, por muy buenos que sean el hardware y la red. Si esa ubicación cae, ya sea por una avería eléctrica, por un problema de red o simplemente por un error durante un mantenimiento, la aplicación queda fuera de servicio. Docker Swarm en varios centros de datos resuelve justo este problema: los contenedores se ejecutan en tres ubicaciones independientes, idealmente en tres continentes, y si una de ellas cae por completo, las otras dos toman el relevo sin que los usuarios lo noten.

Este artículo muestra paso a paso cómo montar un clúster de Docker Swarm diseñado para un 100 % de uptime: un servidor en Norteamérica, otro en Europa y otro en Asia, una red WireGuard cifrada entre los nodos, un quórum de managers que sobrevive a la caída de un continente entero, un punto de entrada por región y un failover de DNS que dirige automáticamente a los usuarios a la ubicación en buen estado más cercana. Además, explicamos con franqueza qué puede seguir fallando incluso con esta arquitectura y cómo cubrir también esos riesgos.

¿Se puede lograr un 100 % de uptime con Docker Swarm?

Un Docker Swarm repartido en tres continentes está diseñado para un 100 % de uptime: ni un solo servidor, ni un solo centro de datos ni un solo continente pueden paralizar la aplicación por sí solos. Aun así, nadie puede garantizar una disponibilidad absoluta, ni siquiera los grandes proveedores cloud, cuyos compromisos más altos se sitúan entre el 99,99 y el 99,999 %. El motivo no son los centros de datos, sino los elementos que todas las ubicaciones tienen en común. Este artículo también se ocupa precisamente de ellos, para que te acerques al 100 % tanto como sea técnicamente posible.

Qué significa la disponibilidad en cifras

El cálculo se basa en 8.760 horas al año y 730 horas al mes. Cada nueve adicional reduce el tiempo de inactividad permitido a una décima parte, y justo ahí empieza el trabajo que un único servidor ya no puede asumir.

Por qué tres continentes marcan tanta diferencia

Sobre el papel, tres ubicaciones independientes entre sí, cada una con un 99,9 % de disponibilidad, solo caen a la vez si las tres sufren una incidencia en el mismo momento: 0,1 % por 0,1 % por 0,1 % da 0,0000001 %. Cuanto más alejadas están las ubicaciones, más independientes son en la práctica: redes eléctricas propias, conexiones de red propias, condiciones meteorológicas propias y ventanas de mantenimiento propias. Por eso, el reparto entre Norteamérica, Europa y Asia es la forma más sólida de tolerancia a fallos que se puede construir con servidores.

Qué puede seguir fallando incluso con tres continentes

Los riesgos que quedan son las dependencias que comparten todas las ubicaciones, y para cada una existe una contramedida:

• Una actualización defectuosa la reparte el clúster a todas las ubicaciones con la misma fiabilidad que una correcta. Contramedida: health checks y rollback automático, además de actualizaciones región por región.
• El DNS es el único punto por el que pasan todos los usuarios. Contramedida: un proveedor de DNS con una red distribuida por todo el mundo y failover, y un TTL corto.
• La base de datos tiene que contener los mismos datos en todas las ubicaciones. Contramedida: replicación con conmutación automática; encontrarás los detalles en la sección sobre los datos.
• Los certificados y dominios caducados afectan a todas las ubicaciones a la vez. Contramedida: renovación automática y monitorización de las fechas de caducidad.
• La propia conmutación tarda lo que necesitan los health checks y el DNS para reaccionar, normalmente entre uno y dos minutos, durante los cuales algunas peticiones pueden fallar. Contramedida: intervalos de comprobación cortos, un TTL corto y clientes que repitan las peticiones fallidas.

La arquitectura de un vistazo

Un Docker Swarm repartido en varios continentes se compone de seis piezas. Cada una de ellas elimina un punto de fallo concreto:

¿Cuántos managers y dónde?

Los nodos manager de un Swarm gestionan el estado del clúster con el algoritmo de consenso Raft. Cada cambio necesita la aprobación de una mayoría de los managers, el llamado quórum. Si se pierde la mayoría, los contenedores existentes siguen funcionando, pero el clúster ya no puede replanificar, ni compensar fallos, ni distribuir actualizaciones.

Docker recomienda un número impar de managers repartidos en al menos tres zonas: con tres managers, en proporción 1-1-1, y con cinco, en proporción 2-2-1. De ahí se deriva la regla más importante de este artículo: dos ubicaciones no bastan. Con dos ubicaciones, una de ellas alberga forzosamente más managers que la otra, y si cae justo esa, se pierde la mayoría. Solo con tres ubicaciones el quórum sobrevive a la caída de cualquier centro de datos y, con tres continentes, por tanto, a la caída de un continente entero.

Tres continentes o uno solo: pros y contras

Cada cambio en el clúster, cada despliegue y cada replanificación de un contenedor espera la confirmación de la mayoría de los managers. Entre Europa, Norteamérica y Asia, cada una de esas confirmaciones supone un tiempo de tránsito de los paquetes de unos 80 a 250 milisegundos. Para los usuarios es irrelevante, porque sus peticiones se responden localmente; en cambio, los despliegues y las replanificaciones tardan bastante más que en un clúster con distancias cortas.

Para aplicaciones con usuarios en varios continentes y el objetivo de la máxima disponibilidad posible, la variante adecuada es la de tres continentes, y es la que montamos en la guía. Hay una regla importante que recorre todos los pasos: cada petición se responde en su región y nunca viaja de un continente a otro.

Qué ubicaciones de KernelHost son adecuadas

KernelHost opera servidores en el centro de datos maincubes de Frankfurt am Main y ofrece servidores virtuales en otras ubicaciones de Europa, Norteamérica y Asia-Pacífico, entre ellas tres ubicaciones en EE. UU., además de Canadá, Londres, Estrasburgo, Varsovia, Helsinki, Singapur, Japón, Sídney y Mumbai. La lista completa con mapa está en la página Ubicaciones de servidores. Para el ejemplo de este artículo usamos Frankfurt am Main para Europa, la costa este de EE. UU. para Norteamérica y Singapur para Asia.

Guía: montar Docker Swarm en tres continentes

El ejemplo utiliza tres servidores: swarm-eu en Frankfurt am Main, swarm-us en la costa este de EE. UU. y swarm-asia en Singapur. Las direcciones públicas proceden de la red de documentación 203.0.113.0/24, y la red WireGuard usa 10.10.0.0/24. Sustituye ambas por tus propios valores. Los tres nodos son a la vez managers y workers; si necesitas más rendimiento, más adelante puedes añadir en cada región nodos que solo actúen como workers.

Paso 1: aprovisionar servidores en tres continentes

Contrata tres servidores con Debian 12 o 13 en tres regiones y aplica el endurecimiento básico: SSH solo con clave, actualizaciones de seguridad automáticas y usuarios propios. La checklist para servidores root nuevos cubre todo esto. Asigna nombres de host descriptivos para ver de un vistazo en docker node ls dónde está cada nodo.

hostnamectl set-hostname swarm-eu

Paso 2: instalar Docker en todos los nodos

Instala Docker Engine desde el repositorio oficial de Docker en los tres servidores, tal como se describe en el artículo Instalar Docker en Debian y Ubuntu. Después, comprueba la versión en cada nodo; los tres deberían tener la misma versión principal:

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

Paso 3: crear una red WireGuard entre los continentes

Los nodos se comunican entre sí a través de la internet pública. Para que todo el tráfico del clúster vaya cifrado y los puertos de Swarm nunca sean accesibles públicamente, una red WireGuard une los tres servidores. Primero genera un par de claves en cada nodo:

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

Después, cada nodo recibe un archivo /etc/wireguard/wg0.conf. Así queda en swarm-eu; los otros dos nodos se configuran de forma simétrica:

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

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

[Peer]
PublicKey = CLAVE_PUBLICA_DE_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

Si todos los nodos responden a través de sus direcciones 10.10.0.x, la red está lista. PersistentKeepalive mantiene la conexión abierta incluso detrás de firewalls con estado. Las latencias que ping muestra ahora entre los continentes son exactamente los tiempos de espera que cuesta cada cambio en el clúster.

Paso 4: un firewall que solo deja entrar a los nodos de Swarm

Entre los nodos, Docker Swarm necesita el puerto 2377/TCP para la gestión del clúster, el 7946/TCP y UDP para la comunicación de los nodos entre sí y el 4789/UDP para la red overlay. Permite estos puertos únicamente en la interfaz de WireGuard; públicamente solo queda abierto el propio WireGuard, y únicamente para los otros nodos. Con ufw, en swarm-eu queda así:

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: los puertos que Docker publica para los contenedores se saltan ufw, porque Docker establece sus propias reglas de iptables. Por eso, publica solo los puertos del punto de entrada (80 y 443) y nunca puertos de bases de datos o de administración.

Paso 5: inicializar el Swarm y añadir los managers

En swarm-eu, inicializa el Swarm y asegúrate de que tanto la gestión como el tráfico de datos pasen por WireGuard:

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

El segundo comando muestra la instrucción de unión para más managers. Ejecútala en swarm-us y en swarm-asia, cada uno con su propia dirección WireGuard; esta es la de 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 continuación, docker node ls muestra tres nodos, uno con el estado Leader y los otros dos con Reachable. El token de unión es un secreto: quien lo conozca puede colar un manager propio en tu clúster. Una vez terminado el montaje, renuévalo con docker swarm join-token --rotate manager.

Paso 6: activar Autolock

Los managers guardan en /var/lib/docker/swarm/ el estado del clúster junto con las claves con las que se cifran los logs de Raft. Con Autolock, esas mismas claves se cifran a su vez, y un manager que se reinicia no vuelve a unirse al clúster hasta que se introduce una clave de desbloqueo:

docker swarm update --autolock=true
docker swarm unlock

El primer comando muestra la clave de desbloqueo, que debes guardar en un gestor de contraseñas. El segundo lo necesitas después de cada reinicio de un manager. Sin esa clave, el Swarm tampoco se puede restaurar desde un backup, así que guárdala separada de los servidores.

Paso 7: etiquetar los nodos por región

Las etiquetas le indican al planificador dónde está cada nodo. En ellas se basan las reglas de colocación de los pasos siguientes:

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

Paso 8: crear una red overlay con la MTU adecuada

Los contenedores de distintas ubicaciones se comunican entre sí a través de una red overlay. Como esta red pasa por el túnel de WireGuard, su MTU tiene que ser menor: WireGuard trabaja con 1420 bytes, la red overlay (VXLAN) necesita 50 de ellos para sus propias cabeceras y quedan 1370 bytes:

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

Una MTU demasiado grande se manifiesta de forma traicionera: las peticiones pequeñas funcionan, pero las respuestas grandes se quedan colgadas. Si prescindes de WireGuard, puedes cifrar la red overlay con --opt encrypted; en ese caso, entre los nodos también tiene que estar permitido el protocolo IP 50 (ESP), y Docker advierte expresamente de una pérdida de rendimiento notable. Recomendamos WireGuard porque cubre todo el tráfico, incluida la gestión.

Paso 9: ejecutar la aplicación en cada región

Un servicio de Swarm normal reparte las peticiones a través de su dirección de servicio entre todas las réplicas del clúster, es decir, también entre las de los otros continentes. Con tres continentes, una de cada dos o tres peticiones recorrería medio mundo. Por eso, cada región recibe su propio servicio, que una regla de colocación mantiene dentro de su región. Los ajustes de actualización se encargan de que las versiones nuevas se desplieguen contenedor a contenedor y se reviertan automáticamente si hay errores:

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

Para que Swarm sepa si un contenedor funciona de verdad y no solo está en marcha, la imagen debe incluir un health check, por ejemplo esta línea en el Dockerfile de tu aplicación:

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

Un contenedor cuyo health check falla tres veces seguidas se sustituye, y durante una actualización, un health check fallido detiene el despliegue.

Paso 10: un punto de entrada por región

Del punto de entrada se encarga un reverse proxy como Caddy, Traefik o nginx. También se ejecuta como servicio propio en cada región y reenvía las peticiones únicamente a la aplicación de su región. En modo host, publica los puertos 80 y 443 directamente en el servidor de su región. Basta con una configuración común, porque Caddy lee el destino de una variable de entorno:

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

Todas las regiones necesitan un certificado TLS para el mismo dominio. Por eso, obtén los certificados mediante el desafío DNS, que funciona con independencia de la región a la que apunte en ese momento el registro DNS; para ello, Caddy necesita el módulo de tu proveedor de DNS. Los fundamentos del proxy están en el artículo Configurar nginx como reverse proxy.

Paso 11: configurar Geo-DNS con failover

La última pieza lleva a los usuarios a la región correcta. Un servicio DNS con enrutamiento geográfico y health checks envía a los usuarios de Europa a Frankfurt am Main, a los de América a la costa este de EE. UU. y a los de Asia a Singapur. Si una región cae, el health check lo detecta en un plazo de 30 a 60 segundos y envía a sus usuarios a la región en buen estado más cercana. Fija el tiempo de vida (TTL) de los registros en 60 segundos para que los resolvers adopten rápidamente un cambio. Varios registros A sin health check son solo una solución de emergencia: es cierto que los navegadores suelen probar la siguiente dirección, pero no todos los clientes lo hacen, y una región caída sigue apareciendo en la respuesta.

Sé realista con las cuentas: entre la caída y el cambio transcurren el intervalo de comprobación más el TTL, es decir, en el ejemplo, entre uno y dos minutos, durante los cuales parte de los usuarios de la región afectada sigue llegando a la ubicación caída. Las aplicaciones y las apps que repiten las peticiones fallidas tras una breve pausa salvan ese intervalo casi sin que se note.

Paso 12: probar la caída de una región

Un failover que nunca se ha ensayado rara vez funciona cuando llega el momento de la verdad. Simula la caída de una región retirando su nodo del servicio y observa cómo reaccionan el clúster y el DNS:

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

Como una regla de colocación vincula los servicios de la región a su nodo, no se trasladan a otro, sino que quedan en pausa; de los usuarios de la región se encarga el failover de DNS. Por eso, en este ensayo fíjate sobre todo en si el health check retira la región de las respuestas y si la región vecina soporta la carga adicional. Para una prueba más exigente, desconecta el nodo por completo de la red, por ejemplo deteniendo WireGuard. Repite la prueba después de cambios importantes y, como mínimo, una vez por trimestre.

Datos: la parte más difícil de la alta disponibilidad

Docker Swarm replica contenedores, no datos. Un volumen está siempre en el nodo en el que se ejecuta el contenedor. Por eso, los servicios sin estado, como los frontends web y las API, se pueden ejecutar sin problemas en cada región, pero para todo lo que maneje datos necesitas una replicación propia.

Replicar bases de datos entre continentes

Las bases de datos incluyen su propia replicación, y siempre es preferible a un almacenamiento compartido entre centros de datos. Entre continentes ha demostrado su eficacia una instancia primaria en una región con réplicas asíncronas en las otras dos: en PostgreSQL, por ejemplo, mediante streaming replication con una herramienta como Patroni para la conmutación automática, y en MariaDB y MySQL, con la replicación integrada. Así, cada región responde localmente a las consultas de lectura, y las escrituras van a la instancia primaria. Siendo sinceros, asíncrona también significa que, si cae la región primaria, pueden perderse los últimos segundos de escrituras. Quien quiera escribir en todo el mundo sin perder nada recurre a bases de datos diseñadas para varias regiones, como CockroachDB o YugabyteDB. Vincula los nodos de la base de datos a su región con una regla de colocación, para que Swarm nunca los mueva sin sus datos:

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

Archivos y subidas

Los archivos subidos no deben ir a un volumen local, sino a un almacenamiento de objetos compatible con S3 con replicación en una segunda región, o a un sistema de almacenamiento propio y replicado. Los sistemas de archivos en red como NFS entre continentes son lentos y son en sí mismos un punto único de fallo.

Sesiones y cachés

Si la aplicación guarda las sesiones en la memoria de un contenedor, los usuarios pierden su inicio de sesión cuando se produce la conmutación. Guarda las sesiones en una base de datos replicada o en una caché replicada como Redis, o utiliza tokens firmados que cada región pueda verificar por sí misma.

Los backups siguen siendo obligatorios

La replicación protege frente a la caída de una ubicación, pero no frente a los errores: un registro borrado por descuido desaparece segundos después en todas las regiones. Por eso, toda arquitectura de alta disponibilidad necesita backups periódicos y probados en un lugar independiente, tal como se describe en el artículo Estrategia de backup para servidores.

Operación: actualizaciones, mantenimiento y monitorización

Actualizaciones región por región

No despliegues las versiones nuevas en todas las regiones a la vez, sino una tras otra, y observa cada región un rato antes de pasar a la siguiente. Así, un error que ningún health check detecta llega como mucho a una región, y las otras dos siguen atendiendo a los usuarios de esa región:

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

Si una actualización falla, Swarm la revierte automáticamente gracias a los ajustes del paso 9, y || break termina el bucle en cuanto el comando devuelve un error. Si el fallo de una actualización solo se nota más tarde, la reviertes a mano con docker service rollback web-asia.

Mantenimiento de una región

Si hay que reiniciar o actualizar un servidor, sácalo de servicio con docker node update --availability drain y deja que el failover de DNS desvíe antes a sus usuarios a las regiones vecinas. Después del mantenimiento, vuelve a incorporarlo con --availability active. Antes de pasar al siguiente manager, espera hasta que docker node ls vuelva a mostrar los tres como accesibles, para que nunca falten dos managers a la vez.

Monitorización desde fuera

Monitoriza cada región por separado y desde fuera del clúster: la accesibilidad de los puntos de entrada, los health checks de los servicios, el estado de los managers, el retraso de replicación de la base de datos y las fechas de caducidad de certificados y dominios. Una alerta tiene que llegar incluso cuando una región entera deja de dar señales. El artículo Configurar la monitorización del servidor muestra cómo montarlo para servidores individuales.

Distribuir los secretos de forma segura

Las contraseñas y las claves no deben ir en variables de entorno ni en archivos de Compose, sino en Docker Secrets. Se guardan cifrados en el log de Raft y solo se entregan a los servicios a los que se los asignes expresamente:

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

Por qué KernelHost para un Swarm en varios continentes

Un clúster repartido en varios continentes plantea al proveedor exigencias distintas de las de un único servidor. En la práctica, estos son los puntos decisivos:

En la página Alquilar un servidor cloud encontrarás un resumen de todos los planes cloud con sus precios y una comparativa de costes con los grandes proveedores cloud.

Errores frecuentes y cómo evitarlos

• Managers en solo dos ubicaciones. Si cae la ubicación que tiene la mayoría, el clúster se paraliza. Solución: tres ubicaciones, con un reparto 1-1-1 o 2-2-1.
• Número par de managers. Cuatro managers no toleran más fallos que tres, pero aumentan el esfuerzo de coordinación. Solución: 3, 5 o 7.
• Peticiones que viajan entre continentes. Una dirección de servicio común a todas las regiones hace que los usuarios crucen medio mundo. Solución: un servicio y un punto de entrada por región.
• Puertos de Swarm accesibles públicamente. El puerto 2377 y la red overlay nunca deben quedar expuestos a internet. Solución: solo a través de WireGuard; públicamente, solo 80, 443 y WireGuard para los otros nodos.
• Olvidarse de la MTU. Las respuestas grandes se quedan colgadas y las pequeñas funcionan. Solución: MTU de 1370 en la red overlay con WireGuard a 1420.
• Confiar en ufw para los puertos de los contenedores. Docker se salta ufw en los puertos publicados. Solución: publicar solo el punto de entrada.
• Base de datos en un volumen sin replicación. Si la región cae, los datos no están accesibles. Solución: replicación de la base de datos y colocación fija en su región.
• Actualizar todas las regiones a la vez. En ese caso, un error afecta a todos los usuarios del mundo. Solución: desplegar región por región.
• TTL de DNS alto. Con un TTL de un día, el failover no surte efecto hasta el día siguiente. Solución: 60 segundos.
• Replicación en lugar de backup. Un error se replica igual que los datos correctos. Solución: además, backups probados en un lugar independiente.

En resumen

• Un Docker Swarm repartido en tres continentes está diseñado para un 100 % de uptime: puede caer una ubicación o un continente entero sin que la aplicación se detenga.
• Nadie puede garantizar una disponibilidad absoluta; los riesgos que quedan son el DNS, las actualizaciones defectuosas, la base de datos y los certificados, y para cada uno existe una contramedida.
• Tres managers en tres ubicaciones son el mínimo; dos ubicaciones no bastan para un quórum tolerante a fallos.
• Cada petición se queda en su región: un servicio y un punto de entrada por región, más Geo-DNS con health checks y un TTL corto.
• WireGuard cifra el tráfico del clúster, los puertos de Swarm quedan invisibles y la MTU de la red overlay baja a 1370.
• Swarm replica contenedores, no datos: las bases de datos necesitan su propia replicación y los backups siguen siendo obligatorios.
• KernelHost ofrece ubicaciones en Europa, Norteamérica y Asia-Pacífico, tráfico ilimitado, protección DDoS en cada ubicación y facturación PrePaid sin permanencia mínima.