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.


Este escenario puede parecer artificial. Sin embargo, tenga en cuenta que un panorama de aplicaciones típico incluye tiempos de ejecución de idiomas, bases de datos, servidores web y caché. Por lo tanto, puede haber imágenes base para Java, Python, PHP, MySQL, PostgreSQL, Reds, Apache HTTPD, Apache Tomcat y Nginx para satisfacer las dependencias de la aplicación.


La disponibilidad de imágenes de contenedor preconstruidas para componentes de software en registros públicos ofrece a los desarrolladores una gran variedad de opciones. El desarrollador que selecciona la imagen para una base de datos puede centrarse en elegir la última versión, pero no investigar qué sistema operativo forma la base de esas imágenes. O pueden elegir una imagen basada simplemente en el tamaño de imagen más pequeño, aunque la distribución de Linux base para esa imagen podría no ser algo que una empresa elegiría ejecutar en su entorno.


Debido al potencial de que las versiones de software se multipliquen en un entorno, tener una SOE para contenedores es tan importante como una SOE para sistemas operativos.


Para obtener más información, consulte el artículo de Infoworld, "Los contenedores también necesitan entornos operativos estándar ", de Scott McCarty.


Los beneficios de la RBU como empresa pública


Presentamos Red Hat Universal Base Image (UBI) en 2019. El objetivo de Red Hat al crear UBI es producir una imagen base para todas las necesidades de desarrolladores, socios de software y proyectos comunitarios. UBI es un subconjunto de Red Hat Enterprise Linux (RHEL) que se puede redistribuir libremente para crear software basado en contenedores.


Los bits proporcionados en UBI son los mismos que los proporcionados en RHEL. Solo difieren en los términos y condiciones para su uso. Este es el mismo software que se utiliza ampliamente para algunas de las cargas de trabajo más críticas del mundo, como la informática de alto rendimiento (HPC), los servicios financieros y la IA / ML.


Se utiliza en entornos altamente seguros como gobiernos y banca, aplicaciones intensivas de E / S como procesamiento de transacciones y aplicaciones críticas para el rendimiento con requisitos de hardware especializado y / o latencias bajas.


  • Socios de software: al elegir UBI, las empresas de software pueden utilizar las mismas imágenes de contenedor para el software que ponen a disposición de las empresas o lo venden de forma gratuita. Los clientes empresariales de estos desarrolladores pueden elegir opciones de soporte de Red Hat que satisfagan sus necesidades.

  • Empresas y otras organizaciones: los desarrolladores, las operaciones y los equipos de seguridad de muchas organizaciones de TI tienen una amplia experiencia con Red Hat Enterprise Linux. UBI les brinda imágenes base familiares, paquetes y herramientas de administración de paquetes que pueden admitir fácilmente sin tener que volver a capacitarse.

UBI comparte el mismo ciclo de vida de más de 10 años que la versión de RHEL en la que se basa. Los componentes de UBI se actualizan cuando se actualizan los componentes RHEL correspondientes.


No hay requisitos de registro o administración de suscripciones para usar UBI. Esto, combinado con el largo ciclo de vida del soporte, convierte a UBI en una excelente opción para proyectos de software libre y sistemas de compilación automatizados como las canalizaciones de CI / CD.


Por último, Red Hat se compromete a utilizar UBI como imagen base para los productos Red Hat. Tiene el conocimiento de que UBI es fundamental para el éxito de los productos de Red Hat, lo que le brinda la confianza para usarlo también como base para su propio software.


Nuevo libro electrónico: Red Hat Universal Base Images


Para obtener más información sobre cómo desarrollar y cumplir con la RBU, lo invitamos a descargar este libro electrónico gratuito desde cualquiera de estas dos ubicaciones de Red Hat:


  • Socios de software - descargarlo de este Red Hat Partner Connect página.

  • Desarrolladores: descárguelo de esta página del libro electrónico Red Hat Developer.

Fuente: Blog de Red Hat.

2 vistas0 comentarios