Imagen
Artefacto empaquetado e inmutable que contiene la aplicación, sus dependencias y la configuración necesaria para ejecutarla.
Un contenedor encapsula una aplicación y su entorno de ejecución con una estructura más ligera que una máquina virtual. En lugar de empaquetar un sistema operativo completo, incluye la aplicación, sus dependencias y las bibliotecas necesarias.
Concepto 1 de 7
Cuatro conceptos que conviene distinguir antes de profundizar en el funcionamiento de los contenedores.
Artefacto empaquetado e inmutable que contiene la aplicación, sus dependencias y la configuración necesaria para ejecutarla.
Instancia en ejecución de una imagen. Puede iniciarse, detenerse, reiniciarse o eliminarse.
Componente que ejecuta el contenedor y aplica los mecanismos de aislamiento y control definidos por la plataforma.
Los contenedores no arrancan su propio kernel. Todos utilizan el kernel del sistema operativo anfitrión.
Pruébalo: crea varios contenedores a partir de la misma imagen y cambia su estado. Observa que la imagen nunca se modifica.
Imagen inmutable
mi-app:1.0
app · dependencias · configuración
Aún no hay contenedores. Crea el primero desde la imagen.
0 contenedores desde una sola imagen
docker images # mi-app:1.0 está lista para ejecutarseConcepto 2 de 7
Un contenedor no es una mini máquina virtual. Es un proceso o conjunto de procesos del sistema operativo anfitrión ejecutados con aislamiento adicional.
Cambia el punto de vista: primero mira los procesos desde dentro del contenedor y luego desde el host. Son los mismos procesos con otra numeración.
docker exec web psProcesos del contenedor
Dentro del contenedor, el namespace PID muestra solo sus propios procesos, numerados desde 1. El proceso principal de la aplicación es el PID 1.
Concepto 3 de 7
Dos modelos de aislamiento con diferencias fundamentales en su estructura y consumo de recursos.
Selecciona cada capa para ver qué aporta y usa Simular arranque para comparar cuánto trabajo hace cada modelo antes de que la aplicación esté disponible.
Explora las capas
Selecciona una capa para ver qué aporta, o simula el arranque de ambos modelos.
Concepto 4 de 7
Dos enfoques distintos para usar contenedores, con propósitos y herramientas diferentes.
Empaqueta y ejecuta un servicio o proceso principal de la forma más ligera posible. Es el enfoque típico de Docker y el estándar predominante en el desarrollo de software moderno, microservicios, CI/CD y despliegues en la nube.
Ofrece una experiencia más cercana a un sistema completo, con múltiples servicios y un init, sin llegar a virtualizar hardware. Herramientas como LXC y gestores como LXD o Incus apuntan a este caso de uso.
Concepto 5 de 7
No requieren arrancar un kernel ni un sistema operativo invitado. Su ciclo de vida se asemeja al de los procesos del sistema operativo.
Los contenedores suelen ser rápidos de crear e iniciar. Sin embargo, no son “gratuitos” en términos de costo operativo. En escenarios reales existe una sobrecarga asociada a los siguientes factores. Abre cada uno para ver de dónde viene.
“Los contenedores no tienen costo operativo.”
Tienen menos sobrecarga que una VM, pero no cero. Estos factores la explican:
El daemon y los procesos que gestionan el ciclo de vida de cada contenedor (dockerd, containerd, containerd-shim) consumen CPU y memoria propios.
OverlayFS combina capas de solo lectura con una capa escribible. La copia en escritura añade costo cuando la aplicación modifica muchos archivos.
Bridges, interfaces veth y reglas NAT agregan saltos al tráfico entre contenedores y hacia el exterior.
Recolectores de logs, proxies y agentes que acompañan a la aplicación también consumen recursos del host.
Concepto 6 de 7
Un contenedor depende del tipo de kernel del host. Esto define qué contenedores pueden ejecutarse en cada sistema.
La regla es simple: el contenedor necesita el mismo tipo de kernel para el que fue construido. Elige un sistema anfitrión y un tipo de contenedor para ver qué ocurre.
Sistema anfitrión
Tipo de contenedor
Nativo
El contenedor comparte directamente el kernel Linux del host. Es el caso más común en servidores y en la nube.
Concepto 7 de 7
Los contenedores utilizan capacidades nativas del kernel Linux para aislar procesos y controlar el consumo de recursos.
Dos mecanismos trabajan juntos: los namespaces deciden qué ve un proceso y los cgroups deciden cuánto puede consumir. Explora cada uno en su pestaña.
Aíslan la vista del proceso sobre los recursos. Responden a la pregunta: ¿qué puede ver?
Árbol de procesospid
Ve todos los procesos del host.
Solo ve sus propios procesos; el principal es el PID 1.
Interfaces de rednet
Usa las interfaces, direcciones IP y puertos del host.
Tiene su propia interfaz (eth0), su IP y sus puertos.
IDs de usuariouser
root dentro del proceso es root en el host.
root dentro puede corresponder a un usuario sin privilegios en el host (en Docker requiere userns-remap o modo rootless).
Sistemas de archivosmnt
Ve el sistema de archivos del host.
Ve su propio árbol de archivos, construido a partir de la imagen.
Limitan y monitorean el consumo de recursos. Responden a la pregunta: ¿cuánto puede usar?
Limitar: el comando que aplica estos límites
Monitorear: lo que reporta docker stats
Si el proceso supera el límite de memoria, el kernel lo termina (OOM kill). El de CPU, en cambio, solo lo frena.
Autoevaluación
Cinco preguntas rápidas para verificar las ideas clave de la lectura. Cada respuesta incluye una explicación.
0/5 respuestas correctas