Container Linux (anteriormente CoreOS Linux ) es un sistema operativo ligero de código abierto descontinuado basado en el núcleo Linux y diseñado para proporcionar infraestructura para implementaciones en clúster . Uno de sus enfoques era la escalabilidad . Como sistema operativo, Container Linux proporcionaba solo la funcionalidad mínima requerida para implementar aplicaciones dentro de contenedores de software , junto con mecanismos integrados para el descubrimiento de servicios y el uso compartido de configuraciones. [10] [11] [12] [13] [14]
Container Linux comparte bases con Gentoo Linux , [15] [16] ChromeOS y ChromiumOS a través de un kit de desarrollo de software (SDK) común. Container Linux agrega nueva funcionalidad y personalización a esta base compartida para admitir hardware de servidor y casos de uso. [13] [17] : 7:02 CoreOS fue desarrollado principalmente por Alex Polvi, Brandon Philips y Michael Marineau, [12] con sus principales características disponibles como una versión estable . [18] [19] [20]
El equipo de CoreOS anunció el fin de la vida útil de Container Linux el 26 de mayo de 2020, [1] ofreciendo Fedora CoreOS , [21] y RHEL CoreOS como su reemplazo, ambos basados en Red Hat Enterprise Linux .
Container Linux no proporciona un administrador de paquetes como una forma de distribuir aplicaciones de carga útil, requiriendo en cambio que todas las aplicaciones se ejecuten dentro de sus contenedores. Al funcionar como un único host de control, una instancia de Container Linux utiliza las características de virtualización a nivel de sistema operativo subyacentes del kernel de Linux para crear y configurar múltiples contenedores que funcionan como sistemas Linux aislados. De esa manera, la partición de recursos entre contenedores se realiza a través de múltiples instancias de espacio de usuario aisladas , en lugar de usar un hipervisor y proporcionar máquinas virtuales completas . Este enfoque se basa en las funcionalidades de cgroups y espacios de nombres del kernel de Linux, [22] [23] que juntas brindan capacidades para limitar, contabilizar y aislar el uso de recursos ( CPU , memoria, E/S de disco , etc.) para las colecciones de procesos de espacio de usuario . [11] [14] [24]
Inicialmente, Container Linux utilizó exclusivamente Docker como un componente que proporciona una capa adicional de abstracción e interfaz [25] a las características de virtualización a nivel de sistema operativo del kernel de Linux, además de proporcionar un formato estandarizado para contenedores que permite que las aplicaciones se ejecuten en diferentes entornos. [11] [24] En diciembre de 2014, CoreOS lanzó y comenzó a soportar rkt (inicialmente lanzado como Rocket ) como una alternativa a Docker, proporcionando a través de él otro formato estandarizado de las imágenes de contenedores de aplicaciones, la definición relacionada del entorno de ejecución de contenedores y un protocolo para descubrir y recuperar imágenes de contenedores. [26] [27] [28] [29] CoreOS proporciona rkt como una implementación de la denominada especificación de contenedor de aplicaciones (appc) que describe las propiedades requeridas de la imagen de contenedor de aplicaciones (ACI). CoreOS creó appc y ACI como un conjunto de especificaciones dirigidas por un comité independiente [30] [31] con el objetivo de convertirse en parte de la Iniciativa de Contenedores Abiertos ( OCI), independiente del proveedor y del sistema operativo, inicialmente llamada el estándar de contenedorización Open Container Project (OCP), [32] que fue anunciado [¿ por quién? ] en junio de 2015. [33] [34] [35]
Container Linux utiliza scripts ebuild de Gentoo Linux para la compilación automatizada de los componentes de su sistema, [15] [16] y utiliza systemd como su sistema de inicio principal , con una estrecha integración entre systemd y varios mecanismos internos de Container Linux. [11] [36]
Container Linux logra una seguridad y confiabilidad adicionales de las actualizaciones de su sistema operativo al emplear FastPatch como un esquema de partición dual para la parte de solo lectura de su instalación, lo que significa que las actualizaciones se realizan como un todo y se instalan en una partición de arranque secundaria pasiva que se activa al reiniciar o usar kexec . Este enfoque evita posibles problemas que surgen de actualizar solo ciertas partes del sistema operativo, garantiza reversiones fáciles a una versión estable del sistema operativo y permite que cada partición de arranque esté firmada para mayor seguridad. [11] [14] [37] La partición raíz y su sistema de archivos raíz se redimensionan automáticamente para llenar todo el espacio de disco disponible al reiniciar; mientras que la partición raíz proporciona espacio de almacenamiento de lectura y escritura, el sistema operativo en sí se monta como de solo lectura en /usr . [38] [39] [40]
Para garantizar que solo una cierta parte del clúster se reinicie a la vez cuando se aplican las actualizaciones del sistema operativo, preservando los recursos necesarios para ejecutar las aplicaciones implementadas, CoreOS proporciona locksmith como un administrador de reinicio para Container Linux. [41] Al usar locksmith, se puede seleccionar entre diferentes estrategias de actualización que están determinadas por cómo se realizan los reinicios como el último paso en la aplicación de actualizaciones; por ejemplo, se puede configurar cuántos miembros del clúster pueden reiniciarse simultáneamente. Internamente, locksmith opera como el demonio locksmithd que se ejecuta en los miembros del clúster, mientras que la utilidad de línea de comandos locksmithctl administra los parámetros de configuración. [42] [43] Locksmith está escrito en el lenguaje Go y se distribuye bajo los términos de la Licencia Apache 2.0 . [44]
El sistema de distribución de actualizaciones empleado por Container Linux se basa en el proyecto de código abierto Omaha de Google , que proporciona un mecanismo para implementar actualizaciones y el protocolo de solicitud-respuesta subyacente basado en XML . [6] [45] [46] Además, CoreOS proporciona CoreUpdate como un panel basado en la web para la gestión de actualizaciones de todo el clúster. Las operaciones disponibles a través de CoreUpdate incluyen la asignación de miembros del clúster a diferentes grupos que comparten políticas de actualización personalizadas, la revisión de desgloses de todo el clúster de versiones de Container Linux, la detención y reinicio de actualizaciones y la revisión de registros de actualización registrados. CoreUpdate también proporciona una API basada en HTTP que permite su integración en utilidades de terceros o sistemas de implementación . [37] [47] [48]
Container Linux proporciona etcd, un demonio que se ejecuta en todas las computadoras de un clúster y proporciona un registro de configuración dinámico, lo que permite que varios datos de configuración se compartan de manera fácil y confiable entre los miembros del clúster. [6] [38] Dado que los datos de clave-valor almacenados dentro de etcd se distribuyen y replican automáticamente con elección maestra automatizada y establecimiento de consenso utilizando el algoritmo Raft , todos los cambios en los datos almacenados se reflejan en todo el clúster, mientras que la redundancia lograda evita que las fallas de los miembros individuales del clúster provoquen la pérdida de datos. [29] [50] Además de la gestión de la configuración, etcd también proporciona descubrimiento de servicios al permitir que las aplicaciones implementadas se anuncien a sí mismas y los servicios que ofrecen. La comunicación con etcd se realiza a través de una API expuesta basada en REST , que internamente usa JSON sobre HTTP; la API se puede usar directamente (a través de curl o wget , por ejemplo), o indirectamente a través de etcdctl , que es una utilidad de línea de comandos especializada también suministrada por CoreOS. [11] [14] [51] [52] [53] etcd también se usa en el software de Kubernetes .
Container Linux también proporciona el administrador de clúster de flotas , que controla las instancias systemd separadas de Container Linux a nivel de clúster. A partir de 2017, "fleet" ya no se desarrolla activamente y está obsoleto a favor de Kubernetes. [54] Al usar fleed , Container Linux crea un sistema de inicio distribuido que une instancias systemd separadas y una implementación etcd en todo el clúster ; [50] internamente, el demonio fleed se comunica con instancias systemd locales a través de D-Bus y con la implementación etcd a través de su API expuesta. El uso de fleed permite la implementación de uno o varios contenedores en todo el clúster, con opciones más avanzadas que incluyen redundancia , conmutación por error , implementación en miembros específicos del clúster, dependencias entre contenedores e implementación agrupada de contenedores. Se utiliza una utilidad de línea de comandos llamada fleectl para configurar y monitorear este sistema de inicio distribuido; [55] internamente, se comunica con el demonio fleed utilizando una API basada en JSON sobre HTTP, que también se puede usar directamente. Cuando se utiliza localmente en un miembro del clúster, fleectl se comunica con la instancia local de fleed a través de un socket de dominio Unix ; cuando se utiliza desde un host externo, se utiliza la tunelización SSH con autenticación proporcionada a través de claves SSH públicas . [56] [57] [58] [59] [60]
Todos los demonios y utilidades de línea de comandos mencionados anteriormente ( etcd , etcdctl , fleed y fleectl ) están escritos en el lenguaje Go y se distribuyen bajo los términos de la Licencia Apache 2.0. [8] [61]
Cuando se ejecuta en hardware dedicado, Container Linux se puede instalar de forma permanente en el almacenamiento local, como una unidad de disco duro (HDD) o una unidad de estado sólido (SSD), [62] o iniciarse de forma remota a través de una red utilizando el entorno de ejecución de prearranque (PXE) en general, o iPXE como una de sus implementaciones. [63] [64] CoreOS también admite implementaciones en varias plataformas de virtualización de hardware , incluidas Amazon EC2 , DigitalOcean , Google Compute Engine , Microsoft Azure , OpenStack , QEMU / KVM , Vagrant y VMware . [14] [65] [66] [67] Container Linux también se puede instalar en Citrix XenServer, teniendo en cuenta que existe una "plantilla" para CoreOS.
Container Linux también se puede implementar a través de su distribución comercial llamada Tectonic , que además integra Kubernetes de Google como una utilidad de gestión de clústeres. A partir de abril de 2015 [actualizar], se planea ofrecer Tectonic como software beta para clientes seleccionados. [30] [68] [69] Además, CoreOS proporciona Flannel como un componente, implementando una red superpuesta requerida principalmente para la integración con Kubernetes. [30] [70] [71]
A partir de febrero de 2015 [actualizar], Container Linux solo admite la arquitectura x86-64 . [6]
Tras la adquisición de CoreOS, Inc. [72] en enero de 2018, Red Hat anunció [73] que fusionaría CoreOS Container Linux con el Proyecto Atomic de Red Hat para crear un nuevo sistema operativo, Red Hat CoreOS, al tiempo que alinearía la comunidad de código abierto del Proyecto Fedora en torno a Fedora CoreOS, combinando tecnologías de ambos predecesores.
El 6 de marzo de 2018, Kinvolk GmbH anunció [74] Flatcar Container Linux, un derivado de CoreOS Container Linux. Este sigue las versiones de los canales alfa, beta y estable de CoreOS, con un canal de lanzamiento Edge experimental agregado en mayo de 2019. [75]
LWN.net revisó CoreOS en 2014: [76]
Para quienes están armando sistemas distribuidos de gran tamaño (las aplicaciones web son un claro ejemplo), CoreOS parece tener muchas funciones interesantes. Debería permitir que las aplicaciones de ese tipo crezcan o se reduzcan según la demanda, además de proporcionar una plataforma estable donde las actualizaciones no sean un dolor de cabeza constante. Para las "implementaciones masivas de servidores", CoreOS, o algo con muchas de las mismas características, parece ser el futuro.
Anunciado en la conferencia DockerCon en San Francisco el lunes, el Open Container Project (OCP) mantendrá y desarrollará un entorno de ejecución de contenedores y un formato de imagen comunes basados en parte en el código y las especificaciones donadas por Docker.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
