Inicio / Documentación / docs/DOCKER_RESOURCES.md

🐳 Análisis de Recursos Docker (Total vs. Actual)#

☢️ Comando de Liberación Total (Un solo paso)#

Si deseas borrar todo rastro (imágenes base, volúmenes, contenedores y caché) y recuperar ~10GB de espacio:

make nuke

(O directamente: docker system prune -a -f --volumes)

Este documento detalla el consumo de recursos (Disco y RAM) del proyecto Social Bot Scheduler. Se ha ajustado para reflejar la diferencia entre el estado actual de tu entorno y el potencial total del repositorio para que reclutadores y novatos tomen decisiones informadas.

🏁 Estado del Entorno Docker#

Advertencia

Tu entorno actual puede estar "incompleto" si solo has descargado algunos servicios. Para ejecutar el laboratorio completo, debes considerar el Tamaño Real Total.

🧹 Gestión de Recursos y Limpieza#

Dada la alta demanda técnica de este repositorio (múltiples bases de datos simultáneas), es vital saber cómo liberar recursos:

• Consulta el Reporte de Recursos Docker para ver el uso real de imágenes, volúmenes y caché de build.
• Usa make clean o python hub.py clean para una limpieza estándar.
• Usa docker system prune -a -f --volumes para una limpieza total (Deep Cleanup).

Este documento detalla el consumo de recursos (Disco y RAM) del proyecto Social Bot Scheduler. Se ha ajustado para reflejar la diferencia entre el estado actual de tu entorno y el potencial total del repositorio para que reclutadores y novatos tomen decisiones informadas.

🏁 Estado del Entorno Docker#

Advertencia

Tu entorno actual puede estar "incompleto" si solo has descargado algunos servicios. Para ejecutar el laboratorio completo, debes considerar el Tamaño Real Total.

🏗️ Desglose Exhaustivo de Almacenamiento (Potential)#

Si decides hacer un docker-compose --profile full pull, este es el impacto en disco:

🖼️ Imágenes (Total: ~6.8 GB)#

💾 Volúmenes y Persistencia (Total: ~1.2 GB)#

• Caché de Construcción: ~500 MB (Capas intermedias de Dockerfiles personalizados).
• Datos de DBs: ~550 MB (Espacio reservado para persistencia de los motores externos del núcleo y DuckDB embebida).
• Configuración: ~200 MB (Logs, n8n workflows, grafana dashboards).

📊 Consumo de RAM por Caso (Activación Selectiva)#

Consejo

Cada caso se levanta con docker-compose --profile caseXX up -d. Las cifras incluyen el núcleo siempre activo (n8n 1 GB + master-dashboard 128 MB ≈ 1.13 GB). Si ya tienes el núcleo arriba, súmale solo la columna Δ Caso.

Nota

19 de 20 casos implementados (Lotes 1–4, v4.5.0–v4.8.0); sólo resta el 19. El 11 no añade contenedor de BD (Mnesia vive en el runtime BEAM); 13 (Kafka), 18 (Neo4j) y 20 (emulador Firestore) son los más pesados. Los límites deploy.resources son valores del docker-compose.yml.

Importante

Casos 07 y 08 son los únicos "pesados" del laboratorio: cada uno consume ~3.25 GB por culpa de Cassandra/SQL Server. Si tu máquina tiene <8 GB de RAM disponibles, evita ejecutarlos en paralelo con otros casos.

🎯 Combinaciones recomendadas según RAM disponible#

🚧 Estimación para el único caso planificado (19)#

Advertencia

Cifra estimada, sin medición real (el caso 19 aún no está verificado end-to-end). Ver PLANNED_CASES.md.

Implementar el caso 19 restante requeriría ~2.65 GB de RAM adicionales sobre el --profile full actual.

➕ Componentes opcionales#

Nota

El caso planificado 19 no se contabiliza aquí (no tiene perfil aún). Estimación bruta si se implementara: +2.65 GB adicionales por la incorporación de XTDB (F#/Clojure).

🚦 Decisión de Implementación: ¿Todo o Caso a Caso?#

Para usuarios con recursos limitados, recomendamos la Activación por Perfiles (profiles):

1. Novato (Ligero): docker-compose --profile case01 up -d
   • Consumo: ~1.2 GB Disco / 1.5 GB RAM Total.
   • Si solo quieres el core del laboratorio, make up-secure deja fuera observabilidad y casos pesados.
2. Reclutador (Estándar): Casos 01 al 06.
   • Consumo: ~4.0 GB Disco / 8 GB RAM.
3. Senior (Full Lab): Todos los casos + Infraestructura.
   • Consumo: ~8.0 GB Disco / 16 GB RAM.
4. Edge Controlado: make up-edge además del modo base.
   • Consumo: añade ~50-100 MB de RAM para Caddy y no sustituye el hardening de producción.

🏁 Reporte de Prueba de Estrés (Stress Test - Feb 2026)#

Se realizó una ejecución del stack completo (--profile full) en el hardware actual, resultando en los siguientes hallazgos críticos:

Importante

Conclusión: El hardware actual es ideal para el Perfil Óptimo (Casos 01-06). Para el Perfil Experto (Todo el repo), se recomienda una máquina con al menos 16-24 GB de RAM (ej: Mac Mini con Silicon) para evitar la caída de servicios pesados como Cassandra.

🧹 Limpieza y Liberación de Recursos#

Antes de apagar el sistema o migrar de máquina, es fundamental limpiar los recursos para devolver el disco y la memoria al sistema operativo.

Opción 1: Vía Makefile (Recomendado)#

make clean

Opción 2: Vía HUB CLI#

python hub.py clean

Opción 3: Limpieza Total (Deep Cleanup)#

Si deseas liberar todo el espacio (incluyendo imágenes base como MSSQL, Cassandra y PHP) para que la máquina quede como si nunca hubiera ejecutado el repo:

# ADVERTENCIA: Esto borrará todas las imágenes no usadas por otros contenedores activos
docker system prune -a -f --volumes

¿Qué hace este proceso?#

1. Detiene y elimina todos los contenedores del proyecto.
2. Elimina los volúmenes (borrando todos los datos de las bases de datos).
3. Limpia imágenes huérfanas y redes temporales.
4. Prune -a: Elimina imágenes base, liberando hasta 10GB+ de espacio.