Trabajar con contenedores

Qué son los containers

Los containers son execution environments self-contained que comparten el kernel del host y están (opcionalmente) aislados de otros containers en el sistema. Es lo que se llama OS-level virtualization.

A diferencia de VMs (que tienen su propio kernel sobre un hypervisor), los containers son procesos del host kernel con aislamiento. Ventajas:

• Eficiencia de recursos: no necesitas una instancia completa de OS por cada workload aislado.
• Menos capas de indirección: cuando un proceso llama al hardware, no hay doble salto como en VMs.
• Casi todo lo que corre en el kernel del host puede correr en un container.

Breve historia

Los containers no son nuevos. La semilla se plantó en 1979 con chroot (Unix V7), que restringe la vista del filesystem de un proceso a un subárbol. En los 80s y 90s hubo variantes Unix con mandatory access controls. En 2000, FreeBSD 4.0 introdujo jail, que expandía chroot con restricciones de red y procesos. En 2004, Solaris Zones apareció como la primera implementación comercial importante. En 2008, LXC (Linux Containers) llegó al kernel Linux. En 2013, user namespaces (kernel 3.8) y el lanzamiento de Docker un mes después dispararon la adopción masiva.

Crear un container

docker container run es un wrapper que combina dos pasos: docker container create (crea el container desde la imagen) y docker container start (lo ejecuta). Puedes hacerlos por separado:

# Crear
docker container create --name="awesome-service" ubuntu:latest sleep 120

# Iniciar
docker container start awesome-service
# Se detendrá automáticamente a los 120s, o antes con:
docker container stop awesome-service

Configuración básica

Container name

docker container create --name="mi-app" ubuntu:latest sleep 120

Si no se especifica, Docker genera un nombre aleatorio combinando adjetivo y nombre de famoso (ecstatic-babbage, serene-albattani).

Labels

Metadata key/value que se heredan de la imagen y puedes extender:

docker container run --rm -d --name has-some-labels \
  -l deployer=Ahmed -l tester=Asako \
  ubuntu:latest sleep 1000

# Filtra por label
docker container ls -a -f label=deployer=Ahmed

# Ver todos los labels
docker container inspect has-some-labels

Hostname

Por defecto, el hostname es el ID del container. Para algo más legible:

docker container run --rm -ti --hostname="mycontainer.example.com" \
  ubuntu:latest /bin/bash
# Dentro: hostname -f → mycontainer.example.com

DNS

/etc/resolv.conf se bind-mounte desde el host. Para sobreescribir:

docker container run --rm -ti \
  --dns=8.8.8.8 --dns=8.8.4.4 \
  --dns-search=example1.com --dns-search=example2.com \
  ubuntu:latest /bin/bash

MAC address

Por defecto, el container recibe una MAC calculada con prefijo 02:42:ac:11. Para fijarla (por ejemplo, para evitar conflictos con otra capa de virtualización):

docker container run --rm -ti --mac-address="a2:11:aa:22:bb:33" \
  ubuntu:latest /bin/bash

Storage volumes

A veces el espacio default del container o su naturaleza ephemeral no es suficiente y necesitas storage que persista entre deploys.

# Bind mount (monta directorio del host en el container)
docker container run --rm -ti \
  --mount type=bind,target=/mnt/session_data,source=/data \
  ubuntu:latest /bin/bash

# O con -v (sintaxis corta)
docker container run --rm -ti \
  -v /mnt/session_data:/data \
  ubuntu:latest /bin/bash

# Read-only
docker container run --rm -ti \
  -v /mnt/session_data:/data:ro \
  ubuntu:latest /bin/bash

SELinux y volume mounts

Con SELinux habilitado en el host, mount puede dar “Permission Denied”. Usa las opciones z (compartido entre containers) o Z (privado, un solo container):

# Compartido entre containers
docker container run --rm -v /app/dhcpd/etc:/etc/dhcpd:z dhcpd

# Privado (un solo container, mejor seguridad)
docker container run --rm -v /app/dhcpd/etc:/etc/dhcpd:Z dhcpd

Read-only root filesystem

Para prevenir que procesos escriban al filesystem del container (logs, archivos temporales inesperados):

docker container run --rm -ti --read-only=true \
  -v /mnt/session_data:/data \
  ubuntu:latest /bin/bash
# El root está read-only, pero /data (volume) sigue rw

Combinado con tmpfs para directorios como /tmp:

docker container run --rm -ti --read-only=true \
  --mount type=tmpfs,destination=/tmp,tmpfs-size=256M \
  ubuntu:latest /bin/bash

Resource quotas

El problema clásico de “noisy neighbor”: otros containers consumen recursos en el mismo host. Las VMs resuelven esto con límites estrictos de memoria y CPU por VM. En Docker, cgroups del Linux kernel hacen este trabajo.

# Verificar soporte de cgroups en tu kernel
docker system info
# Si falta soporte, verás warnings como:
# WARNING: No swap limit support

CPU shares

El total de poder de cómputo de los cores es 1,024 shares. Asignar 512 a un container significa que puede usar hasta la mitad de CPU. Son shares, no exclusivo: si otros containers no usan CPU, este puede usar más.

# 50% del CPU
docker container run --rm -ti \
  --cpu-shares=512 \
  spkane/train-os \
  stress --cpu 2 --io 1 --vm 2 --vm-bytes 128M --timeout 30s

Si A no está corriendo, B y C pueden usar el 100% cada uno.

Memory limits

# Limitar a 256 MB
docker container run --rm -d \
  --memory=256m \
  --memory-swap=512m \
  your-image

# Si el container excede la memoria, es OOMKilled

[!note] --memory-swap --memory-swap es memory + swap. Si --memory=256m y --memory-swap=512m, el container puede usar 256 MB RAM + 256 MB swap. Si pones --memory-swap=-1, swap ilimitado. Si lo pones igual a --memory, swap deshabilitado.

Block I/O limits

Limitar el I/O de disco es especialmente útil para databases y workloads I/O-intensive:

# Limitar lectura/escritura a /dev/sda
docker container run --rm -d \
  --device-read-bps /dev/sda:1mb \
  --device-write-bps /dev/sda:1mb \
  your-image

Valores en kb, mb o gb. Para reads/writes per second en vez de bytes per second, usa --device-read-iops y --device-write-iops.

Próximos pasos

• 07-explorando-docker: comandos para explorar Docker (versión, info, imágenes, contenedores, logs, stats), entrando a containers corriendo con docker container exec y nsenter, retornando resultados, y explorando el shell de un container.