Conociendo Docker
Ya sabemos qué es un contenedor. Ahora podemos retomar la pregunta con la que terminamos la unidad anterior: ¿cómo nos ayuda Docker a trabajar con ellos?
Imagina que queremos ejecutar TasteMatch en un contenedor. No solo necesitamos ponerlo en marcha: también querremos saber si está funcionando, consultar qué ocurre y detenerlo cuando corresponda. Necesitamos herramientas que nos permitan pedir esas operaciones.
Vamos a conocer las piezas que intervienen antes de instalar nada. Lo importante será entender quién pide el trabajo y quién lo realiza, no memorizar comandos.
Docker: herramientas para trabajar con contenedores
Docker es una plataforma y un conjunto de herramientas que facilita preparar, distribuir y ejecutar aplicaciones mediante contenedores. También permite gestionar esos contenedores una vez creados.
La diferencia con lo que ya conocemos es esta:
Contenedor
└── Entorno aislado donde podemos ejecutar una aplicación
Docker
└── Herramientas para crear y gestionar esos entornos
Si retomamos el símil del edificio, los apartamentos representaban los contenedores y el edificio, el anfitrión. Ahora añadimos las herramientas con las que se gestiona el edificio: ayudan a organizar los apartamentos, pero no son los apartamentos.
Es solo un símil para distinguir lo que gestionamos de las herramientas de gestión; no representa literalmente la arquitectura de Docker.
Docker utiliza los mecanismos del sistema para trabajar con los entornos aislados que vimos. No convierte cualquier aplicación en software compatible con cualquier equipo ni elimina la necesidad de preparar su configuración y sus datos.
¿Qué podremos hacer con él?
Para empezar utilizaremos software que otras personas ya han preparado. Esa base preparada se llama imagen y sirve para crear un contenedor. Enseguida veremos dónde encaja, sin entrar todavía en sus detalles.
| Lo que necesitamos | Lo que podremos pedir a Docker |
|---|---|
| Disponer de una base preparada. | Obtener una imagen. |
| Poner en marcha la aplicación. | Crear un contenedor e iniciarlo. |
| Saber cómo va. | Consultar su estado y los mensajes que produce. |
| Dejar de utilizarlo. | Detener el contenedor o eliminarlo cuando corresponda. |
Estas operaciones forman parte de la gestión del ciclo de vida: trabajar con un contenedor desde que lo creamos hasta que dejamos de necesitarlo. Las practicaremos más adelante; ahora vamos a seguir el recorrido de una petición.
¿Quién se encarga del trabajo? Docker Engine
Para realizar esas operaciones hace falta un motor. Docker Engine es el conjunto de componentes que permite crear y gestionar los recursos de Docker, como imágenes y contenedores.
Funciona con un modelo cliente-servidor: una parte solicita una operación y otra la recibe y se encarga de realizarla. Son dos papeles distintos, aunque normalmente empezaremos utilizándolos desde el mismo equipo.
Vamos a poner nombre a esas dos partes. Engine no es un tercer paso que añadimos entre ambas: es el motor organizado de esa forma.
Cómo pedimos una operación: Docker CLI
Utilizaremos una terminal, una herramienta donde escribimos órdenes en forma de texto. Esas órdenes se llaman comandos.
Docker CLI es el cliente que permite enviar esas órdenes a Docker desde la terminal. CLI significa Command Line Interface, o interfaz de línea de comandos.
Cuando más adelante escribamos una orden con esta forma:
docker ...
estaremos utilizando ese cliente. Los puntos representan la operación y sus opciones; no es un comando que tengas que copiar ni ejecutar ahora.
Si pedimos crear un contenedor, la CLI comunica esa petición a la parte que se encarga de gestionarlo. La CLI también nos muestra la respuesta o el error que recibe.
Quién recibe la petición: Docker daemon
Un daemon es un programa que permanece funcionando en segundo plano para atender tareas. El de Docker se llama Docker daemon y su proceso se conoce como dockerd.
Actúa como servidor: recibe las solicitudes del cliente y se encarga de operaciones como gestionar imágenes o crear, iniciar y detener contenedores, apoyándose en los mecanismos del sistema.
Aquí, «servidor» describe el papel de ese programa. No significa que necesitemos otro ordenador.
El daemon forma parte de Docker Engine; no es todo Engine. También gestiona otros recursos, llamados redes y volúmenes, que conoceremos cuando necesitemos trabajar con la comunicación y el almacenamiento de los contenedores.
Sigue el recorrido de una petición
Supongamos que ya tenemos un contenedor y queremos consultar si está funcionando:
Nosotros
│ Queremos conocer el estado del contenedor
▼
Docker CLI — cliente
│ Envía la petición
▼
Docker daemon — servidor de Docker Engine
│ Atiende la consulta
▼
Contenedor gestionado por ese daemon
Respuesta: daemon → CLI → nosotros
La CLI es nuestra forma de pedirlo. El daemon consulta el recurso que gestiona y devuelve información. Ese reparto es lo que llamamos arquitectura cliente-servidor.
Al empezar, trabajaremos con un entorno de Docker preparado en nuestro equipo. Según la instalación, el daemon puede ejecutarse directamente en el sistema o en el entorno que proporciona Docker Desktop, que veremos enseguida.
Como curiosidad: el cliente también puede comunicarse con un daemon que esté en otra máquina. En ese caso, gestiona los recursos de ese daemon remoto. No necesitamos configurar esa posibilidad para empezar.
Comprueba la idea
Tenemos disponible el cliente, pero no puede comunicarse con el daemon. ¿Basta con tener la CLI para crear un contenedor?
No. El cliente permite solicitar la operación, pero para realizarla necesitamos que el daemon esté disponible y sea accesible. En la próxima unidad aprenderemos a comprobarlo en nuestro equipo.
La imagen es el punto de partida
Hasta ahora hemos hablado de preparar el entorno de una aplicación. Para crear un contenedor con Docker utilizaremos una imagen: una base preparada con archivos e información necesarios para ese entorno.
Para situar las piezas, basta con este recorrido:
Imagen preparada
│
│ Docker la utiliza como base
▼
Contenedor creado a partir de ella
│
│ Lo iniciamos
▼
Aplicación ejecutándose dentro
Tener una imagen no significa tener ya una aplicación en ejecución. La imagen sirve como base; el contenedor es lo que creamos y gestionamos para ejecutarla. La imagen no se convierte literalmente en el contenedor ni desaparece al crearlo.
En Docker 0 utilizaremos imágenes existentes. Más adelante aprenderemos a trabajar con ellas y con los contenedores que creemos a partir de ellas.
¿De dónde salen las imágenes? Docker Hub
Un registro de imágenes, también llamado registry, es un lugar donde se almacenan y distribuyen imágenes. Docker puede obtenerlas de uno de esos registros.
Docker Hub es uno de ellos: allí podemos encontrar imágenes ya preparadas, como la de Nginx, un servidor web que atiende peticiones y puede entregar páginas web.
Docker Hub u otro registro
│ Obtener una imagen
▼
Imagen disponible en el entorno de Docker
│ Crear un contenedor
▼
Contenedor
Docker Hub no es una parte que tenga que estar dentro de cada contenedor ni el lugar donde se ejecuta nuestra aplicación. Además, una imagen puede estar ya disponible localmente: no toda operación requiere descargarla otra vez ni utilizar Docker Hub.
Probemos el recorrido con Nginx, sin comandos
Queremos ejecutar Nginx en un contenedor utilizando una imagen existente. Imagina que nuestro entorno de Docker ya está preparado y que la imagen es compatible.
¿Qué tendría que ocurrir desde que lo pedimos hasta que Nginx empieza a funcionar?
Nosotros: queremos ejecutar Nginx
│
▼
Docker CLI envía la solicitud
│
▼
Docker daemon atiende la petición
│
├── Necesita la imagen de Nginx
│ Puede obtenerla de un registro
│ si no está disponible localmente
│
└── Crea e inicia un contenedor
│
▼
Nginx se ejecuta dentro
Antes de continuar, responde:
- ¿Cuál es la aplicación que queremos ejecutar?
- ¿Qué será el contenedor?
- ¿Qué papel tienen la CLI y el daemon de Docker?
- ¿Qué necesitamos como base antes de crear el contenedor?
Compara tu razonamiento
Nginx es la aplicación. El contenedor es el entorno aislado que creamos para ejecutarla. La CLI envía la solicitud y el daemon se encarga de gestionar la imagen y el contenedor. Necesitamos una imagen de Nginx como base.
El registro aporta la imagen cuando hace falta obtenerla; no sustituye al daemon ni ejecuta Nginx por nosotros. Por ahora solo estamos siguiendo las piezas: acceder a ese servidor web desde el navegador requerirá otros pasos que practicaremos después.
¿Dónde encaja Docker Desktop?
Ya conocemos el cliente y el motor. Ahora falta saber cómo podemos disponer de ellos en un ordenador de uso cotidiano.
Docker Desktop es una aplicación para Windows, macOS y Linux que integra Docker Engine, la CLI y herramientas que facilitan trabajar con contenedores desde el escritorio. También ofrece una interfaz gráfica, con ventanas y controles.
No es simplemente otro nombre para Engine ni representa todo lo que llamamos Docker. Es una forma de disponer de un entorno integrado para utilizarlo.
La relación con Linux
Los contenedores Linux necesitan los mecanismos de un kernel Linux, como vimos en la unidad anterior.
- En Linux, podemos ejecutar Docker Engine directamente sobre el sistema, sin utilizar Docker Desktop. Desktop también está disponible como opción.
- En Windows y macOS, Docker Desktop puede proporcionar un entorno Linux mediante virtualización para ejecutar contenedores Linux. El kernel que utilizan esos contenedores pertenece a ese entorno Linux, no directamente a Windows o macOS.
Esto explica por qué dos personas pueden utilizar la misma CLI y tener una preparación del equipo diferente. En la siguiente unidad veremos cómo preparar el entorno que corresponda a nuestro sistema.
Sitúa cada nombre
| Nombre | Qué papel tiene |
|---|---|
| Docker | Plataforma y herramientas para trabajar con contenedores. |
| Docker Engine | Motor que funciona con un modelo cliente-servidor y gestiona los recursos. |
| Docker CLI | Cliente que utilizamos desde la terminal para solicitar operaciones. |
| Docker daemon | Parte servidora del motor que atiende las peticiones y gestiona los recursos. |
| Docker Desktop | Aplicación que integra componentes y herramientas de Docker para el escritorio. |
| Docker Hub | Registro del que podemos obtener imágenes. |
No necesitas memorizar la tabla. Utilízala para responder: «¿Qué pieza interviene en lo que quiero hacer?»
Ideas que pueden llevarnos a error
«Docker es un contenedor o una máquina virtual»
Docker proporciona herramientas para trabajar con contenedores. Que Desktop pueda utilizar virtualización para preparar el entorno no convierte Docker en una VM ni cambia qué es un contenedor.
«Docker Desktop y Docker Engine son exactamente lo mismo»
Desktop integra el motor y otras herramientas. Podemos utilizar Engine sin Desktop, por ejemplo en un sistema Linux.
«El comando docker ejecuta directamente mi aplicación»
Para solicitar la ejecución de un contenedor, utilizamos el cliente. Este envía la petición al daemon, que se encarga de gestionarla. La aplicación se ejecuta dentro del contenedor.
«Docker hará que cualquier programa funcione en cualquier ordenador»
Seguimos necesitando un entorno compatible, recursos suficientes y la configuración adecuada. Docker no corrige automáticamente los errores de la aplicación.
«Sin Docker Hub no puede funcionar ningún contenedor»
Hub es un posible origen de imágenes. Podemos utilizar imágenes que ya estén disponibles en nuestro entorno u obtenerlas de otros registros.
«Docker inventó los contenedores y es la única opción»
El aislamiento de procesos y las tecnologías de contenedores existían antes. Docker ha facilitado su uso, pero también hay otras herramientas para trabajar con ellos.
«Tengo que entender todos sus componentes internos antes de usarlo»
Para empezar basta con reconocer quién solicita una operación, quién la realiza y qué recurso gestiona. Ese modelo nos ayudará a entender la práctica sin estudiar todavía los detalles internos.
Mini reto: reconstruye el recorrido
Completa los dos huecos con Docker CLI y Docker daemon:
Usuario
↓
Primer hueco: ¿quién envía la solicitud?
↓
Segundo hueco: ¿quién realiza la operación?
↓
Contenedor
Después responde con tus propias palabras:
- ¿Qué herramienta utilizaremos desde la terminal para escribir órdenes?
- ¿Qué componente recibe la petición de crear un contenedor y se encarga de realizarla?
- Si pedimos ejecutar Nginx, ¿Docker y el contenedor son lo mismo?
- ¿Qué papel tiene la imagen? ¿Tenerla significa que Nginx ya está funcionando?
- ¿De dónde podemos obtener una imagen preparada? ¿Tiene que ser siempre Docker Hub?
- ¿Qué diferencia hay entre Docker Engine y Docker Desktop?
Compara tu respuesta
El orden es usuario → Docker CLI → Docker daemon → contenedor. Utilizamos la CLI desde la terminal; el daemon recibe la petición y gestiona la operación.
Docker es el conjunto de herramientas que usamos. El contenedor es el entorno donde ejecutamos Nginx. La imagen proporciona la base para crearlo, pero tenerla no significa que la aplicación esté funcionando.
Podemos obtener esa imagen de un registro como Docker Hub; también existen otros registros y la imagen puede estar ya disponible localmente.
Engine es el motor con su organización cliente-servidor. Desktop es una aplicación que integra ese motor y otras herramientas para facilitar su uso en el escritorio.
De conocer las piezas a preparar el equipo
Ya podemos seguir una petición: usamos el cliente, el daemon atiende la solicitud y gestiona recursos como imágenes y contenedores. También sabemos que Desktop puede ayudarnos a disponer de ese entorno y que Hub puede ser el origen de las imágenes.
Ahora surge la siguiente pregunta: ¿cómo preparamos nuestro equipo para empezar a utilizar Docker y comprobamos que sus piezas pueden comunicarse?
Ese será el siguiente paso en Preparando Docker.