Virtualización para contenedores
- 13 minutos
La virtualización mediante hipervisores como Zen y Hyper-V crea particiones de un servidor físico en varios servidores virtuales y aísla las cargas de trabajo que se ejecutan en cada uno de ellos. Pero las máquinas virtuales tienen sus inconvenientes:
Requisitos de recursos: las máquinas virtuales requieren una gran cantidad de RAM. Si en un servidor de Windows se hospedan 10 máquinas virtuales Windows, Windows se carga en la memoria 11 veces: una copia para el propio servidor y una copia para cada una de las máquinas virtuales. Las máquinas virtuales no pueden compartir una única instancia en memoria del sistema operativo, ya que el objetivo de la virtualización es crear servidores virtuales que actúen de la misma forma que los servidores físicos. Dos máquinas virtuales no pueden compartir un sistema operativo más de lo que dos servidores físicos pueden hacerlo. Esto es así con independencia de que el sistema operativo sea Windows, Linux o cualquier otro (como macOS).
Facilidad de transporte: las imágenes de máquina virtual tienden a ser más grandes (a menudo de decenas o centenares de gigabytes), en parte porque también almacenan una copia completa del sistema operativo. Esto limita su facilidad de transporte. Una imagen de 1 MB se puede migrar fácilmente de un equipo a otro, incluso a través de una conexión moderadamente lenta. Por el contrario, una imagen de máquina virtual de 200 GB no se mueve fácilmente mediante una conexión de red típica. Se podría mover mediante un medio físico, como un stick USB o un disco duro, pero esto plantea desafíos logísticos en escenarios de informática en la nube en los que no se tiene acceso a los servidores físicos de un centro de datos.
Tiempo de inicio: el arranque de una máquina virtual es similar al de un equipo físico. El hardware virtualizado debe estar encendido e inicializado, el sistema operativo debe estar cargado e inicializado, los controladores de dispositivo deben estar cargados y conectados al hardware virtualizado, etc.Por tanto, después de crea una máquina virtual, puede requerir un minuto o más para iniciarse. Aunque el tiempo de inicio medido en minutos es insignificante en comparación con el tiempo necesario para adquirir, instalar y configurar un servidor físico, se trata de una limitación importante a la hora de crear máquinas virtuales sobre la marcha para satisfacer la creciente demanda o crear y destruir máquinas virtuales para atender las cargas de trabajo variables.
Estos son solo algunos de los motivos de la adopción generalizada de los contenedores, no solo en la informática en la nube, sino también en centros de datos locales y equipos individuales. En esta lección, se explica qué son los contenedores, cómo funcionan y las ventajas que ofrecen. También se presenta Docker, la plataforma de contenedores más popular del mundo y algunas de las formas en las que se ha integrado en las plataformas de nube más populares.
¿Qué es un contenedor?
Los contenedores están revolucionando el desarrollo de TI y de software. Permiten agrupar software y archivos en paquetes independientes conocidos como imágenes de contenedor que se ejecutan en equipos diferentes (reales o virtuales) y lo hacen de forma coherente y predecible. La descripción siguiente procede del sitio web de Docker:
Un contenedor es una unidad estándar de software que empaqueta el código y todas sus dependencias para que la aplicación se ejecute de forma rápida y confiable desde un entorno informático en otro. Una imagen de contenedor de Docker es un paquete de software ligero, independiente y ejecutable que incluye todo lo necesario para ejecutar una aplicación: código, entorno de ejecución, herramientas y bibliotecas del sistema y configuración.
Mientras que los hipervisores virtualizan el hardware, los contenedores virtualizan los sistemas operativos. En la figura 7 se muestran las diferencias principales entre las máquinas virtuales y los contenedores1. A la izquierda, un servidor hospeda una copia del sistema operativo y una copia del entorno de ejecución de Docker. También hospeda seis aplicaciones en seis contenedores, en los que se usa el sistema operativo del host. A la derecha, el mismo servidor hospeda tres máquinas virtuales, y cada una carga su propia copia del sistema operativo. Normalmente, un servidor determinado puede hospedar muchos más contenedores que las máquinas virtuales, debido a los menores requisitos de recursos de los contenedores.

Figura 7: contenedores frente a máquinas virtuales.
Los contenedores son similares a las máquinas virtuales, ya que proporcionan un entorno predecible y aislado en el que se puede ejecutar el software. Pero como los contenedores son más pequeños que las máquinas virtuales, requieren menos RAM y se mueven más fácilmente entre equipos. También se inician con mayor rapidez (a menudo en un par de segundos) porque no tienen que virtualizar el hardware ni cargar e inicializar un sistema operativo. Varios contenedores que se ejecutan en una sola máquina comparten el mismo kernel del sistema operativo, incluso si los propios contenedores son completamente diferentes, es decir, contienen software distinto y se crean a partir de imágenes de contenedor distintas.
Los contenedores y las máquinas virtuales no son mutuamente excluyentes. De hecho, se suelen usar de forma conjunta. Los usuarios de Windows que ejecutan software empaquetado en contenedores de Linux ejecutan Linux en una máquina virtual y hospedan Docker y el software en contenedores en la máquina virtual. En la nube, los contenedores se hospedan en máquinas virtuales como otras cargas de trabajo en la nube.
Los contenedores no reemplazan a las máquinas virtuales ni se deben considerar equivalentes funcionales. A diferencia de las máquinas virtuales, los contenedores no permiten que varios sistemas operativos se ejecuten en paralelo en el mismo equipo. Por ejemplo, si el equipo host ejecuta Linux, todos los contenedores de ese equipo también deben usar Linux. (Los usuarios de Windows suelen ejecutar contenedores de Linux en Windows, pero funciona porque Docker ejecuta una máquina virtual Linux en el equipo con Windows y hospeda los contenedores en la máquina virtual). Además, como los contenedores no virtualizan el hardware, no son adecuados para las aplicaciones que realizan tareas de nivel de sistema que implican una interacción directa con el hardware. Una manera sencilla de pensar en ello es que los hipervisores virtualizan un equipo completo, incluido su hardware, mientras que los contenedores virtualizan el software y usan el sistema operativo del host como plataforma de sistema operativo.
Docker
Docker es, de lejos, la plataforma de contenedores más popular. Es gratuita y de código abierto, y se ejecuta en todas las distribuciones principales de Linux, así como en Windows Server 2016. En 2015, Docker donó la especificación de imagen de contenedor y el código del entorno de ejecución a la iniciativa Open Container Initiative (OCI) para ayudar a normalizar y aumentar el ecosistema de contenedores. En 2017, Docker donó un entorno de ejecución de contenedor estándar del sector a la fundación Cloud Native Computing Foundation (CNCF). Ese entorno de ejecución se creó para ser sencillo, robusto y portable.
En la figura 8 se muestra cómo se diseña un sistema que ejecuta aplicaciones en contenedores de Docker. Comienza con el cliente de Docker, una herramienta que se usa para crear, ejecutar y administrar contenedores e imágenes de contenedor. (Una imagen de contenedor constituye un plano técnico para un contenedor en ejecución, de la misma forma que una imagen de máquina virtual define lo que se carga en una máquina virtual en ejecución). Existen varios clientes de Docker, incluida la propia interfaz de la línea de comandos de Docker, que se ejecuta en todos los sistemas operativos conocidos, y Kitematic, que incluye una interfaz gráfica de usuario y se ejecuta en Windows y macOS. Docker adquirió Kitematic en 2015 y lo incorporó a Docker Toolbox, que está disponible de forma gratuita.

Figura 8: arquitectura de Docker.
Una vez que se ha creado una imagen de contenedor, se carga en un repositorio de un registro de contenedor. El propósito de un registro de contenedor es almacenar imágenes de contenedor y hacer que estén disponibles de forma pública o privada. Docker ofrece un registro de contenedores basado en la nube, conocido como Docker Hub, que proporciona a los usuarios repositorios públicos gratuitos ilimitados y un repositorio privado gratuito. También permite, e incluso fomenta, que otros usuarios creen registros propios y ofrece Docker Registry (de código abierto) para ayudarles en su trabajo. Es una de las razones por la que los principales proveedores de servicios en la nube, como Amazon, Microsoft y Google, han podido ofrecer registros compatibles con Docker en sus plataformas en la nube.
Para iniciar un contenedor, se usa el cliente de Docker para emitir un comando al demonio de Docker y especificar la imagen a partir de la que se debe crear el contenedor. (Un demonio es un programa que se ejecuta en segundo plano en el equipo host). Después, el demonio crea un contenedor y carga la imagen en él. Una vez en ejecución, un contenedor se puede iniciar y detener mediante la emisión de comandos desde el cliente de Docker. El cliente y el demonio de Docker no tienen que residir en el mismo equipo. En un escenario típico, el cliente se ejecuta en un equipo mientras el demonio se ejecuta en un servidor remoto y el cliente usa el protocolo Secure Shell (SSH) para transmitir comandos al demonio.
Servicios de contenedor en la informática en la nube
Aunque los usuarios pueden adoptar un enfoque de IaaS para los contenedores mediante la creación de máquinas virtuales y la instalación del entorno de ejecución de Docker en ellas, los proveedores de servicios en la nube, para reconocer la importancia de los contenedores, ofrecen servicios PaaS para admitir la ejecución en la nube de aplicaciones en contenedores. Azure ofrece Azure Container Instances, que proporcionan un entorno sólido, escalable y fácil de usar para hospedar aplicaciones en contenedor, así como Azure Container Registry, que permite hospedar imágenes de contenedor en Azure en lugar de Docker Hub u otros registros externos, así como cargarlas rápidamente en Azure Container Instances. Amazon ofrece AWS Elastic Container Registry (ECR) y AWS Elastic Container Service (ECS), mientras que Google ofrece Container Registry y Contenedores en Compute Engine.
En la figura 9 se muestra cómo funcionan REC y ECS de Amazon para proporcionar una pila de Docker basada en la nube para hospedar contenedores e imágenes de contenedor2. Las imágenes de contenedor se compilan y se cargan en REC, que es un registro de contenedor compatible con Docker similar a Docker Hub. (Las imágenes de contenedor que se ejecutan en AWS no tienen que almacenarse en REC, pero su almacenamiento ofrece varias ventajas, como el control de acceso específico mediante la identidad de AWS, el cifrado automático, la compatibilidad con el control de versiones de las imágenes de contenedor y la carga más rápida, especialmente si las imágenes de contenedor se almacenan y se ejecutan en el mismo centro de datos). Desde ahí, las imágenes se cargan en contenedores hospedados en ECS u otros servicios en la nube.
Figura 9: contenedores en AWS.
Azure Container Registry y Azure Container Instances funcionan de forma muy similar, pero usan Microsoft Entra en lugar de la identidad de AWS para controlar el acceso a las imágenes de contenedor. Una diferencia entre la compatibilidad con contenedores en AWS y Azure es que AWS usa una combinación de software de código abierto y tecnología propia, mientras que la pila de contenedores de Azure se crea totalmente a partir de código abierto. Por tanto, cualquier herramienta que funcione con Docker funciona también con Azure. Además, Azure Cloud Shell y la CLI de Azure disponen de comandos para crear y administrar imágenes de contenedor de Docker. Estos comandos no obvian completamente la necesidad de clientes de Docker, pero cubren los casos de uso más comunes y están optimizados para Azure.
Más recientemente, los proveedores de servicios en la nube han empezado a agregar compatibilidad con contenedores a servicios PaaS concretos. Por ejemplo, Azure ofrece Azure Web App for Containers, que básicamente es Azure App Service con la capacidad adicional de cargar software desde una imagen de contenedor. Amazon ha realizado pasos similares para integrar contenedores de Docker con Elastic Beanstalk.
Orquestación de contenedores
Docker proporciona la infraestructura para compilar y ejecutar contenedores, pero se necesita un mayor nivel de supervisión para coordinar las acciones de los contenedores y escalar las cargas de trabajo en contenedores de la misma manera que se escalan las máquinas virtuales. Aunque existe una variedad de herramientas de orquestación de contenedores, el sector se ha decantado en gran medida por Kubernetes, que surgió de un proyecto de código abierto de Google, como orquestador preferido. Hoy en día, los principales proveedores de servicios en la nube ofrecen implementaciones administradas de Kubernetes que facilitan la ejecución de contenedores en sus plataformas y su administración con Kubernetes. En la figura 9, "EKS" equivale a Elastic Kubernetes Service (Servicio Kubernetes elástico). Azure ofrece un servicio complementario denominado Azure Kubernetes Service (AKS), mientras que Google Cloud Platform ofrece Kubernetes Engine.
Referencias
- Docker (2019). ¿Qué es un contenedor?https://www.docker.com/resources/what-container
Amazon (2019). Cómo funciona Amazon ECS. https://aws.amazon.com/ecs/.
Comprobación de conocimientos
Comentarios
¿Le ha resultado útil esta página?
No
¿Necesita ayuda con este tema?
¿Desea intentar usar Ask Learn para aclarar o guiarle a través de este tema?
