Está conformado por 3 componentes:
También conocido como demonio Docker, ya que es un demonio que corre sobre cualquier distribución de Linux y que expone una API externa para la gestión de imágenes y contenedores y otras entidades que van añadiéndose sucesivamente en distribuciones de Docker como volúmenes o redes virtuales. Entre sus funciones tenemos:
- La creación de imágenes Docker.
- La publicación de imágenes de un Docker Registry, siendo este otro componente Docker.
- Descarga de imágenes de un registro de Docker.
- Ejecución de contenedores usando imágenes locales.
- Gestión de contenedores en ejecución, permitiendo parar su ejecución, reiniciarla, ver sus logs o sus estadísticas de uso de recursos.
Herramienta que hace uso de la API remota de Docker Engine, el cual suele hacer referencia al comando Docker que hace las veces de herramienta de línea de comandos. Para gestionar un Docker Engine, al CLI (Command Line Interface) de Docker se puede configurar para hablar con un Docker Engine local o remoto, permitiendo controlar tanto el entorno de desarrollo local como servidores de producción.
Los comandos más comunes de Docker son:
docker info docker images docker build docker push
Suele correr en un servidor independiente y es donde se publican las imágenes que generan los Docker Engine, de tal manera que esté disponible para la utilización de cualquier otra máquina, siendo fundamental dentro de la arquitectura de Docker, ya que permite distribuir nuestras aplicaciones. Docker Registry es un proyecto Open Source, sin embargo, Docker ofrece Docker Hub de pago, donde puedes subir tus propias imágenes, acceder a imágenes públicas de otros usuarios y también imágenes oficiales de las principales aplicaciones como MySQL, MongoDB, Ubuntu, Redis y muchas más que podemos consultar en la web oficial: https://hub.docker.com/
Docker Registry funciona de una manera muy parecida a Git, contando con gestión de imágenes con un servicio similar en funcionamiento a GitHub, donde cada imagen también conocida como repositorio es una sucesión de capas.
Permiten el monitoreo y correcta gestión de los contenedores creados por ejemplo con Docker, siendo este proceso comúnmente conocido como orchestration o orquestación.
Podríamos decir que una imagen es una instantánea de un contenedor, queriendo decir que una vez la ejecuto en un servidor ya viene siendo el contenedor, la cual tiene toda la configuración necesaria para que funcione el servicio, como lo son paquetes y todo lo que sea requerido para su funcionamiento.
Ahora, es importante tener en cuenta que las imágenes se componen por capas, donde una imagen puede tener n cantidad de capas.
Vamos a explicar un ejemplo donde tenemos 3 Capas.
Capa Número 1: normalmente la primera Capa tiene un FROM donde se define con qué sistema operativo vamos a comenzar, por lo que la imagen va a contener un mini sistema operativo que no pesa más de 120 megas normalmente. Luego veremos como podemos bajar ese sistema operativo o esa imagen inicial en la capa.
Capa Número 2: en esta capa vamos a asignar la instrucción RUN, la cual nos permite asignar una tarea como la instalación de un servicio dentro del sistema operativo, por ejemplo el servidor http Apache.
Capa Número 3: para el ejemplo a esta capa le asignaremos el CMD siendo la línea que se va a ejecutar o lo que va a levantar el servicio.
Si tenemos un FROM Centos en la capa 1 y en la capa 2 tenemos un RUN (ejemplo: yum -y install httpd), en la capa 3 definiríamos un comando que inicie el servicio de la capa 2.
Estas 3 capas previamente creadas son de solo lectura, por lo que no será posible modificarlas. Las acciones que si podré realizar es crear capas adicionales sobre las existentes o crear una imagen nueva.
Las capas se crean utilizando un archivo llamado Dockerfile, el cual es un archivo de texto plano básico, siendo el archivo por Default que Docker va a buscar. En el definiríamos las capas de la siguiente manera:
FROM centos:7 RUN yum -y install httpd CMD ["apachectl","-DFOREGROUND"]
Esta última línea CMD lo que haría es iniciar el servicio de Apache que instalamos en la capa anterior. Con Foreground le estamos dando la instrucción que se ejecute en el primer plano.
Podríamos definir un contenedor como una capa adicional, que va a permitir la ejecución en tiempo real de las 3 capas anteriores, por lo que para el ejemplo, la capa 4 sería el contenedor y va a permitir ejecutar Centos, va a instalar Apache y ejecutar el comando CTL para iniciarlo.
La capa 4 la podríamos definir como una capa de escritura, ya que tiene ejecución, por lo que vamos a poder acceder a las 3 capas anteriores con lectura y escritura. Cabe tener en cuenta que todos los cambios que hagamos en la capa 4 van a ser temporales, ya que las imágenes al ser de solo lectura, no se almacena dicho cambio, por lo que no se recomienda realizar configuraciones sobre el Contenedor.
Adicionalmente, los contenedores contienen volúmenes siendo un tema muy completo por lo que lo vamos a tratar en otro blog.
Por último en los contenedores tenemos redes, para lograr comunicar contenedores entre sí principalmente.
Ephemeral code