Computación en la Nube — Unidad 2

Virtualización y Containerización

En la Unidad 1 vimos qué es "la nube" como modelo. En esta unidad bajamos un nivel: ¿cómo hace técnicamente un proveedor para que muchos clientes compartan un mismo servidor físico sin pisarse? La respuesta tiene dos capas, una sobre la otra: virtualización y containerización.

1. La idea de fondo

Una computadora física es cara, ocupa espacio y consume energía. Si en cada servidor corre una sola aplicación, la mayoría del tiempo está al 10 % de uso: pagamos por capacidad que no usamos. Las dos tecnologías de esta unidad resuelven el mismo problema desde ángulos distintos: aislar varias cargas dentro de un mismo hardware para aprovecharlo bien.

2. Virtualización

La idea de virtualización es vieja: ya estaba en los mainframes de IBM de los años 60-70 (CP/CMS, VM/370), donde se usaba para tiempo compartido entre usuarios. Lo que apareció en los 2000 fue la virtualización x86 mainstream (VMware ESX en 2001, Xen en 2003, KVM en 2007), que llevó esa idea al hardware de commodity y fue la primera respuesta seria al problema del desperdicio en servidores comunes. Permite ejecutar varios sistemas operativos completos sobre un mismo hardware, cada uno dentro de una "máquina virtual" (VM).

3. Containerización

Las VMs resuelven el problema del aislamiento, pero arrastran un costo: cada una lleva un sistema operativo entero adentro. Si necesitás 50 VMs para 50 microservicios, tenés 50 kernels corriendo en paralelo. Mucho desperdicio de RAM y disco. La containerización es la siguiente vuelta de tuerca: aprovecha que el sistema operativo ya está corriendo y aísla solamente los procesos.

Container contenedor

Un proceso (o grupo de procesos) que corre sobre el kernel del sistema operativo del host, pero con su propio sistema de archivos, su propia red y sus propios límites de recursos. No tiene sistema operativo propio: comparte el del host.

Metáfora

Como un local en un shopping: usás la estructura, electricidad y aire acondicionado del edificio (kernel del host), pero adentro decorás y vendés lo que vos quieras, sin ver a los locales vecinos.

Tecnologías populares

Docker Podman containerd LXC / LXD

Ventajas frente a una VM

• Arranque en milisegundos (vs minutos de una VM).
• Imagen liviana: decenas de MB vs gigabytes.
• Reproducible: la misma imagen corre igual en tu laptop, en CI y en producción.

4. VM vs Contenedor

La pregunta "VM o contenedor" no tiene una respuesta única: depende del aislamiento, la portabilidad y la velocidad que necesites.

Máquina virtual vs Contenedor

Máquina virtual

• Aislamiento fuerte (kernel propio).
• Puede correr cualquier SO.
• Arranque en minutos.
• Pesada (GB de disco, mucha RAM).

Contenedor

• Liviano (MB de disco, poca RAM).
• Arranque en milisegundos.
• Comparte kernel con el host (menor aislamiento).
• Atado al SO del host (un contenedor Linux no corre en Windows nativo).

5. Docker, el estándar de facto

Docker no inventó los contenedores —la tecnología venía desde los 2000 con cgroups y namespaces en Linux— pero los hizo accesibles a todo el mundo en 2013 con un CLI simple, un formato de imagen estándar y un registry público. Hoy es prácticamente sinónimo de "contenedor" en el día a día. Para el panorama completo de productos gestionados por proveedor (ECS, GKE, Cloud Run, Container Apps, Fly.io y el resto) y cuándo conviene cada uno, ver el recurso containers.

Docker es un conjunto de herramientas para construir, distribuir y ejecutar contenedores. Tiene tres componentes principales: el daemon (servicio en segundo plano que ejecuta los contenedores), el CLI (el cliente que usás vos para darle órdenes) y el registry (Docker Hub u otros, donde se publican las imágenes). La pieza más importante para el desarrollador es el Dockerfile: un archivo de texto que describe paso a paso cómo construir una imagen. A partir de él, docker build produce la imagen, docker run levanta un contenedor desde ella, y docker push / pull la sube o baja de un registry.

# Ver contenedores corriendo
docker ps

# Ver TODOS los contenedores (incluso los detenidos)
docker ps -a

# Entrar a un contenedor con shell
docker exec -it <container_id> sh

# Ver logs en vivo
docker logs -f <container_id>

# Detener y eliminar un contenedor
docker stop <container_id> && docker rm <container_id>

# Limpiar imágenes, contenedores y volúmenes sin usar
docker system prune -a --volumes

6. Persistencia y red

Por defecto, los contenedores son efímeros: cuando se eliminan, sus datos se pierden. Y están aislados de la red del host. Para apps reales necesitamos dos cosas: una forma de persistir datos y una forma de comunicar contenedores entre sí.

Para resolver la persistencia, Docker provee volúmenes: espacios de almacenamiento gestionados por el motor que sobreviven al ciclo de vida del contenedor. Se montan dentro de uno o varios contenedores y los datos escritos ahí persisten aunque el contenedor se elimine. Hay tres tipos: named volumes, gestionados por Docker y recomendados para datos de aplicaciones; bind mounts, que mapean un directorio del host directamente al contenedor (útil en desarrollo); y tmpfs, almacenamiento en RAM que se pierde al reiniciar. Un ejemplo típico: docker run -v miapp_datos:/var/lib/postgresql/data postgres:16.

Para resolver la comunicación entre contenedores, Docker crea redes virtuales. Dentro de una misma red, cada contenedor "ve" a los demás por su nombre de servicio en vez de por IP. Las redes típicas son: bridge (default, red privada entre contenedores del mismo host), host (sin aislamiento, comparte la red del host), overlay (distribuida entre múltiples hosts, usada por Swarm y Kubernetes) y none (aislamiento total sin red). Así, si tu aplicación se llama web y la base se llama db, podés conectarte desde la app a postgres://db:5432 y Docker resuelve el nombre internamente.

7. Orquestación: cuando un solo host no alcanza

Con Docker corriendo en una máquina solucionás el "desarrollo local" y los despliegues simples. Pero en producción real necesitás varios hosts, balanceo de carga, reinicios automáticos, despliegues sin interrupción y escalado horizontal. Esa capa se llama orquestación. Una alternativa para evitar parte de esa complejidad cuando el caso de uso es event-driven y la carga es esporádica es ir directo a serverless: el proveedor decide dónde y cuándo correr tu código y vos no operás cluster.

Para escenarios más simples existe Docker Compose, una herramienta de Docker para definir aplicaciones multi-contenedor en un solo archivo YAML (compose.yaml) y levantarlas con un comando. No reemplaza a Kubernetes, pero es el "punto dulce" para desarrollo local, demos y producciones chicas. Un compose.yaml típico define un servicio web (tu app), un servicio db (Postgres) y un volumen para la base; con docker compose up -d levanta todo configurado y conectado. Es exactamente lo que usa este mismo proyecto Sidecar.

8. Errores comunes

Usar la etiqueta :latest en producción

Qué suele pasar

El despliegue funciona hoy con nginx:latest; mañana sale una versión major nueva, :latest apunta a ella y tu producción se rompe sin que hayas tocado nada.

Por qué

:latest es una etiqueta mutable: lo que apunta hoy puede ser distinto mañana. Rompe la promesa de reproducibilidad de los contenedores.

Cómo evitarlo

Usá etiquetas específicas (nginx:1.27.3) o, todavía mejor, digests inmutables (nginx@sha256:abc...) en los manifiestos de producción.

9. Tips y buenas prácticas

10. Glosario rápido

11. Para profundizar

12. Cierre