Docker facilita considerablemente la gestión de imágenes mediante comandos intuitivos y efectivos desde tu terminal u opciones visuales desde Docker Desktop. Aprender a administrar adecuadamente versiones, etiquetas (tags) y eliminación de imágenes es clave para mantener un control claro y efectivo sobre proyectos que implican múltiples imágenes y contenedores.
¿Cómo asignar versiones específicas a tus imágenes Docker?
Asignar versiones específicas a tus imágenes Docker es sencillo mediante el parámetro -tag. Desde tu terminal puedes hacerlo fácilmente de esta manera:
docker build -tag sitio_web22:2.1.5 .
Aquí puedes definir según tus preferencias el nombre y número de versión, lo que facilita la identificación posterior de cada versión particular.
¿Cuál es la forma eficiente de filtrar y encontrar imágenes Docker?
Al trabajar con múltiples imágenes, utilizar filtros en la línea de comandos simplifica enormemente la búsqueda y gestión. Usa el parámetro filter para ubicar imágenes según su tag específico:
docker images --filter=reference="*:1.0"
Así obtendrás únicamente aquellas imágenes etiquetadas con un tag específico, evitando revisar largas listas.
¿Cómo visualizar el ID completo de tus imágenes Docker?
Docker habitualmente muestra IDs resumidos. Para mostrar el ID real completo del tipo SHA-256, emplea el parámetro --no-trunc:
docker images --no-trunc
Esto proporciona mayor detalle cuando necesitas identificar inequívocamente imágenes usadas en distintos contextos.
¿Cómo actualizar y eliminar etiquetas fácilmente?
Docker permite modificar etiquetas (tags) sin necesidad de reconstrucción, ejecutando simplemente:
docker image tag sitio_web:latest amin/sitio_web:latest
Para eliminar etiquetas (no imágenes completas), usa el comando:
docker rmi amin/sitio_web:latest
¿De qué forma puedes forzar la eliminación de imágenes Docker?
Si intentas borrar una imagen activa (en uso por alguno de tus contenedores), Docker arroja un error. Una solución eficiente es el uso del parámetro -f (force):
docker rmi -f <IMAGE_ID>
Esto eliminará la imagen inmediatamente, deteniendo también cualquier contenedor relacionado.
La gestión ágil y efectiva de imágenes Docker mediante estos comandos te proporciona control absoluto sobre el entorno de trabajo. ¿Tienes alguna experiencia usando Docker que desees compartir? ¡Cuéntanos en los comentarios!
El profe no indica como se borra el contenedor en la terminal pero buscando es primero deteniendolo si esta usando
docker stop id del contenedor
el id se consigue con docker ps, luego borrando el contenedor (aunque cuando yo lo detuve me lo borro de una vez):
docker rm id contenedor
y luego ya podriamos borrar la imagen que se ejecutaba en el contenedor
Correcto
Un atajo para eliminar un contenedor encendido, es el comando:
dockerrm -f id\_contenedor
Este comando, apaga el contenedor y luego lo elimina.
Comandos para Imágenes
Construir una imagen a partir de un archivo Dockerfile
docker build -t <nombre_de_imagen>
Construir una imagen desde un archivo Dockerfile sin la caché
docker build -t <nombre_de_imagen> . -no-cache
Listar imágenes locales
docker images
Eliminar una imagen
docker rmi <nombre_imagen>
Eliminar todas las imágenes no utilizadas
docker image prune
Inicie sesión en Docker
docker login -u <nombredeusuario>
Publica una imagen en Docker Hub
docker push <nombre_usuario>/<nombre_imagen>
Buscar una imagen en Hub
docker search <nombre_imagen>
Extraer una imagen de un Docker Hub
docker pull <nombre_imagen>
Algunos aspectos a tener en cuenta en esta clase:
En el minuto 4:35 se habla del parámetro --no-trunc asociado al comando images, el cual es necesario en versiones anteriores de Docker, debido a que esta herramienta reutilizaba la imagen existente en lugar de crear una nueva, lo que hacía que el IMAGE ID fuera el mismo para todas las imágenes resultantes de construcciones basadas en el mismo dockerfile y la misma imagen de base, que en este caso es la del NGINX que se trajo del Docker Hub.
En la nueva versión de Docker esto cambió, ya que la herramienta genera una nueva imagen siempre, incluso si el contenido es idéntico, por lo que el IMAGE ID asignado a cada imagen es diferente.
Esto se relaciona con lo indicado en el minuto 5:42 de esta misma clase, en la que se menciona que al combinar el parámetro tag con el comando image, se obtiene una actualización, pero lo que realmente sucede es que se clona una imagen y se le asigna un alias o nombre diferente, por lo que en este caso el IMAGE ID de la imagen clonada es igual al asignado a su alias, ya que están empleando la misma referencia.
Les comparto la documentación oficial de Docker, siento que es de gran ayuda y puede permitir a más de uno entender a profundidad ciertos conceptos para reforzar con el curso:
Entonces al final de cuentas no se habían creado nuevas imagenes sino que se estaban creando tags que apuntaban a la misma. Estoy en lo correcto? Si es así eso quiere decir que no se pueden crear imagenes de algo igual dentro de un contenedor
No! Son imagenes distintas y con no trunc podes ver que al final tiene ID distinto. Lo que explica es que provienen del mismo dockerfile.
Saludos
Entiendo que el SHA256 es un algoritmo de hash, que a partir de los datos que están en un archivo genera este identificador único que vemos de 64 caracteres. Esto mediante una función matemática.
Como el profesor utilizo el mismo "conjunto de datos", la misma imagen pero le cambio el tag, siempre se genera el mismo HASH. Entonces, si modificara los datos, en ese caso veríamos un hash distinto.
En definitiva, son distintas imágenes pero devuelve el mismo HASH porque los datos son los mismos. Justamente, una de las características de los HASH es que ante una misma entrada de datos siempre produce el mismo hash, lo cual es crucial cuando se quiere verificar la integridad de los datos o autenticar información.
Eso es lo que entiendo, si estoy equivocado me corrigen.
# Asignar versión específica (etiqueta) a una imagen durante la construcción
docker build --tag sitio_web22:2.1.5 .
# Filtrar y encontrar imágenes por etiqueta específica
docker images --filter=reference="*:1.0"
# Visualizar el ID completo (SHA-256) de las imágenes
docker images --no-trunc
# Modificar una etiqueta de imagen (ej. de 'latest' a 'latest' en otro repositorio)
docker image tag sitio_web:latest amin/sitio_web:latest
# Eliminar una etiqueta (no la imagen completa, si tiene más de una)
docker rmi amin/sitio_web:latest
# Forzar la eliminación de una imagen (deteniendo cualquier contenedor relacionado)
docker rmi -f <IMAGE_ID>
Ejemplos de Uso
Listar todas las imágenes:
docker images
Listar todas las imágenes, incluyendo intermedias:
docker images -a
Mostrar solo los IDs de las imágenes:
docker images -q
Filtrar imágenes por etiqueta:
docker images -f "label=version=1.0"
Mostrar los digests de las imágenes:
docker images --digests
Listar imágenes sin truncar la salida:
docker images --no-trunc
Usar un formato personalizado para listar las imágenes:
La diferencia entre docker rmi y docker rm radica en lo que cada uno elimina:
docker rmi: Se utiliza para eliminar imágenes de Docker. Al ejecutar este comando, puedes remover imágenes específicas o todas las que no están en uso.
docker rm: Se utiliza para eliminar contenedores en ejecución o detenidos. Este comando elimina la instancia del contenedor, pero no afecta a la imagen de la que fue creado.
Ambos comandos son esenciales para la gestión de tus recursos en Docker.
También puedes usar docker image rm IMAGE_ID
Antes de ir a buscar una respuesta por mi cuenta, en este punto tengo dos preguntas:
Entiendo la función de Docker para empaquetar y mover a producción asegurando que corra transparente como en nuestras máquinas.. // Docker reemplaza CONDA al empaquetar todo y asegurando con el archivo "requirements" que se instale todo lo necesario.. o Ya son dos cosas diferentes ?
Si al crear las imágenes en Docker puedo ver un sistema de diferentes versiones.. dónde queda o entra Github en este proceso ?
De lo poco que he aprendido hasta ahora, creo el producto en local a partir de un ambiente en CONDA.. lo subo a Github en diferentes versiones.. y de ahí lo conecto a una plataforma como VERCEL para hacer el deployment.. Perdón por la confusión pero realmente estoy perdido. Gracias!!
Pregunta 1: No son cosas diferentes, solo son pasos diferentes
Pregunta 2: Github es un control de versiones para tu código, Docker solo puede establecer las versiones de cada imagen, funcionan para fines muy diferentes.
Pregunta 3: CONDA es un gestor de paquetes mucho más parecido a PIP, NPM o NuGet, únicamente gestiona los ambientes, puedes por ejemplo establecer instrucciones de CONDA dentro de un contenedor de Docker.
Con CONDA puedes crear ambientes virtuales, pero al intentar correr tu aplicación en otras máquinas necesitarias crear el mismo ambiente, con el mismo requirements.txt y cruzar dedos de que no haya diferencias con el sistema operativo u otra causa que pueda generar problemas. Sin embargo, con Docker te llevas todo empaquetado en una imagen y solo debes ejecutar en tu nueva máquina, porque la nueva imagen de Docker ya tiene todo incluido (OS, paquetes y demas).
El comando docker images --no-trunc en Docker se utiliza para mostrar la lista de imágenes en tu sistema sin truncar (cortar) la información de los IDs de las imágenes. Esto te permite ver los IDs completos de las imágenes, que son útiles para identificar imágenes de manera única y realizar operaciones de gestión.
Detalles del Comando
docker images: Muestra una lista de imágenes en tu sistema Docker.
-no-trunc: Opción que evita que se trunque (corte) la información, mostrando los IDs completos de las imágenes.
Cuándo Utilizar-no-trunc
Identificación Precisa: Cuando necesitas el ID completo para ejecutar operaciones específicas, como eliminar una imagen o verificar información detallada.
Depuración: Cuando estás depurando problemas relacionados con imágenes y necesitas asegurarte de que estás trabajando con la imagen correcta.
Scripts y Automatización: Cuando estás escribiendo scripts o herramientas que necesitan procesar el ID completo de las imágenes.
que gran curso! bien explicado
Para los que estamos trabajando desde Linux:
Detener docker container:
docker stop nombre_o_id_contenedor
Eliminará todas las imágenes y tags creados:
docker rmi -f id_imagen
NO jodas!
Que alguien le una cerveza al profe...
Van 2 clases con chistes FINOS - FINOS!
Larga vida al profe Amin Espinoza !!
¿Cuál es la mejor forma de filtrar imágenes?
Cuando acumulas decenas de proyectos y versiones, buscar visualmente en la terminal se vuelve completamente ineficiente. La estrategia más efectiva es usar el parámetro --filter combinado con el atributo reference. Por ejemplo, al ejecutar docker images --filter "reference=*:1.0", le indicas al motor que ignore todo el ruido visual y te muestre únicamente las imágenes que coincidan con esa versión exacta, sin importar el nombre del repositorio base. Este enfoque es invaluable en servidores de integración continua o entornos de desarrollo saturados. Te permite auditar rápidamente qué aplicaciones están desactualizadas, agrupar proyectos que comparten la misma etapa de lanzamiento o preparar limpiezas masivas de versiones antiguas sin afectar tu trabajo actual.
Me sucede que sea como sea que cree la imagen sin importar si se hace de inmediato o no cada nueva imagen tiene un "image id" distinto (a diferencia de la clase), verificando con Gemini parece ser que se debe a un cambio en como Docker actualmente hace uso de los metadatos para sellar las imágenes. Acá te dejo su explicación:
📝 Aclaración: ¿Por qué los Image IDs son diferentes si el Dockerfile es el mismo?
Si al seguir la clase notas que, a diferencia del profesor, tus imágenes tienen un Image ID diferente cada vez que haces build (aunque no cambies nada), no te preocupes. Aquí la explicación:
BuildKit y Timestamps: Actualmente Docker usa BuildKit por defecto. Este motor sella la imagen con un metadato de tiempo llamado CreatedAt. Incluso si las capas están en caché (CACHED), el ID de la imagen es un hash de su configuración. Al haber segundos de diferencia entre un build y otro, el hash cambia y genera un ID único.
Por qué en la clase salen iguales: En versiones más antiguas de Docker (o con el builder clásico), si todas las capas se recuperaban de la caché, Docker simplemente reutilizaba el objeto de imagen anterior sin actualizar el timestamp de creación, manteniendo así el mismo ID.
¿Afecta al rendimiento?: No. Aunque los IDs sean distintos, Docker es inteligente: las imágenes comparten las mismas capas físicas en el disco. No estás duplicando el espacio utilizado, solo estás creando "firmas" diferentes para el mismo contenido.
Tip: Puedes comprobar que es el tiempo lo que cambia ejecutando docker inspect <ID_IMAGEN> y comparando el campo "Created".
en mi caso se crean diferentes IMAGE ID?
dejanos ver lo que estas ejecutando
Me paso igual, cuando cree la segunda imagen, se genero con diferente ID, al crear la tercera tenia el mismo ID de la primera
Así ejecute la segunda imagen:
docker build -t sitioweb22:1.5 .
Asi la tercera image:
docker build .
docker images --filter=reference='*:latest'
--filter: Permite filtrar en una lista de imagenes
reference='*latest' : Este es el filtro que estamos aplicando, *: Este carácter comodín significa "cualquier nombre de repositorio", latest: Esto se refiere a la etiqueta de la imagen
🐳 Administración de Imágenes en Docker: De la Teoría a la Práctica
A continuación, se presenta un resumen estructurado y enriquecido con ejemplos para que esta práctica se convierta en un proceso claro y profesional.
📦 De un Dockerfile a múltiples imágenes
Partimos del proceso básico: un Dockerfile produce una imagen y, de esa imagen, se crea un contenedor. En entornos de aprendizaje, esto es suficiente, pero en proyectos reales pronto se acumulan múltiples imágenes y contenedores.
Ejemplo: un proyecto con diferentes versiones de una aplicación web puede generar varias imágenes, todas basadas en el mismo Dockerfile.
Reto: sin gestión adecuada, se convierte en un caos de versiones y nombres confusos.
🏷️ Uso de tags para versionar imágenes
El tag permite identificar versiones específicas de una imagen y organizarlas de manera clara.
Se utiliza el parámetro -t al construir la imagen:
Ejemplo: docker build -t sitio-web:1.5 .
Esto permite diferenciar fácilmente entre sitio-web:1.0 y sitio-web:1.5.
Convención de nombres: queda a discreción del equipo, pero seguir un patrón consistente es clave para la trazabilidad.
👉 Recomendación: usar numeración semántica (1.0.0, 1.1.0, etc.) o basada en releases.
🔍 Filtrado y búsqueda de imágenes
Cuando la lista de imágenes crece, localizar la correcta se vuelve esencial.
Comando básico:docker images lista todas las imágenes.
Filtrar por nombre:docker images sitio-web muestra solo las relacionadas con el repositorio indicado.
Filtrar por tag:docker images --filter=reference='*:1.0' devuelve únicamente las imágenes con ese tag específico.
💡 Este enfoque ahorra tiempo en entornos con decenas o cientos de imágenes.
🆔 Identificación real de imágenes
Cada imagen tiene un Image ID basado en SHA-256.
Por defecto: Docker muestra una versión corta del ID.
Versión completa:docker images --no-trunc revela el hash completo.
Ejemplo: varias imágenes con diferentes tags pueden compartir el mismo ID porque provienen del mismo Dockerfile.
🪄 Creación y actualización de tags
No siempre es necesario reconstruir una imagen para cambiar su tag.
Comando:docker image tag.
Ejemplo: renombrar sitio-web:latest como amin/sitio-web:latest para seguir convenciones de repositorios.
Resultado: mayor organización al preparar imágenes para registries privados o Docker Hub.
🗑️ Eliminación de imágenes
La limpieza es parte fundamental de la administración.
Eliminar etiqueta (untag):docker rmi amin/sitio-web:latest solo quita el tag, no la imagen real.
Eliminar por ID:docker rmi image_id elimina todas las referencias a esa imagen, siempre que no esté en uso.
Forzar eliminación:docker rmi -f image_id borra imágenes incluso si están asociadas a contenedores detenidos.
⚠️ No se pueden eliminar imágenes en uso por contenedores activos. Primero deben detenerse o eliminarse esos contenedores.
✅ Conclusión y recomendaciones prácticas
La gestión de imágenes en Docker no es solo cuestión de comandos, sino de disciplina y organización.
Usa tags claros y consistentes para versionar tus imágenes.
Filtra y busca imágenes con --filter para mantener control en entornos complejos.
Aprende a identificar imágenes por su Image ID real cuando trabajes con múltiples etiquetas.
Establece convenciones de nombres alineadas con tu flujo de CI/CD y repositorios de imágenes.
Limpia periódicamente las imágenes obsoletas para evitar acumulación y liberar recursos.
En resumen, dominar los comandos docker images, docker image tag y docker rmi te da el control total sobre tu ecosistema de imágenes, permitiéndote trabajar con orden, seguridad y eficiencia.
Interesante, me recuerda mucho a git por los comandos, me está gustando bastante