Docker
Diferencias de aislamiento, kernel, arranque, densidad y casos de uso.
Una máquina virtual y un contenedor resuelven problemas relacionados, pero aíslan en niveles diferentes.
Una máquina virtual emula o virtualiza hardware suficiente para ejecutar un sistema operativo invitado completo. Un contenedor aísla procesos dentro de un sistema operativo y comparte el kernel con el host.
Máquina virtual
hardware físico
→ hypervisor
→ hardware virtual
→ guest OS + kernel
→ procesos
Contenedor
hardware físico
→ host OS + kernel
→ runtime de containers
→ procesos aisladosLa diferencia no significa que uno sustituya siempre al otro. En producción es común ejecutar contenedores dentro de máquinas virtuales: la VM delimita hosts o tenants y los contenedores empaquetan y organizan aplicaciones.
Las VMs permiten ejecutar sistemas operativos independientes sobre el mismo hardware. Son útiles cuando se necesita:
Los contenedores evitan repetir un sistema operativo completo por aplicación. Son útiles cuando se necesita:
Piensa en una VM como una casa completa dentro de un terreno virtual: tiene su propia instalación eléctrica, tuberías y reglas internas. Un contenedor se parece más a una habitación aislada dentro de un edificio: tiene límites y acceso controlado, pero comparte infraestructura fundamental.
La analogía tiene límites, pero ayuda a recordar:
Un hypervisor expone CPU, memoria, almacenamiento y dispositivos virtuales. El guest inicia su bootloader y kernel, detecta ese hardware virtual y arranca servicios del sistema.
crear VM
→ asignar vCPU, RAM y disco
→ arrancar firmware/bootloader
→ iniciar guest kernel
→ iniciar system services
→ ejecutar aplicaciónLa VM conserva estado en discos virtuales. Reiniciar la aplicación no implica recrear el guest. Esto facilita tratarla como una máquina tradicional, pero también favorece configuración manual y drift si no se automatiza.
El runtime crea un proceso en el kernel del host y configura namespaces, cgroups, mounts, capabilities y red.
crear container
→ preparar filesystem desde image
→ crear namespaces
→ aplicar cgroups y seguridad
→ configurar red y mounts
→ iniciar proceso principalNo existe un boot completo de sistema operativo. Por eso el arranque suele ser más rápido y el overhead menor.
| Aspecto | Máquina virtual | Contenedor |
|---|---|---|
| Kernel | Kernel propio del guest | Kernel compartido con el host |
| Unidad principal | Sistema operativo completo | Proceso o conjunto de procesos |
| Arranque | Boot del guest OS | Inicio del proceso |
| Densidad | Menor por guest OS y memoria reservada | Mayor, aunque depende del workload |
| Aislamiento | Frontera de virtualización más fuerte | Frontera basada en kernel y políticas |
| Compatibilidad | Puede ejecutar kernels distintos | Necesita kernel compatible con la image |
| Estado | Frecuentemente administrada como máquina duradera | Idealmente instancia reemplazable |
| Distribución | Images de VM, snapshots o templates | OCI images y registries |
Una imagen Linux necesita interfaces de un kernel Linux. En un host Linux, Docker Engine puede usar directamente ese kernel. En macOS y Windows, Docker Desktop ejecuta contenedores Linux dentro de una VM Linux.
macOS / Windows
→ Docker Desktop
→ Linux VM
→ Linux containersPor eso un contenedor Linux no ejecuta directamente sus syscalls sobre el kernel de macOS. La VM suministra el kernel esperado.
Los contenedores Windows utilizan otro modelo y requieren compatibilidad entre host, base image y versión del sistema. No debes asumir que una Dockerfile Linux será portable a Windows.
Los contenedores suelen usar menos memoria de base y arrancar más rápido porque no repiten un guest OS. Sin embargo, “contenedor = rendimiento nativo perfecto” es una simplificación.
El coste puede aparecer en:
Las VMs también pueden tener rendimiento cercano al nativo con virtualización moderna. La decisión no debe basarse únicamente en milisegundos de arranque.
La VM suele ofrecer una frontera más fuerte porque el atacante debe atravesar el guest y luego el hypervisor para alcanzar el host. En un contenedor, un proceso comprometido ya interactúa con el kernel compartido mediante syscalls permitidas.
Esto no significa que los contenedores sean inseguros. La seguridad depende de defensa en profundidad:
image confiable
+ usuario no root
+ capabilities mínimas
+ seccomp
+ AppArmor/SELinux
+ mounts restringidos
+ kernel actualizado
+ daemon protegidoPara ejecutar código hostil o multi-tenant no confiable pueden usarse VMs, microVMs o sandboxes adicionales. Un simple container con --privileged no ofrece una frontera adecuada.
Supón una plataforma con API, worker y base de datos.
Una opción es dedicar una VM a cada componente:
VM API → guest OS + API
VM worker → guest OS + worker
VM DB → guest OS + PostgreSQLOtra es usar una VM como nodo y varios contenedores:
VM Linux
├── API container
├── worker container
└── proxy container
Database administrada externaLa segunda opción aumenta densidad y simplifica despliegues. La VM sigue aportando aislamiento frente al proveedor físico y una unidad para parches, networking y capacidad.
La combinación es común cuando:
No es redundancia accidental: cada capa resuelve una frontera distinta.
No puede llevar su propio kernel. Puede requerir módulos en el host, privilegios elevados o directamente una VM.
Puede usarse emulación, pero con coste y posibles fallos en binarios nativos. Una VM tampoco elimina automáticamente la diferencia de arquitectura.
Parte de los recursos pertenecen a la VM Linux, cache del filesystem y containers. Debes medir dentro de la VM y del proceso, no comparar solo un número del monitor del host.
En una VM, root controla el guest. En un container, root puede estar restringido, pero mounts, capabilities o socket pueden darle impacto sobre el host. “Root” debe evaluarse según la frontera concreta.
Oculta la dependencia del kernel compartido y conduce a errores de seguridad, compatibilidad y lifecycle.
El boot es más pesado, pero workloads de larga duración pueden tener rendimiento adecuado. La comparación depende del recurso y la implementación.
Docker empaqueta procesos. No sustituye hosts, redes físicas, almacenamiento, backups ni alta disponibilidad.
Es uno de los despliegues más comunes: la VM y el container resuelven niveles diferentes.
En Linux, ejecuta:
docker run --rm alpine uname -a
docker run --rm alpine cat /proc/version
uname -aEl contenedor reportará el kernel del host. Cambiar la distribución de la image modifica userland, no el kernel compartido.
También observa los procesos:
docker run -d --name demo alpine sleep 300
docker top demo
ps aux | grep '[s]leep 300'El proceso existe tanto desde la vista aislada del contenedor como desde el host.
Arquitectura de Docker, donde se sigue una solicitud desde la CLI hasta el proceso creado por el runtime.