x
1

CoreOS



Container Linux (anteriormente CoreOS Linux) es un sistema operativo código abierto basado en el núcleo Linux y diseñado para proporcionar infraestructura a implementaciones en clúster, mientras se enfoca en la automatización, facilidad de implementación de aplicaciones, seguridad, confiabilidad y escalabilidad. Como sistema operativo, Container Linux proporciona 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 configuración.[1][2][3][4]

Container Linux comparte fundamentos con Gentoo Linux,[5][6]Chrome OS y Chromium OS a través de un kit de desarrollo de software común (SDK). Container Linux agrega nuevas funciones y personalización a esta base compartida para admitir el hardware de servidor y los casos de uso.[3][7]​ A enero de 2015 , CoreOS es desarrollado activamente, principalmente por Alex Polvi, Brandon Philips y Michael Marineau, con sus principales características disponibles como versión estable.[8][9][10]

El equipo de desarrollo de CoreOS anunció el fin de ciclo de vida de Container Linux para el 26 de mayo de 2020,[11]​ ofreciendo como reemplazo las distribuciones Fedora CoreOS[12]​ o RHEL CoreOS, ambos basados en Red Hat.

Container Linux no proporciona un administrador de paquetes como una forma de distribuir aplicaciones de carga útil, lo que requiere 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 núcleo Linux para crear y configurar varios 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 namespaces del núcleo Linux,[13][14]​ que en conjunto proporcionan capacidades para limitar, contabilizar y aislar el uso de recursos (CPU, memoria, E/S de almacenamiento, etc.) para las colecciones de procesos de espacio de usuario.[2][4][15]

Inicialmente, Container Linux utilizó exclusivamente Docker como un componente que proporciona una capa adicional de abstracción e interfaz[16]​ a las características de virtualización a nivel del sistema operativo del núcleo Linux, además de proporcionar un formato estandarizado para contenedores que permite que las aplicaciones se ejecuten en diferentes ambientes.[2][15]​ En diciembre de 2014, CoreOS lanzó y comenzó a admitir rkt (inicialmente lanzado como Rocket) como una alternativa a Docker, proporcionando a través de él otro formato estandarizado de las imágenes del contenedor de aplicaciones, la definición relacionada del entorno de ejecución del contenedor y un protocolo para descubrir y recuperar imágenes de contenedores.[17][18][19][20]​ CoreOS proporciona rkt como una implementación de la denominada especificación del contenedor de aplicaciones (appc) que describe las propiedades requeridas de la imagen del contenedor de aplicaciones (ACI); CoreOS inició appc y ACI como un conjunto de especificaciones independiente dirigido por un comité,[21][22]​ objetivo de que se conviertan en parte de la Open Container Initiative (OCI) independiente del proveedor y del sistema operativo; inicialmente llamada Open Container Project o OCP [23]​ ) estándar de contenedorización, que se anunció   en junio de 2015. [24][25][26]

Container Linux usa scripts ebuild de Gentoo Linux para la compilación automatizada de los componentes de su sistema,[5][6]​ y usa systemd como su sistema de inicialización primario con una estrecha integración entre systemd y varios mecanismos internos de Container Linux.[2][27]

Container Linux logra 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 inicio secundaria pasiva que se convierte en activo tras un reinicio o kexec. Este enfoque evita posibles problemas derivados de la actualización en sólo ciertas partes del sistema operativo, asegura reversiones del sistema operativo y permite que cada partición de arranque sean firmadas digitalmente para mayor seguridad.[2][4][28]​ La partición raíz y su sistema de archivos raíz se redimensionan automáticamente para llenar todo el espacio disponible en disco al reiniciar; mientras que la partición raíz proporciona espacio de almacenamiento de lectura y escritura, el sistema operativo en sí está montado en modo solo lectura en /usr.[29][30][31]

Para garantizar que solo una determinada parte del clúster se reinicie a la vez cuando se apliquen las actualizaciones del sistema operativo, preservando de esa manera los recursos necesarios para ejecutar aplicaciones implementadas, CoreOS proporciona locksmith como administrador de reinicio para Container Linux.[32]​ Usando locksmith, uno puede seleccionar entre diferentes estrategias de actualización que están determinadas por cómo se realizan los reinicios como ú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 miembros del clúster, mientras que la utilidad de línea de comandos locksmithctl administra los parámetros de configuración.[33][34]​ Locksmith está escrito en Go y se distribuye según los términos de la licencia Apache 2.0.[35]

El sistema de distribución de actualizaciones empleado por Container Linux se basa en el proyecto Omaha de código abierto de Google, que proporciona un mecanismo para implementar actualizaciones y el protocolo de solicitud-respuesta subyacente basado en XML.[36][37][38]​ Además, CoreOS proporciona CoreUpdate como un panel de control basado en la web para la administración de actualizaciones en 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 los desgloses de las versiones de Container Linux en todo el clúster, la detención y reinicio de las actualizaciones y la revisión de los registros de actualización registrados. CoreUpdate también proporciona una API basada en HTTP que permite su integración en sistemas de implementación o utilidades de terceros.[28][39][40]

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ámica, lo que permite compartir de manera fácil y confiable varios datos de configuración entre los miembros del clúster.[36][29]​ Dado que los datos clave-valor almacenados en etcd se distribuye y replica automáticamente con la elección maestra automatizada y el 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.[20][42]​ 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 basada en REST expuesta, que utiliza internamente JSON sobre HTTP; la API se puede utilizar 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 proporcionada por CoreOS.[2][4][43][44][45]etcd también se usa en el software de Kubernetes.

Container Linux también proporciona el administrador de clúster fleet, el que controla las instancias de systemd separadas de Container Linux a nivel de clúster. A partir de 2017, fleet ya no se desarrolla activamente y está obsoleta en favor de Kubernetes.[46]​ Mediante el uso fleetd, Container Linux crea un sistema de inicio distribuido que une instancias de systemd separadas y un despliegue de etcd a nivel de clúster; [42]​ internamente, fleetd se comunica con las instancias systemd sobre D-Bus, y con la etcd través de su API expuesta. Utilizando fleetd, 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. Una utilidad de línea de comandos llamada fleetctl se utiliza para configurar y monitorear este sistema de inicio distribuido;[47]​ internamente, se comunica con el fleetd utilizando una API basada en JSON sobre HTTP, que también se puede utilizar directamente. Cuando se usa localmente en un miembro del clúster, fleetctl se comunica con otra instancia local de fleetd sobre un socket Unix; cuando se usa desde un host externo, la tunelización SSH se usa con autenticación proporcionada a través de claves SSH públicas.[48][49][50][51][52]

Todos los demonios y utilidades de línea de comandos mencionados anteriormente (etcd , etcdctl , fleetd y fleetctl) están escritos en el lenguaje Go y distribuidos bajo los términos de la Licencia Apache 2.0.[53]

Cuando se ejecuta en hardware dedicado, Container Linux se puede instalar permanentemente en el almacenamiento local, como una unidad de disco duro (HDD) o una unidad de estado sólido (SSD),[54]​ o se puede iniciar de forma remota a través de la red utilizando el entorno de ejecución de prearranque (PXE), o iPXE como una de sus implementaciones.[55][56]​ CoreOS también admite implementaciones en varias plataformas de virtualización de hardware, incluidas Amazon EC2, DigitalOcean, Google Cloud, Microsoft Azure, OpenStack, QEMU / KVM, Vagrant y VMware.[4][57][58][59]​ 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 administración de clústeres. A abril de 2015, se planeó ofrecer Tectonic como software beta para clientes selectos.[21][60]​ Además, CoreOS proporciona Flannel como un componente que implementa una red de superposición necesaria principalmente para la integración con Kubernetes.[61][62]

A febrero de 2015, Container Linux soporta solo la arquitectura x86-64.[36]

Tras la adquisición de CoreOS, Inc.[63]​ en enero de 2018, Red Hat anunció que fusionaría CoreOS Container Linux con Project Atomic de Red Hat,[64]​ para crear un nuevo sistema operativo, Red Hat CoreOS, mientras se alinea el upstream. La comunidad de código abierto del Proyecto Fedora en torno a Fedora CoreOS, que combina tecnologías de ambos predecesores.[65]

El 6 de marzo de 2018, Kinvolk GmbH anunció[66]​ Flatcar Container Linux, un derivado de CoreOS Container Linux. Esto realiza un seguimiento de las versiones upstream de CoreOS alpha/beta/estable, con un canal de lanzamiento experimental de Edge agregado en mayo de 2019.[67]

En mayo de 2020 se anunció el fin del ciclo de vida de Container Linux.[11]Red Hat lanzó Fedora CoreOS[12]​ y RHEL CoreOS como su reemplazo.



Escribe un comentario o lo que quieras sobre CoreOS (directo, no tienes que registrarte)


Comentarios
(de más nuevos a más antiguos)


Aún no hay comentarios, ¡deja el primero!