# Deploy Ubuntu

## Obiettivo di deploy

La topologia reale documentata per questo workspace non espone ogni servizio come app pubblica separata.

In produzione corrente il modello di riferimento e:

- Apache su `*:443`
- `portal` come ingresso principale
- `backend-hub` pubblicato dietro `/api/`
- `prenotazioni` e `menu` come servizi separati dietro path dedicati
- `ordini` pubblicato come `https://powerup.cool/ordini/` tramite il Nginx del `portal`

## Prerequisiti

Sul server Ubuntu servono:

- Docker Engine
- Docker Compose plugin
- accesso SSH
- un file `.env` coerente con il dominio reale
- un reverse proxy HTTPS esterno al compose

Verifica minima:

```bash
docker --version
docker compose version
```

## Layout consigliato

Esempio:

```text
/opt/hospitality-platform
```

Contenuto atteso:

- repository clonato
- `.env`
- volumi Docker di Compose

## Configurazione `.env`

1. Copia `.env.example` in `.env`
2. Allinea le variabili al dominio reale

Esempio coerente con routing path-based:

```env
PORTAL_PUBLIC_URL=https://powerup.cool
BACKEND_HUB_PUBLIC_URL=https://powerup.cool/api
PRENOTAZIONI_FRONTEND_PUBLIC_URL=https://powerup.cool/prenotazioni
PRENOTAZIONI_BACKEND_PUBLIC_URL=https://powerup.cool/prenotazioni-api
MENU_LEGACY_PUBLIC_URL=https://powerup.cool/menu/
ORDINI_FRONTEND_PUBLIC_URL=https://powerup.cool/ordini/
LLM_BASE_URL=http://your-llm-host:1234/v1
```

Nota pratica:

- l'URL pubblico di prodotto per `ordini` deve restare `/ordini/`
- non serve pubblicare `:3300` come endpoint utente finale

## Avvio iniziale

Dalla root del progetto:

```bash
docker compose up -d --build
```

Controlli rapidi dopo l'avvio:

```bash
docker compose ps
docker compose logs -f backend-hub
```

## Routing pubblico consigliato

Il proxy HTTPS esterno deve rispettare questa logica:

- `/` -> `portal`
- `/api/` -> `backend-hub`
- `/prenotazioni` e `/prenotazioni/` -> `prenotazioni-frontend`
- `/prenotazioni-api/` -> `prenotazioni-backend`
- `/menu/` -> `menu-legacy`

Per `ordini`:

- il proxy pubblico deve inoltrare `/` al `portal`
- il `portal` gestisce internamente `/ordini/`
- il frontend ordini poi proxya `/api/` verso `ordini-backend`

## Dati persistenti da preservare

Il deploy non e stateless. Vanno preservati:

- volume `backend_hub_state_data`
- volume `prenotazioni_postgres_data`
- volume `ordini_postgres_data`
- eventuale `.env`

Nel volume condiviso del `backend-hub` vivono anche:

- registry dei tenant
- database SQLite dei tenant
- asset menu caricati
- eventuale file di stato Google Workspace

## Aggiornamenti

Aggiornamento tipico:

```bash
git pull
docker compose up -d --build
```

Riavvio completo:

```bash
docker compose restart
```

Riavvio di un singolo servizio:

```bash
docker compose restart portal
```

## Log e diagnostica

Log completi:

```bash
docker compose logs -f
```

Log servizio specifico:

```bash
docker compose logs -f backend-hub
docker compose logs -f prenotazioni-backend
docker compose logs -f ordini-backend
```

## Note operative

- mantenere il reverse proxy pubblico fuori dal compose riduce il coupling con le legacy
- il servizio LLM resta esterno al repository e va monitorato come dipendenza separata
- per Google Workspace usare sempre un redirect URI coerente con `BACKEND_HUB_PUBLIC_URL`
- in produzione conviene fare backup regolari dei volumi Docker e non solo del repository