0.3Arquitectura: imagen, contenedor, registro, daemon
Lo esencial en 30 segundos
- El cliente ordena, el daemon ejecuta: solo hablas con el cliente (docker), el motor de fondo hace el trabajo.
- La imagen es el molde inmutable, el contenedor la pieza viva: una imagen → N contenedores independientes, cada uno con su capa escribible.
- El registro almacena las imágenes versionadas por etiquetas: pull descarga, push publica — siempre una etiqueta explícita, nunca latest en producción.
Minicaso hilado — Idir hace funcionar tres servidores web idénticos en Argel
Idir, devops junior en Argel, debe probar el reparto de carga: en lugar de reinstalar tres veces nginx, aplica la arquitectura. Descarga UNA vez la imagen con docker pull nginx:1.27 (registro Docker Hub, etiqueta explícita) y luego lanza tres contenedores llamados web1, web2, web3 desde esa misma imagen. Con docker ps, ve la misma imagen y tres vidas independientes. Elimina web2: la imagen y los demás contenedores sobreviven — la prueba viva de que el molde nunca cambia cuando desaparece una pieza.
Caso autónomo de esta sección: reaparece en el curso, el esquema, el guion y el reto 48h de la sección 0.3.
1. Los cinco actores
El cliente (docker) envía órdenes al daemon (el motor de fondo). El daemon construye imágenes, las almacena localmente, las descarga desde un registro (Docker Hub) y las ejecuta como contenedores. Solo hablas con el cliente; el daemon hace el trabajo. Idir ve el cliente como el mando a distancia y el daemon como el servidor.
2. Imagen frente a contenedor: el molde y la pieza
La imagen es un modelo inmutable (apilamiento de capas de solo lectura). El contenedor es una instancia viva de ese modelo, con una fina capa escribible encima. Se pueden lanzar diez contenedores de la misma imagen sin duplicarla: cada uno vive su vida, la imagen nunca cambia. Idir retiene: eliminar un contenedor no toca ni la imagen ni sus vecinos.
3. El registro, biblioteca mundial
El registro almacena las imágenes versionadas por etiquetas (nginx:1.27, postgres:16). docker pull descarga, docker push publica. Docker Hub es el registro público por defecto; las empresas suelen añadir un registro privado (GHCR, Harbor). Idir siempre precisa su etiqueta: latest no fija ninguna versión.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Tres servidores web idénticos
Idir lanza tres nginx independientes desde una sola imagen descargada una vez.
docker pull nginx:1.27
docker run -d --name web1 nginx:1.27
docker run -d --name web2 nginx:1.27
docker run -d --name web3 nginx:1.27Lectura: una sola imagen descargada, tres contenedores independientes.
Lección: elimina web2: la imagen y los demás contenedores sobreviven.
Vocabulario de la sección
- Cliente
- La CLI docker: envía órdenes, no las ejecuta.
Ejemplo sencillo: Idir escribe docker pull nginx:1.27: el cliente transmite al daemon.
Lo que no es: el motor que ejecuta los contenedores.
Reflejo: el cliente ordena, el daemon ejecuta.
- Daemon
- El motor dockerd que construye y ejecuta de verdad.
Ejemplo sencillo: Idir sabe que sus tres web funcionan gracias al daemon.
Lo que no es: el comando tecleado.
Reflejo: nada arranca si el daemon está detenido.
- Imagen
- Modelo inmutable en capas, identificado por nombre:etiqueta.
Ejemplo sencillo: Idir fija nginx:1.27: tres contenedores, una sola imagen intacta.
Lo que no es: un contenedor vivo y modificable.
Reflejo: siempre nombre:etiqueta explícita.
- Contenedor
- Instancia viva de una imagen, con su capa escribible.
Ejemplo sencillo: Idir elimina web2: web1 y web3 continúan, la imagen sobrevive.
Lo que no es: el molde almacenado en el registro.
Reflejo: --name para orientarse entre vecinos.
- Etiqueta
- La etiqueta de versión de una imagen (1.27, 16, latest).
Ejemplo sencillo: Idir elige nginx:1.27 en lugar de latest para fijar su versión.
Lo que no es: un nombre de contenedor.
Reflejo: latest solo en pruebas, nunca en producción.
En la práctica — En la práctica — Ver a los actores en acción
- Descarga nginx:1.27 con pull y lista tus imágenes, como Idir.
- Lanza dos contenedores de esta imagen con --name diferentes.
- Lístalos con docker ps: misma imagen, dos vidas.
- Elimina uno: verifica que la imagen y el otro sobreviven.
Guion paso a paso — una imagen, tres contenedores como Idir (5 min)
1) Escribe docker pull nginx:1.27 y luego docker images: localiza la imagen descargada. 2) Escribe docker run -d --name web1 nginx:1.27 y luego docker run -d --name web2 nginx:1.27: dos vidas desde el mismo molde. 3) Escribe docker ps: verifica misma imagen, dos contenedores. 4) Escribe docker rm -f web2 y luego docker ps y docker images: como Idir, constata que web1 y la imagen sobreviven.
run descarga sola la imagen ausente: el pull explícito sirve aquí para ver el registro en acción.
Modelo copiar-pegar — mi memorándum de los 5 actores
docker pull nginx:1.27 # registre → local (tag explicite)
docker images # stock local du daemon
docker run -d --name web1 nginx:1.27 # moule → pièce vivante
docker ps # même image, vies indépendantes
docker rm -f web2 # supprimer une pièce, garder le moule
# Client = télécommande / Daemon = serveur / Registre = bibliothèque.Triple web
Idir prueba el reparto: web1, web2, web3 desde nginx:1.27 — una imagen, tres vidas.
Base versionada
Idir fija postgres:16 para sus ensayos: misma etiqueta en todas partes, comportamiento reproducible.
Registro privado
En empresa, Idir añadirá GHCR o Harbor al Hub público: mismo pull, otra biblioteca.
Contenedor detenido
Un contenedor detenido ocupa disco (capa + registros) sin consumir CPU/RAM: Idir limpia con rm y prune.
✓ Buenas prácticas
- Precisa siempre una etiqueta de versión explícita.
- Nombra tus contenedores (--name) para orientarte.
- Ve el daemon como el «servidor», el cliente como el «mando a distancia».
✗ Errores frecuentes
- Confundir imagen y contenedor (eliminar uno queriendo el otro).
- Usar latest pensando que fija una versión.
- Creer que pull es obligatorio (run lo hace solo).
Puntos clave
- El cliente ordena, el daemon ejecuta.
- La imagen es inmutable, el contenedor está vivo.
- El registro almacena las imágenes versionadas.
- Una imagen → N contenedores independientes.
Reto 48h — aplica mañana
Repite el trío de Idir: pull de nginx:1.27, dos contenedores nombrados, ps para ver las dos vidas — y luego elimina uno y demuestra que la imagen y el otro sobreviven.
- Puedo citar los 5 actores y el papel de cada uno sin jerga.
- He lanzado N contenedores desde una sola imagen etiquetada.
- Sé lo que sobrevive cuando elimino un contenedor (imagen + vecinos).
Preguntas frecuentes
¿Dónde se almacenan mis imágenes?
En local, en el espacio del daemon (docker images). La copia de referencia vive en el registro remoto hasta que se hace pull — Idir verifica en local tras cada pull.
¿Un contenedor detenido consume recursos?
Casi nada de CPU/RAM, pero ocupa disco (su capa + sus registros). Se limpia con rm y prune — Idir purga las cáscaras en lugar de acumularlas.
¿Qué imagen describe mejor la pareja imagen / contenedor?