Docker en un router industrial o en un Edge Gateway independiente: cuándo alojar juntos y cuándo separar

Empecemos con una situación real en una planta. Ya hay un router industrial instalado en el armario y ahora hace falta ejecutar un programa de conversión de protocolos. Como el router admite Docker, colocar allí el contenedor parece una opción eficiente: un equipo menos, una conexión eléctrica menos y menos cableado. La respuesta cambia rápidamente si la carga es una base de datos local, un análisis de vídeo o una aplicación que escribe registros de forma continua. La pregunta real no es solo si el contenedor puede iniciarse. También hay que saber si un proceso saturado, un disco lleno o una actualización fallida podría llevarse consigo la conectividad de toda la planta.

Puntos clave

El alojamiento conjunto suele ser razonable cuando los límites de recursos del contenedor están claros, las escrituras son limitadas, los permisos pueden reducirse y el ciclo de mantenimiento puede seguir al del router. Un Edge Gateway independiente es la opción más segura cuando la aplicación consume CPU o memoria de forma continua, almacena muchos datos locales, necesita privilegios elevados sobre el host o debe poder fallar mientras la red sigue disponible. El orden de decisión importa: primero hay que proteger el enrutamiento, los túneles cifrados, el firewall y la gestión remota; después se asignan al contenedor los recursos restantes; por último, se valida la decisión con pruebas de reinicio, pérdida de alimentación, interrupción de la conexión ascendente y vuelta atrás de una versión defectuosa.

---

No empieces por Docker: empieza por la carga de trabajo

Los contenedores pueden dar la impresión de que el despliegue está casi terminado cuando la imagen se descarga y el proceso se inicia. En realidad, ese es solo el punto de entrada.

Hay dos capas que se confunden con facilidad. La imagen define cómo se empaqueta una aplicación y cómo se lleva al equipo; el runtime define cómo se ejecuta realmente. La OCI Image Specification y la OCI Runtime Specification describen esas capas, pero no responden a tres preguntas mucho más prácticas para la planta: ¿cuánto margen queda en el host?, ¿cuántos datos escribirá la aplicación? y ¿se puede revertir una versión defectuosa de forma segura?

Volvamos a las dos cargas del ejemplo inicial. Un programa de conversión de protocolos con tráfico limitado, poco estado y permisos estrictamente acotados puede ser un buen candidato para quedarse en el router. Una base de datos local o una carga de análisis de vídeo presiona continuamente la CPU, la memoria y el almacenamiento, y su calendario de versiones puede no coincidir con el ciclo de firmware del router. Ambas se llaman contenedores Docker, pero para el host son cargas completamente distintas.

Por eso, no decidas según el tamaño de la imagen ni solo porque el proceso se inicie. Registra primero la carga estable y los picos, el aumento de recursos durante el arranque, el volumen diario de escritura, las interfaces necesarias y el impacto del fallo de la aplicación en el negocio. Cuando la carga de trabajo está clara, también lo está la decisión de dónde colocarla.

Reserva primero los recursos del router para el enrutamiento

Un router industrial no es un pequeño servidor vacío esperando aplicaciones. Las sesiones celulares, la supervisión del enlace, los túneles cifrados, el firewall, los protocolos de enrutamiento, la administración web y el mantenimiento remoto ya utilizan sus recursos. Que haya margen durante el funcionamiento normal no significa que exista el mismo margen durante una reconexión, la reconstrucción de un túnel o una actualización remota del firmware.

La documentación oficial de Docker sobre límites de recursos explica que un contenedor sin límites puede competir por CPU y memoria con otros procesos del host. Durante la evaluación, observa las funciones de red en condiciones normales, en los picos y durante la recuperación. Después, utiliza la interfaz de gestión del firmware objetivo o `docker info` para comprobar las capacidades reales de CPU, memoria y cgroups. Solo después de confirmar que el firmware admite los controles necesarios debes establecer límites medidos para el contenedor. Que un contenedor funcione no significa que esté aislado.

La memoria se ve con facilidad; el almacenamiento se subestima más fácilmente. Los controladores de almacenamiento de Docker gestionan las capas de la imagen y la capa escribible del contenedor, mientras que los volúmenes separan los datos que deben conservarse del ciclo de vida de un contenedor individual. Antes del despliegue, documenta qué datos de base de datos, caché, cola y configuración deben conservarse y cuáles pueden reconstruirse.

Los registros también son escrituras. Cuando el equipo utiliza `json-file`, `local` u otro controlador de logging que almacena datos en el host, la salida estándar y la salida de error siguen consumiendo espacio local. Una aplicación puede tener una imagen pequeña y aun así acumular un historial de registros grande durante varios meses. El tamaño de la imagen es solo el punto de partida; las escrituras sostenidas y el crecimiento en el peor caso se acercan más al riesgo real de una planta sin atención permanente.

Los permisos del contenedor llegan hasta el router

Los contenedores no ofrecen el mismo límite de aislamiento que las máquinas virtuales. Normalmente comparten el kernel del host, por lo que estar dentro de un contenedor no crea automáticamente una frontera de seguridad independiente entre la aplicación y el sistema de enrutamiento. La diferencia ya es importante en un servidor normal y resulta aún más directa en un router industrial que controla la ruta de red de la planta.

El modelo de seguridad del daemon y el socket de Docker suele implicar privilegios elevados sobre el host. Cualquiera que pueda controlarlos debe considerarse una entidad de confianza. Montar el socket en un contenedor de negocio, exponer una API remota sin protección, habilitar el modo privilegiado o mapear directorios del host sin cuidado puede permitir que una vulnerabilidad de la aplicación cruce el límite del contenedor y alcance el propio router.

Un enfoque más seguro consiste en revisar por separado el origen de la imagen, el usuario de ejecución, las capacidades de Linux, los mapeos de dispositivos, los puertos de red y los directorios del host montados, reduciendo cada permiso al mínimo necesario. Cuando la compilación de Docker Engine de destino incluye soporte para seccomp y el kernel del host habilita la capacidad correspondiente, el perfil seccomp predeterminado limita las llamadas al sistema mediante una lista de permitidos. Comprueba las Security Options reales en el modelo objetivo; no des por hecho que todos los firmwares tienen la misma configuración. `seccomp=unconfined` puede resolver un problema de compatibilidad, pero también puede eliminar parte de la frontera de seguridad.

La Application Container Security Guide del NIST considera conjuntamente los riesgos de la imagen, el registro, el runtime, el host y las operaciones. Para un proyecto industrial, convierte ese principio en una regla práctica: si un contenedor solo necesita enviar datos hacia arriba, no debería poder modificar el enrutamiento, las reglas del firewall, las interfaces celulares ni los túneles cifrados. Si realmente necesita acceso serie, red sin procesar o un directorio del host, documenta cada permiso, su motivo y el procedimiento para retirarlo y recuperar el equipo.

El reinicio automático no equivale a la recuperación del negocio

Ver que el contenedor vuelve al estado `running` puede tranquilizar. Pero si el proceso se ha reiniciado, ¿los datos hacia el sistema superior se han recuperado realmente? No necesariamente.

Las políticas de reinicio de Docker gestionan principalmente la salida del contenedor y el ciclo de vida del daemon. Si una aplicación se bloquea pero su proceso sigue vivo, el contenedor puede continuar apareciendo como activo. Si se bloquea repetidamente, quizá solo entre en un ciclo de reinicios. Un health check muestra una parte del estado, pero no sustituye una verificación de negocio. Como mínimo, hay que revisar tres niveles: si el contenedor está en ejecución, si la aplicación está sana y si el sistema superior recibe los datos correctos. Al mismo tiempo, la conectividad celular, los túneles cifrados y la gestión remota deben seguir disponibles.

Lo mismo se aplica a las actualizaciones. Define versiones y rutas de vuelta claras para la imagen de la aplicación, la configuración, los datos persistentes y el firmware del router. Antes del despliegue, responde dónde se conserva la imagen anterior, cómo se retira una versión defectuosa, cómo se recupera el sistema después de una pérdida de alimentación durante la actualización y si el acceso remoto seguirá disponible. Sin una prueba de ingeniería en el equipo objetivo, presenta estos puntos como acciones de validación y no como capacidades de recuperación ya demostradas.

Cuándo dejar Docker en el router y cuándo separarlo

Déjalo en el router cuando la tarea tenga un límite claro y estrecho.

La adaptación de protocolos, el filtrado de datos, el envío de estados o un agente de monitorización pueden encajar cuando la carga es ligera, los picos se pueden medir, la persistencia es limitada y los permisos son reducidos, siempre que el contenedor pueda actualizarse junto con la ventana de mantenimiento del router. Alojarlo en el router elimina un equipo y acerca el procesamiento a los PLC, instrumentos o cámaras. Lo importante es el límite de la tarea, no el nombre de la aplicación.

Usa un Edge Gateway independiente cuando la aplicación ya tenga su propio ciclo de vida.

Una base de datos local, el análisis de vídeo, varios servicios interdependientes o un software que necesite lanzamientos frecuentes y permisos amplios sobre los equipos normalmente ya no es una función pequeña del router. El Fog Computing Conceptual Model del NIST aporta el contexto arquitectónico para colocar el cómputo en el borde de la red. Separar estas cargas permite dividir el impacto de los recursos del host, las actualizaciones de firmware y el mantenimiento de la aplicación sobre los dominios de fallo.

Añadir otra caja tampoco crea alta disponibilidad automáticamente. El Edge Gateway y el router pueden seguir compartiendo la alimentación, el switch, la conexión ascendente y el plano de gestión. Esos puntos de fallo compartidos también deben revisarse.

Cierra la decisión con una pregunta: si la aplicación agota los recursos, su imagen se corrompe o una actualización falla, ¿la conectividad celular, los túneles cifrados y el acceso remoto de rescate deben seguir disponibles? Si la respuesta es sí y el equipo actual no puede demostrar suficiente aislamiento y margen de recuperación, separa las cargas.

Un equipo menos es una ventaja. El objetivo de diseño es reducir el dominio de fallo compartido.

Valida el despliegue antes de ponerlo en producción

La decisión de arquitectura tiene que funcionar en el equipo objetivo. Registra el modelo exacto, el firmware, la arquitectura de la imagen, el uso normal y máximo de CPU y memoria, las escrituras persistentes, el crecimiento de los registros, los puertos y permisos de dispositivos, la frecuencia de lanzamiento y el objetivo de recuperación. Si falta cualquiera de estos datos, será difícil saber si una prueba se ha superado realmente.

Ejecuta primero las pruebas de fallo en un equipo de reserva no productivo o en un laboratorio aislado. Antes de comenzar, exporta la configuración del equipo y los datos persistentes, prepara una consola local o una vía independiente fuera de banda y confirma una imagen conocida como válida junto con el procedimiento de vuelta atrás. Para las pruebas de presión de almacenamiento, utiliza cuotas y alertas controladas; no llenes de verdad la partición del sistema. Realiza pruebas de pérdida de alimentación solo cuando el fabricante las permita, no haya una escritura de firmware en curso y exista una recuperación local posible. Inyecta un fallo cada vez y observa a la vez el enrutamiento, los túneles, el firewall y la gestión remota.

Según la confirmación interna actual del producto, todos los routers industriales de la serie 6 de Wavetel pueden ejecutar Docker. Para revisar un modelo concreto, puede consultarse el router industrial 5G WR575 como ejemplo. Si un proyecto está evaluando esta serie, proporciona la arquitectura de la imagen, los picos de CPU y memoria, el volumen de escritura previsto, los permisos de las interfaces y el objetivo de recuperación antes de elegir un modelo concreto. Con esos datos se puede emparejar el equipo con la carga y definir el plan de validación.

FAQ

¿Qué información del equipo debe confirmarse antes de desplegar Docker?

Confirma el modelo objetivo, la versión del firmware, la arquitectura de CPU, la memoria y el almacenamiento disponibles, el runtime de contenedores y la arquitectura de la imagen. Después, verifica los controles de recursos, las rutas de persistencia, la rotación de registros, los permisos de las interfaces y los procedimientos de vuelta atrás. Solo al combinar estos datos del equipo con las curvas de carga medidas se puede decidir si el alojamiento conjunto es adecuado.

¿Cuánta CPU, memoria y almacenamiento hay que reservar para un contenedor ligero?

No existe una cifra universal para todas las imágenes y modelos. Mide primero las funciones de red propias del router en operación normal y durante la recuperación de fallos. Después mide el pico de arranque del contenedor, su uso estable y el crecimiento de registros y datos persistentes. La reserva debe salir de ambos conjuntos de datos.

¿Puede un contenedor Docker afectar al enrutamiento, los túneles cifrados o el cambio de la conexión ascendente?

Sí. Un contenedor que agote CPU, memoria o almacenamiento, modifique la red del host o reciba permisos excesivos puede afectar a los servicios de red del mismo equipo. Valida el impacto real en el modelo, firmware y configuración objetivo mediante inyección controlada de fallos y funcionamiento prolongado; que el contenedor se inicie correctamente no es suficiente.

¿Los datos del contenedor deben guardarse en la capa de la imagen, en un volumen o en almacenamiento externo?

La imagen debe poder recuperarse o reconstruirse. Los datos que deban sobrevivir a la recreación, actualización o eliminación del contenedor no deben quedarse solo en la capa escribible. Colócalos en un volumen de datos o en almacenamiento externo diseñado para la capacidad, las copias de seguridad y la consistencia tras una pérdida de alimentación.

¿Qué señales indican que conviene un Edge Gateway independiente?

Una carga alta y sostenida, mucha persistencia local, varios servicios interdependientes, permisos amplios sobre el host o los equipos, un ciclo de lanzamiento independiente y la exigencia de que la red siga disponible cuando falle la aplicación son señales claras. Un Edge Gateway independiente puede separar el impacto de los recursos del host, el firmware y el mantenimiento de la aplicación, pero las dependencias compartidas de alimentación, LAN, conexión ascendente y plano de gestión aún deben revisarse por separado.