docker-compose.yml

services:
  backend:
    build:
      context: ./backend
      args:
        # torch/faiss/transformers (varios cientos de MB): necesarios para
        # que la geolocalización por imagen funcione DE VERDAD en este
        # contenedor (no solo para poder construir el índice, que puedes
        # hacer aparte con tu propio venv). Ponlo en "false" si prefieres
        # una imagen más ligera y no usas esta función.
        - WITH_GEOLOCATION=true
    container_name: backend
    image: ghcr.io/nacho50900/amitraceable-backend:latest
    ports:
      - "3000:3000"
    env_file:
      - ./backend/.env
    volumes:
      # El índice FAISS de geolocalización (backend/data/osv5m_spain/) no
      # se copia dentro de la imagen (pesa demasiado y se regenera con
      # scripts/build_faiss_index.py, ver .gitignore) -- se monta en vez de
      # eso, para que el contenedor vea el mismo índice que ya tengas
      # construido en tu disco. Sin este volumen, el backend informará
      # "índice no construido" aunque exista de verdad en tu máquina.
      - ./backend/data:/app/data
      # Caché de HuggingFace (pesos del modelo DINOv2, ~90MB): sin este
      # volumen, se re-descarga en CADA reinicio del contenedor (el
      # filesystem del contenedor es efímero) -- con él, solo la primera
      # vez. Se precarga en el arranque igualmente (ver _lifespan en
      # app/main.py), así que el ahorro real es solo en la descarga, no en
      # la carga en memoria (esa sigue pasando en cada arranque).
      - ./backend/data/hf_cache:/root/.cache/huggingface
    networks:
      - monitor-net
    # GPU dedicada (NVIDIA, vía Docker Desktop + WSL2 en Windows -- no hace
    # falta instalar nvidia-container-toolkit aparte, Docker Desktop lo trae
    # integrado en su backend WSL2; solo hace falta tener actualizado el
    # driver NVIDIA de Windows con soporte WSL2 y "GPU support" activo en
    # Docker Desktop, Settings > Resources). Sin este bloque, aunque
    # requirements-vision.txt instale el build CUDA de torch, el contenedor
    # no ve la GPU y `torch.cuda.is_available()` da False en silencio (cae
    # a CPU sin avisar) -- ver el comentario largo en
    # app/vision/scene_analysis.py sobre el presupuesto de VRAM ajustado
    # (4GB) antes de asumir que esto por sí solo arregla el problema.
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

  webapp:
    build:
      context: ./webapp
      args:
        # Vacío: la imagen trae su propio nginx.conf que hace de proxy
        # hacia "backend" bajo el mismo origen (ver webapp/nginx.conf), así
        # que el frontend llama a la API con rutas relativas. Esto es lo
        # que permite que un túnel de Cloudflare apuntando SOLO a este
        # servicio (puerto 8080 en el host) sirva también, transparentemente,
        # todo lo de auth/instagram y auth/reddit.
        - VITE_API_URL=
    container_name: webapp
    image: ghcr.io/nacho50900/amitraceable-webapp:latest
    ports:
      - "8080:80"
    depends_on:
      - backend
    networks:
      - monitor-net

  dinov2-igpu-worker:
    build:
      context: ./backend/igpu_worker
    container_name: dinov2-igpu-worker
    # profiles: igual mecanismo que prometheus/grafana más abajo -- NUNCA
    # arranca con un `docker compose up` a secas, solo con
    # `docker compose --profile igpu up`. Motivo distinto al de
    # monitoring: este servicio necesita torch-directml, que solo tiene
    # sentido en una máquina con iGPU (Intel/AMD) ADEMÁS de la GPU NVIDIA
    # dedicada (ver ENABLE_IGPU_OFFLOAD en backend/.env) -- en cualquier
    # otra máquina ni siquiera debería construirse la imagen. Ver el
    # docstring de backend/igpu_worker/app.py para el motivo completo por
    # el que esto vive en un proceso/imagen aparte del backend.
    profiles:
      - igpu
    # Sin bloque `ports:` a propósito -- ver más abajo.
    #
    # SonarCloud marca `igpu_worker_url = "http://..."` en
    # app/config.py como hotspot de seguridad ("usa HTTPS en vez de
    # HTTP"). No se ha añadido TLS aquí porque el tráfico backend <->
    # worker NUNCA sale de la red interna de Docker Compose
    # (`monitor-net`, ambos servicios la comparten, ver `networks:` de
    # `backend` más arriba) -- ni pasa por el host ni por ninguna red
    # externa, así que TLS no protegería contra ninguna amenaza real
    # aquí y sí añadiría gestión de certificados a un servicio interno
    # y opt-in.
    #
    # Lo que SÍ se ha corregido es la superficie de exposición real: sin
    # `ports:`, el puerto 8001 NO se publica en el host (a diferencia de
    # backend/webapp) -- nada fuera de `monitor-net` puede alcanzarlo,
    # ni siquiera desde la propia máquina Windows. Si necesitas
    # depurarlo a mano (`curl http://localhost:8001/devices` desde
    # Windows/WSL2), publica el puerto solo temporalmente:
    #   docker compose --profile igpu run --rm -p 8001:8001 dinov2-igpu-worker
    # en vez de dejarlo publicado de forma permanente en este fichero.
    # Paso de la iGPU al contenedor vía DirectML sobre WSL2: /dev/dxg es
    # el dispositivo de paravirtualización de GPU que expone WSL2 (TODAS
    # las GPUs visibles desde Windows, dedicada Y integrada -- a
    # diferencia del bloque `deploy.resources` del backend, que es
    # específico de NVIDIA vía nvidia-container-toolkit y solo expone la
    # dedicada). Sin este device y sin las librerías de usuario de
    # /usr/lib/wsl, torch_directml.device_count() devuelve 0 dentro del
    # contenedor aunque Windows sí vea la iGPU.
    #
    # NOTA (Vicen): esto no está verificado todavía en una máquina real
    # con Docker Desktop -- si GET /devices devuelve una lista vacía una
    # vez arrancado el contenedor, empieza por comprobar que /dev/dxg
    # existe en el host WSL2 (`ls -la /dev/dxg` dentro de la distro WSL,
    # no en PowerShell) y que "GPU support" está activo en Docker
    # Desktop > Settings > Resources.
    devices:
      - /dev/dxg:/dev/dxg
    volumes:
      - /usr/lib/wsl:/usr/lib/wsl
    environment:
      - LD_LIBRARY_PATH=/usr/lib/wsl/lib
    networks:
      - monitor-net

  prometheus:
    image: prom/prometheus
    container_name: prometheus
    # profiles: solo arranca con `docker compose --profile monitoring up`,
    # NO con `docker compose up` a secas -- ver comentario junto a
    # `grafana` más abajo para el motivo.
    profiles:
      - monitoring
    ports:
      - "9090:9090"
    volumes:
      - ./backend/monitoring/prometheus:/etc/prometheus
    networks:
      - monitor-net

  grafana:
    image: grafana/grafana
    container_name: grafana
    # profiles: Grafana y Prometheus meten bastante ruido en los logs de
    # `docker compose up` (mensajes de arranque, migraciones de BD,
    # reintentos de "No last resource version found" cada 30s...) que no
    # aporta nada cuando lo que se está depurando es el backend -- con
    # "profiles" (mecanismo nativo de Docker Compose, no una variable de
    # entorno casera) estos dos servicios quedan FUERA por defecto.
    #   docker compose up                       -> solo backend + webapp
    #   docker compose --profile monitoring up   -> los cuatro servicios
    # Los dashboards de Grafana siguen estando disponibles siempre que se
    # necesiten, solo que no arrancan solos en cada `docker compose up`.
    profiles:
      - monitoring
    ports:
      - "9091:3000"
    volumes:
      - ./backend/monitoring/grafana/provisioning:/etc/grafana/provisioning
    networks:
      - monitor-net

networks:
  monitor-net:
    driver: bridge