Listado de la etiqueta: contenedores

Docker vs Kubernetes: cuándo me alcanza con uno y cuándo necesito el otro

/0 Comentarios/en /por

Me pidieron «alta disponibilidad» para un sistema crítico. Tenía Docker Compose funcionando perfecto en un solo nodo. Pensé: «con –scale lo resuelvo». Hasta que entendí que escalar horizontalmente en múltiples nodos con Compose no es trivial. Ese fue el momento en que Kubernetes dejó de ser «esa tecnología complicada» y se convirtió en la herramienta correcta para el trabajo.

Docker standalone: cuándo alcanza

No todo necesita Kubernetes. Docker solo, o Docker Compose, es perfecto para muchos casos de uso:

  • Aplicaciones en un solo servidor
  • Entornos de desarrollo local
  • Proyectos personales o startups en etapa temprana
  • Workloads que no requieren alta disponibilidad real
  • Pipelines de CI/CD

La tabla que lo resume todo

CaracterísticaDocker soloDocker SwarmKubernetes
ComplejidadBajaMediaAlta
HA multi-nodoNoSí (básico)Sí (avanzado)
Auto-scalingManualBásicoHPA / VPA automático
Self-healingrestart policySíSí (avanzado)
Rolling updatesManualSíSí (con control fino)
SecretsEnv vars / archivosDocker SecretsKubernetes Secrets + Vault
NetworkingBridge / overlay básicoOverlayCNI (Calico, Flannel, etc.)
Observabilidaddocker logs / statsBásicaPrometheus, Grafana, Jaeger
Curva de aprendizajeDíasSemanasMeses

Docker Swarm: el punto medio

Swarm es el orquestador nativo de Docker. Más simple que Kubernetes, soporta multi-nodo y HA básica. Si necesitás distribuir contenedores en 2-5 nodos sin la complejidad de K8s, Swarm es una opción válida.

# Inicializar un swarm
docker swarm init --advertise-addr 192.168.1.10

# Agregar un nodo worker
docker swarm join --token SWMTKN-1-xxx 192.168.1.10:2377

# Desplegar un stack (similar a docker compose)
docker stack deploy -c docker-compose.yml mi-app

# Ver servicios del stack
docker service ls
docker service ps mi-app_api

# Escalar un servicio
docker service scale mi-app_api=3

Kubernetes: cuándo lo necesitás de verdad

En mi cluster SUSE Linux HA con dos nodos, Swarm funcionaba. Pero cuando los requisitos crecieron — deploys sin downtime garantizado, auto-scaling basado en métricas, gestión de secretos centralizada, rollbacks automáticos — Kubernetes fue la respuesta correcta.

La diferencia fundamental: Docker (y Swarm) son herramientas para correr contenedores. Kubernetes es una plataforma para gestionar aplicaciones. La distinción importa cuando tu aplicación crece.

# El mismo concepto en Docker Compose vs Kubernetes

# docker-compose.yml
services:
  api:
    image: mi-api:1.4.2
    replicas: 3
    restart: unless-stopped

# ─────────────────────────────────────────────
# En Kubernetes (deployment.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1    # nunca baja de 2 replicas durante update
      maxSurge: 1          # puede tener 4 temporalmente
  selector:
    matchLabels:
      app: api
  template:
    spec:
      containers:
      - name: api
        image: mi-api:1.4.2
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 30
        readinessProbe:
          httpGet:
            path: /ready
            port: 80

El camino natural: Docker → Compose → Kubernetes

No es un salto, es una progresión. Empecé con docker run, pasé a Compose para gestionar múltiples servicios, y cuando los requisitos de producción superaron lo que Compose podía manejar cómodamente, migramos a Kubernetes. Los conceptos son los mismos — imágenes, contenedores, redes, volúmenes — pero Kubernetes agrega la capa de orquestación inteligente que necesitás a escala.

El conocimiento de Docker no se descarta al llegar a Kubernetes: es el prerequisito. Todo pod de Kubernetes corre contenedores Docker. Los Dockerfiles que aprendiste a escribir son exactamente los mismos. La diferencia está en quién los gestiona y con qué nivel de sofisticación.

Mi setup actual

Hoy corro Kubernetes en mi cluster on-premise SUSE con dos nodos en HA. Docker sigue presente — lo uso en CI/CD para buildear imágenes y en desarrollo local. Compose lo uso para levantar entornos de desarrollo con múltiples servicios. Kubernetes gestiona producción. Cada herramienta en su lugar.

← Artículo anterior: Seguridad en Docker | Fin de la Serie Docker Completo

Esta fue la serie completa sobre Docker. Si llegaste hasta acá, tenés las bases para trabajar con contenedores en entornos reales. El siguiente paso natural es Kubernetes — cubriremos eso en una serie dedicada.

← Artículo anterior: Seguridad en Docker: errores que cometí y cómo los corregí | Fin de la Serie Docker Completo

Seguridad en Docker: errores que cometí y cómo los corregí

/0 Comentarios/en /por

Desplegué una imagen con credenciales hardcodeadas en el Dockerfile. Una vez. Cuando me di cuenta, la imagen estaba en el registry privado de la empresa y nadie más la había visto — pero el susto fue suficiente para que revisara la seguridad de todos mis contenedores ese mismo día.

Los errores de seguridad más comunes en Docker

La mayoría de los problemas de seguridad en Docker no son bugs exóticos: son malas prácticas que cometemos por desconocimiento o por apurarnos. Acá van los que yo cometí y cómo los corregí.

Error 1: Correr contenedores como root

# ❌ Por defecto, el proceso corre como root dentro del contenedor
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "server.js"]
# Si el proceso es comprometido, tiene privilegios de root dentro del contenedor

# ✅ Crear y usar un usuario no-root
FROM node:20-alpine
WORKDIR /app

# Crear usuario sin privilegios
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# Copiar archivos con el usuario correcto
COPY --chown=appuser:appgroup . .
RUN npm install --only=production

USER appuser
CMD ["node", "server.js"]

Error 2: Secretos en el Dockerfile o en variables de entorno planas

# ❌ NUNCA - el secreto queda grabado en una capa para siempre
ENV DB_PASSWORD=mipassword123
RUN curl -H "Authorization: Bearer TOKENREALAQUI" https://api.interna.com/config

# Aunque hagas otra capa que lo "borre", sigue en la historia de la imagen:
docker history mi-imagen  # el secreto es visible

# ✅ Para secrets en build-time, usar BuildKit secrets
# Esto NO deja rastro en las capas
# syntax=docker/dockerfile:1
FROM alpine
RUN --mount=type=secret,id=api_token     TOKEN=$(cat /run/secrets/api_token) &&     curl -H "Authorization: Bearer $TOKEN" https://api.interna.com/config

# Build:
docker build --secret id=api_token,src=./secrets/api_token .

# ✅ Para secrets en runtime, usar Docker secrets (Swarm) o variables de entorno
# via archivo .env que NUNCA va al repositorio
docker run --env-file .env.prod mi-imagen

Error 3: Imágenes base desactualizadas

# Escanear una imagen en busca de vulnerabilidades conocidas
docker scout cves mi-imagen:latest

# O con Trivy (más completo, lo que uso en CI)
docker run --rm   -v /var/run/docker.sock:/var/run/docker.sock   aquasec/trivy image mi-imagen:latest

# Resultado típico:
# 2026-03-11T10:00:00Z INFO Detected OS: alpine 3.18
# CRITICAL: 0, HIGH: 1, MEDIUM: 3, LOW: 8
# HIGH: libssl CVE-2024-XXXXX - update to 3.1.5-r0

Error 4: El .dockerignore inexistente

# Sin .dockerignore, COPY . . incluye todo — incluyendo:
# - .git/ (historial completo del repo)
# - .env (credenciales locales)
# - node_modules/ (pesado e innecesario)
# - tests/ (código de tests en la imagen de producción)

# .dockerignore completo que uso en todos mis proyectos:
.git
.gitignore
.env
.env.*
!.env.example
**/node_modules
**/bin
**/obj
**/*.log
**/.DS_Store
docker-compose*.yml
Dockerfile*
tests/
docs/
README.md
.github/

Dockerfile inseguro vs seguro: comparación completa

# ❌ Dockerfile inseguro
FROM node:latest                    # versión impredecible
ENV API_KEY=abc123supersecret       # secreto en capa
WORKDIR /app
COPY . .                            # sin .dockerignore, incluye .env y .git
RUN npm install                     # instala todo incluyendo devDependencies
EXPOSE 3000
CMD ["node", "server.js"]           # corre como root
# ✅ Dockerfile seguro
FROM node:20.11.0-alpine3.19        # versión fija y verificable

WORKDIR /app

# Usuario no-root
RUN addgroup -S app && adduser -S app -G app

# Dependencias primero (aprovecha cache, sin devDependencies)
COPY --chown=app:app package*.json ./
RUN npm ci --only=production && npm cache clean --force

# Código fuente (sin secretos - .dockerignore los excluye)
COPY --chown=app:app src/ ./src/

# Sin variables de entorno sensibles en la imagen
# Se pasan en runtime con --env-file

USER app
EXPOSE 3000

# Healthcheck
HEALTHCHECK --interval=30s --timeout=3s --retries=3   CMD wget -q -O /dev/null http://localhost:3000/health || exit 1

CMD ["node", "src/server.js"]

Limitar capacidades del contenedor

# Eliminar todas las capabilities de Linux y agregar solo las necesarias
docker run   --cap-drop=ALL   --cap-add=NET_BIND_SERVICE \   # solo si necesita bind a puerto < 1024
  --read-only \                   # sistema de archivos de solo lectura
  --tmpfs /tmp \                  # área de escritura temporal
  --security-opt=no-new-privileges   --user 1001:1001   mi-imagen:latest

El checklist que uso antes de cada deploy

  • ✅ ¿La imagen corre con usuario no-root?
  • ✅ ¿Hay .dockerignore con .env excluido?
  • ✅ ¿Los secretos van en runtime, no en la imagen?
  • ✅ ¿La imagen base tiene versión fija?
  • ✅ ¿Pasé Trivy o docker scout y no hay CVEs críticos?
  • ✅ ¿Los puertos expuestos son solo los necesarios?
  • ✅ ¿Hay healthcheck configurado?

← Artículo anterior: Microservicios con Docker | Serie Docker Completo | Próximo: Docker vs Kubernetes →

← Artículo anterior: Microservicios con Docker: lo que aprendí armando mi primera arquitectura | Serie Docker Completo | Próximo: Docker vs Kubernetes: cuándo me alcanza con uno y cuándo necesito el otro →

Microservicios con Docker: lo que aprendí armando mi primera arquitectura

/0 Comentarios/en /por

Arrancé con un monolito .NET en un solo contenedor. Funcionaba bien, hasta que el equipo creció y todos tocábamos el mismo código. Desplegar un cambio en la pantalla de login requería redeployar toda la aplicación. Fue entonces cuando empecé a explorar microservicios con Docker.

Monolito vs microservicios: cuándo tiene sentido el cambio

AspectoMonolito en DockerMicroservicios en Docker
Complejidad inicialBajaAlta
Deploy independienteNo — todo o nadaSí — servicio por servicio
Escalabilidad selectivaNoSí — escalar solo lo que lo necesita
Fallo aisladoUn bug afecta todoUn servicio caído no baja todo
Equipos independientesDifícilCada equipo dueño de su servicio
Overhead operacionalBajoAlto — más servicios que monitorear

Mi recomendación: empezá con el monolito. Cuando los puntos de dolor de la tabla de arriba se vuelvan reales en tu día a día, ahí es el momento de dividir.

Mi primera arquitectura de microservicios: auth + api + frontend

# docker-compose.yml — tres servicios independientes

version: '3.8'

services:
  # Servicio de autenticación (JWT, usuarios)
  auth-service:
    build: ./services/auth
    environment:
      - DB_CONNECTION=Host=postgres;Database=auth;Username=auth;Password=${AUTH_DB_PASS}
      - JWT_SECRET=${JWT_SECRET}
      - JWT_EXPIRY=1h
    depends_on:
      postgres:
        condition: service_healthy
    restart: unless-stopped
    # Sin puerto expuesto - solo accesible internamente

  # API principal de negocio
  api-service:
    build: ./services/api
    environment:
      - DB_CONNECTION=Host=postgres;Database=apidb;Username=api;Password=${API_DB_PASS}
      - AUTH_SERVICE_URL=http://auth-service:8080
      - CACHE_URL=redis:6379
    depends_on:
      - auth-service
      - redis
    restart: unless-stopped

  # Frontend React
  frontend:
    build: ./services/frontend
    environment:
      - REACT_APP_API_URL=http://api-service:8080
    restart: unless-stopped

  # Proxy - único punto de entrada externo
  nginx:
    image: nginx:1.25-alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx/microservices.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - frontend
      - api-service

  # Infraestructura compartida
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_MULTIPLE_DATABASES: auth,apidb  # extensión para múltiples DBs
      POSTGRES_PASSWORD: ${POSTGRES_ROOT_PASS}
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready"]
      interval: 10s
      retries: 5

  redis:
    image: redis:7-alpine
    volumes:
      - redis-data:/data

volumes:
  postgres-data:
  redis-data:

Comunicación entre servicios

Dentro de la red Docker, los servicios se llaman por nombre. La API valida tokens llamando al servicio de auth en cada request:

# En el código de api-service (.NET):
// Validar token contra auth-service
var authResponse = await _httpClient.GetAsync(
    $"{_authServiceUrl}/validate?token={token}"
);

// En el docker-compose, AUTH_SERVICE_URL = http://auth-service:8080
// Docker resuelve "auth-service" al contenedor correcto automáticamente

Deploy independiente: la ventaja real

# Actualizar solo el servicio de auth sin tocar nada más
docker compose up -d --build auth-service

# Escalar solo la API (recibe más carga)
docker compose up -d --scale api-service=3

# Rollback solo del frontend
docker compose stop frontend
docker compose rm -f frontend
TAG=anterior docker compose up -d frontend

Lo que aprendí en el proceso

La transición de monolito a microservicios no es solo técnica: es organizacional. Cada servicio necesita su propio repositorio (o al menos su propia carpeta), su propio pipeline de CI/CD y su propio dueño. La complejidad operacional sube. Por eso Docker Compose no es suficiente para microservicios en producción a escala — ese es el camino hacia Kubernetes, que vemos en el próximo artículo.

← Artículo anterior: Docker en CI/CD | Serie Docker Completo | Próximo: Seguridad en Docker →

← Artículo anterior: Docker en mi pipeline de CI/CD: builds reproducibles sin sorpresas | Serie Docker Completo | Próximo: Seguridad en Docker: errores que cometí y cómo los corregí →

Docker Compose: el día que dejé de levantar contenedores a mano

/0 Comentarios/en /por

Tenía un script Bash con 8 comandos docker run. Cada vez que alguien del equipo necesitaba levantar el entorno de desarrollo, le mandaba el script por Slack y rezaba para que no hubiera cambiado nada desde la última vez. Un día un compañero me mostró su docker-compose.yml. Nunca más volví al script.

¿Qué es Docker Compose?

Docker Compose es una herramienta para definir y ejecutar aplicaciones multi-contenedor usando un archivo YAML. En lugar de recordar 8 comandos docker run con todos sus flags, definís todos los servicios, redes y volúmenes en un solo archivo versionado. Un comando levanta todo; otro lo baja.

El docker-compose.yml completo: .NET + PostgreSQL + Redis + Nginx

Este es el stack que uso como base en mis proyectos. Cada servicio tiene su rol claro:

version: '3.8'

services:
  # Proxy inverso - único punto de entrada
  nginx:
    image: nginx:1.25-alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./nginx/certs:/etc/nginx/certs:ro
    depends_on:
      - api
    restart: unless-stopped

  # API .NET 8
  api:
    build:
      context: .
      dockerfile: Dockerfile
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
      - ConnectionStrings__Default=Host=postgres;Database=miapp;Username=app;Password=${DB_PASSWORD}
      - Redis__ConnectionString=redis:6379
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_started
    restart: unless-stopped
    # Sin -p: solo accesible internamente a través de nginx

  # Base de datos PostgreSQL
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: miapp
      POSTGRES_USER: app
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data
      - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql:ro
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d miapp"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

  # Cache Redis
  redis:
    image: redis:7-alpine
    command: redis-server --appendonly yes --requirepass ${REDIS_PASSWORD}
    volumes:
      - redis-data:/data
    restart: unless-stopped

volumes:
  postgres-data:
  redis-data:

networks:
  default:
    name: miapp-network

El archivo .env: secretos fuera del YAML

# .env (en .gitignore - nunca en el repo)
DB_PASSWORD=password-super-seguro-aqui
REDIS_PASSWORD=otro-password-seguro

Los comandos que uso todos los días

# Levantar todo en background
docker compose up -d

# Levantar y ver los logs mientras arranca
docker compose up

# Levantar solo un servicio (y sus dependencias)
docker compose up -d api

# Ver estado de los servicios
docker compose ps

# Logs de todos los servicios
docker compose logs -f

# Logs de un servicio específico
docker compose logs -f api

# Ejecutar comando en un servicio
docker compose exec api bash
docker compose exec postgres psql -U app -d miapp

# Bajar todo (mantiene volúmenes)
docker compose down

# Bajar y eliminar volúmenes (¡CUIDADO en producción!)
docker compose down -v

# Rebuild y restart de un servicio
docker compose up -d --build api

# Escalar un servicio (múltiples instancias)
docker compose up -d --scale api=3

Health checks: que Compose espere a que los servicios estén listos

Uno de los problemas clásicos: la API arranca antes que la base de datos y falla al conectar. La solución está en los healthcheck y depends_on con condición, como hice en el ejemplo de Postgres. Compose espera hasta que el healthcheck pase antes de arrancar los servicios dependientes.

# Verificar el healthcheck de un servicio
docker compose ps
# NAME              STATUS
# miapp-postgres-1  healthy   ← Postgres superó el healthcheck
# miapp-api-1       running   ← API arrancó después

El antes y el después

Mi script Bash antes:

# ❌ Lo que tenía antes (8 líneas que siempre tenía que recordar actualizar)
docker network create miapp
docker run -d --name postgres --network miapp -e POSTGRES_PASSWORD=... ...
docker run -d --name redis --network miapp ...
docker run -d --name api --network miapp -e DB_HOST=postgres ...
docker run -d --name nginx --network miapp -p 80:80 ...
# etc...

Ahora:

# ✅ Todo el stack en un comando
docker compose up -d

El archivo está en el repo. Cualquier miembro del equipo puede clonar y levantar el entorno completo en un comando. Sin documentación de «cómo levantar el entorno». Sin scripts que se desactualizan. El docker-compose.yml es la documentación.

← Artículo anterior: Redes en Docker | Serie Docker Completo | Próximo: Entornos consistentes →

← Artículo anterior: Redes en Docker: de ‘no puedo conectar mis contenedores’ a entenderlo de verdad | Serie Docker Completo | Próximo: Cómo uso Docker para tener el mismo entorno en dev, test y producción →

Redes en Docker: de ‘no puedo conectar mis contenedores’ a entenderlo de verdad

/0 Comentarios/en /por

Pasé casi tres horas intentando que un contenedor de frontend se comunicara con un contenedor de backend. Hacía curl http://localhost:3000 desde dentro del frontend y no llegaba nada. El problema no era el código: era que no entendía cómo funcionan las redes en Docker.

El modelo de red de Docker

Cada contenedor tiene su propia interfaz de red virtual y su propia dirección IP dentro de la red Docker. El localhost dentro de un contenedor es ese contenedor, no el host ni otro contenedor. Ese fue mi error: intentar llegar a otro contenedor como si fuera mi máquina.

Los tres drivers de red nativos

┌─────────────────────────────────────────────────────────────────┐
│  BRIDGE (default)                                               │
│                                                                 │
│  Host ──── docker0 ──── contenedor1 (172.17.0.2)               │
│                    └─── contenedor2 (172.17.0.3)               │
│                                                                 │
│  • Red virtual privada                                          │
│  • Contenedores aislados entre sí por defecto                  │
│  • Se exponen puertos explícitamente con -p                     │
├─────────────────────────────────────────────────────────────────┤
│  HOST                                                           │
│                                                                 │
│  Host ──── contenedor (comparte la red del host)               │
│                                                                 │
│  • Sin aislamiento de red                                       │
│  • Máximo rendimiento (sin NAT)                                 │
│  • Solo disponible en Linux                                     │
├─────────────────────────────────────────────────────────────────┤
│  NONE                                                           │
│                                                                 │
│  contenedor (sin red - solo loopback)                          │
│                                                                 │
│  • Aislamiento total                                            │
│  • Para procesos que no necesitan red                           │
└─────────────────────────────────────────────────────────────────┘

La solución: redes definidas por el usuario

La red bridge por defecto tiene una limitación importante: los contenedores no se pueden resolver por nombre, solo por IP. Las redes personalizadas solucionan esto con DNS automático. Esta es la forma correcta de conectar contenedores.

# Crear una red personalizada
docker network create mi-app-network

# Levantar backend
docker run -d   --name backend   --network mi-app-network   -e DB_HOST=postgres   mi-api:latest

# Levantar frontend - puede resolver "backend" por nombre
docker run -d   --name frontend   --network mi-app-network   -p 80:3000   -e API_URL=http://backend:8080   mi-frontend:latest

# Levantar base de datos en la misma red
docker run -d   --name postgres   --network mi-app-network   -v postgres-data:/var/lib/postgresql/data   -e POSTGRES_PASSWORD=secreto   postgres:16-alpine

# Ahora desde frontend podés hacer:
# curl http://backend:8080/api/health  ✅
# La base de datos NO está expuesta al exterior (sin -p)

Publicación de puertos: qué exponés y qué no

Un error común es publicar todos los puertos de todos los servicios. La buena práctica: solo el punto de entrada de tu aplicación (el frontend o la API pública) se expone al host. La base de datos, el cache, los servicios internos — solo accesibles dentro de la red Docker.

# ❌ Exponer todo - superficie de ataque innecesaria
docker run -p 5432:5432 postgres    # DB expuesta al mundo
docker run -p 6379:6379 redis       # Cache expuesta al mundo
docker run -p 8080:8080 mi-api      # API interna expuesta

# ✅ Solo exponer el punto de entrada
docker run -p 80:80 mi-nginx        # Solo el proxy/frontend al exterior
# El resto: en red interna, sin -p

Comandos de diagnóstico de red

# Ver redes existentes
docker network ls

# Inspeccionar una red (ver qué contenedores están conectados)
docker network inspect mi-app-network

# Conectar/desconectar un contenedor de una red en caliente
docker network connect mi-app-network contenedor-existente
docker network disconnect mi-app-network contenedor-existente

# Diagnóstico de conectividad desde dentro de un contenedor
docker exec -it frontend ping backend
docker exec -it frontend curl http://backend:8080/health
docker exec -it frontend nslookup backend  # resolución DNS

Lo que debería haber hecho desde el principio

La solución a mis tres horas de frustración era simple: crear una red personalizada y usar los nombres de contenedor como hostnames. Desde que lo entendí, la comunicación entre servicios es trivial. La clave mental: dentro de una red Docker personalizada, el nombre del contenedor es el hostname. http://backend:8080 funciona igual que http://192.168.1.100:8080, pero sin tener que saber IPs que cambian.

← Artículo anterior: Volúmenes y persistencia | Serie Docker Completo | Próximo: Docker Compose →

← Artículo anterior: Cuando perdí datos de producción por no usar volúmenes (y cómo no repetirlo) | Serie Docker Completo | Próximo: Docker Compose: el día que dejé de levantar contenedores a mano →

docker run y todo lo que nadie te explica del ciclo de vida de un contenedor

/0 Comentarios/en /por

Son las 3 de la mañana. Me llega una alerta: un contenedor en producción está en estado Exited (137). No arranca. No hay logs visibles. Y yo no entiendo qué pasó. Esa noche aprendí más sobre el ciclo de vida de un contenedor que en semanas de tutoriales.

Los estados de un contenedor Docker

Un contenedor no está simplemente «prendido o apagado». Tiene un ciclo de vida con varios estados bien definidos, y entenderlos es fundamental para diagnosticar problemas.

EstadoSignificadoCómo llegar
createdCreado pero nunca iniciadodocker create
runningEn ejecucióndocker start / docker run
pausedProcesos suspendidos (SIGSTOP)docker pause
restartingReiniciándose (restart policy activa)Fallo del proceso principal
exitedDetenido — con código de salidadocker stop o fallo
deadFallo en la eliminaciónError interno del daemon

Ese Exited (137) de las 3am significaba: el proceso fue terminado por una señal 9 (SIGKILL). En mi caso, el OOMKiller del kernel mató el contenedor porque superó el límite de memoria. El código de salida 137 = 128 + 9. Una vez que entendés la convención, el diagnóstico es inmediato.

docker run: el comando que más usás y menos conocés

El 80% de las veces empezamos con docker run nombre-imagen y nos conformamos con eso. Pero docker run tiene decenas de flags que cambian completamente el comportamiento del contenedor. Acá están los que realmente uso:

Flags de ejecución básicos

# -d: modo detached (background) - casi siempre lo quiero en producción
docker run -d nginx

# --name: nombre legible - SIEMPRE lo pongo
docker run -d --name mi-nginx nginx

# -p: mapeo de puertos host:contenedor
docker run -d --name mi-nginx -p 8080:80 nginx

# -e: variables de entorno
docker run -d --name mi-api   -e ASPNETCORE_ENVIRONMENT=Production   -e ConnectionStrings__Default="Server=db;Database=miapp"   mi-api:latest

# --env-file: variables desde archivo (no las expongo en bash history)
docker run -d --name mi-api --env-file .env.prod mi-api:latest

Políticas de reinicio: la diferencia entre prod y dev

# no (default): no reinicia nunca
docker run --restart=no mi-app

# always: siempre reinicia, incluso al reboot del host
# (úsalo para servicios críticos en producción)
docker run -d --restart=always --name mi-api mi-api:latest

# unless-stopped: como always, pero respeta docker stop manual
docker run -d --restart=unless-stopped --name mi-api mi-api:latest

# on-failure:N: reinicia solo si falla, máximo N veces
docker run -d --restart=on-failure:3 mi-worker:latest

Límites de recursos: lo que me hubiera evitado la alerta de las 3am

# Limitar memoria y CPU
docker run -d   --name mi-api   --memory="512m" \          # máximo 512MB de RAM
  --memory-swap="1g" \       # swap incluido
  --cpus="0.5" \             # máximo 50% de un CPU
  --restart=unless-stopped   mi-api:latest

# Ver uso de recursos en tiempo real
docker stats
docker stats mi-api           # solo ese contenedor

Los comandos de gestión que uso todos los días

# Listar contenedores
docker ps                    # en ejecución
docker ps -a                 # todos, incluso detenidos
docker ps -a --format "table {{.Names}}	{{.Status}}	{{.Ports}}"

# Logs - mi herramienta principal de diagnóstico
docker logs mi-api
docker logs -f mi-api        # follow (como tail -f)
docker logs --tail 100 mi-api
docker logs --since 1h mi-api   # última hora
docker logs --since "2026-03-11T03:00:00" mi-api

# Ejecutar comandos dentro del contenedor
docker exec mi-api ls /app
docker exec -it mi-api bash  # shell interactivo
docker exec -it mi-api sh    # para contenedores Alpine (sin bash)

# Copiar archivos entre host y contenedor
docker cp mi-api:/app/logs/error.log ./error.log
docker cp ./config.json mi-api:/app/config.json

Diagnosticar el problema de las 3am: mi checklist

Cuando me llega una alerta de contenedor caído, sigo siempre el mismo proceso:

# 1. Ver el estado y el código de salida
docker ps -a | grep mi-api
# CONTAINER ID   IMAGE       STATUS                      NAMES
# a1b2c3d4e5f6   mi-api     Exited (137) 2 minutes ago  mi-api

# 2. Ver los últimos logs ANTES de que muriera
docker logs --tail 50 mi-api

# 3. Inspeccionar el contenedor completo
docker inspect mi-api | python3 -m json.tool | grep -A5 "State"

# 4. Ver eventos del daemon
docker system events --since 1h --filter container=mi-api

# Códigos de salida comunes:
# 0   → salida normal (proceso terminó correctamente)
# 1   → error genérico de la aplicación
# 137 → SIGKILL (OOM Killer o docker kill)
# 143 → SIGTERM (docker stop - salida limpia)
# 126 → permisos insuficientes para ejecutar el comando
# 127 → comando no encontrado

Detener y eliminar contenedores correctamente

# Detener con gracia (envía SIGTERM, espera 10s, luego SIGKILL)
docker stop mi-api

# Detener más rápido (menos tiempo de espera)
docker stop --time=5 mi-api

# Forzar eliminación inmediata (SIGKILL directo - para emergencias)
docker kill mi-api

# Eliminar contenedor detenido
docker rm mi-api

# Detener Y eliminar en uno
docker rm -f mi-api

# Limpiar todos los contenedores detenidos
docker container prune

Lo que aprendí esa noche

El contenedor que falló a las 3am no tenía límites de memoria configurados, y el proceso .NET tenía una fuga de memoria. El OOMKiller del kernel lo mató antes de que pudiera afectar al nodo completo. En cierta forma, funcionó como debía. Desde entonces, todos mis contenedores de producción tienen --memory configurado y política --restart=unless-stopped. Una mala noche bien aprovechada.

← Artículo anterior: Cómo escribir Dockerfiles | Serie Docker Completo | Próximo: Volúmenes y persistencia →

← Artículo anterior: Mi guía para escribir Dockerfiles que no me den vergüenza | Serie Docker Completo | Próximo: Cuando perdí datos de producción por no usar volúmenes (y cómo no repetirlo) →

Por dentro del motor: entendiendo la arquitectura de Docker

/0 Comentarios/en /por

La primera vez que ejecuté docker run funcionó. Pero cuando algo falló, no tenía idea de dónde buscar. No entendía quién hacía qué, cómo se comunicaban las piezas ni por qué a veces el daemon parecía tener vida propia. Este artículo es lo que me hubiera gustado leer antes de ese momento.

Docker no es un solo programa: es un sistema de piezas

Uno de los errores conceptuales más comunes cuando arrancás con Docker es pensarlo como «el comando que corre contenedores». En realidad, Docker es una arquitectura cliente-servidor compuesta por varios componentes que trabajan juntos. Entenderlos hace que todo lo demás tenga sentido.

El flujo completo en un diagrama

┌─────────────────────────────────────────────────────────────┐
│                        TU TERMINAL                          │
│                                                             │
│   $ docker run nginx        ← Docker Client (CLI)          │
└──────────────────┬──────────────────────────────────────────┘
                   │  REST API (Unix socket o TCP)
                   ▼
┌─────────────────────────────────────────────────────────────┐
│                    DOCKER DAEMON (dockerd)                   │
│                                                             │
│   • Escucha comandos del cliente                            │
│   • Administra imágenes, contenedores, redes, volúmenes     │
│   • Delega la ejecución a containerd                        │
└──────────┬─────────────────────────┬────────────────────────┘
           │                         │
           ▼                         ▼
┌──────────────────┐      ┌──────────────────────────────────┐
│   containerd     │      │         Docker Registry           │
│                  │      │   (Docker Hub / privado)          │
│  • Gestiona      │      │                                   │
│    ciclo de vida │      │  • Almacena imágenes              │
│    del contenedor│      │  • docker pull baja de acá        │
│  • Usa runc para │      │  • docker push sube acá           │
│    crear procesos│      └──────────────────────────────────┘
└──────────────────┘

Docker Engine: el corazón del sistema

El Docker Engine es el conjunto completo: client + daemon + la API REST que los conecta. Cuando instalás Docker en un servidor, lo que instalás es el Engine. En mis nodos SUSE Linux, el daemon corre como servicio systemd y arranca automáticamente con el sistema.

# Ver estado del daemon
sudo systemctl status docker

# Ver logs del daemon en tiempo real
sudo journalctl -u docker -f

# Información completa del sistema Docker
docker info

Docker Client: lo que escribís en la terminal

El cliente es simplemente la CLI: el binario docker que usás en la terminal. Su único trabajo es traducir tus comandos a llamadas a la API REST del daemon. Lo que importa saber: el cliente y el daemon pueden estar en máquinas diferentes. Puedo controlar el daemon de un servidor remoto desde mi notebook sin ningún problema.

# Conectar el cliente a un daemon remoto
export DOCKER_HOST=tcp://192.168.1.100:2376
docker ps  # Lista contenedores del servidor remoto

# O con contextos (la forma moderna)
docker context create servidor-prod --docker "host=ssh://mbernal@192.168.1.100"
docker context use servidor-prod
docker ps  # Ahora habla con el servidor remoto

Docker Daemon (dockerd): quien realmente hace el trabajo

El daemon es el proceso que corre en background y gestiona todo: imágenes, contenedores, redes y volúmenes. Cuando ejecutás docker run nginx, es el daemon quien:

  1. Recibe el comando del cliente
  2. Verifica si la imagen nginx existe localmente
  3. Si no existe, la descarga del registry
  4. Crea el contenedor usando containerd y runc
  5. Configura la red y el sistema de archivos
  6. Arranca el proceso principal del contenedor

Imágenes Docker: plantillas inmutables

Una imagen es una plantilla de solo lectura que define el sistema de archivos y la configuración inicial de un contenedor. Está compuesta por capas (layers), donde cada instrucción del Dockerfile agrega una capa nueva. Esta arquitectura por capas es brillante: si dos imágenes comparten las mismas capas base, se almacenan una sola vez en disco.

# Ver imágenes locales
docker images

# Ver las capas de una imagen
docker history nginx:latest

# Inspeccionar metadatos completos
docker inspect nginx:latest

Contenedores: instancias en ejecución de una imagen

Un contenedor es una imagen en ejecución. La diferencia clave: la imagen es inmutable (solo lectura), mientras que el contenedor agrega una capa de escritura encima donde los procesos pueden crear y modificar archivos. Cuando el contenedor se destruye, esa capa desaparece. Por eso los datos importantes van en volúmenes — pero eso lo vemos en otro artículo.

# Relación imagen → contenedor
docker images ls          # ver imágenes (plantillas)
docker ps -a              # ver contenedores (instancias)

# Crear contenedor sin arrancarlo
docker create --name mi-nginx nginx

# Arrancarlo
docker start mi-nginx

# O directamente: crear + arrancar
docker run -d --name mi-nginx -p 80:80 nginx

Docker Registry: el repositorio de imágenes

El registry es donde viven las imágenes. Docker Hub es el registry público por defecto, pero en producción muchas empresas usan registries privados. En mi entorno on-premise uso un registry privado para no depender de internet en los deploys.

# Levantar un registry privado local
docker run -d -p 5000:5000 --name registry-privado   -v /data/registry:/var/lib/registry   registry:2

# Tagear imagen para el registry privado
docker tag mi-api:latest localhost:5000/mi-api:latest

# Subir al registry privado
docker push localhost:5000/mi-api:latest

# Bajar desde el registry privado
docker pull localhost:5000/mi-api:latest

Docker Compose: orquestación local

Docker Compose es la herramienta para definir y ejecutar aplicaciones multi-contenedor. En lugar de ejecutar múltiples docker run, definís todos los servicios en un archivo YAML y los gestionás con un solo comando. Lo veremos en profundidad más adelante — te adelanto que cambia completamente la forma de trabajar.

El flujo completo: qué pasa cuando ejecutás docker pull nginx

# Esto es lo que pasa internamente:
$ docker pull nginx

# 1. Docker Client envía petición al daemon via /var/run/docker.sock
# 2. Daemon consulta: ¿tengo nginx:latest localmente?
# 3. Si no → contacta Docker Hub (registry.hub.docker.com)
# 4. Autentica (si la imagen es privada)
# 5. Descarga cada capa (layer) que no tenga en cache
# 6. Verifica integridad con el digest SHA256
# 7. Almacena las capas en /var/lib/docker/overlay2/

Using default tag: latest
latest: Pulling from library/nginx
a803e7c4b030: Pull complete   ← cada línea es una capa
8b625c47d697: Pull complete
4d3239651a63: Pull complete
Digest: sha256:bc5eac5eafc581aeda3008b4b1f07ebba230de2f27d47767129a6a905c84f470
Status: Downloaded newer image for nginx:latest

Por qué me importa entender esto

El día que tuve un contenedor que no arrancaba y no sabía por dónde empezar a debuggear, entender la arquitectura me salvó. Saber que el daemon escribe en /var/lib/docker/, que los logs del daemon están en journalctl, que el socket Unix es /var/run/docker.sock — esos detalles marcan la diferencia entre resolver el problema en 5 minutos o perder una hora.

# Cuando algo falla, estos son mis primeros comandos:
sudo journalctl -u docker --since "1 hour ago"
docker info
docker system df          # ver uso de disco
docker system events      # stream de eventos del daemon

← Artículo anterior: Cómo Docker cambió la forma en que trabajo | Serie Docker Completo | Próximo: Mi guía para escribir Dockerfiles →

← Artículo anterior: Cómo Docker cambió la forma en que trabajo (y por qué tardé en entenderlo) | Serie Docker Completo | Próximo: Mi guía para escribir Dockerfiles que no me den vergüenza →

Cómo Docker cambió la forma en que trabajo (y por qué tardé en entenderlo)

/0 Comentarios/en /por

Durante años trabajé con máquinas virtuales y pensé que era suficiente. Cada nuevo proyecto significaba clonar una VM, esperar que levantara, rezar para que las dependencias fueran las correctas y luego descubrir, inevitablemente, que algo fallaba en producción que no fallaba en mi máquina. Docker cambió todo eso. Pero no fue amor a primera vista.

El problema que todos tenemos (y nadie quiere admitir)

Me acuerdo exactamente del momento. Eran las 11 de la noche, estábamos por hacer un deploy de una API .NET y el servidor de producción se negaba a arrancar la aplicación. El error era críptico: una biblioteca de dependencias con versión diferente a la que teníamos en desarrollo. Tres horas después, con el equipo exhausto, logramos resolver el problema manualmente. Al día siguiente alguien preguntó: «¿y si usamos Docker?»

En ese momento yo tenía mis reservas. «¿Para qué complicar las cosas si las VMs ya funcionan?», pensé. Tardé un tiempo en entender que no se trataba de complicar, sino exactamente de lo contrario.

¿Qué es Docker, realmente?

Docker es una plataforma de código abierto que permite empaquetar una aplicación junto con todas sus dependencias —bibliotecas, runtime, herramientas del sistema, configuración— en una unidad estandarizada llamada contenedor. Ese contenedor se puede ejecutar de forma idéntica en cualquier entorno que tenga Docker instalado: tu notebook, el servidor de staging, producción en cloud o un cluster on-premise como el que manejo yo en SUSE Linux HA.

La definición técnica es elegante: Docker comparte el kernel del sistema operativo anfitrión en lugar de virtualizar hardware completo. Eso lo hace liviano, rápido y eficiente. Pero lo que me convenció no fue la definición técnica sino lo que significa en la práctica: el contenedor que probé en mi máquina es exactamente el mismo que se ejecuta en producción. Sin sorpresas.

# Así de simple es levantar un servidor nginx con Docker
docker run -d -p 8080:80 --name mi-web nginx

# En segundos tenés un servidor web corriendo
# Sin instalar nginx, sin configurar nada en el sistema

Un poco de historia: Docker no inventó los contenedores

Algo que me resultó fascinante cuando profundicé en el tema es que la idea de contenedores no nació con Docker. La tecnología de aislamiento de procesos tiene décadas:

  • 1979 — chroot: El abuelo de todo. Permitía cambiar el directorio raíz de un proceso, aislándolo del sistema de archivos principal. Unix V7.
  • 2000 — FreeBSD Jails: Llevó el concepto más lejos: aislamiento de procesos, usuarios y red.
  • 2008 — Linux Containers (LXC): El kernel de Linux incorporó cgroups (para limitar uso de recursos) y namespaces (para aislar procesos, red, sistema de archivos). Esta es la base técnica sobre la que se construyó Docker.
  • 2013 — Docker: Solomon Hykes, trabajando en dotCloud (una empresa PaaS francesa), tomó toda esa tecnología del kernel y la envolvió en una herramienta con una CLI amigable y un ecosistema de distribución de imágenes. Presentado en PyCon 2013, liberado como open source ese mismo año.

La genialidad de Docker no fue inventar algo nuevo sino hacer accesible lo que ya existía. Y eso, en tecnología, suele ser la innovación más poderosa.

Por qué Docker importa: los 5 beneficios que cambiaron mi forma de trabajar

1. Consistencia entre entornos

Este es el grande. El que me hizo pasar de escéptico a evangelista. Con Docker, la frase «funciona en mi máquina» pierde sentido. Si el contenedor corre en dev, corre en prod. La imagen es la misma. Las dependencias son las mismas. El runtime es el mismo.

# Si esto funciona en tu máquina...
docker run --rm -v $(pwd):/app -w /app node:20 node app.js

# ...esto funcionará igual en el servidor de producción
docker run --rm -v /apps/miapp:/app -w /app node:20 node app.js

2. Arranque en segundos (no en minutos)

Venía de un mundo donde levantar una VM significaba esperar 2 o 3 minutos mínimo. Con Docker, un contenedor arranca en segundos o incluso milisegundos. Eso transforma completamente el flujo de trabajo: podés destruir y recrear entornos constantemente sin perder el hilo.

# Levantar PostgreSQL 16 completo en segundos:
docker run -d   --name postgres-dev   -e POSTGRES_PASSWORD=mipassword   -e POSTGRES_DB=miapp   -p 5432:5432   postgres:16-alpine

# Listo. Base de datos funcionando sin instalar nada en el sistema.

3. Eficiencia de recursos

En mi cluster on-premise de dos nodos SUSE Linux, cada recurso cuenta. Antes, cada servicio necesitaba su propia VM con un SO completo. Hoy tengo decenas de contenedores corriendo en los mismos nodos que antes apenas soportaban cinco VMs. Los contenedores comparten el kernel del host: no replican el sistema operativo, solo empaquetan lo que la aplicación necesita.

4. Portabilidad real

Construís la imagen una vez y la ejecutás en cualquier lado: tu notebook con WSL2, un servidor Ubuntu on-premise, AWS EC2, Azure Container Instances, Google Cloud Run. La misma imagen. Sin recompilar, sin reconfigurar. Esta portabilidad es lo que después abre la puerta a Kubernetes, que orquesta esos contenedores a escala.

5. Aislamiento y seguridad

Cada contenedor vive en su propio mundo: sus procesos, su sistema de archivos, su red. Si un contenedor tiene un problema, los demás no se enteran. Puedo tener dos versiones de Python corriendo en paralelo sin conflictos. Puedo experimentar con una nueva versión de una librería sin tocar el sistema. Para un entorno de producción, eso es tranquilidad.

Docker vs. Máquinas Virtuales: la comparación que aclara todo

Cuando empecé con Docker, la pregunta que más me hacían era: «¿y entonces las VMs mueren?». La respuesta corta es no. La respuesta larga es más interesante.

CaracterísticaDocker (Contenedor)Máquina Virtual
AbstracciónNivel de SONivel de hardware
KernelComparte el kernel del hostKernel propio por VM
Tiempo de arranqueSegundos / milisegundosMinutos
Tamaño de imagenMBsGBs
Consumo de recursosMuy bajoAlto (OS completo por VM)
Densidad en el hostAlta (decenas/cientos)Baja (pocas VMs)
AislamientoA nivel de procesoAislamiento completo de SO
PortabilidadMuy altaMedia (imágenes pesadas)

¿Cuándo uso Docker?

  • Microservicios y APIs independientes
  • Entornos de desarrollo locales (base de datos, cache, message broker)
  • Pipelines de CI/CD donde necesito reproducibilidad
  • Cuando necesito escalar rápido y aprovechar recursos
  • Como base para orquestar con Kubernetes

¿Cuándo sigo usando VMs?

  • Cuando necesito aislar completamente a nivel de SO (seguridad máxima)
  • Aplicaciones legacy que dependen de un SO específico
  • Cuando el equipo no está listo para el cambio (la convivencia es válida)
  • Workloads que requieren acceso directo a hardware específico

En muchos de mis entornos actuales uso ambos: contenedores Docker corriendo dentro de VMs. Así combino el aislamiento fuerte de las VMs con la eficiencia y portabilidad de los contenedores.

Un ejemplo real: de «funciona en mi máquina» a «funciona en todos lados»

Hace poco tuve que desplegar una aplicación .NET 8 que en desarrollo corría perfecto y en producción fallaba por diferencias en las librerías del sistema. Con Docker, la solución fue crear una imagen que empaquetara exactamente el runtime y las dependencias necesarias:

# Dockerfile simple para una API .NET 8
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["MiApi.csproj", "."]
RUN dotnet restore
COPY . .
RUN dotnet build -c Release -o /app/build

FROM build AS publish
RUN dotnet publish -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MiApi.dll"]

Desde ese día, el deploy es siempre el mismo comando:

docker build -t miapi:latest .
docker run -d -p 80:80 --name miapi miapi:latest

Sin sorpresas. Sin diferencias entre entornos. Sin las 11 de la noche arreglando dependencias.

Conclusión: vale la curva de aprendizaje

Si estás evaluando si meterte con Docker, mi respuesta es sí, sin dudar. La curva de aprendizaje existe, pero no es empinada. En pocos días podés tener tus primeros contenedores funcionando. Y una vez que lo incorporás a tu flujo de trabajo, no entendés cómo trabajabas sin él.

En los próximos artículos de esta serie voy a ir a fondo con la arquitectura interna de Docker, los Dockerfiles, la gestión de redes, volúmenes y finalmente Docker Compose —el salto que te lleva de un contenedor a un entorno completo con múltiples servicios coordinados.

Si tenés preguntas o querés compartir tu propia experiencia con Docker (o con las VMs que todavía no pudiste abandonar), dejá tu comentario abajo. 👇

Este artículo forma parte de la serie Docker Completo, donde recorro desde los conceptos básicos hasta casos de uso avanzados en entornos on-premise y cloud.

Serie Docker Completo | Próximo: Por dentro del motor: entendiendo la arquitectura de Docker →