Módulo 2: Manejo de imágenes Docker

Ya sabes arrancar contenedores a partir de una imagen, pero todavía las tratas como una caja negra que «simplemente funciona». En este módulo vamos a abrir esa caja: de dónde vienen las imágenes, cómo se versionan y por qué el hábito de tirar siempre de latest te va a explotar en la cara en producción tarde o temprano.

#Buscar y descargar imágenes

El comando docker search consulta Docker Hub desde tu terminal, aunque en la práctica la mayoría de gente prefiere mirar directamente en la web de Docker Hub porque muestra más contexto (documentación, tags disponibles, si es imagen oficial).

docker search nginx --limit 5
docker pull nginx:1.27
docker pull alpine:3.20
docker pull postgres:16

Contexto: ejecutado en tu máquina local. Qué hemos hecho: docker search lista repositorios públicos que coinciden con el nombre, limitando a 5 resultados para no saturar la terminal; docker pull con una etiqueta específica descarga esa versión exacta de cada imagen en lugar de la genérica.

#Etiquetas, versiones y por qué evitar latest

La etiqueta latest no significa «la versión más reciente y estable»: es simplemente el tag por defecto que cualquier mantenedor puede apuntar a lo que quiera, y en muchos repositorios cambia de imagen subyacente de un día para otro sin previo aviso. Si tu docker-compose.yml usa nginx:latest hoy y funciona, dentro de seis meses un docker pull puede traerte una versión mayor con cambios que rompan tu configuración, sin que tú hayas tocado nada.

docker pull nginx:1.27-alpine
docker pull postgres:16-alpine
docker images

Qué hemos hecho: fijamos versiones concretas (1.27-alpine, 16-alpine) en lugar de tags flotantes, y las variantes -alpine además reducen drásticamente el tamaño de la imagen final frente a la base completa basada en Debian.

#Listar, inspeccionar y eliminar imágenes

docker images
docker inspect nginx:1.27-alpine
docker image history nginx:1.27-alpine
docker rmi alpine:3.20

Qué hemos hecho: docker images lista todo lo descargado localmente con su tamaño y ID; docker inspect devuelve un JSON completo con metadatos (variables de entorno, comando por defecto, arquitectura, capas); docker image history muestra capa por capa cómo se construyó esa imagen; docker rmi la elimina de tu disco local.

#Capas de imagen y caché de construcción

Cada instrucción de un Dockerfile (que veremos a fondo en el próximo módulo) genera una capa de solo lectura, y Docker las apila unas sobre otras usando un sistema de archivos por capas. Cuando reconstruyes una imagen, Docker reutiliza las capas que no han cambiado desde caché, lo que acelera enormemente builds repetidos; solo reconstruye desde el punto exacto donde detecta un cambio hacia abajo.

docker image history postgres:16-alpine

Qué hemos hecho: este comando te deja ver, capa por capa, exactamente qué comando generó cada una y cuánto peso añadió, lo cual es clave para entender más adelante por qué el orden de instrucciones en un Dockerfile importa tanto para aprovechar la caché.

#Docker Hub, registros públicos y privados

Docker Hub es el registro público por defecto y el más usado, pero no es el único: existen alternativas como GitHub Container Registry, GitLab Registry o registros privados autohospedados con la imagen oficial registry, útiles cuando no quieres exponer tus imágenes propietarias al mundo.

• Registro público (Docker Hub): ideal para imágenes de software abierto como Nginx, Alpine, PostgreSQL
• Registro privado: necesario para imágenes con código propietario de tu empresa o proyecto
• Autenticación: con docker login puedes acceder a repos privados o subir tus propias imágenes con docker push

#Práctica: descargar e inspeccionar Nginx, Alpine y PostgreSQL

cd ~/proyectos-docker/mi-proyecto
docker pull nginx:1.27-alpine
docker pull alpine:3.20
docker pull postgres:16-alpine
docker images
docker inspect nginx:1.27-alpine | grep -A 5 "Architecture"
docker inspect alpine:3.20 | grep -A 5 "Size"
docker inspect postgres:16-alpine | grep -A 5 "Env"

Contexto: el cd inicial es solo por costumbre de trabajar desde la carpeta del proyecto, aunque como en el módulo anterior, estos comandos no dependen de la ubicación de tu terminal. Qué hemos hecho: descargamos las tres imágenes con versiones fijas, listamos lo que ya tienes en disco, y usamos grep para filtrar del JSON de inspect solo los campos que nos interesan (arquitectura, tamaño y variables de entorno) sin tener que leer el JSON completo a pelo.

#Troubleshooting Frecuente

#Plan de Rollback / Limpieza

docker rmi nginx:1.27-alpine alpine:3.20 postgres:16-alpine
docker image prune -a -f

Qué hemos hecho: borramos explícitamente las tres imágenes de la práctica y luego forzamos la limpieza de cualquier imagen huérfana sin tags que haya quedado suelta ocupando espacio.

El siguiente paso lógico es meterte con el Dockerfile: ahora que entiendes capas y caché, vas a construir tu propia imagen desde cero aprovechando exactamente estos conceptos para que tus builds sean rápidos.

#Hoja de trucos

xml