Apuntes AWS y resumen de sus servicios
12 ejemplos de comando cURL

Una breve historia de los contenedores

Historia de los contenedores

La breve historia de los contenedores se publicó por primera vez en el blog Aquasec en 2017, el panorama tecnológico de los contenedores era muy diferente al actual.

En los últimos dos años, hemos visto cómo se han producido cambios significativos que afectaron, y siguen afectando, a la forma en que se adoptan los contenedores. Al entrar en la nueva década, queremos recapitular los cambios y desarrollos que vimos y ofrecer nuestra visión de hacia dónde creemos que se dirigen los Contenedores en 2020.

Para este viaje, súbete a mi máquina del tiempo DeLorean y viajemos a 1979, cuando surgió el concepto de los contenedores.

1979: Unix V7

Nota para el lector, sí, tenía menos de 10 años en ese momento. Durante el desarrollo de Unix V7 en 1979, se introdujo la llamada al sistema chroot, que cambiaba el directorio raíz de un proceso y sus hijos a una nueva ubicación en el sistema de archivos. Este avance fue el inicio del aislamiento de procesos: segregando el acceso a los archivos para cada proceso. Chroot se añadió a BSD en 1982.

unix v7

2000: Las jaulas de FreeBSD

Avancemos casi dos décadas hasta el año 2000, cuando un pequeño proveedor de alojamiento de entorno compartido ideó las jaulas de FreeBSD para lograr una clara separación entre sus servicios y los de sus clientes por motivos de seguridad y facilidad de administración. Las jaulas de FreeBSD permiten a los administradores dividir un sistema informático FreeBSD en varios sistemas independientes y más pequeños -llamados «jaulas»- con la posibilidad de asignar una dirección IP para cada sistema y configuración.

jails freebsd

2001: Linux VServer

Al igual que las jaulas de FreeBSD, Linux VServer es un mecanismo de jaula que puede particionar recursos (sistemas de archivos, direcciones de red, memoria) en un sistema informático. Introducido en 2001, esta virtualización del sistema operativo que se implementa mediante parches en el kernel de Linux. Todavía existen parches experimentales, pero el último parche estable se publicó en 2006.

2004: Contenedores Solaris

En 2004, se lanzó la primera beta pública de Solaris Containers, que combina los controles de los recursos del sistema y la separación de los límites proporcionada por las zonas, lo que permitió aprovechar características como las instantáneas y la clonación de ZFS.

2005: Open VZ (Open Virtuzzo)

Se trata de una tecnología de virtualización a nivel de sistema operativo para Linux que utiliza un kernel Linux parcheado para la virtualización, el aislamiento, la gestión de recursos y el checkpointing. El código no se publicó como parte del núcleo oficial de Linux.

2006: Contenedores de procesos

Process Containers (lanzado por Google en 2006) fue diseñado para limitar, contabilizar y aislar el uso de recursos (CPU, memoria, E/S de disco, red) de una colección de procesos. Un año más tarde pasó a llamarse «Grupos de control (cgroups)» y finalmente se incorporó al núcleo de Linux 2.6.24.

2008: LXC

LXC (LinuX Containers) fue la primera y más completa implementación del gestor de contenedores de Linux. Se implementó en 2008 utilizando cgroups y espacios de nombres de Linux, y funciona en un único núcleo de Linux sin requerir ningún parche.

2011: Warden

CloudFoundry puso en marcha Warden en 2011, utilizando LXC en sus inicios y sustituyéndolo posteriormente por su propia implementación. Warden puede aislar entornos en cualquier sistema operativo, ejecutándose como un demonio y proporcionando una API para la gestión de contenedores. Desarrolló un modelo cliente-servidor para gestionar una colección de contenedores a través de múltiples hosts, y Warden incluye un servicio para gestionar cgroups, namespaces y el ciclo de vida del proceso.

2013: LMCTFY

Let Me Contain That For You (LMCTFY) se puso en marcha en 2013 como una versión de código abierto de la pila de contenedores de Google, proporcionando contenedores de aplicaciones de Linux. Las aplicaciones pueden hacerse «conscientes de los contenedores», creando y gestionando sus propios subcontenedores. El despliegue activo en LMCTFY se detuvo en 2015 después de que Google comenzara a contribuir con los conceptos centrales de LMCTFY a libcontainer, que ahora forma parte de la Open Container Foundation.

Docker

Cuando Docker surgió en 2013, los contenedores explotaron en popularidad. No es casualidad que el crecimiento de Docker y el uso de contenedores vayan de la mano.

Al igual que Warden, Docker también utilizó LXC en sus inicios y posteriormente sustituyó ese gestor de contenedores por su propia librería, libcontainer. Pero no hay duda de que Docker se separó del resto al ofrecer todo un ecosistema para la gestión de contenedores.

dead docker

2016: Se revela la importancia de la seguridad de los contenedores

Con la amplia adopción de aplicaciones basadas en contenedores, los sistemas se volvieron más complejos y el riesgo aumentó, sentando las bases para la seguridad de los contenedores. Vulnerabilidades como la de dirty COW no hicieron más que fomentar esta idea. Esto condujo a un cambio hacia la izquierda en la seguridad a lo largo del ciclo de vida del desarrollo de software, convirtiéndola en una parte clave de cada etapa en el desarrollo de aplicaciones en contenedores, también conocido como DevSecOps. El objetivo es construir contenedores seguros desde el principio sin reducir el tiempo de comercialización.

2017: Las herramientas para contenedores maduran

Se han desarrollado cientos de herramientas para facilitar la gestión de contenedores. Aunque este tipo de herramientas existen desde hace años, 2017 es el año en el que muchas de ellas se han ganado sus galones. No hay más que ver Kubernetes; desde su adopción en la Fundación de Computación Nativa en la Nube (CNCF) en 2016, VMWare, Azure, AWS e incluso Docker han anunciado su apoyo, además de sus infraestructuras.

Mientras el mercado sigue creciendo, algunas herramientas han llegado a definir ciertas funciones en la comunidad de contenedores. Ceph y REX-Ray establecen estándares para el almacenamiento de contenedores, mientras que Flannel conecta millones de contenedores a través de los centros de datos. Y en CI/CD, Jenkins está cambiando por completo la forma de construir y desplegar aplicaciones.

Adopción de rkt y Containerd por la CNCF

El ecosistema de contenedores es único, ya que está impulsado por un esfuerzo y un compromiso de toda la comunidad con los proyectos de código abierto. La donación por parte de Docker del proyecto Containerd al CNCF en 2017 es emblemática de este concepto, así como la adopción por parte del CNCF del tiempo de ejecución de contenedores rkt (pronunciado «rocket») en la misma época. Esto ha llevado a una mayor colaboración entre proyectos, más opciones para los usuarios y una comunidad centrada en la mejora del ecosistema de contenedores.

Kubernetes crece

En 2017, el proyecto de código abierto demostró grandes avances para convertirse en una tecnología más madura. Kubernetes admite clases de aplicaciones cada vez más complejas, lo que permite la transición de las empresas tanto a la nube híbrida como a los microservicios. En la DockerCon de Copenhague, Docker anunció que dará soporte al orquestador de contenedores Kubernetes, y Azure y AWS se alinearon, con AKS (Azure Kubernetes Service) y EKS, un servicio Kubernetes para rivalizar con el ECS propietario. También fue el primer proyecto adoptado por el CNCF y comanda una lista creciente de proveedores de servicios de integración de sistemas de terceros.

kubernetes

2018: El estándar de oro

En 2018, la contenerización se convirtió en la base de la infraestructura de software moderna y Kubernetes se utilizó para la mayoría de los proyectos de contenedores empresariales. En 2018, el proyecto Kubernetes en GitHub tenía más de 1500 contribuyentes, con una de las comunidades de código abierto más significativas, con más de 27000 estrellas. La adopción masiva de Kubernetes empujó a los proveedores de la nube como AWS, Google con GKE (Google Kubernetes Engine), Azure y Oracle con Container Engine for Kubernetes, a ofrecer servicios gestionados de Kubernetes. Además, los principales proveedores de software como VMWare, RedHat y Rancher comenzaron a ofrecer plataformas de gestión basadas en Kubernetes.

El proveedor de infraestructura VMware avanzó hacia la adopción de Kubernetes cuando a finales de 2018 anunció que adquiría Heptio, una consultora que ayuda a las empresas a desplegar y gestionar Kubernetes.

También fuimos testigos de las tecnologías híbridas emergentes que combinan el aislamiento tipo VM con la velocidad de los contenedores. Los proyectos de código abierto como los contenedores Kata, gVisor y Nabla intentan proporcionar tiempos de ejecución de contenedores seguros con máquinas virtuales ligeras que funcionan de la misma manera que los contenedores, pero proporcionan un aislamiento más fuerte de la carga de trabajo.

2019: Un paisaje cambiante

El año marcó cambios significativos en el panorama de los contenedores. Nuevos motores de tiempo de ejecución comenzaron a reemplazar el motor de tiempo de ejecución de Docker, sobre todo containerd, un motor de tiempo de ejecución de contenedores de código abierto, y CRI-O, un motor de tiempo de ejecución ligero para Kubernetes.

En 2019 vimos cómo se producía un cambio tectónico en el panorama de los contenedores, cuando Docker Enterprise fue adquirida y escindida, lo que provocó que Docker Swarm se pusiera en un horizonte de fin de vida de 2 años. Al mismo tiempo, asistimos al declive de la popularidad del motor de contenedores rkt, aunque oficialmente sigue formando parte del establo del CNCF.

VMware redobló su apuesta por Kubernetes adquiriendo primero Heptio y luego Pivotal Software (tanto con PAS como con PKS). El objetivo de este movimiento es ofrecer a las empresas la posibilidad de aprovechar las capacidades similares a las de la nube de las implantaciones nativas en sus entornos locales.

El año pasado también vimos avances en la adopción de la tecnología sin servidor con plataformas como Knative, una plataforma de gestión de cargas de trabajo sin servidor basada en Kubernetes, que ganó tracción entre las organizaciones.

En 2019 se lanzaron soluciones de nube híbrida basadas en Kubernetes, como IBM Cloud Paks , Google Anthos , Aws Outposts y Azure Arc. Estas plataformas en la nube desdibujan las líneas tradicionales entre la nube y los entornos on-prem , ya que ahora se pueden gestionar clústeres en la nube on-prem y de un solo proveedor.

Creemos que la aparición de estas nuevas capacidades representa el siguiente paso en la evolución de Kubernetes. Las nuevas capacidades de la nube, como Anthos, Arc y Outposts, apuntan hacia el futuro de la hiperabstracción, en el que los recursos informáticos se desvinculan de la capa de gestión, de forma similar a como funciona Kubernetes, que desvincula las cargas de trabajo del lugar donde se gestionan.

En el Kubernetes actual, el nodo maestro se encuentra en el mismo clúster físico que el nodo trabajador. Con la hiperabstracción, el plano de gestión de la carga de trabajo gestionará las cargas de trabajo en nodos que pueden estar distribuidos entre varias infraestructuras informáticas, y el usuario no sabrá ni le importará dónde se ejecutan físicamente.

A juzgar por el récord de más de 12.000 asistentes a la KubeCon de San Diego, creemos que Kubernetes se convertirá en la plataforma de gestión estándar para contenedores, máquinas virtuales y otras cargas de trabajo nativas de la nube.

Traducción del Artículo de Rani Osnat

Más apuntes

Invítame a un café con bitcoins:
1QESjZDPxWtZ9sj3v5tvgfFn3ks13AxWVZ

Bitcoins para café
También puedes invitarme a algo para mojar...

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Rellena este campo
Rellena este campo
Por favor, introduce una dirección de correo electrónico válida.
Tienes que aprobar los términos para continuar