Gestión de Imágenes y Contenedores en Docker
Contenido del curso
Diego Alejandro Pinto Moreno
Edgar Ramirez
Caleb Espinoza Gutierrez
Leandro Espino Espino
Neil Ruiz
Diego Alejandro Pardo Montero
Ivan David Martinez Baron
Daniel Crespin
Franco Teseyra
IVAN CARAPIA BARAJAS
Jesus Gabriel Chavez Gimenez
Juan Miguel Garcia Moreno
Jhon Alexander Túquerres Jiménez
Gustavo Pú
Yorgen Omar Marciales Parada
Samuel Soto Hoyos
Javier Ladino
Amin Espinoza
Profesor
Juan Jose Tovar
Antonella Tortoza
Joel Orellana
Daniel Eduardo Rojas Pulido
Cristopher Porras
Miguel Gomez
Diego Aurelio Landa Torres
Camilo Carrillo
Luis alberto Plata Bonilla
Libardo Arturo Arroyave Bustos
Roberto Shirásago Domínguez
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:
docker rm -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:
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.
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
NO jodas! Que alguien le una cerveza al profe... Van 2 clases con chistes FINOS - FINOS! Larga vida al profe Amin Espinoza !!
# 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
docker imagesdocker images -adocker images -qdocker images -f "label=version=1.0"docker images --digestsdocker images --no-truncdocker images --format "{{.Repository}}:{{.Tag}} @ {{.ID}}"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
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
¿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:
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.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 .
🐳 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.
🏷️ Uso de tags para versionar imágenes
El tag permite identificar versiones específicas de una imagen y organizarlas de manera clara.
-t al construir la imagen:
docker build -t sitio-web:1.5 .sitio-web:1.0 y sitio-web:1.5.👉 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.
docker images lista todas las imágenes.docker images sitio-web muestra solo las relacionadas con el repositorio indicado.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.
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.
docker image tag.sitio-web:latest como amin/sitio-web:latest para seguir convenciones de repositorios.🗑️ Eliminación de imágenes
La limpieza es parte fundamental de la administración.
docker rmi amin/sitio-web:latest solo quita el tag, no la imagen real.docker rmi image_id elimina todas las referencias a esa imagen, siempre que no esté en uso.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.
--filter para mantener control en entornos complejos.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