Edge: agentes y stacks

Hasta ahora el Server se conectaba a cada agent. Pero, ¿qué pasa con hosts a los que no podés llegar: una sucursal detrás de NAT, un dispositivo IoT en una red doméstica, un servidor sin IP pública? Para eso existe Portainer Edge.

El modelo invertido: túnel saliente

La diferencia clave del Edge Agent es la dirección de la conexión:

flowchart LR
    subgraph remoto["Red remota (NAT / firewall)"]
        EA["Edge Agent"]
    end
    EA -->|"túnel saliente HTTPS<br/>iniciado por el agent"| S["Portainer Server<br/>(IP pública, puerto 8000)"]

En vez de que el Server inicie la conexión (lo que exigiría abrir puertos entrantes en cada sitio remoto), el Edge Agent inicia un túnel saliente hacia el Server. Solo necesitás que el Server sea alcanzable; los hosts remotos no exponen nada. Por eso se publicó el puerto 8000 en la instalación: es el endpoint del túnel Edge.

Dar de alta un entorno Edge

Environments → Add environment → Edge Agent (Standard o Async). Portainer genera un comando de despliegue con dos datos incrustados:

• La URL del Server (a dónde conectar el túnel).
• Una Edge key única que identifica y autoriza a ese agent.

Copiás ese comando y lo corrés en el host remoto (como contenedor Docker, servicio Swarm o en K8s). El agent abre el túnel y el entorno aparece “online” en el Server.

Standard vs Async

• Edge Standard: túnel persistente; interactuás casi en tiempo real (consola, logs en vivo).
• Edge Async: el agent sondea al Server cada cierto intervalo en vez de mantener un túnel permanente. Ideal para flotas enormes o conectividad intermitente (retail, IoT con datos móviles), porque reduce conexiones simultáneas y tolera caídas de red.

Edge Groups

Gestionar cientos de dispositivos uno por uno no escala. Los Edge Groups agrupan entornos Edge:

• Estáticos: elegís manualmente qué entornos pertenecen.
• Dinámicos: defines reglas por tags (ej. todos los que tengan region:norte + tipo:kiosco). Cuando un nuevo dispositivo se da de alta con esos tags, entra automáticamente al grupo.

Los grupos son la base del despliegue masivo.

Edge Stacks

Un Edge Stack despliega un Compose sobre uno o varios Edge Groups a la vez. Definís el stack una vez, elegís los grupos destino y Portainer lo propaga a todos los dispositivos de esos grupos.

Caso de uso típico: 300 tiendas, cada una con un mini-host. Definís el Edge Stack de la app de punto de venta, lo asignás al Edge Group tiendas, y se despliega en las 300. Cuando abrís una tienda nueva y su host se registra con el tag correcto, recibe el stack automáticamente.

Edge Jobs

Un Edge Job ejecuta un script (un comando shell) en los dispositivos de uno o varios Edge Groups, una vez o de forma recurrente (cron). Sirve para tareas de mantenimiento de flota: recolectar un log, limpiar disco, aplicar un parche puntual.

Por qué Edge importa

flowchart TD
    S["1 Portainer Server"] --> G["Edge Groups (por tags)"]
    G --> ES["Edge Stacks → despliegue masivo"]
    G --> EJ["Edge Jobs → mantenimiento de flota"]
    G --> D1["dispositivo 1"]
    G --> D2["dispositivo ..."]
    G --> D3["dispositivo N"]

Edge es lo que lleva a Portainer de “administro unos servidores” a “gobierno una flota distribuida desde un panel”, sin abrir puertos entrantes en cada sitio. Es el escenario donde Portainer se diferencia con más fuerza.

---

Anterior → Capítulo 10: Kubernetes · Siguiente → Capítulo 12: Usuarios, equipos y RBAC