Notas pertenecientes al curso Docker a fondo e Introducción a Kubernetes: aplicaciones basadas en contenedores

Para seguir correctamente el curso, el único prerrequisito es disponer de un ordenador con cualquier sistema operativo reciente actualizado y Docker Engine (en Linux) o Docker Desktop instalado (en Linux, Windows o MacOS).

Docker Engine existe para Linux mientras que Docker Desktop existe para Linux, MacOS y Windows, por lo que el sistema operativo que uses no es problema (aunque más adelante habrá ciertos apartados propios de Windows únicamente).

Adicionalmente se asume cierta experiencia en la interfaz de línea de comandos (terminales bash en Linux/macOS; símbolo del sistema y Powershell en Windows).

El curso se puede seguir en cualquier sistema operativo, ya sea Windows, Linux o Mac. En el caso de entornos Windows la única condición es que Docker for Desktop se pueda instalar en la versión concreta de Windows.

La gran mayoría del curso aplica igual y sin diferencias a los tres sistemas operativos, pero hay algunos aspectos avanzados que pueden referirse a sólo uno de ellos:

• Cuando hablemos de contenedores Windows, el contenido afecta solamente a Windows, ya que es el único SO que puede ejecutarlos.
• Cuando hablemos de aspectos avanzados (en concreto temas de seguridad y permisos), los contenidos harán referencia básicamente a Linux, ya que es el SO donde se pueden experimentar y ver con más facilidad (al no haber una capa intermedia que ejecute los contenedores). En Windows y Mac, algunos temas referentes a seguridad experimentan ligeras variaciones que dependen exactamente de la configuración del sistema.
• Cuando hablemos de cómo funcionan los contenedores, nos referimos básicamente a contenedores Linux. Aunque en el apartado de “Contenedores Windows” se menciona un poco el funcionamiento de contenedores Windows, en el resto del curso se asume que estás usando contenedores Linux (aunque tu máquina sea Windows o Mac)

Para instalar Docker Engine, dirígete a la documentación de Docker y sigue las instrucciones correspondientes a tu distro de Linux.

Para instalar Docker Desktop, dirígete a la página de Docker Desktop y sigue las instrucciones de tu sistema operativo.

Como se ha comentado antes, Docker Desktop es más bien un conjunto unificado de varios productos destinados a permitir el uso de Docker Engine en aquellos sistemas donde no se encuentra disponible. Eso te puede sonar confuso, así que voy a intentar explicártelo

Docker Engine existe solo para Linux (y Windows Server, aunque podemos obviarlo por el momento: trataremos ese caso en el módulo opcional de contenedores Windows). Así, si trabajas en Linux, te basta con instalar directamente Docker Engine y obtienes los siguientes componentes:

• El cliente (el comando docker), que usa la línea de comandos (CLI).
• El componente servidor, que crea y ejecuta los contenedores.

El cliente de línea de comandos (docker) sí que existe para Windows y MacOS, pero obviamente requiere del componente servidor y ese solo existe en Linux. Dado que los contenedores los ejecuta el servidor y un contenedor no virtualiza, eso implica una cosa: solo puedes usar contenedores que sean binarios Linux.

Entonces la situación que tenemos es que, realmente se requiere de Linux para ejecutar contenedores. Pero la gente de Docker era (y es) consciente de que muchos desarrolladores usan Windows o MacOS y de ahí que sacaran Docker Desktop para esos dos sistemas. Docker Desktop permite ejecutar la parte servidora de Docker en Windows o MacOS. Dado que esta parte servidora existe solo en Linux, Docker Desktop recurre a la virtualización para conseguirlo.

Así, cuando instalas Docker Desktop, se instala también una máquina virtual (MV) Linux en tu sistema y esa MV es la que ejecutará la parte servidora de Linux, y por lo tanto los contenedores. Al instalar Docker Desktop también obtenemos el cliente nativo (el comando docker, para Windows o MacOS), configurado de tal modo que automáticamente se conecta a dicha MV sin que nosotros tengamos que hacer nada: tú usas el comando docker desde una línea de comandos Windows o un terminal de MacOS y automáticamente se comunica con la parte servidora ejecutándose en la VM. Esa MV la configura y aprovisiona Docker Desktop automáticamente y no tienes que hacer nada con ella (ni pararla, ni configurarla, ni encenderla, ni nada de nada).

• En Windows puedes usar Hyper-V o WSL2 siendo ese último el modo recomendado por rendimiento
• En MacOS usa xhyve
• En Linux usa KVM (sí, Docker Desktop en Linux también usa una máquina virtual)

Además, Docker Desktop añade los siguientes componentes:

• Una pequeña interfaz gráfica de configuración en el caso de Docker Desktop (inexistente en Docker Engine)
• La integración de herramientas adicionales como Synk o Compose
• La posibilidad de ejecutar un Kubernetes de desarrollo

Pero lo que debes tener claro es que cuando hablamos de crear y administrar contenedores no hay diferencia alguna entre Docker Desktop y Docker Engine.

Resumiendo: Docker Desktop es un producto que integra Docker Engine junto con una VM para permitir de forma fácil el uso de contenedores Linux en Windows y MacOS. Además, tiene pequeños añadidos como una pequeña interfaz gráfica y la posibilidad de ejecutar un Kubernetes de desarrollo.

A diferencia de Docker Engine, Docker Desktop no es un producto gratuito en todos los casos. Recuerda que no existe Docker Engine para Windows o MacOS, así que, dependiendo de la situación de tu empresa, es posible que esta deba licenciar el producto. Digo “empresa” porque Docker ha declarado que tiene la intención de que el producto siga siendo gratuito para “uso personal o de enseñanza” y, efectivamente, así es. En la página de precios puedes consultar las distintas opciones y en qué casos es obligatorio alguno de los planes de pago. Esos planes incorporan algunas características adicionales, así que también se puede dar el caso de que a tu empresa le interese contratar alguno de ellos a pesar de no estar legalmente obligada. En la página de precios están detallados todos los planes, sus características y en qué casos es legalmente obligatorio contratar alguno de ellos.

Para verificar qué Docker está instalado en tu máquina, abre una CLI y teclea:

docker --version

Deberías ver la versión de Docker instalada. Cualquier versión mínimamente moderna te servirá para seguir el curso. Te recomiendo que uses la última que esté disponible para poder aprovechar todas sus características.

  Diálogo de version de Docker Desktop

El soporte para contenedores en Windows llegó con Windows Server 2016 y Windows 10 Anniversary Edition. Eso significa que un contenedor Windows (un contenedor que tenga binarios de Windows) solo puede ser ejecutado si tienes una versión del sistema operativo igual o posterior a las indicadas. Eso implica que en Linux el escenario de los contenedores está bastante avanzado y en Windows lleva menos tiempo en funcionamiento.

En general, si tienes una versión reciente y actualizada de Windows (que sería lo recomendable), deberías instalar Docker Desktop integrado con el subsistema Linux de Windows (WSL 2), como veremos ahora mismo.

WSL es el subsistema Linux de Windows. Gracias a WSL es posible ejecutar nativamente aplicaciones de Linux, e incluso distribuciones completas, dentro de Windows, y sin necesidad de virtualizar o configurar un arranque dual. Es decir, gracias a WSL puedes tener a la vez Windows y Linux funcionando en tu equipo. La versión inicial de WSL, de 2016, no implementaba el Kernel completo de Linux, pero daba bastante margen para trabajar.

En 2020 Microsoft lanzó la versión 2 de la tecnología. WSL 2 está disponible en cualquier versión de Windows 10 o posterior cuyo número de build sea igual o superior a 18917.

Si tienes una versión de Windows que NO disponga de WSL 2, o no quieres activarla por algún motivo, entonces se va a instalar Hyper-V en tu máquina.

Debemos entender que cuando instalamos Docker Desktop for Windows sin WSL 2, terminamos teniendo dos sistemas Docker independientes:

• La máquina virtual DockerDesktopVM que contiene imágenes Linux y ejecuta contenedores Linux
• Nuestro ordenador, que contiene imágenes Windows y ejecuta contenedores Windows

Una vez instalado, para que funcione, tu usuario deberá pertenecer al grupo docker-users, un grupo de seguridad especialmente creado para ejecutar Docker.

• Docker Engine
• Docker Desktop

Tras instalar Docker Engine es posible que obtengamos un error de permisos al ejecutarlo porque no podamos conectarnos al pipe /var/run/docker.sock que es el mecanismo que utiliza la CLI de Docker para comunicarse con el servidor.

Por supuesto tener que usar sudo no es lo ideal. Para evitarlo y poder usar Docker sin permisos de root, debes añadir el usuario actual al grupo de usuarios docker:

sudo usermod -aG docker $USER

Al igual que ocurre en Windows y en Mac, Docker Desktop en Linux utiliza una máquina virtual (VM) para ejecutar contenedores (concretamente utiliza KVM). Eso te puede sorprender un poco, pues Linux ya tiene soporte de contenedores en el propio sistema operativo, así que, no habría motivo alguno a priori para usar una VM (se pueden ejecutar los contenedores directamente, tal y como hace Docker Engine). Los motivos por los cuales Docker Desktop usa una VM en Linux son los siguientes:

• Para controlar el SO subyacente: al usar una VM controlada por Docker Desktop, es posible asegurar que todos los usuarios van a tener el mismo SO con la misma versión (especialmente del kernel de Linux), lo que permite a Docker garantizar que todas las funcionalidades funcionan igual para cualquier usuario. También permite a Docker garantizar, en la medida de lo posible, que las características de Docker Desktop serán lo más similar posible en los 3 entornos (Windows, MacOS y Linux).
• Por seguridad: al ejecutarse los contenedores en el entorno aislado de una VM, cualquier acción maliciosa que un contenedor pudiese realizar se verá limitada.

Docker Desktop y Docker Engine funcionando a la vez: Para indicarle a la CLI sobre qué entorno actuar (si Docker Engine o Docker Desktop) se usa el comando docker context.

Si queremos parar Docker Engine:

systemctl stop docker docker.socket containerd

Y deshabilitarlo del inicio:

systemctl disable docker docker.socket containerd

Si quisiéramos habilitarlo de nuevo:

systemctl enable docker docker.socket containerd

Y arrancarlo:

systemctl start docker docker.socket containerd

Docker es una herramienta para crear, administrar y ejecutar contenedores. Así, que lo primero que debemos tener claro es, qué entendemos por “contenedor”.

Una comparación típica es comparar un contenedor con una máquina virtual (MV). La siguiente imagen ilustra dicha comparación:

IMAAAAAAAAAAAAGEN

Las semejanzas entre un contenedor y una MV son las siguientes:

• Ambos proveen un entorno aislado para la ejecución de programas.
• Ambos pueden moverse entre hosts de forma segura: si una MV o un contenedor se ejecuta correctamente en un host lo hará en todos los demás.

Por eso muchas veces se dice que los contenedores son “máquinas virtuales ligeras”, pero eso dista mucho de la verdad. La realidad es que existen más diferencias que semejanzas entre una MV y un contenedor:

• Una MV puede ejecutar un SO distinto del que hay en el huésped. Puedo ejecutar Linux en una MV en un host Windows o Mac y viceversa. Técnicamente, cualquier combinación entre sistema operativo host y sistema operativo que ejecuta la MV es posible (otra cosa es que haya algunas restricciones de licencia, como ocurre con MacOS). Por su parte, un contenedor solo puede ejecutar binarios de la misma arquitectura que el sistema operativo host. Es decir, si ejecutamos Docker en Linux, solo vamos a poder ejecutar binarios Linux (y de la misma arquitectura) en los contenedores. Lo mismo ocurre en Windows y en Mac, por supuesto.
• Una MV ejecuta un SO completo y dentro de ese SO ejecuta varios procesos. Por su parte, un contenedor ejecuta un solo proceso. Cuando ese proceso finaliza, el contenedor “muere” (aunque es cierto que este proceso raíz puede iniciar otros procesos).
• Efectivamente, tanto MV como contenedores ofrecen un entorno aislado para la ejecución de aplicaciones. Pero, a diferencia de las MV, en los que cada MV tiene toda la infraestructura (memoria, procesador, red, …), los contenedores comparten dicha infraestructura, que es proveída por el host. Por eso, a diferencia de una MV, no vas a establecer “la memoria de un contenedor” o “su tamaño de disco” (aunque sí puedes establecer límites de memoria o CPU).

En definitiva, y a pesar de la comparación, los contenedores no son una tecnología de virtualización. No compiten (ni lo pretenden) con las máquinas virtuales. Juegan un rol distinto.

Dejemos pues de ver los contenedores como un sistema de virtualización y pasemos a verlos como una manera de empaquetar una aplicación y todas sus dependencias. Así, un contenedor es un mecanismo para distribuir una aplicación y todas sus dependencias de forma que dicha aplicación pueda funcionar en cualquier máquina, sin necesidad de que esta tenga instalada nada más que un entorno de ejecución de contenedores, es decir, Docker.

Cuando empaquetas una aplicación en un contenedor, dicho contenedor contiene la aplicación y todas sus dependencias, es decir:

• Una copia de la base del SO. Si es una aplicación para Linux, el contenedor contendrá una distro base de Linux. La llamo “base” porque no es necesario que sea una “distro” completa, solo que tenga lo mínimo necesario para poder ejecutar aplicaciones.
• Una copia de todas las bibliotecas necesarias para tu aplicación. Si tu aplicación depende de foo.so o de bar.dll esos ficheros estarán en el contenedor.
• El código de tu aplicación, así como cualquier recurso adicional necesario.

Quizá te preguntes cuál es la ventaja de empaquetar aplicaciones en contenedores. Pues, básicamente, asegurar la independencia del contenedor respecto al host. Esto es muy interesante en escenarios con hosts que ejecutan varias aplicaciones.

Lo que es importante recalcar es que, al final, un contenedor es un artefacto binario, que por lo tanto podremos mover y copiar entre hosts.

En 2015 se creó la OCI (Open Container Initiative), un organismo participado por varias empresas (entre ellas Docker, pero también los grandes “players” como RedHat, IBM o Google) con el objetivo de definir estándares de contenedores, de forma que puedan compartirse contenedores e imágenes creados mediante distintas tecnologías.

Existen varios proyectos de contenedores que creo importante mencionar, para que veas que el mundo de los contenedores no se reduce a Docker:

• rkt: lo pongo aquí por motivos de completitud, ya que fue la primera gran alternativa a Docker. Vino de la mano de CoreOS (ahora RedHat) y llegó incluso a ser un proyecto incubatorio de la CNCF, pero su desarrollo se ha parado y por lo tanto no es una opción que debas considerar.
• podman: quizá la alternativa más sugerente a Docker. La ventaja principal con respecto a Docker es que no requiere de ningún daemon, lo que simplifica su arquitectura y le da mucha versatilidad. Por supuesto, las imágenes construidas con Docker son compatibles con podman y viceversa, ya que ambos sistemas son compatibles con OCI. Permite la ejecución no solo de contenedores, sino de otro concepto llamado pod (relacionado con Kubernetes).
• kaniko: a diferencia de podman y Docker, Kaniko no es un sistema para crear y ejecutar contenedores, sino un sistema para construir imágenes OCI. Está diseñado para ejecutarse en Kubernetes y permitir la ejecución de pipelines de CI/CD que construyan imágenes de contenedores en Kubernetes.
• buildah: se trata de otro sistema para construir imágenes OCI, al igual que Kaniko. Es de la gente de RedHat: de hecho, al construir una imagen con podman se usa buildah por debajo (de forma transparente). Pero, no es requisito usarlo junto con podman, puedes hacerlo de forma separada, y dado que no requiere daemon es una alternativa muy interesante en determinados escenarios (p. ej. Kubernetes).

Las arquitecturas orientadas a microservicios son una de las tendencias más en boga actualmente. Es importante destacar que el uso de contenedores no implica estar desarrollando en una arquitectura orientada a microservicios y viceversa: se pueden implementar arquitecturas de microservicios sin el uso de contenedores.

Una arquitectura de microservicios requiere que cada microservicio pueda ser desarrollado, desplegado y actualizado de forma independiente. Los contenedores ayudan en los dos últimos puntos al ofrecer un entorno totalmente aislado e independiente en el que empaquetar, desplegar y actualizar nuestro microservicio.

Si usamos contenedores nos independizamos del host que al final ejecutará nuestros microservicios y además, dado que el contenedor contiene todo lo necesario para ejecutar mi aplicación (o microservicio), este se podrá desplegar de forma independiente.

Ahora bien, si usamos una arquitectura monolítica tradicional, también nos podemos beneficiar de los contenedores. Así que resumiendo: aunque los contenedores como mecanismo de despliegue facilitan y encajan muy bien con las necesidades de una arquitectura orientada a microservicios, se pueden usar en muchos otros escenarios. No caigas en el error de pensar que solo grandes arquitecturas distribuidas se benefician de los contenedores. Y tampoco caigas en el error de pensar que sin el uso de contenedores dichas arquitecturas no son posibles. Cualquier tipo de aplicación y de arquitectura se puede beneficiar de los contenedores.

Haciendo un símil con la POO (Programación Orientada a Objetos) podríamos decir que la relación entre “imagen” y “contenedor” es la misma que hay entre “clase” y “objeto”. Una imagen nos describe los contenidos que tendrá el contenedor, así como su configuración y el proceso que se ejecutará. Mientras que un contenedor es el resultado de ejecutar una imagen.

Las imágenes no se ejecutan, son meras definiciones que contienen todo lo necesario para crear los contenedores. Así, cuando antes dijimos que “un contenedor es un artefacto binario, que por lo tanto podremos mover y copiar entre hosts”, lo que deberíamos haber dicho realmente es que “una imagen es un artefacto binario, que por lo tanto podremos mover y copiar entre hosts”.

Los contenedores tienen un ciclo de vida (básicamente pueden estar ejecutándose o bien pueden haber finalizado su ejecución), mientras que las imágenes no tienen ningún ciclo de vida asociado.

Para poder crear contenedores, primero necesitamos la imagen correspondiente. Para ello, o bien debemos crearla, o bien la podemos descargar de un registro.

Muchas empresas proporcionan imágenes que podemos descargar y utilizar directamente, y nosotros podemos compartir nuestras propias imágenes de forma pública o privada utilizando un registro.

Existen muchos registros de imágenes, pero el registro por defecto es Docker Hub. Podemos usar Docker Hub para:

• Publicar nuestras propias imágenes para que puedan ser usadas por terceros.
• Descargar imágenes publicadas por otras personas, empresas u organizaciones.

Usaremos el comando pull para indicar cuál es la imagen que nos queremos descargar. Así que, abre una CLI y teclea:

docker pull hello-world

La salida de dicho comando será algo parecido a:

Using default tag: latest
latest: Pulling from library/hello-world
b04784fba78d: Pull complete
Digest: sha256:f3b3b28a45160805bb16542c9531888519430e9e6d6ffc09d72261b0d26ff74f
Status: Downloaded newer image for hello-world:latest

No te preocupes por esa salida por ahora, más adelante aprenderemos qué significa cada una de esas líneas.

Lo importante es que ahora nos hemos descargado la imagen hello-world y ya la tenemos en nuestro sistema. Y dicha descarga ha sido realizada desde el registro “Docker Hub” que es el que se usa por defecto (más adelante veremos cómo usar otros registros alternativos).

Para ver el listado de imágenes que tenemos descargadas en nuestro sistema:

docker images

Solo podemos ejecutar un contenedor a partir de imágenes que tengamos descargadas.

docker run hello-world

• Docker Engine: se trata de un entorno de desarrollo y ejecución de contenedores basado en línea de comandos. No incluye ninguna herramienta gráfica y está solo disponible para Linux. Es lo que debes instalar si vas a crear, testear, depurar, empaquetar y desplegar contenedores con Docker en este sistema operativo. Usando Docker Engine los contenedores se ejecutan directamente en la máquina host, a diferencia de Docker Desktop que emplea tecnologías de virtualización para ejecutarlos en una máquina virtual.
• Docker Desktop: producto de Docker que integra Docker Engine, una pequeña interfaz gráfica, herramientas adicionales y soporte para Kubernetes (por lo que te permite crear y depurar despliegues complejos utilizando esta tecnología de orquestación). Es la herramienta que debes instalar en Windows y en Mac (ya que no existe Docker Engine en esos sistemas). En el caso específico de Windows te proporciona la capacidad de poder ejecutar contenedores nativos que trabajan sobre Windows en lugar de sobre *NIX. Si bien su instalación es obligatoria en Windows y en Mac, en Linux es opcional (al existir Docker Engine) y puedes decidir si quieres instalarla o no. Si usas Linux, para seguir el curso basta con Docker Engine. A diferencia de Docker Engine, que es completamente gratuito (y open source), Docker Desktop requiere licencia de pago bajo algunas circunstancias, como ya hemos visto. En cualquier caso, para esta formación puedes instalarlo sin problema.
• Docker EE (Docker Enterprise Edition): producto ya desaparecido orientado a CaaS (Container as a Service), que permitía hospedar contenedores en una plataforma certificada por la propia empresa Docker. Se trataba de un producto de pago para desplegar tanto en la nube como en los sistemas propios de la empresa. A finales del año 2019 fue adquirido por la empresa Mirantis quienes terminaron convirtiéndolo en lo que ahora se conoce como Mirantis Kubernetes Engine.
• Docker Toolbox: se trata de un producto obsoleto (la recomendación es usar Docker Desktop), para permitir ejecutar contenedores Linux en MacOS y Windows. Docker Toolbox es para Windows anteriores a Windows 10 y usa VirtualBox como tecnología de virtualización para soportar contenedores Linux. Ninguno de los aspectos más avanzados (como contenedores Windows) está disponible, así que deberías evitarlo.

• Moby: nombre que se le da actualmente al proyecto open source que es el motor de Docker. La diferencia con Docker Desktop/Engine es que, este último es un producto comercial con más cosas, mientras que Moby es tan solo el motor de Docker. Si tienes interés en personalizar el motor de Docker, en modificar su comportamiento o entender cómo está implementado, ahí es donde debes mirar.
• containerd: es lo que utiliza Docker desde su versión 1.11 y posteriores como motor de ejecución de contenedores. Moby usa containerd para ejecutar los contenedores. Es una herramienta de muy bajo nivel.
• runC: herramienta de línea de comandos para lanzar contenedores según la especificación OCI (Open Container Initiative). Se trata de una herramienta de bajo nivel que, en según qué escenarios, es utilizada por containerd.

Es importante que comprendas la relación entre Moby, containerd y runC. Moby es el motor de Docker con el cual interactuamos (a través de la CLI de docker) y que usa containerd para ejecutar y manejar los contenedores. A su vez, para crear y ejecutar los contenedores, containerd lanza y controla varias instancias de runC

• Docker daemon: conocido también como dockerd sería la “parte servidora” de Docker que se encarga de comunicarse con la CLI y de llevar a cabo las tareas solicitadas por esta. Cuando utilices la interfaz de línea de comandos (CLI) de Docker para gestionar tus contenedores, esta se comunicará con Docker daemon para ello. Es importante notar que el daemon puede estar ejecutándose en otra máquina distinta de la que ejecuta la CLI, lo que nos permite gestionar contenedores de máquinas remotas. Por defecto, la CLI y el daemon se comunican mediante una named pipe, aunque también es posible usar TCP.
• BuildKit: también conocido como “el docker build de nueva generación”, es la nueva herramienta que usa Docker para construir las imágenes. Si usas una versión reciente de Docker, seguramente lo estás usando sin ser consciente de ello. Tiene varias ventajas respecto al antiguo sistema (cuestiones de rendimiento fundamentalmente), siendo su limitación principal que solo puede construir contenedores Linux. Tienes todos los detalles en la documentación de Docker.

• LinuxKit: distribución minimalista de Linux que contiene fundamentalmente tan solo el Kernel de Linux (aprox. 35MB). El objetivo de LinuxKit es permitir un subsistema de Linux que pueda ejecutar contenedores en entornos muy limitados como escenarios IoT (Internet de las cosas) o similares. No es, por supuesto, una distro Linux de uso general y, además, partes solo del Kernel y tienes que configurarla para cada escenario.
• Alpine: distribución de Linux pequeña que se usa como base para muchas imágenes de contenedores. No hay que confundirla con LinuxKit, la anterior: Alpine es un Linux de uso general, mientras que LinuxKit no.