Docker Swarm y Portainer Edge para despliegues en el edge

Informatec Digital » Recursos » Docker Swarm y Portainer Edge para despliegues en el edge

Cuando empiezas a jugar con Docker Swarm, Portainer y despliegues en el edge es fácil hacerse un lío: agentes, Edge Agents, routing mesh, redes overlay, latencias entre VPS en distintas ciudades… todo suena genial, pero a la hora de montarlo quieres algo claro, estable y que no te obligue a abrir medio firewall.

En las siguientes líneas vas a encontrar una explicación detallada y en castellano “de la calle” de cómo encaja todo esto: qué aporta Docker Swarm, cómo funciona el routing mesh, qué papel juegan el Portainer Agent y el Edge Agent (en modo estándar y asíncrono), cómo gestionar entornos distribuidos (por ejemplo, un VPS en Nueva York y otro en Seattle), y cómo aprovechar Docker en el edge, incluso con WebAssembly (Wasm) para dispositivos más limitados.

Conceptos básicos: Docker Swarm, edge computing y Portainer

Antes de ponernos a toquetear comandos, conviene tener claros algunos conceptos fundamentales que se repiten en cualquier arquitectura Docker Swarm edge: Swarm como orquestador, el papel del edge computing y por qué Portainer facilita tanto la vida.

Docker Swarm es el modo de clúster nativo de Docker que te permite juntar varios Docker Engine (por ejemplo, varias VMs o VPS) y gestionarlos como si fueran un único host virtual. A nivel práctico, esto significa que puedes desplegar servicios replicados, usar redes overlay entre nodos, balancear tráfico y aprovechar alta disponibilidad de forma bastante sencilla.

Por otro lado, el edge computing consiste en acercar el procesamiento de datos al lugar donde se generan (sensores, dispositivos IoT, pequeñas máquinas en fábrica, routers, gateways, etc.). Con esto cortas latencias, ahorras ancho de banda hacia la nube y ganas capacidad de operar incluso con conectividad limitada o intermitente. Aquí Docker encaja bien en dispositivos medianamente potentes, pero en hardware muy limitado —por ejemplo, cuando usamos una distribución Linux inmutable— empieza a sufrir.

Ahí entra en juego Portainer, una plataforma ligera que ofrece una interfaz web y una API para gestionar entornos Docker, Swarm, Kubernetes o ACI. Portainer te permite manejar contenedores, imágenes, redes, volúmenes y demás recursos de forma cómoda, ya sea en un único host o en decenas de nodos remotos.

Para conectar estos entornos remotos a tu Portainer Server, dispones de varias opciones: Portainer Agent clásico, conexión directa al Docker API/socket y Portainer Edge Agent en modo estándar o asíncrono. Escoger bien la opción marca la diferencia entre un montaje limpio y uno lleno de agujeros de seguridad y puertos abiertos.

Docker Swarm: puertos, routing mesh y publicación de servicios

Cuando activas Swarm mode en Docker, todos los nodos del clúster participan en lo que se conoce como ingress routing mesh. Dicho en cristiano: cualquier nodo del clúster puede recibir tráfico en los puertos publicados de un servicio, aunque en ese nodo concreto no haya ninguna tarea de ese servicio corriendo.

Para que todo esto funcione, hay que tener ciertos puertos abiertos entre los nodos del Swarm. En concreto, el plano de red de Swarm utiliza:

• Puerto 7946 TCP/UDP para el descubrimiento de red de contenedores.
• Puerto 4789 UDP (configurable) para el tráfico de la red de ingreso (ingress) basada en VXLAN.

Además, los puertos que publiques para tus servicios deben estar accesibles desde los recursos externos que vayan a consumirlos: balanceadores externos, otros sistemas, usuarios finales, etc. Ese tráfico entrará por cualquier nodo y el routing mesh se encargará de redirigirlo a un contenedor activo del servicio.

Para publicar puertos en Swarm, se utiliza la opción –publish al crear o actualizar un servicio. El parámetro target indica el puerto interno del contenedor, mientras que published define el puerto expuesto en el routing mesh. Si te saltas el puerto publicado, Docker asigna uno alto aleatorio por cada tarea, y luego toca inspeccionar los tasks para saber cuál se ha usado.

El puerto publicado (<PUBLISHED-PORT>) es donde el Swarm expone el servicio al exterior, mientras que el puerto de contenedor (<CONTAINER-PORT>) es donde escucha el proceso dentro del contenedor. Si, por ejemplo, publicas el 8080 externo apuntando al 80 interno de un Nginx, pedir a cualquier nodo por el 8080 hará que Swarm enrute la petición a uno de los contenedores activos sin que tengas que preocuparte por dónde está corriendo realmente.

El routing mesh escucha en la IP del nodo y en el puerto publicado. Si la IP es enrutable externamente, el servicio será accesible desde fuera del host; si es una IP sólo interna, el acceso se limitará al propio host o a su red privada. Puedes usar docker service inspect para ver en cualquier momento la relación entre los puertos objetivo (TargetPort) y los publicados (PublishedPort).

Publicar puertos TCP y/o UDP y usar modo host

Por defecto, cuando publicas un puerto en Swarm se asume protocolo TCP. Si quieres publicar puertos UDP, o combinar TCP y UDP, debes usar la sintaxis larga del --publish y ajustar la clave protocol a tcp o udp. Si publicas ambos y omites el protocolo, se publica como TCP.

También puedes saltarte el routing mesh para un servicio concreto usando el llamado host mode. En este modo, cuando accedes a un puerto en un nodo, llegas únicamente a la instancia del servicio que corre en ese nodo, si es que hay una. Para conseguirlo, usas la sintaxis larga de --publish y estableces mode=host. Si no especificas nada o dejas mode=ingress, se utilizará el mesh.

Con el modo host hay que tener un par de cosas claras para no llevarse sustos: si entras a un nodo donde no hay ninguna tarea del servicio, ese puerto puede estar sin nadie escuchando o ocupado por otra aplicación; y si esperas correr varias réplicas por nodo, no podrás usar un puerto estático sin conflictos, salvo que dejes que Docker asigne puertos aleatorios o limites a una única réplica por nodo mediante servicios globales o constraints.

En arquitecturas más grandes es frecuente combinar Swarm con un balanceador de carga externo como HAProxy o similares. Puedes hacerlo tanto aprovechando el routing mesh como usando DNSRR (sin VIP) y balanceando directamente hacia las IPs de las tareas, según lo que te convenga a nivel de tráfico y observabilidad.

Gestión remota con Portainer: Agent vs Edge Agent

Portainer ofrece varias formas de conectar entornos Docker o Swarm remotos a tu Portainer Server, y aquí es donde mucha gente se lía. Las tres opciones principales son: usar Portainer Agent, conectar directamente al Docker API/socket o desplegar el Portainer Edge Agent (modo estándar o async).

El Portainer Agent clásico está pensado para entornos donde el Portainer Server y los hosts gestionados están en la misma red o, al menos, se pueden comunicar de forma directa. En este escenario, el servidor se conecta al agente, por lo que necesitas abrir puertos desde el servidor hacia los nodos con Agent, lo cual no siempre es deseable cuando hablamos de VPS repartidos por varios datacenters o redes caseras detrás de NAT.

La alternativa más segura y flexible en entornos distribuidos es Portainer Edge Agent. Aquí el flujo se invierte: es el Edge Agent en el host remoto el que establece la conexión hacia el Portainer Server. En vez de mantener una conexión entrante abierta, el Edge Agent hace polling periódico al servidor para ver si hay trabajos pendientes y actúa en consecuencia.

Para que el Edge Agent funcione, en el Portainer Server tienes que exponer, como mínimo, el puerto de la interfaz web (UI), normalmente 9443 o un NodePort como 30779 en Kubernetes. Además, en modo estándar, necesitas también el puerto de túnel (8000 o 30776 en Kubernetes con NodePort). Este túnel crea una conexión TLS segura entre el Edge Agent y el servidor, permitiendo la interacción en tiempo real con el entorno remoto.

Las guías de instalación oficiales de Portainer ya configuran el servidor para escuchar en ambos puertos, pero tú tendrás que asegurarte de que el firewall de tu entorno expone esos puertos al exterior. Portainer asume además que cumples ciertos requisitos mínimos de sistema; si te sales mucho del guion, puede que necesites ajustes adicionales o que alguna funcionalidad quede limitada.

Edge Agent en modo estándar en un clúster Docker Swarm

Si quieres gestionar un entorno Docker Swarm remoto con Edge Agent estándar, el flujo en Portainer suele ser algo como esto: desde el menú de Portainer, abres la sección de entornos (Environment-related → Environments) y pulsas en “Add environment”. Ahí eliges “Docker Swarm” y arrancas el asistente (Start Wizard).

Dentro del asistente seleccionas la opción Edge Agent Standard y rellenas los datos del entorno: nombre descriptivo, URL a la que el agente se conectará, opciones de grupo o etiquetas, etc. En el apartado de “More settings” puedes ajustar la frecuencia de sondeo (Poll frequency), que marca cada cuánto el Edge Agent comprueba si hay nuevas tareas o cambios. Por defecto suele ser cada 5 segundos, pero puedes modificarlo si quieres reducir tráfico o mejorar reactividad.

Una vez completados los campos básicos, haces clic en “Create”. Si estás pre-etiquetando entornos o preparando scripts de automatización, puedes obtener el token de unión (join token) en este momento para reutilizarlo en tus despliegues. Después Portainer mostrará los campos adicionales que necesitas para generar el comando de instalación.

El siguiente paso es escoger la plataforma del host remoto (Linux o Windows), copiar el comando que Portainer genera y ejecutarlo en el entorno Edge. Ese comando se encarga de bajar la imagen del Edge Agent y configurarla con el token y la URL adecuados. Cuando arranca, el nuevo entorno aparece en la pantalla principal de Portainer como un nodo más.

Si tienes que desplegar otro entorno Edge estándar similar, puedes usar “Add another environment” y repetir el proceso. Cuando termines con todos los Edge, simplemente pulsas “Continue” para seguir con la configuración de otros entornos o “Close” para volver al listado general.

Edge Agent en modo async y conexiones de baja calidad

El modo async del Portainer Edge Agent está pensado para escenarios donde la conectividad es limitada, cara o muy inestable (enlaces móviles (conectividad 5G M2M), conexiones rurales, dispositivos que se conectan sólo de vez en cuando, etc.). En este modo no se establece un túnel interactivo en tiempo real; en su lugar, el Edge Agent envía capturas de estado (snapshots) al Portainer Server a intervalos configurables.

Con async no puedes abrir sesiones interactivas contra el entorno remoto, pero sí puedes ver el estado reciente del clúster y lanzar acciones basadas en ese snapshot. El consumo de datos es mucho menor, lo que lo hace ideal para despliegues edge donde cada megabyte cuenta.

En modo async, el Edge Agent sólo necesita que el servidor tenga abierto el puerto de UI (9443 o el NodePort equivalente). El puerto de túnel 8000 ya no es necesario, lo que simplifica aún más la exposición de puertos públicos. La configuración del entorno en Portainer es muy parecida al modo estándar, solo que escoges “Edge Agent Async” en el asistente para entornos Docker Swarm.

A la hora de añadir un Edge async, desde Environments → Add environment eliges “Docker Swarm”, arrancas el asistente, seleccionas “Edge Agent Async” y completas los datos básicos. En “More settings” tienes tres intervalos importantes: Ping, Snapshot y Command, que controlan la frecuencia de latido, la actualización de la foto del entorno y la comprobación de nuevos comandos, respectivamente. Por defecto todo va a un minuto, pero puedes variar según necesidades.

Igual que en el modo estándar, puedes usar grupos y etiquetas para clasificar entornos Edge, crear el entorno, obtener el join token y, una vez generado el comando para tu plataforma (Linux o Windows), ejecutarlo en el host remoto. Cada agente async se registrará y Portainer podrá mostrarte su estado basado en el último snapshot recibido.

Escenario típico: dos VPS en distintas regiones y uso de Portainer

Un caso bastante habitual es el de alguien que tiene dos VPS en ubicaciones diferentes (por ejemplo, uno en Nueva York y otro en Seattle) y quiere gestionarlos con Portainer, usando Docker Swarm o no, y montando cosas como Prometheus, cAdvisor y Node Exporter con tráfico interno privado entre nodos.

En un escenario así, te planteas si usar sólo Swarm es suficiente o si necesitas además un Portainer Agent o un Edge Agent en cada VPS. Docker Swarm por sí mismo te da orquestación y redes overlay entre nodos, lo cual te permite, por ejemplo, que un Prometheus en el VPS de Nueva York recoja métricas de contenedores que están en Seattle a través de una red overlay cifrada.

Portainer, en este contexto, no es obligatorio pero sí muy conveniente para centralizar la gestión de servicios, stacks, volúmenes y redes. Si montas Portainer Server en uno de los VPS (por ejemplo, NY), puedes conectar el VPS de Seattle con un Edge Agent. De ese modo no necesitas abrir la API de Docker ni mantener puertos de agentes clásicos accesibles desde fuera.

En cuanto a la latencia entre nodos Swarm en distintas ciudades, lo normal es que esté en decenas de milisegundos, lo que en la mayoría de casos no es un problema serio para servicios como Prometheus, Node Exporter o cAdvisor, que hacen scrapes periódicos. Eso sí, hay que tenerlo en cuenta si vas a hacer servicios extremadamente sensibles a la latencia o a la consistencia entre nodos.

Resumiendo este tipo de montaje, lo habitual y más práctico es: usar Docker Swarm para el clúster y redes overlay entre los VPS, y usar Portainer Edge Agent (mejor que el Agent normal) para gestionar los VPS remotos de forma segura sin abrir más puertos de la cuenta. El Agent clásico tiene sentido cuando todo está en la misma red o con conectividad muy directa; en escenarios geográficamente distribuidos el Edge Agent es la opción lógica.

Edge Jobs en Portainer sobre Docker Swarm

Otra funcionalidad potente cuando trabajas con Portainer y entornos Swarm son los Edge Jobs. Estos trabajos te permiten definir tareas que se ejecutarán en tus entornos Edge gestionados por Portainer, algo muy útil para mantenimiento, reconfiguración o despliegues periódicos.

Una pregunta recurrente es si se puede forzar a que un Edge Job corra en un nodo concreto del clúster Swarm. En muchos casos, el job parece ejecutarse siempre en uno de los nodos y no tienes control evidente de a cuál le toca, lo que puede resultar confuso si esperas un comportamiento equilibrado o quieres apuntar a un nodo específico.

La clave para controlar esto está en entender cómo Portainer distribuye los jobs y cómo Swarm gestiona la colocación de tareas. Dependiendo de si el job se lanza como contenedor suelto en un nodo gestionado por Edge Agent o como servicio dentro del clúster Swarm, tendrás más o menos control mediante constraints o configuración del propio Edge Job.

Aunque la experiencia out-of-the-box puede dar la impresión de que el nodo se elige al azar, se puede jugar con etiquetas de nodos, grupos y reglas de asignación para orientar mejor dónde se ejecuta cada trabajo. Es un punto donde conviene revisar con lupa la documentación de Portainer y hacer pruebas controladas hasta tener claro el patrón de scheduling.

Portainer en casa: Edge Agent para controlar dispositivos como Raspberry Pi

Cuando hablamos de usar Portainer para gestionar dispositivos domésticos o pequeños hosts como Raspberry Pi, el enfoque cambia un poco. Aquí es muy frecuente que los Docker hosts estén detrás de NAT, en redes caseras y sin IP pública directa, lo que hace incómodo y peligroso exponer la API de Docker o el Agent clásico hacia Internet.

En este contexto muchos usuarios optan por el Portainer Edge Agent en modo estándar para controlar sus Raspberry u otros dispositivos. De esta manera, no es necesario modificar la configuración de Docker para habilitar la API TCP ni abrir sockets expuestos. El Edge Agent, recordemos, es quien abre la conexión hacia el servidor, atravesando NAT sin que tú tengas que pelearte con redirecciones de puertos. Además es habitual usar estos dispositivos para proyectos de visión embebida con OpenMV y otros usos edge.

El Portainer Agent clásico obliga a que el Portainer Server se pueda conectar directamente a los agentes, algo que en una red doméstica con CG-NAT o routers “de operadora” no siempre es viable. Además, implica abrir puertos desde fuera hacia tu red doméstica, lo cual no suele ser lo más recomendable en términos de seguridad si no tienes una buena estrategia de protección.

Con Edge Agent, en cambio, sólo necesitas que el servidor tenga el puerto de UI (y, en modo estándar, el de túnel) accesible desde Internet o desde la red donde estén tus dispositivos. Una vez los Edge Agents se conectan, en la vista principal (“Home”) de Portainer ves cada dispositivo como un entorno independiente, y puedes aprovechar grupos y etiquetas para organizar decenas de Raspberry o dispositivos edge sin volverte loco.

Modo async frente a modo estándar en entornos edge

Una decisión importante cuando eliges Portainer Edge Agent es si trabajar en modo estándar o en modo async. El estándar ofrece una experiencia muy parecida a tener el host “casi local”: puedes abrir una sesión de consola en contenedores, ver logs en directo, desplegar stacks de manera interactiva, etc.

El modo async, en cambio, sacrifica esa interactividad para minimizar el consumo de ancho de banda y tolerar mejor conexiones erráticas. En entornos donde sólo quieres revisar el estado de vez en cuando, lanzar jobs puntuales y ahorrar datos, async es la opción inteligente. En ambos casos, Portainer te sigue permitiendo categorizar y gestionar tus entornos por grupos y etiquetas.

En términos de puertos abiertos, el modo estándar requiere tanto el puerto de UI como el de túnel, mientras que en async te bastas con el de UI. Si vas justo de seguridad o quieres minimizar la superficie expuesta, async simplifica bastante el esquema, a costa de perder el túnel TLS interactivo.

Docker y WebAssembly (Wasm) para workloads en el edge

Cuando bajamos al terreno del edge computing en dispositivos muy limitados (ARM pequeños, gateways con poca RAM, etc.), incluso los contenedores tradicionales pueden quedarse algo pesados. Aquí entra en juego WebAssembly (Wasm), que ya se integra con Docker de forma nativa a través de runtimes como WasmEdge o Wasmtime.

Las ventajas de Wasm para el edge son claras: binarios muy pequeños, arranques casi instantáneos y fuerte aislamiento basado en capacidades. Además, la portabilidad entre arquitecturas (x86, ARM, RISC-V…) es muy alta, porque el binario Wasm se ejecuta sobre el runtime, no directamente sobre el sistema operativo.

Para usar Wasm con Docker en el edge, necesitas una versión de Docker que soporte runtimes Wasm: Docker Desktop a partir de la 4.15 o Docker Engine con containerd 1.7 o superior suelen cumplir. Es clave activar en daemon.json el almacén de imágenes de containerd y declarar los runtimes Wasm correspondientes (por ejemplo, io.containerd.wasmedge.v1 o io.containerd.wasmtime.v1), y reiniciar después el daemon de Docker.

Un ejemplo típico es un pequeño servicio de procesado de datos de sensores escrito en Rust y compilado a Wasm (target wasm32-wasi). Este programa puede leer datos en JSON línea a línea, filtrar lecturas que superen ciertos umbrales de temperatura o humedad y emitir alertas también en JSON, todo con un consumo de recursos ridículo.

Una vez compilado a WebAssembly, puedes usar un Dockerfile minimalista basado en scratch, copiando únicamente el binario .wasm y declarándolo como ENTRYPOINT. Al crear la imagen con docker buildx para la plataforma wasi/wasm y cargarla localmente, verás cómo el tamaño resultante es de apenas unos megas frente a imágenes de Python o Node que llegan fácilmente al giga.

Despliegue de Wasm en el edge con Docker y Compose

En arquitecturas edge reales suele haber varios servicios por dispositivo: procesadores de sensores en Wasm, brokers MQTT para la comunicación, bases de datos de series temporales, proxies inversos ligeros, etc. Docker Compose encaja de maravilla para agrupar todo esto en un solo archivo.

Un ejemplo de nodo edge podría tener un servicio Wasm para procesar lecturas (usando el runtime Wasm correspondiente), un broker Eclipse Mosquitto para recibir datos de sensores, una base de datos TimescaleDB/PostgreSQL para almacenar series, y un Caddy como proxy inverso para exponer APIs o dashboards. Cada servicio con sus puertos, volúmenes y políticas de reinicio siempre activas.

Para facilitar la distribución, es frecuente montar un registro Docker local en el propio gateway edge, típicamente en el puerto 5000. Paquetas tu imagen Wasm, la etiquetas hacia localhost:5000/... y la empujas al registro. Desde otros nodos edge cercanos puedes tirar de ese registro local, reduciendo latencia y consumo hacia registros remotos.

En ejecutores muy limitados conviene además fijar restricciones duras de recursos: memoria máxima (por ejemplo, 32 MB) y límites de CPU (0.5 cores, etc.), aun sabiendo que Wasm ya de por sí consume poco. Esto evita que un bug o un pico de carga deje tieso el dispositivo y te obliga a reiniciar manualmente.

Redes, Swarm y tolerancia a desconexiones en el edge

En el edge las redes suelen ser menos fiables que en un datacenter: cortes frecuentes, cambios de IP, enlaces móviles, etc. Por ese motivo es habitual crear redes bridge dedicadas en cada nodo con subredes personalizadas, o incluso construir Swarms multi-sitio enlazados mediante VPNs o túneles seguros.

Con Docker puedes crear redes bridge aisladas con su propio nombre de bridge en el host (por ejemplo, edge-br0), y después asociar tus servicios a esa red para lograr mayor separación del resto del tráfico. Si das un paso más y montas Docker Swarm en el gateway edge, puedes tirar de redes overlay para conectar contenedores entre varios nodos usando el mecanismo de cluster-store y cluster-advertise (normalmente sobre Consul u otro backend).

Para escenarios multi-host con Swarm, Docker Machine sigue siendo una herramienta útil, como demuestran algunos despliegues con OpenNebula. En ese caso, puedes usar docker-machine con un driver de OpenNebula para levantar VMs con boot2docker, montar un Consul para discovery, crear el Swarm master y los nodos, y terminar uniendo todo con redes overlay.

La idea es sencilla: primero creas una VM para Consul, la arrancas con el contenedor correspondiente en el puerto 8500, obtienes su IP y luego usas esa IP en los comandos de docker-machine create con las opciones –swarm y –swarm-discovery. Con cluster-store y cluster-advertise configurados, puedes después crear una red overlay y lanzar servicios (por ejemplo, un Nginx en un nodo y un BusyBox en otro) que se ven entre sí usando nombres de servicio.

En entornos edge que sufren desconexiones frecuentes, conviene habilitar persistencia local mediante volúmenes o bind mounts para almacenar datos en disco cuando se pierde la conectividad (ciber-resiliencia del dato). Así, tus contenedores pueden acumular datos (por ejemplo, lecturas de sensores) y enviarlos en bloque cuando la conexión vuelve, siguiendo un patrón de “store-and-forward”.

A nivel de monitorización, Docker ofrece un comando sencillo como docker stats para obtener métricas básicas de CPU, memoria y tráfico de red. Para despliegues más serios es habitual usar agentes ligeros como Node Exporter junto con Prometheus, incluso definidos en un docker-compose separado de “monitoring”, que exponen métricas del host al ecosistema de observabilidad central.

Actualizar estos despliegues edge también se vuelve más cómodo con Docker: haces pull de la nueva imagen, paras el contenedor antiguo, lo eliminas y vuelves a levantar el servicio con la versión nueva. Y, como los contenedores Wasm arrancan en milisegundos, la ventana de indisponibilidad es mínima, algo muy valioso cuando el edge está recogiendo datos en tiempo real.

Con todo este panorama, se entiende mejor cómo encajan las piezas: Docker Swarm aporta orquestación y redes overlay, Portainer Edge Agent simplifica la gestión remota sin abrir puertos peligrosos, y Wasm reduce el coste de ejecutar aplicaciones en hardware ajustado. Con una planificación adecuada de puertos, redes y modos de agente (estándar o async), puedes construir arquitecturas edge robustas, distribuidas entre distintas ubicaciones y listas para crecer sin volverte loco con la administración diaria.