Hay muchas plantillas de construcción de contenedores. Un contenedor es solo una versión ejecutable de su propia imagen. Por lo tanto, la forma de construir un contenedor está estrechamente relacionada con cómo se inicia.
Algunas imágenes de contenedor funcionan bien sin ningún privilegio especial; otras requieren privilegios de root. Además, la misma imagen / contenedor puede combinar varios patrones de construcción y escenarios de uso a la vez.
A continuación consideraremos los casos de uso de contenedores más comunes.
(Para una introducción a la terminología del contenedor, vea la primera
parte )
Escenarios de uso de contenedores
Contenedores de aplicaciones
Los contenedores de aplicaciones son el tipo más común de contenedor. Los desarrolladores y propietarios de aplicaciones los manejan, y ellos mismos contienen el código fuente, además de cosas como MySQL, Apache, MongoDB y Node.js.
Se está formando un vasto ecosistema de contenedores de aplicaciones. Proyectos como Software Collections proporcionan imágenes de contenedores de aplicaciones seguras y compatibles para Red Hat Enterprise Linux. Al mismo tiempo, los miembros de la comunidad de Red Hat están desarrollando y respaldando contenedores de aplicaciones innovadores.
En Red Hat, creemos que los contenedores de aplicaciones generalmente no necesitan privilegios especiales. Sin embargo, al construir entornos de producción de contenedores, existe la necesidad de otros contenedores.
Contenedores del sistema operativo
El contenedor del sistema operativo es un contenedor que se parece mucho más a un sistema operativo virtual completo. Dichos contenedores también usan el núcleo del host, pero ejecutan el sistema init completo, lo que les permite ejecutar fácilmente varios procesos. Ejemplos de contenedores del sistema operativo son LXC y LXD.
Los contenedores del sistema operativo pueden, en principio, emularse utilizando contenedores docker / OCI, siempre que sea posible ejecutar el sistema dentro de ellos para que el usuario final pueda instalar el software dentro de dichos contenedores de la manera habitual y los perciba como un sistema operativo virtual completo.
yum install mysql systemctl enable mysql
Esto simplifica enormemente la contenedorización de las aplicaciones existentes. Red Hat está trabajando arduamente para simplificar los contenedores del sistema operativo al permitir que systemd se ejecute dentro del contenedor y use el demonio mecanizado. Aunque muchos clientes aún no están listos para la arquitectura de microservicios, la transición a un modelo de entrega de software en contenedor basado en imágenes de contenedor aún puede brindarles muchas ventajas.
Contenedores para mascotas
Aunque Red Hat recomienda, promueve y apoya firmemente el uso de
plantillas basadas en la nube al desarrollar nuevas aplicaciones, somos conscientes de que no todas las aplicaciones existentes se reescribirán de esta manera. En particular, porque muchos de ellos son tan únicos e inimitables que, en comparación con las aplicaciones estándar, se ven como mascotas (
Pets ) contra un rebaño de vacas. Es para tales aplicaciones que se diseñan
contenedores especiales para
mascotas .
Los contenedores para mascotas combinan la portabilidad y la conveniencia de una infraestructura de contenedores construida sobre la base de servidores de registro, imágenes de contenedores y hosts de contenedores con la flexibilidad de un entorno de TI tradicional, implementado dentro de un contenedor separado. La idea aquí es simplificar la contenedorización de aplicaciones existentes debido a la misma
capacidad de usar systemd dentro del contenedor para usar herramientas de automatización existentes, instalaciones de software y otras herramientas para crear fácilmente imágenes listas para contenedores para el lanzamiento.
Contenedores Super Privilege
Cuando se construye una infraestructura de contenedores basada en hosts de contenedores dedicados como Red Hat Enterprise Linux Atomic Host, los administradores de sistemas aún deben administrar. Y los
contenedores súper privilegiados (SPC) demuestran ser muy útiles en dichos entornos distribuidos, ya sea Kubernetes, OpenShift o incluso contenedores independientes. Los SPC pueden incluso cargar módulos de kernel especializados, como systemtap.
En la infraestructura creada para ejecutar contenedores, es probable que los administradores necesiten contenedores SPC para realizar tareas como monitoreo, respaldo, etc. Es importante entender que, dado que los contenedores SPC generalmente están mucho más conectados al núcleo del host, los administradores deberían Preste especial atención a los problemas de confiabilidad y estandarización al elegir los sistemas operativos host, especialmente en entornos grandes agrupados y distribuidos que dificultan la solución de problemas. Además, los administradores deben asegurarse de que el espacio del usuario dentro del SPC sea compatible con el núcleo del host.
Herramientas y software del sistema
Las distribuciones de Linux siempre proporcionaron al usuario software del sistema, como Rsyslogd, SSSD, sadc, etc. Tradicionalmente, este software se instaló en forma de paquetes RPM o DEB, pero con el advenimiento de los formatos de empaquetado de contenedores se hizo más fácil y más conveniente instalarlo usando imágenes de contenedor. En particular, Red Hat ofrece cosas como contenedores ya hechos, como las herramientas de virtualización de Red Hat, rsyslog, sssd y sadc.
Arquitectura de contenedores
A medida que la entrega de software en contenedores está ganando impulso, están surgiendo nuevos patrones de diseño de contenedores. En esta sección hablaremos sobre algunos de ellos.
La forma en que el contenedor se guarda en el disco (en otras palabras, el formato de la imagen) puede afectar en gran medida cómo se inicia. Por ejemplo, un contenedor diseñado para ejecutar sssd debe tener privilegios especiales cada vez que se inicia; de lo contrario, no podrá hacer su trabajo. A continuación, consideramos brevemente los patrones principales que actualmente se encuentran en la etapa de formación activa.
Imágenes de aplicación
Es con estas imágenes que los usuarios finales tratan. Los escenarios para usar tales imágenes van desde DBMS y servidores web hasta aplicaciones individuales y buses de servicio. Estas imágenes pueden ser creadas internamente por la organización o proporcionadas por proveedores de software. Por lo tanto, los usuarios finales a menudo se relacionan con el contenido de dichos contenedores autónomos con precaución y escrupulosidad. Además, aunque esta es la opción más fácil para el usuario final de los contenedores, las imágenes independientes son mucho más difíciles de diseñar, construir y parchear.
Imágenes basicas
Una imagen básica es uno de los tipos de imágenes más simples. Sin embargo, las personas pueden denotar este término con una variedad de cosas, por ejemplo, un ensamblaje corporativo estándar o incluso una imagen de aplicación. Aunque, estrictamente hablando, estas no son imágenes básicas, sino intermedias.
Tan solo deje en claro que la imagen base es una imagen que no tiene una capa principal. Las imágenes básicas generalmente contienen una copia limpia del sistema operativo, así como las herramientas necesarias para instalar paquetes de software o actualizar la imagen más tarde (yum, rpm, apt-get, dnf, microdnf). Las imágenes básicas pueden ser recopiladas manualmente por el usuario final, pero en la práctica generalmente son creadas y publicadas por comunidades de desarrollo (por ejemplo, Debian, Fedora o CentOS) o proveedores de software (por ejemplo, Red Hat). El origen de la imagen base es crítico para la seguridad. En resumen, el principal y único propósito de la imagen básica es proporcionar una base sobre la cual puede crear las imágenes de su hijo. Cuando se utiliza dockerfile, la selección de la imagen base subyacente se realiza explícitamente:
FROM registry.access.redhat.com/rhel7-atomic
Imágenes de constructor
Este es un tipo especial de imagen en función del cual se crean imágenes secundarias de contenedores de aplicaciones. Las imágenes del constructor incluyen todo excepto el código fuente escrito por los desarrolladores, a saber, bibliotecas del sistema operativo, tiempos de ejecución del lenguaje, middleware y herramientas de
fuente a imagen .
Al inicio, la imagen del generador extrae el código fuente de la aplicación escrito por los desarrolladores y crea una imagen secundaria del contenedor de la aplicación que está lista para ser lanzada, que luego puede ejecutarse en un entorno de desarrollo o producción.
Digamos que los desarrolladores han escrito el código PHP para la aplicación y quieren ejecutarlo en el contenedor. Para hacer esto, simplemente toman la imagen del constructor de PHP y le pasan la URL en el sitio web de GitHub, donde se almacena su código. Como resultado, los desarrolladores obtienen una imagen del contenedor de la aplicación lista para su lanzamiento que contiene Red Hat Enterprise Linux, PHP de las Colecciones de software y, por supuesto, el código fuente de PHP para la aplicación.
Las imágenes del generador son una forma poderosa, fácil y rápida de convertir el código fuente en un contenedor construido sobre la base de componentes confiables.
Componentes en contenedores
Un contenedor está diseñado principalmente para implementarse como un componente de un sistema de software más grande, y no como una unidad autónoma. Y hay dos razones principales para esto.
En primer lugar, la arquitectura de microservicios aumenta la libertad de elección de componentes, y también conduce a un aumento en el número de componentes de los que se componen las aplicaciones y los sistemas de software. Los componentes en contenedores ayudan a implementar dichos sistemas de manera más rápida y fácil. Por ejemplo, las imágenes de contenedor facilitan la resolución del problema de la coexistencia de diferentes versiones del mismo componente. Y las herramientas de definición de aplicaciones, como las
implementaciones yaml / json en Kubernetes / OpenShift,
el broker de servicios abiertos , las
plantillas OpenShift y los
Gráficos Helm, proporcionan la creación de descripciones de aplicaciones de alto nivel.
En segundo lugar, lejos de siempre, todas las partes de un sistema de software se pueden contener fácilmente. Por lo tanto, tiene sentido realizar la contenedorización solo para los componentes individuales más adecuados para esto o más prometedores en términos de resultados. En aplicaciones multiservicio, una parte de los servicios se puede implementar como contenedores, y la otra utilizando métodos tradicionales, como RPM o scripts de instalación, consulte contenedores de mascotas. Además, algunos componentes pueden ser difíciles de contener, porque están mal divididos en componentes, o están vinculados a algún hardware especial, o usan llamadas API de kernel de bajo nivel, etc. Por lo tanto, en un sistema de software grande, muy probablemente Habrá partes que pueden ser contenedorizadas y partes que no pueden ser contenedorizadas. Los componentes en contenedores son lo que se puede contener en contenedores y ya en contenedores. Los componentes en contenedores están diseñados para ejecutarse como parte de una aplicación específica, y no por sí mismos. Es importante comprender que no están destinados a un funcionamiento autónomo, ya que son útiles solo como parte de un sistema de software más grande y, de forma aislada, son prácticamente inútiles.
Por ejemplo, en OpenShift Enterprise 3.0, la mayor parte del código principal se implementó usando RPM, pero después de que se instaló, los administradores implementaron el enrutador y el registro como contenedores. OpenShift 3.1 introdujo la opción de implementación en contenedores para master, node, openvswitch y etcd, y una vez instalados, los administradores también podrían implementar elasticsearch, fluentd y kibana como contenedores.
Aunque el instalador de OpenShift todavía está haciendo cambios en el sistema de archivos del servidor, todos los componentes principales del software ahora se pueden instalar utilizando imágenes de contenedor. Por lo tanto, estos componentes en contenedores, por ejemplo, una instancia de la imagen etcd incrustada en OpenShift, nunca deberían, y no serán, utilizados para almacenar el código fuente de la aplicación con la que trabajan sus clientes, simplemente porque estos componentes en contenedores están destinados a ejecutarse como parte Plataforma de contenedores OpenShift.
En las nuevas versiones de OpenShift, la tendencia hacia la contenedorización de componentes solo se está intensificando, y otros desarrolladores de software utilizan cada vez más este enfoque.
Imágenes del desplegador
La imagen del desplegador es un tipo especial de contenedor que, cuando se inicia, implementa o administra otros contenedores. Deployer le permite implementar esquemas de implementación complejos, por ejemplo, lanzar contenedores en un cierto orden o realizar algunas acciones al primer inicio, como generar un esquema de datos o llenar inicialmente la base de datos.
Por ejemplo, en OpenShift, la plantilla "tipo de imagen / contenedor" se utiliza para implementar registros y métricas. La implementación de estos componentes utilizando imágenes de implementación permite a los ingenieros de OpenShift controlar el orden en que se ejecutan los distintos componentes y verificar que funcionan correctamente.
Imágenes intermedias
Una imagen intermedia es cualquier imagen de un contenedor que se basa en una imagen base. Los ensamblajes del núcleo, el middleware y los tiempos de ejecución del lenguaje generalmente se implementan como capas adicionales en la parte superior de la imagen base y luego se especifican en la directiva FROM con esta imagen base. Las imágenes intermedias generalmente no se usan solas, sino como bloques de construcción para crear una imagen autónoma.
Las diferentes capas de la imagen, por regla general, participan en diferentes grupos de especialistas. Por ejemplo, los administradores del sistema son responsables de la capa de ensamblaje del núcleo y los desarrolladores de la capa de middleware. Al mismo tiempo, las capas subyacentes preparadas por un equipo actúan como una imagen intermedia para los responsables de las capas de un nivel superior. Aunque a veces tales imágenes intermedias se pueden usar de forma autónoma, especialmente cuando se realizan pruebas.
Imágenes multipropósito (intermodales)
Las imágenes de contenedor multipropósito son imágenes con una arquitectura híbrida. Por ejemplo, muchas de las imágenes en Red Hat Software Collections se pueden usar de dos maneras. En primer lugar, como contenedores de aplicaciones regulares con Ruby on Rails completo y el servidor Apache. En segundo lugar, puede usarlos como imágenes de construcción para OpenShift Container Platform y crear imágenes secundarias basadas en ellas que contengan Ruby on Rails, Apache y el código de aplicación que pasó al proceso de
origen a imagen al construir una imagen secundaria de este tipo.
Tenga en cuenta que las imágenes multipropósito están ganando popularidad porque le permiten resolver dos tareas fundamentalmente diferentes utilizando la misma imagen.
Contenedores del sistema
Al implementar el software del sistema en forma de contenedores, estos últimos a menudo requieren privilegios de superusuario. Para simplificar esta opción de implementación y garantizar que dichos contenedores se inicien antes del tiempo de ejecución del contenedor y del sistema de orquestación, Red Hat ha desarrollado una plantilla especial llamada
contenedores del sistema . Estos contenedores se inician durante el proceso de arranque del sistema operativo utilizando systemd y el comando atómico, lo que los hace independientes de cualquier sistema de orquestación de contenedores o tiempo de ejecución. Hoy, Red Hat ofrece contenedores del sistema para rsyslog, cockpit, etcd y flanneld y ampliará esta lista en el futuro.
Los contenedores del sistema simplifican enormemente la adición selectiva de estos servicios a Red Hat Enterprise Linux y Atomic Host.
Conclusión
Los contenedores parecen ser algo bastante simple para el consumidor final, pero surgen muchas preguntas al construir un entorno de producción de contenedores. Para discutir fructíferamente la arquitectura y los métodos de construcción de tales entornos, se requiere una terminología uniforme para todos los participantes. Cuanto más profundice en el diseño y la construcción de dichos entornos, surgirán más dificultades. Finalmente, recordamos solo un par de ellos.
Las personas a menudo no ven la diferencia entre los términos "imagen del contenedor" y "repositorio", especialmente cuando se usan en los comandos de Docker. Pero si puede usar los comandos sin comprender las diferencias, cuando trabaje en la arquitectura de entornos de contenedor, debe comprender claramente que el repositorio es realmente la estructura de datos principal.
También es bastante fácil entender mal la diferencia entre espacios de nombres, repositorios, capas de imágenes y etiquetas. Cada una de estas cosas tiene su propósito en la arquitectura de contenedores. Y aunque los proveedores y usuarios los usan para una variedad de propósitos, son solo herramientas.
El propósito de este artículo es ayudarlo a comprender la terminología para que pueda crear arquitecturas más avanzadas. Por ejemplo, imagine que le acaban de encargar que desarrolle una infraestructura que debería delimitar la disponibilidad de espacios de nombres, repositorios y, además, etiquetas y capas dependiendo de los roles y las reglas comerciales. Y el último: recuerde que la forma en que se ensambla el contenedor determina en gran medida cómo se inicia (orquestación, privilegios, etc.).