Kitabı oku: «Aprender Docker, un enfoque práctico», sayfa 3
1.12. Docker Registry
Un Docker Registry, o registro de contenedores Docker, es un servicio encargado de almacenar y distribuir repositorios de imágenes Docker. Los usuarios pueden utilizar este servicio para publicar sus repositorios de imágenes y compartirlos con otros usuarios de una forma sencilla.
Un repositorio de imágenes es un conjunto de imágenes que se agrupan bajo el mismo nombre dentro del mismo registro. Cada una de las imágenes de un repositorio está etiquetada con un tag, que se suele utilizar para indicar su versión.
En el capítulo 3, estudiaremos con más detalle qué es un registro y los diferentes tipos que existen. En este apartado, solo se trata de mostrar una descripción general que nos ayude a entender, de forma global, cuál es el papel de cada uno de los componentes de Docker.
1.12.1. Docker Hub
Docker Hub es el registro de contenedores oficial de Docker. Es el registro que viene configurado por defecto cuando se instala Docker Engine, aunque puede ser reemplazado por otros registros de contenedores.
Los usuarios pueden utilizar repositorios públicos de Docker Hub para almacenar y compartir sus imágenes de forma gratuita, o pueden contratar una suscripción de pago para disponer de repositorios privados ilimitados.
Entre las principales funcionalidades de Docker Hub, podemos destacar las siguientes:
Permite crear equipos y organizaciones.
Posibilita descargar y utilizar una gran cantidad de imágenes oficiales y de organizaciones verificadas, de forma gratuita.
Facilita crear y publicar imágenes de manera automática a partir del contenido de un repositorio externo de GitHub o Bitbucket; por ejemplo, un repositorio de Docker Hub se puede configurar para crear una imagen de modo automático cada vez que se publican nuevos cambios en el código de una aplicación que está alojada en un repositorio de GitHub o BitBucket. Además, se pueden configurar una serie de test para que la imagen solo se publique cuando los test se hayan ejecutado con éxito.
También proporciona el uso de webhooks para desencadenar acciones en otros servicios externos; por ejemplo, cada vez que se publica una imagen en Docker Hub, se puede activar un webhook, que hace una petición POST a una determinada URL que podemos configurar en Docker Hub.
1.12.2. Otros registros
Además de Docker Hub, podemos hacer uso de otros registros de contenedores como:
GitHub Container Registry.
GitLab Container Registry.
DigitalOcean Container Registry.
Amazon Elastic Container Registry.
Azure Container Registry.
Google Cloud Container Registry.
1.13. Objetos de Docker
Los principales objetos de Docker con los que vamos a trabajar a lo largo del libro son:
Imágenes.
Contenedores.
Volúmenes.
Redes.
Hemos dedicado un capítulo para estudiar con detalle cada uno de estos objetos. En esta sección, solo mostraremos una descripción general de cada uno de ellos.
1.13.1. Imágenes
Las imágenes contienen el sistema de archivos que utilizarán los contenedores Docker. Para crear un contenedor, es necesario utilizar una imagen de forma obligatoria. A partir de la misma imagen, se pueden crear todos los contenedores que se necesiten. Por lo tanto, podemos decir que las imágenes son como unas plantillas que contienen el estado inicial del sistema de archivos raíz del contenedor.
En el capítulo 3, aprenderemos cómo crear una imagen, cómo publicarla en Docker Hub y todos los comandos básicos para poder gestionar las imágenes en un host de Docker.
1.13.2. Contenedores
Un contenedor Docker se crea a partir de una imagen. Se puede definir como un proceso que ha sido aislado de todos los demás procesos de la máquina donde se está ejecutando, también conocida como el «host de Docker». Los contenedores pueden tener más de un proceso en ejecución, pero las buenas prácticas recomiendan ejecutar un solo proceso por contenedor.
En el capítulo 4, estudiaremos todos los comandos necesarios para gestionar el ciclo de vida completo de un contenedor.
Contenedores Linux y contenedores Windows
En Docker, existen dos tipos de contenedores.
Contenedores Linux
Los contenedores Linux se pueden ejecutar en los sistemas operativos Linux, macOS y Windows. Estos contenedores solo se pueden crear a partir de imágenes específicas para contenedores Linux.
Cuando estos contenedores se ejecutan en un sistema operativo Linux, utilizan el kernel del sistema operativo de la máquina anfitriona. Sin embargo, cuando se ejecutan en macOS, lo hacen en una máquina virtual ligera sobre el hipervisor HyperKit, que es específico de macOS. En Windows, su ejecución dependerá del backend utilizado en Docker Desktop. En este caso, existen dos posibilidades:
WSL 2 como backend de Docker Desktop. En este caso, los contenedores Linux se ejecutan de forma nativa, sin ningún tipo de emulación, utilizando el kernel de Linux desarrollado por Microsoft para WSL 2.
Hyper-V como backend de Docker Desktop. En este caso, los contenedores Linux se ejecutan en una máquina virtual en Hyper-V basada en LinuxKit. Esta solución ofrece un rendimiento mucho menor que WSL 2; por este motivo, no se recomienda su uso para ejecutar contenedores Linux.
Figura 1.7. Contenedores Linux.
Contenedores Windows
Estos contenedores solo se pueden crear en los sistemas operativos Windows y Windows Server. Las imágenes que utilizan son imágenes específicas para contenedores Windows.
Los contenedores Windows disponen de dos modos de aislamiento en tiempo de ejecución:
Aislamiento de Hyper-V. En este modo, los contenedores se ejecutan en una máquina virtual en Hyper-V y cada contenedor tiene su propio kernel. Ofrece un buen nivel de aislamiento en el ámbito del hardware entre los contenedores y el host, así como un buen nivel de seguridad. Este es el modo de aislamiento que utilizan por defecto los contenedores Windows que se ejecutan en Windows 10.
Aislamiento de procesos. En este modo, los contenedores no tienen su propio kernel, sino que utilizan el kernel del sistema operativo anfitrión, del mismo modo que lo hacen los contenedores Linux de forma nativa. Este es el modo de aislamiento que utilizan por defecto los contenedores Windows que se ejecutan en Windows Server.
Figura 1.8. Contenedores Windows.
1.13.3. Volúmenes
Los volúmenes son un mecanismo que nos ofrece Docker para implementar persistencia de datos en un contenedor. Los contenedores que no tienen volúmenes asociados perderán todos los datos cuando el contenedor finalice su ejecución y se elimine. Si queremos conservar los datos que se han generado durante la ejecución del contenedor, necesitamos utilizar volúmenes.
Un contenedor puede tener asociados uno o varios volúmenes. Estos permiten almacenar en el host de Docker los datos de los directorios del contenedor que queremos conservar cuando el contenedor se elimine. El ciclo de vida de los volúmenes es independiente del ciclo de vida de los contenedores. Por lo tanto, los volúmenes seguirán estando disponibles, aunque se eliminen los contenedores que los están utilizando.
En el capítulo 5, estudiaremos las posibilidades que nos ofrece Docker para implementar persistencia de datos entre los contenedores y el host de Docker.
1.13.4. Redes
Docker nos permite crear diferentes tipos de redes para que los contenedores puedan comunicarse entre ellos y con el exterior. El componente principal de Docker Engine que se encarga de la gestión de las redes en Docker es libnetwork.
En el capítulo 6, estudiaremos los diferentes tipos de redes que podemos crear en Docker y los comandos básicos para poder gestionarlas.
1.14. Orquestación de contenedores
En muchas situaciones, vamos a necesitar que las aplicaciones se ejecuten sobre un cluster de servidores, para garantizar la alta disponibilidad y escalabilidad de los servicios.
Para desplegar una aplicación basada en contenedores en un cluster, vamos a necesitar el uso de herramientas adicionales, para realizar tareas que no se pueden hacer de forma manual. Estas herramientas son conocidas como «orquestadores de contenedores» y los más conocidos dentro del ecosistema Docker son Docker Swarm y Kubernetes.
Entre las tareas que suele realizar un orquestador de contenedores, podemos destacar las siguientes:
Automatiza el despliegue de una aplicación en un cluster de servidores.
Crea y ejecuta los contenedores entre los diferentes nodos del cluster.
Balancea la carga entre todos los contenedores.
Escala los servicios de forma automática cuando sea necesario.
Permite que una aplicación se recupere automáticamente de los errores.
Posibilita actualizar una aplicación sin que exista tiempo de inactividad.
Docker Swarm
Docker Swarm es un orquestador que viene integrado de forma nativa en Docker Engine. Este orquestador está siendo desarrollado por Docker, Inc. y forma parte del proyecto Moby Project, con el nombre de SwarmKit.
Figura 1.9. Ejemplo de un cluster de Docker Swarm formado por tres nodos Managers y cuatro Workers.
Kubernetes
Kubernetes, también conocido como K8s, es el orquestador más utilizado en la actualidad. Este orquestador fue desarrollado originalmente por Google, pero fue donado a la Cloud Native Computing Foundation (CNCF), que actualmente es la encargada de su desarrollo.
Kubernetes puede utilizar diferentes container runtimes para ejecutar contenedores. El único requisito reside en que sean compatibles con una API llamada Container Runtime Interface (CRI), que es la que permite interaccionar al container runtime con Kubernetes.
Kubernetes es compatible con containerd, que es el container runtime que utiliza Docker Engine. Por lo tanto, en un cluster de Kubernetes, se pueden crear y ejecutar contenedores a partir de imágenes Docker, que son imágenes que cumplen con la especificación OCI.
La aplicación Docker Desktop para macOS y Windows incluye soporte para crear un cluster de Kubernetes de un único nodo, que se ejecuta de forma local. Esta funcionalidad está deshabilitada por defecto y solo se debe utilizar en un entorno local de pruebas.
Figura 1.10. Ejemplo de un cluster de Kubernetes formado por un nodo Master y tres nodos Workers.
1.15. Organizaciones y estándares
La Open Container Initiative (OCI) y la Cloud Native Computing Foundation (CNCF) son dos proyectos que forman parte de la Fundación Linux, que trabajan para el impulso de las tecnologías de contenedores y las tecnologías abiertas en la nube.
La OCI se centra en el desarrollo de especificaciones y estándares abiertos, mientras que la CNCF está orientada al desarrollo de proyectos open source.
1.15.1. Open Container Initiative (OCI)
La Open Container Initiative (OCI) fue creada en 2015 por Docker, Inc., CoreOs y otras empresas, con el objetivo de diseñar estándares abiertos para que las tecnologías de contenedores no estuviesen vinculadas a ninguna empresa ni proyecto específico.
En la actualidad, la OCI cuenta con tres especificaciones:
OCI Runtime Specification
En esta especificación, se describe cómo tiene que ser la configuración, el entorno de ejecución y el ciclo de vida de un contenedor.
OCI Image Format Specification
Esta especificación define cómo tiene que ser una imagen OCI, para que todas las herramientas que cumplan este estándar puedan hacer uso de ella.
Las imágenes OCI están formadas por un archivo de manifiesto, un índice (opcional) que apunta a otros archivos de manifiesto para diferentes arquitecturas, el conjunto de capas que forman el sistema de archivos de la imagen y un archivo de configuración.
OCI Distribution Specification
Esta especificación define una API para facilitar y estandarizar la distribución de imágenes OCI.
1.15.2. Cloud Native Computing Foundation (CNCF)
La Cloud Native Computing Foundation (CNCF) es una organización que fue creada en 2015, donde las grandes empresas de la industria tecnológica colaboran entre sí para impulsar el uso de las tecnologías abiertas en la nube mediante proyectos de código abierto que no están vinculados a un único proveedor. Esta organización forma parte de la Fundación Linux y actualmente cuenta con el apoyo de las principales empresas del sector.
Las tecnologías conocidas como «Cloud Native» hacen referencia a las tecnologías actuales, que permiten ejecutar aplicaciones escalables en entornos de nube pública, privada o híbrida. Algunos ejemplos de estas tecnologías son los contenedores, los microservicios, las mallas de servicios, la infraestructura inmutable y las API declarativas.
Los proyectos de la CNCF se clasifican según su nivel de madurez en:
Proyectos graduados.
Proyectos en incubación.
Proyectos en sandbox.
Entre los proyectos graduados, encontramos dos de los proyectos de los que hemos estado hablando en este capítulo:
containerd: se encuentra en la categoría de container runtime.
Kubernetes: se sitúa en la categoría de orquestación.
1.16. Alternativas a Docker
Docker no es la única tecnología de contenedores que existe en la actualidad. De hecho, existen varias alternativas, pero solo vamos a nombrar algunas de las más conocidas:
Podman
Se trata de un container engine desarrollado por Red Hat. A diferencia de Docker, Podman no utiliza ningún proceso daemon y no necesita privilegios de root. Solo está disponible para sistemas operativos Linux y es compatible con las especificaciones OCI.
cri-o
Es un container runtime de alto nivel para Kubernetes. Se trata de una implementación de la especificación Kubernetes CRI (Container Runtime Interface), que permite utilizar cualquier runtime compatible con la especificación OCI. Actualmente, tiene soporte para interaccionar con los runtimes de bajo nivel runc y Kata Containers.
LXD
Es un proyecto open source desarrollado por Canonical, pero también recibe contribuciones de otras empresas y desarrolladores individuales. Este container engine permite trabajar con contenedores LXC (Linux Containers).
rkt
Este proyecto fue desarrollado originalmente por CoreOS en 2014. Años más tarde, Red Hat adquirió CoreOS y donó el proyecto a la CNCF. En 2020, se suspendió su desarrollo.
CAPÍTULO 2
Instalación de Docker
2.1. Docker Engine Community
Cuando decimos que vamos a instalar Docker en una máquina, realmente queremos decir que vamos a instalar el componente Docker Engine. Y lo más probable es que nos estemos refiriendo a la versión de la comunidad o Docker Engine Community.
Actualmente, existen dos ediciones de Docker Engine:
Docker Engine Community Edition (CE)
Es la versión open source mantenida por la empresa Docker, Inc.
Docker Engine Enterprise Edition (EE) o Mirantis Container Runtime (MCR)
Es una versión empresarial para sistemas Linux y Windows Server. Es uno de los productos que adquirió la empresa Mirantis cuando compró la plataforma Docker Enterprise en noviembre de 2019. Su nombre original era Docker Engine Enterprise, pero ha sido renombrado a Mirantis Container Runtime (MCR).
En este capítulo, nos vamos a centrar en la instalación de la versión Docker Engine Community para los sistemas operativos Linux, Windows y macOS.
Para instalar la versión Docker Engine Community, utilizaremos los siguientes productos:
Docker Engine para Linux.
Docker Desktop para Windows.
Docker Desktop para macOS.
En los sistemas operativos Linux es posible instalar, de forma aislada, el componente Docker Engine, pero, en los sistemas Windows y macOS, necesitamos instalar la aplicación Docker Desktop que, además de Docker Engine, incluye otros componentes, como Docker CLI, Docker Compose, Docker Content Trust, Kubernetes y Credential Helper.
Docker Engine para Linux es de uso gratuito, mientras que Docker Desktop solo se puede utilizar de forma gratuita con la suscripción Docker Personal, que permite su utilización en pequeñas empresas, para uso personal, educación y proyectos open source sin fines comerciales. Si desea utilizar Docker Desktop con fines comerciales en una gran empresa, deberá contratar una suscripción Pro, Team o Business.
2.2. Instalación de Docker Engine en Linux
En el momento de escribir este libro, Docker Engine está disponible para las siguientes distribuciones Linux para arquitecturas de 32 y 64 bits.
| 64 bits | 32 bits | ||
| x86_64 o amd64 | ARM64 o AArch64 | ARM | |
| CentOS | ✓ | ✓ | |
| Debian | ✓ | ✓ | ✓ |
| Fedora | ✓ | ✓ | |
| Raspbian | ✓ | ✓ | |
| Ubuntu | ✓ | ✓ | ✓ |
Tabla 2.1. Distribuciones Linux y arquitecturas donde está disponible Docker Engine.
En la página web oficial de Docker, encontramos todos los detalles del proceso de instalación para cada una de estas distribuciones Linux. En este capítulo, solo vamos a realizar la instalación de Docker Engine para Ubuntu:
2.2.1. Métodos de instalación en Ubuntu
Para instalar Docker Engine en un sistema operativo Ubuntu, podemos utilizar tres métodos diferentes:
Utilizar un script oficial disponible en la URL https://get.docker.com, que permite realizar la instalación de forma rápida y no interactiva. Esta opción puede ser útil en entornos de desarrollo y no se recomienda su uso en entornos de producción.
Realizar la instalación desde los repositorios oficiales de Docker. Esta es la opción más utilizada por los usuarios, por su facilidad de instalación y actualización. Es la opción recomendada.
Descargar el paquete .deb directamente desde la web oficial y realizar la instalación de forma manual. Tiene el inconveniente de que también habría que gestionar las actualizaciones de manera manual. Este método puede ser útil cuando sea necesario instalar Docker Engine en sistemas que no dispongan de una conexión a Internet.
