Treo Blog

En este espacio puedes explorar las últimas tendencias y noticias en tecnología, seguridad informática e infraestructura TI.

  • Jonathan Rodriguez Paipa

Por qué la imagen base universal de Red Hat es crucial para un entorno operativo estándar

Por: Mike Guerette y Scott McCarty



Crédito: Pexels

Esta publicación analiza los méritos de la estandarización en imágenes de base de contenedores y es un extracto del nuevo libro electrónico sobre imágenes de base universal de Red Hat.


Entornos operativos estándar (SOE) y contenedores Linux


Las organizaciones de TI tradicionales han entendido desde hace mucho tiempo el valor de un entorno operativo estándar (SOE) . Históricamente, los administradores implementaron una SOE como una imagen de disco, kickstart o imagen de máquina virtual para la implementación masiva dentro de una organización. Esto redujo la sobrecarga operativa, fomentó la automatización, aumentó la confiabilidad al reducir la variación y estableció controles de seguridad que aumentaron la postura de seguridad general de un entorno.


Las empresas públicas a menudo incluyen el sistema operativo base (kernel y programas de espacio de usuario), archivos de configuración personalizados, aplicaciones estándar utilizadas dentro de una organización, actualizaciones de software y paquetes de servicios. Es mucho más fácil solucionar problemas de un servicio fallido a las 2 am si todos los servidores ejecutan la misma configuración. Algunas de las principales ventajas de una empresa pública son la reducción de costes y el aumento de la agilidad. El esfuerzo para implementar, configurar, mantener, brindar soporte y administrar sistemas y aplicaciones puede reducirse.


Al comprender el valor de una empresa pública, una organización de TI madura controla estrictamente la cantidad de diferentes sistemas operativos y versiones de SO. El número ideal es uno, pero eso no suele ser factible, por lo que hay esfuerzos para mantener el número lo más pequeño posible. Las organizaciones de TI realizan un esfuerzo considerable para asegurarse de que no se agreguen cajas a la red con versiones y configuraciones de SO ad-hoc.


Contenedores Linux y entornos operativos estándar


Entonces, ¿qué tiene esto que ver con los contenedores? Los contenedores han mejorado drásticamente el desarrollo, la implementación y el mantenimiento de aplicaciones. La facilidad con la que se pueden implementar los contenedores y el aislamiento que ofrecen simplifica muchos aspectos de la gestión de TI. La llegada de los contenedores y, hasta cierto punto, las prácticas de DevOps, ha llevado a la noción de que las prácticas tradicionales de TI como las empresas públicas y las mejores prácticas de gestión de la configuración ya no son relevantes.


Con los contenedores, es fácil pensar que puede usar cualquier tecnología que desee, donde quiera, cuando quiera, sin tener un impacto negativo en su panorama de TI. Los contenedores pueden tener una huella mucho más pequeña y, por lo tanto, tener un área de superficie mucho más pequeña que podría ser vulnerable, pero aún tienen los componentes de un sistema operativo Linux simplificado en su interior. Esos componentes aún deben mantenerse como las implementaciones de sistemas operativos tradicionales. Sin embargo, con los contenedores, la cantidad de versiones para rastrear se multiplica rápidamente.


La explosión de la versión: ¿cuántas versiones diferentes estoy ejecutando?


Cuando los desarrolladores piensan en crear una aplicación en contenedores, su enfoque suele estar en ejecutar un puñado de contenedores. Incluso si se crea una gran aplicación de microservicios con docenas o cientos de contenedores, es probable que los contenedores compartan una herencia similar, por lo que los desarrolladores realmente no piensan en las muchas versiones de software similar que podrían estar en juego.


Para comprender realmente el impacto de las decisiones que toman los desarrolladores, debe considerar a los consumidores de su software y los entornos de TI de los que son responsables. Dados los beneficios que ofrecen los contenedores, la mayoría de las organizaciones de TI terminan ejecutando cientos de imágenes de contenedores, mientras que las grandes corporaciones podrían fácilmente ejecutar miles de imágenes diferentes.


Para comprender su perspectiva, considere lo que sucede si se descubre una vulnerabilidad o error crítico en una biblioteca muy utilizada como la biblioteca de criptografía OpenSSL o la biblioteca C (glibc). La primera tarea es identificar todos los lugares donde se ejecutan las versiones vulnerables. Para hacer eso, necesitan saber qué versión se está ejecutando en cada sistema, que incluye cada contenedor.


Sin una SOE, o al menos políticas que rijan qué imágenes base se utilizan, una organización podría terminar con considerables desafíos de mantenimiento y confiar en los contenedores puede hacer que esto sea más rápido.


Figura 1 - Varias versiones del mismo software debido a la falta de una SOE.

En el entorno que se muestra en la figura 1, hay 11 versiones diferentes de OpenSSL y 8 versiones diferentes de la biblioteca glibc C. ¡La situación podría ser incluso peor que eso! Puede haber números de versiones de origen comunes en todas las versiones del sistema operativo, pero los paquetes reales son diferentes debido a los diferentes niveles de parches o las diferentes marcas de configuración utilizadas en la compilación.


Otra complicación es que las diferentes distribuciones no usan las mismas convenciones para nombrar y versionar paquetes. Una distribución puede empaquetar todos los archivos de una pieza de software en un solo paquete más grande, mientras que otras lo dividen en varios paquetes más pequeños.