¿Qué es la contenerización?
La contenerización es una forma de empaquetar un pedazo de software junto con todo lo que necesita para correr, de modo que se comporte idéntico en la laptop de un desarrollador, en una computadora de piso de planta o en un servidor de nube. En lugar de instalar una aplicación sobre una máquina y esperar que la máquina tenga las bibliotecas y ajustes correctos, la aplicación y todo su entorno viajan juntos como una sola unidad sellada y portátil llamada contenedor. En entornos industriales y de SCADA esta idea se ha vuelto en silencio la forma estándar de enviar drivers de protocolo, gateways e historians, porque elimina los dolores de cabeza de dependencias que solían hacer lento y frágil el despliegue en campo. Esta guía explica qué es de verdad un contenedor, en qué difiere de una máquina virtual y por qué los proveedores de automatización se están moviendo a software contenerizado.
Contenerización en una línea: La contenerización es la práctica de agrupar una aplicación junto con sus bibliotecas, configuración y entorno de ejecución en un solo paquete ligero y portátil llamado contenedor que corre de la misma forma en cualquier anfitrión con un motor de contenedores. Los contenedores comparten el kernel del sistema operativo del anfitrión en lugar de que cada uno cargue un sistema operativo completo, lo que los hace mucho más pequeños y rápidos de arrancar que las máquinas virtuales. Esta portabilidad permite que el mismo software corra sin cambios a través de dispositivos de borde, servidores en sitio y la nube.
Qué es en realidad un contenedor
Un contenedor es una instancia en ejecución de un paquete autocontenido que guarda una aplicación más cada dependencia que necesita: las versiones específicas de las bibliotecas contra las que enlaza, sus archivos de configuración, sus variables de entorno y el ejecutable mismo. Como todo eso se captura junto, el contenedor lleva su propio entorno consistente a donde vaya. El problema clásico que resuelve es la situación donde el software corre perfecto en pruebas pero falla en una máquina objetivo porque esa máquina tiene una versión de biblioteca ligeramente distinta o un paquete faltante. Con la contenerización no hay tal desajuste, ya que el contenedor trae su entorno consigo en lugar de tomarlo prestado del anfitrión.
El truco que hace ligeros a los contenedores es que cada uno no incluye un sistema operativo completo. Comparten el kernel del sistema operativo del anfitrión y se aíslan unos de otros usando funciones integradas en ese kernel, como los espacios de nombres y los grupos de control en Linux. Cada contenedor ve lo que parece su propio sistema de archivos, lista de procesos e interfaz de red privados, pero por debajo todos son servidos por un solo kernel compartido. Por eso un servidor modesto o un dispositivo de borde puede correr con soltura muchos contenedores lado a lado, cada uno con una aplicación distinta, sin el sobrecosto de correr muchos sistemas operativos completos a la vez.
Los contenedores por lo general se construyen a partir de imágenes, que son plantillas de sólo lectura que definen el contenido del contenedor capa por capa. Una imagen es inmutable: usted no parcha un contenedor en ejecución en su lugar, sino que más bien construye una imagen nueva y reemplaza el contenedor viejo con uno fresco arrancado desde ella. Este estilo inmutable de despliegue es buena parte del atractivo, porque hace los despliegues repetibles y reversibles. Si una versión nueva se porta mal, un operador puede detenerla y arrancar de nuevo la imagen anterior, seguro de que nada del entorno se desvió en silencio entre una y otra.
Contenedores contra máquinas virtuales
La tecnología con la que la mayoría compara los contenedores es la máquina virtual. Una máquina virtual emula una computadora entera, incluido un sistema operativo huésped completo con su propio kernel, corriendo encima de un hipervisor. Eso da un aislamiento muy fuerte y le permite correr sistemas operativos completamente distintos en un anfitrión físico, pero es pesado: cada máquina virtual reserva memoria y disco para su propio sistema operativo y puede tardar un minuto o más en arrancar. Los contenedores, en cambio, se saltan por completo el sistema operativo huésped y comparten el kernel del anfitrión, así que se miden en megabytes en lugar de gigabytes y arrancan en segundos o menos.
La consecuencia práctica es densidad y velocidad. En el mismo hardware puede correr muchos más contenedores que máquinas virtuales, y puede arrancarlos, detenerlos y reiniciarlos casi al instante, lo que embona con el despliegue automatizado y los sistemas que se autorreparan. La contrapartida es el aislamiento: como los contenedores comparten un kernel, la frontera de aislamiento entre ellos es más delgada que la frontera dura que un hipervisor provee entre máquinas virtuales. Para la mayoría de las cargas de trabajo eso es perfectamente aceptable, y los contenedores y las máquinas virtuales muchas veces se usan juntos, con contenedores corriendo dentro de máquinas virtuales para obtener a la vez portabilidad y aislamiento fuerte.
Ninguno de los dos enfoques es estrictamente mejor; resuelven problemas que se traslapan pero son distintos. Las máquinas virtuales brillan cuando usted debe correr un sistema operativo distinto, necesita una separación muy fuerte entre inquilinos o está consolidando servidores heredados que esperan tener una máquina entera para ellos. Los contenedores brillan cuando quiere enviar una aplicación y sus dependencias de forma repetible, escalar copias de ella rápido y moverla sin cambios entre entornos. Entender esa distinción es la clave para leer la documentación de los proveedores, ya que los productos de automatización cada vez más se envían como contenedores precisamente para ganar esa portabilidad y ese despliegue rápido y repetible.
Por qué los proveedores de SCADA e IIoT envían contenedores
El software industrial ha sido históricamente doloroso de desplegar porque toca tantas piezas móviles: drivers de protocolo para hablar con controladores, motores de base de datos para historians, brokers de mensajes y frentes web, cada uno con sus propias dependencias y requisitos de versión. Instalar todo eso sobre una computadora de campo a mano invita a conflictos de versión y a desviación de configuración, y cada sitio tiende a terminar ligeramente distinto. Empaquetar cada componente como un contenedor convierte esa dispersión en un conjunto de unidades intercambiables y versionadas que se instalan de la misma forma en todos lados, y por eso los proveedores ahora distribuyen gateways, convertidores de protocolo y servicios de historian como contenedores.
La contenerización es especialmente valiosa en el borde, donde una computadora ruda y pequeña cerca del equipo puede necesitar correr varias funciones a la vez, como un traductor de protocolo, un búfer local y un trabajo de analítica. Correr cada una como un contenedor las mantiene aisladas para que un proceso que se cae no tumbe a los demás, y permite a un técnico actualizar una sola función intercambiando una imagen de contenedor en lugar de reconstruir toda la máquina. La misma imagen de contenedor que corre en esa caja de borde puede correr también en un centro de datos central o en la nube, así que un equipo puede desarrollar y probar una vez y desplegar en cualquiera de los dos lados, lo que acorta el camino de un cambio a un despliegue de campo funcionando.
Para una plataforma SCADA de nube, esta portabilidad sustenta cómo el sistema abarca campo y nube. Un proveedor como Merobix puede enviar la lógica de recolección y protocolo del lado de borde como contenedores que corren en el gateway de un cliente, poniendo en búfer y reenviando datos hacia el norte, mientras que el lado de nube corre sus propios contenedores para ingesta, almacenamiento y visualización. Como ambos extremos están contenerizados, la plataforma puede actualizarse limpiamente, escalarse agregando más instancias de contenedor y mantenerse consistente a través de muchos sitios en petróleo y gas, agua, energía y manufactura sin que cada instalación se desvíe hacia una configuración única que nadie puede reproducir.
Preguntas frecuentes
¿Cuál es la diferencia entre un contenedor y una máquina virtual?
Una máquina virtual emula una computadora entera y corre un sistema operativo huésped completo encima de un hipervisor, así que es grande y lenta de arrancar. Un contenedor empaqueta sólo una aplicación y sus dependencias y comparte el kernel del sistema operativo del anfitrión, así que es mucho más pequeño y arranca en segundos. Los contenedores dan mayor densidad y despliegue más rápido, mientras que las máquinas virtuales dan un aislamiento más fuerte y pueden correr sistemas operativos distintos.
¿La contenerización es lo mismo que Docker?
No. La contenerización es el concepto general de empaquetar software con sus dependencias en unidades portátiles y aisladas, mientras que Docker es un conjunto popular de herramientas para construir y correr contenedores. Docker ayudó a volver mayoritaria la idea, pero existen otros motores y estándares, y los formatos de imagen de contenedor subyacentes ahora están ampliamente estandarizados, así que las imágenes construidas con una herramienta muchas veces pueden correr bajo otra.
¿Por qué los proveedores industriales y de SCADA envían software en contenedores?
Los contenedores permiten a los proveedores agrupar drivers de protocolo, gateways y servicios de historian con sus dependencias exactas para que se instalen y corran idéntico en cada máquina, evitando los conflictos de versión que plagaban al software industrial instalado a mano. La misma imagen de contenedor puede correr en un dispositivo de borde, un servidor en sitio o en la nube, lo que hace el despliegue repetible, las actualizaciones más limpias y las flotas multisitio mucho más consistentes.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.