# Docker

## Stack containerizzato

Il `docker-compose.yml` root avvia l'intero workspace applicativo.

Servizi definiti:

- `portal`
- `backend-hub`
- `prenotazioni-db`
- `prenotazioni-backend`
- `prenotazioni-frontend`
- `menu-legacy`
- `ordini-db`
- `ordini-backend`
- `ordini-frontend`

Ruolo pratico dei servizi:

- `portal` -> build Vite e pubblicazione Nginx dell'hub UI
- `backend-hub` -> API FastAPI centrale, registry tenant, Home assistant, Google Workspace, menu settings
- `prenotazioni-*` -> legacy prenotazioni e relativo PostgreSQL
- `menu-legacy` -> pubblicazione statica della legacy menu
- `ordini-*` -> modulo ordini nativo e relativo PostgreSQL di fallback

## Porte di default

- `3000` -> portal
- `8101` -> backend-hub
- `3100` -> frontend prenotazioni
- `8100` -> backend prenotazioni
- `55432` -> PostgreSQL prenotazioni
- `3200` -> menu legacy
- `3300` -> frontend ordini diretto
- `8200` -> backend ordini diretto
- `55433` -> PostgreSQL ordini

Nota utile:

- nel compose locale il modulo ordini e raggiungibile sia direttamente su `http://localhost:3300`, sia in modo integrato su `http://localhost:3000/ordini/`

## Networking

Tutti i container usano la rete dedicata:

- `hospitality-platform-network`

Questo consente:

- DNS per nome servizio
- proxy interni stabili tra Nginx e backend
- nessuna dipendenza da IP locali

## Volumi e persistenza

Volumi dichiarati:

- `prenotazioni_postgres_data`
- `ordini_postgres_data`
- `backend_hub_state_data`

Uso reale dei volumi:

- `prenotazioni_postgres_data` -> database della legacy prenotazioni
- `ordini_postgres_data` -> PostgreSQL fallback di `ordini`
- `backend_hub_state_data` -> stato condiviso tra `backend-hub` e `ordini-backend`

Dentro `backend_hub_state_data` finiscono tipicamente:

- `/data/platform_registry.sqlite3`
- `/data/tenants/*.sqlite3`
- `/data/menu-assets`
- `/data/google_workspace_state.json` se configurato cosi in `.env`

## Configurazione via `.env`

Le variabili sono centralizzate in `.env`.

Gruppi principali:

- URL pubblici: `PORTAL_PUBLIC_URL`, `BACKEND_HUB_PUBLIC_URL`, `PRENOTAZIONI_*_PUBLIC_URL`, `MENU_LEGACY_PUBLIC_URL`, `ORDINI_FRONTEND_PUBLIC_URL`
- porte locali: `PORTAL_PORT`, `BACKEND_HUB_PORT`, `PRENOTAZIONI_*_PORT`, `MENU_LEGACY_PORT`, `ORDINI_*_PORT`
- LLM: `LLM_BASE_URL`, `LLM_API_KEY`, `ASSISTANT_*`
- Google Workspace: `GOOGLE_WORKSPACE_*`
- database legacy/fallback: `PRENOTAZIONI_DATABASE_URL`, `ORDINI_DATABASE_URL`
- tenancy ordini: `TENANCY_REGISTRY_DATABASE`, `TENANCY_SESSION_DURATION_HOURS`

Attenzione:

- `.env.example` contiene esempi orientati a `powerup.cool`
- per sviluppo locale gli URL pubblici vanno adattati a `localhost`

## Build e runtime

Dettagli rilevanti:

- `portal` riceve gli URL runtime come build args Docker
- `portal` Nginx espone anche il proxy interno `/ordini/`
- `backend-hub` installa dipendenze OCR/PDF per l'ingestione degli asset menu
- `ordini-frontend` proxya `/api/` verso `ordini-backend`
- `menu-legacy` e `prenotazioni-*` vengono pubblicati senza rifattorizzare la loro logica applicativa

## Cosa non e containerizzato

Il servizio LLM non e containerizzato qui.

Resta esterno al compose ed e configurato via:

```env
LLM_BASE_URL=http://amicifede.ddns.net:1234/v1
```

## Relazione con la produzione

Il compose root e un bootstrap locale e di staging leggero.

In produzione corrente:

- l'ingresso HTTPS e fuori dal compose
- il reverse proxy pubblico e Apache
- `ordini` entra da `/ordini/` passando comunque dal Nginx del `portal`

Quindi il compose non e la descrizione completa dell'ingresso pubblico finale, ma della topologia applicativa interna.