1.1Imágenes: etiquetas, capas y Docker Hub
Lo esencial en 30 segundos
- La etiqueta es la versión : postgres:16 fija la mayor, postgres:16.4 la menor, postgres:latest sigue la última (por tanto cambia sin avisar) — en producción, siempre se fija un tag preciso y se anota.
- Capas apiladas y compartidas : una imagen = un apilamiento de capas de solo lectura, puestas en caché y compartidas entre imágenes — diez imágenes sobre la misma base solo descargan la base una vez.
- Elegir sin equivocarse : imágenes oficiales (mantenedor verificado), etiquetas soportadas leídas en la doc, fecha de actualización y arquitectura (amd64/arm64) verificadas — una imagen abandonada desde hace dos años es un riesgo de seguridad.
Minicaso conductor — Idir, devops junior en Argel
Idir, devops junior en Argel, debe contenerizar la base de datos de una pequeña aplicación interna. En lugar de escribir « postgres » y tomar la primera propuesta, abre la página oficial en Docker Hub, compara las etiquetas y se queda con postgres:16.4: versión fijada, actualizada, disponible en amd64 y arm64. Anota esta elección en un archivo versions.txt compartido con su equipo. Seis meses después, cuando un colega relanza el entorno en otra máquina, obtiene exactamente el mismo comportamiento — porque la etiqueta no se ha movido.
Este mismo caso vuelve en el curso, el esquema, el script y el desafío 48h — y continúa en 1.2, 1.3, 1.4 y 1.5.
1. La etiqueta es la versión
Después de los « : », el tag designa la variante de la imagen: postgres:16 fija la versión mayor, postgres:16.4 la menor, postgres:latest sigue la última disponible — por tanto cambia sin avisar. En desarrollo, seguir latest es aceptable; en producción, siempre se fija un tag preciso y se anota (Idir lo escribe en versions.txt).
La regla cabe en una frase: fijar en producción, seguir en vigilancia. Un despliegue reproducible empieza por una etiqueta que no se mueve.
2. Capas apiladas y compartidas
Una imagen es un apilamiento de capas de solo lectura: cada instrucción del build añade una capa, cada capa se pone en caché y se comparte entre imágenes. Descargar diez imágenes basadas en el mismo Debian solo descarga la base una vez: por eso Docker es tan económico en descargas y en disco.
Consecuencia práctica: docker images muestra el tamaño descomprimido, pero la descarga solo trae las capas que faltan. De ahí el interés de las bases compartidas — y de las variantes slim cuando existen.
3. Elegir en Docker Hub sin equivocarse
Prefiera las imágenes oficiales (insignia, mantenedor verificado), lea las etiquetas soportadas y la documentación, verifique la fecha de actualización y la arquitectura (amd64 para PC/servidores, arm64 para Mac M y Raspberry). Una imagen oscura sin actualizar desde hace dos años es un riesgo de seguridad, aunque ahorre 50 MB.
Idir aplica la criba a cada nueva imagen: oficial, actualizada, documentada — solo esas se aceptan. El resto nunca sube a producción.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Elegir bien Postgres
La elección de Idir para la base de su aplicación, sin latest en producción.
docker pull postgres:16.4
docker images
# à éviter en production :
# docker run postgres:latestLectura: se fija la 16.4, se verifica su presencia local, se destierra latest de la prod.
Lección: seis meses después, la misma etiqueta devuelve el mismo comportamiento.
Vocabulario de la sección
- Tag
- Etiqueta de versión después de los « : » (16, 16.4, latest); designa qué variante de la imagen se recupera.
Ejemplo sencillo: Idir fija postgres:16.4 para su base de producción.
Lo que no es: un simple comentario decorativo.
Reflejo: prod = etiqueta fijada y anotada, nunca latest.
- Capa (layer)
- Estrato de solo lectura de la imagen, puesto en caché y compartido entre imágenes.
Ejemplo sencillo: La base Debian descargada una sola vez para diez imágenes.
Lo que no es: una copia completa duplicada por imagen.
Reflejo: bases compartidas = descargas ahorradas.
- Imagen oficial
- Imagen mantenida y verificada en Docker Hub (insignia, mantenedor identificado).
Ejemplo sencillo: El postgres oficial elegido por Idir en lugar de una copia oscura.
Lo que no es: la primera imagen que aparezca con « postgres » en el nombre.
Reflejo: oficial, actualizada, documentada — si no, abstenerse.
- latest
- Etiqueta móvil que sigue la última versión publicada: práctica en dev, inestable en prod.
Ejemplo sencillo: Idir la usa para probar, nunca para desplegar.
Lo que no es: una versión fijada y reproducible.
Reflejo: latest en dev, etiqueta precisa en producción.
En la práctica — En práctica — Auditar sus imágenes
- Liste sus imágenes locales (docker images) y detecte las latest.
- Para cada una, encuentre la etiqueta fijada equivalente en Docker Hub.
- Verifique la arquitectura y la frescura de la actualización.
- Anote su elección (imagen:etiqueta) en un archivo versions.txt.
Script listo para decir — justificar su imagen (30 s)
« Para la base, tomo la imagen oficial postgres, etiqueta 16.4 fijada — no latest, para seguir siendo reproducible. He verificado la fecha de actualización y la arquitectura en Docker Hub, y anoto la elección en versions.txt para el equipo. »
Para decir mostrando la página de Docker Hub y el archivo versions.txt.
Modelo copiar-pegar — versions.txt
# versions.txt — Idir, Alger
# Une ligne par image : nom:tag figé + date du choix
postgres:16.4 # base appli interne (choix 2026-10)
nginx:1.27 # frontal web (choix 2026-10)
# Règle : latest interdit en prod. Tout changement = nouvelle ligne datée.Base de datos de Idir
Como arriba: postgres:16.4 oficial, fijada y anotada — la base de la aplicación interna corre idéntica en cada máquina.
Frontal web ligero
nginx:1.27 oficial, variante slim si cubre la necesidad: misma criba (oficial, actualizada, arquitectura verificada) antes del primer pull.
Portátil arm64
Colega de Idir en Mac M: verificar que la etiqueta elegida exista bien en arm64 en Docker Hub antes de prometer la reproducibilidad.
Imagen de herramienta puntual
ubuntu:24.04 en -it --rm para trastear (nivel 1.2): aun siendo desechable, se fija la etiqueta en lugar de latest para reencontrar la misma herramienta mañana.
✓ Buenas prácticas
- Fijar en producción, seguir en vigilancia.
- Preferir las variantes slim cuando existen.
- Leer la página de Docker Hub antes del primer pull.
✗ Errores frecuentes
- Desplegar latest en producción (deriva silenciosa).
- Tomar una imagen abandonada para ahorrar 50 MB.
- Ignorar la arquitectura (imagen amd64 lenta en Mac M).
Puntos clave
- La etiqueta fija la versión; latest se mueve.
- Las capas se comparten y se cachean.
- Oficiales, actualizadas, documentadas: las únicas aceptadas.
- Se anotan las versiones como código.
Desafío 48h — aplique mañana
Liste sus imágenes con docker images, rastree las latest, encuentre su etiqueta fijada en Docker Hub (oficial, actualizada, buena arquitectura) y escriba su versions.txt.
- Elijo imágenes oficiales, actualizadas y documentadas.
- Fijo una etiqueta precisa en producción (nunca latest).
- Anoto cada elección imagen:etiqueta en versions.txt.
Preguntas frecuentes
¿Alpine o slim, cuál elegir?
Ambas aligeran: slim quita lo inútil de la imagen oficial, alpine cambia de libc (musl). Alpine es minúscula pero puede sorprender (DNS, rendimiento): pruebe antes de la prod. En ambos casos, se fija la etiqueta y se verifica la frescura.
¿Cuánto pesa realmente una imagen?
docker images da el tamaño descomprimido; la descarga solo trae las capas que faltan. De ahí el interés de las bases compartidas: apilar diez imágenes sobre el mismo Debian solo cuesta la base una vez.
¿Qué práctica para una base de datos en producción?