Contenedor vs máquina virtual

Quien aloja una aplicación se topa pronto con los dos términos: el VPS que alquilas es una máquina virtual, y la plataforma que recibe tu código suele ejecutarlo en un contenedor. Parecen lo mismo, pero aíslan de formas distintas, y eso cambia el costo, la seguridad y el trabajo de mantenimiento.

¿Qué es una máquina virtual?#

Una máquina virtual (VM) es una computadora simulada por software. Un hipervisor divide el hardware físico y entrega a cada VM CPU, memoria y disco virtuales. Dentro corre un sistema operativo completo, con su kernel, el núcleo que habla con el hardware. Como ejecuta un sistema entero, la VM exige más CPU, memoria y almacenamiento, según la documentación de Microsoft.

El resultado es una computadora aparte: puedes instalar cualquier sistema compatible, tocar drivers y abrir cualquier puerto. A cambio, actualizar el sistema, configurar el firewall y mantenerlo seguro pasa a ser trabajo tuyo. Es el modelo que describe VPS o nube: qué conviene a tu proyecto.

¿Qué es un contenedor?#

Un contenedor es, en palabras de la documentación de Docker, un proceso aislado con todos los archivos que necesita para ejecutarse. No hay un segundo sistema operativo: todos los contenedores de una máquina comparten el mismo kernel del host. Microsoft lo describe como un espacio ligero y aislado que corre sobre el kernel del host y contiene solo la aplicación y algunas API del sistema en modo usuario.

Puedes verlo en un host Linux con Docker Engine instalado directamente (Docker Desktop ejecuta los contenedores dentro de una VM, así que ahí el kernel que aparece es el de esa VM). Los dos comandos siguientes imprimen la misma versión de kernel, porque el contenedor no tiene kernel propio:

uname -r
docker run --rm alpine uname -r

¿Cómo aísla un contenedor sin kernel propio?#

En Linux, el aislamiento viene de dos funciones del kernel:

• Namespaces hacen que un recurso global parezca exclusivo de quien está dentro del namespace. Hay namespaces para puntos de montaje (mnt), IDs de proceso (pid), red (net), nombre de host (uts), usuarios (user) y otros. Dentro del contenedor, el proceso ve solo sus propios procesos, su propia red y su propio sistema de archivos.
• Cgroups (control groups) agrupan procesos y limitan y monitorean el uso de recursos, como memoria y CPU.

Por eso puedes limitar un contenedor al iniciarlo:

docker run --rm -m 256m --cpus 1 alpine echo "limitado a 256 MB y 1 CPU"

Este aislamiento es real, pero lo aplica el mismo kernel que usan todos. Un fallo grave en ese kernel afecta a todos los contenedores de la máquina. En una VM, un fallo en el kernel del invitado queda dentro de esa VM: para llegar a las demás, el atacante tendría que escapar además del hipervisor.

Contenedor vs VM lado a lado#

La tabla sigue la comparación de Microsoft en aislamiento, sistema operativo y actualizaciones. Hay variantes: contenedores con aislamiento reforzado por una VM ligera, y contenedores dentro de VM (una configuración común en la nube).

¿Cuándo usar un contenedor?#

El contenedor encaja cuando la aplicación es un proceso común y quieres empaquetarla y moverla sin complicaciones:

• bots, APIs y sitios en Node.js, Python, Java y lenguajes parecidos;
• entornos idénticos en desarrollo y producción: la imagen lleva las dependencias, lo que ayuda a evitar el "en mi máquina funciona";
• varios servicios pequeños compartiendo el mismo servidor;
• deploys frecuentes, donde cambiar la imagen es más simple que reconfigurar una máquina.

Las configuraciones como claves y URLs de base de datos quedan fuera de la imagen, en variables de entorno, para que la misma imagen sirva en cualquier entorno.

¿Cuándo usar una máquina virtual?#

La VM es la opción cuando necesitas lo que el contenedor no da:

• un sistema operativo distinto al del host, como Windows en un servidor Linux;
• acceso al kernel: módulos, drivers o parámetros del sistema;
• una barrera de seguridad fuerte entre cargas que no confían entre sí;
• software que espera una máquina entera, administrada a mano.

Si solo quieres mantener un proceso en línea, una VM suele ser más máquina de la necesaria. Ambas también se combinan: el VPS que alquilas puede ser la base de un servidor Docker. Para el siguiente paso, mira qué es un deploy.

Cómo hacerlo en Square Cloud#

Square Cloud es hosting self-service basado en contenedores. Cada aplicación corre en un contenedor aislado, en un datacenter Tier 3 en Nueva York, siempre encendida y sin modo de suspensión, con reinicio automático (activado por defecto en el deploy desde el panel) cuando el proceso termina con un error. No administras un sistema operativo: haces el deploy del código y defines la RAM de la aplicación.

El deploy puede hacerse subiendo un ZIP en el panel, con la CLI, por GitHub (un push dispara el deploy, mediante la GitHub Action oficial o un webhook) o con la extensión de VS Code. Hay diversos runtimes, como Node.js, Python, Java, Go y Rust: consulta los runtimes disponibles hoy en Runtimes. Las variables de entorno viven en el panel, la API o la CLI y se aplican en el próximo reinicio, sin rebuild. Para escalar, cambias la RAM de la aplicación (escala vertical); no hay autoscaling.

No hay acceso root (el proceso corre como usuario sin privilegios) ni Dockerfile o imagen propia. Si necesitas root, otro sistema operativo o acceso al kernel, el camino es una VM. Si te basta un contenedor, consulta qué incluye en las funciones de Square Cloud.