Gabriel Gómez Gómez · 20 de septiembre, 2025

Docker: encender todos los contenedores (cuándo y cómo usarlo)

A veces necesitas reactivar RÁPIDO todos tus contenedores tras un reinicio del servidor o al retomar un entorno local. Aquí verás cómo hacerlo con Docker “puro” y con Docker Compose, cuándo es útil y qué precauciones tomar.
1) Encender todos los contenedores con Docker CLI:
terminalBASH
```
docker start $(docker ps -a -q)
```
Explicación breve:
• docker ps -a -q → lista todos los contenedores (encendidos y apagados) y devuelve solo sus IDs.
• docker start → inicia los contenedores cuyos IDs le pases.
Resultado: enciende también los que estaban detenidos.
2) Variantes útiles (seguras y filtradas):

# Solo los detenidos (evita tocar los que ya están arriba)
docker start $(docker ps -q -f status=exited)

# Evitar error si no hay resultados (GNU xargs)
docker ps -aq | xargs -r docker start

# Detener todos (por si necesitas un reset controlado)
docker stop $(docker ps -q)

3) Con Docker Compose (recomendado cuando tu proyecto tiene servicios definidos):

# Docker Compose v2 (comando moderno)
docker compose up -d

# (Compat) Algunos entornos aún usan:
# docker-compose up -d

Esto levantará todos los servicios definidos en tu docker-compose.yml, construyendo imágenes si faltan y respetando dependencias declaradas (depends_on).
4) ¿Cuándo es ÚTIL encenderlos todos?
• Reinicio del servidor: quieres volver a poner en línea todo tu stack (DB, backend, frontend, workers) sin recordar cada nombre.
• Entorno local de desarrollo: ayer apagaste todo; hoy retomas y subes todo de un jalón.
• Hosts multi-proyecto: varios contenedores de herramientas (pgAdmin, Redis, Portainer, etc.) y deseas reactivarlos rápido.
• Tareas de mantenimiento: tras actualizar Docker/Kernel, reinicias servicios y verificas salud.
5) ¿Cuándo NO conviene o hay que tener cuidado?
• Orden de arranque: bases de datos deben estar listas antes del backend; docker start no sabe dependencias. Usa docker compose para orquestar.
• Conflictos de puertos: al encender todo puedes chocar con puertos ocupados.
• Recursos limitados: levantar todo consume RAM/CPU. Quizá solo necesites 2–3 servicios.
• Estados sensibles: en colas/streams, workers encendidos “a la fuerza” podrían reprocesar o causar eventos inesperados.
6) Buenas prácticas para producción:
• restart policy: configura restart: unless-stopped (Compose) o --restart unless-stopped (CLI) para que los contenedores arranquen con el daemon tras reboot.
• Supervisión: usa healthchecks (healthcheck: en Compose) y un orquestador/monitor (Portainer/Watchtower/Prometheus) para detectar fallas.
• Menos privilegios: evita correr como root dentro del contenedor si no es necesario.
• Logs/volúmenes: rota logs y persiste datos en volúmenes, no en el sistema de archivos del contenedor.
7) Ejemplo minimal de Compose con políticas de reinicio y dependencia:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
    volumes:
      - dbdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s
      timeout: 3s
      retries: 10
    restart: unless-stopped

  backend:
    build: ./backend
    depends_on:
      db:
        condition: service_healthy
    environment:
      DATABASE_URL: postgresql://app:secret@db:5432/app
    ports:
      - "8000:8000"
    restart: unless-stopped

volumes:
  dbdata:

8) Resumen rápido:
• Comando rápido: docker start $(docker ps -a -q) para encender todo.
• Mejor con Compose si hay dependencias: docker compose up -d.
• Filtra/evita sorpresas usando -f status=exited, healthchecks y restart policies.
• Piensa en orden, puertos y recursos antes de encender todo a la vez.