Imagen, contenedor y microservicio: no son lo mismo

Curso de Introducción a los Microservicios

Contenido del curso

Fundamentos de Microservicios

Arquitectura Basada en Microservicios

Automatización y Preparación del Entorno

Comunicación Asíncrona entre Servicios

Despliegue

Observabilidad

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:002:39

Imagen, contenedor y microservicio: no son lo mismo

Curso de Introducción a los Microservicios

Clase 2 de 24

Clase 2 / 24

Recursos

Entender la diferencia entre imagen, contenedor y microservicio es el primer paso para dominar una arquitectura de microservicios. Aunque en el día a día del desarrollo de software solemos usar estos términos como sinónimos, cada uno cumple un rol distinto dentro del ciclo de despliegue. Si confundes los conceptos, vas a confundir también las decisiones técnicas.

¿Qué es una imagen en Docker y para qué sirve?

Una imagen es el punto de partida. La generas a partir de un archivo Dockerfile y, en esencia, es el resultado de compilar tu solución de software en un único paquete que contiene todo lo necesario para que tu aplicación funcione.

Piénsalo así: una imagen es un archivo comprimido, un ZIP muy moderno. No se ejecuta por sí sola, no interactúa con nada, simplemente existe como un artefacto listo para ser distribuido.

¿Qué contiene una imagen de Docker? Contiene el código de tu aplicación, sus dependencias y la configuración mínima del entorno para que pueda correr en cualquier máquina. Todo empaquetado a partir de un Dockerfile.

Esa imagen la puedes publicar dentro de un registro de contenedores, que funciona como el repositorio donde otras instancias (en la nube o locales) van a buscarla cuando la necesiten.

¿Cuándo una imagen se convierte en contenedor?

El salto de imagen a contenedor ocurre en el momento de la ejecución. Cuando una instancia descarga tu imagen y la corre, en automático se vuelve un contenedor. Esto se ve muy claro en Docker Desktop al ejecutar el comando docker run: el concepto pasa de imagen a contenedor frente a tus ojos.

¿Qué puedes hacer con un contenedor?

Una vez que tu imagen está corriendo como contenedor, ganas interacción real con ella. Y ahí es donde aparecen las capacidades operativas:

Acceder a la terminal del contenedor para inspeccionarlo o depurarlo.
Consumir sus recursos asignados, como CPU y memoria.
Compartir volúmenes para persistir datos o sincronizar archivos con el host.

Esa diferencia importa: la imagen es estática, el contenedor es la imagen viva, ejecutándose y respondiendo.

¿Cuál es la diferencia entre imagen y contenedor? La imagen es el archivo empaquetado con tu aplicación. El contenedor es esa imagen ejecutándose como un proceso activo, con el que ya puedes interactuar.

¿Qué es un microservicio y en qué se diferencia de un contenedor?

Aquí viene el concepto que da nombre a toda la arquitectura. Un contenedor ejecutándose por sí solo ya es un servicio. Pero el término microservicio viene heredado de la arquitectura de servicios y aporta una idea distinta: hablamos de un conjunto de pequeñas aplicaciones que trabajan juntas.

En lugar de tener una gran API con 25 métodos distintos, vas a tener probablemente 25 servicios con un método cada uno. Ese conjunto de servicios pequeños y especializados, conviviendo y comunicándose entre sí, es lo que conforma una arquitectura de microservicios.

¿Por qué importa distinguir estos tres conceptos?

Porque cada uno se usa en un momento distinto del flujo de trabajo, y mezclarlos lleva a errores de diseño:

La imagen la usas cuando empaquetas y distribuyes tu aplicación.
El contenedor aparece cuando ejecutas esa imagen en cualquier entorno.
El microservicio lo discutes cuando diseñas cómo se descompone tu sistema en piezas pequeñas e independientes.

Con esta distinción clara, ya puedes saber en qué momento hablas de empaquetar, en qué momento de ejecutar, y en qué momento estás realmente desplegando una arquitectura de microservicios. ¿Tú cómo venías usando estos términos hasta ahora? Cuéntame en los comentarios.

Resumen

¿Qué es una imagen en Docker y para qué sirve?

Piénsalo así: una imagen es un archivo comprimido, un ZIP muy moderno. No se ejecuta por sí sola, no interactúa con nada, simplemente existe como un artefacto listo para ser distribuido.

¿Qué contiene una imagen de Docker? Contiene el código de tu aplicación, sus dependencias y la configuración mínima del entorno para que pueda correr en cualquier máquina. Todo empaquetado a partir de un Dockerfile.

Esa imagen la puedes publicar dentro de un registro de contenedores, que funciona como el repositorio donde otras instancias (en la nube o locales) van a buscarla cuando la necesiten.

¿Cuándo una imagen se convierte en contenedor?

¿Qué puedes hacer con un contenedor?

Una vez que tu imagen está corriendo como contenedor, ganas interacción real con ella. Y ahí es donde aparecen las capacidades operativas:

Acceder a la terminal del contenedor para inspeccionarlo o depurarlo.
Consumir sus recursos asignados, como CPU y memoria.
Compartir volúmenes para persistir datos o sincronizar archivos con el host.

Esa diferencia importa: la imagen es estática, el contenedor es la imagen viva, ejecutándose y respondiendo.

¿Cuál es la diferencia entre imagen y contenedor? La imagen es el archivo empaquetado con tu aplicación. El contenedor es esa imagen ejecutándose como un proceso activo, con el que ya puedes interactuar.

¿Qué es un microservicio y en qué se diferencia de un contenedor?

¿Por qué importa distinguir estos tres conceptos?

Porque cada uno se usa en un momento distinto del flujo de trabajo, y mezclarlos lleva a errores de diseño:

La imagen la usas cuando empaquetas y distribuyes tu aplicación.
El contenedor aparece cuando ejecutas esa imagen en cualquier entorno.
El microservicio lo discutes cuando diseñas cómo se descompone tu sistema en piezas pequeñas e independientes.

Fundamentos de Microservicios

Arquitectura de microservicios vs sistemas monolíticos

Imagen, contenedor y microservicio: no son lo mismo

API monolítica base para microservicios en .NET

Arquitectura Basada en Microservicios

Dividir una API en microservicios escalables

Kafka para comunicar microservicios por eventos

Flujo de trabajo con Kafka para enrutar microservicios automáticamente

Bases de datos fuera de contenedores Docker

Automatización y Preparación del Entorno

Automatiza microservicios ASP.NET con Bash

Automatizar microservicios con Bash y Dockerfile

Azure Service Bus para comunicación entre microservicios

Rest Client como alternativa a Swagger en VS Code

Comunicación Asíncrona entre Servicios

Envía mensajes a Azure Service Bus desde .NET

Microservicio receptor con worker en .NET

Topics de Azure Service Bus con patrón Pub/Sub

Conectar Add Adult a Service Bus y SQL

Despliegue

Tres microservicios .NET corriendo sin Docker

Creación de servicios de consulta con .NET y SQL

Docker Compose con cinco microservicios .NET

Monorepo vs multirepo en microservicios

Configuración de secretos de GitHub para desplegar en Azure

Observabilidad

Despliegue de aplicaciones con Azure Container Apps desde Docker Hub

Despliegue automático de microservicios con GitHub Actions

Desplegando microservicios con GitHub Actions

Próximos pasos de mejora en arquitectura de microservicios

Imagen, contenedor y microservicio: no son lo mismo

Progreso del curso

Fundamentos de Microservicios

Arquitectura Basada en Microservicios

Automatización y Preparación del Entorno

Comunicación Asíncrona entre Servicios

Despliegue

Observabilidad

Recursos

Recursos