ADR-0023 — Deploy della UI come immagine nginx su ECR, insieme al worker

• Stato: Superato da ADR-0025 (2026-07-22)
• Data: 2026-07-20
• Contesto correlato: ADR-0005 (distribuzione container/CLI del worker)

⚠️ Superato. noeva-etl-ui non è più una web-app servita da nginx/ECR: è diventata un'app desktop Tauri (vedi ADR-0025). Il deploy nginx/ECR della UI, il Dockerfile/ nginx.conf della UI, i flag --ui/--no-ui di deploy-ecr.sh/run-ecr.sh e il repository ECR -ui sono stati rimossi. Questo ADR resta come registro storico.

Contesto

noeva-etl-ui è una SPA Vite/React che consuma noeva-server-api e finora non aveva alcun meccanismo di deploy (niente Dockerfile, niente hosting). Il worker si distribuisce già come immagine su AWS ECR via deploy-ecr.sh e si esegue in locale su Docker Desktop (l'esecuzione su ECS è rinviata, vedi ADR-0005). Vogliamo che un singolo deploy porti su worker e UI, riducendo il drift tra le due parti.

Decisione

La UI viene pubblicata come immagine nginx su ECR, buildata e pushata dallo stessodeploy-ecr.sh che pubblica il worker:

• Default ON, opt-out --no-ui. Senza flag si pubblicano due immagini; con --no-ui solo il worker (comportamento storico). La scelta di default riduce il rischio di deployare un worker aggiornato con una UI vecchia.
• Repository: ${ECR_REPOSITORY_NAME}-ui (default gruppo4d/noeva-etl-ui), stessi tag del worker (latest + timestamp condiviso [+ version tag]) per correlare i due artefatti.
• Ricetta container nel repo UI: Dockerfile (multi-stage: build Vite → runtime nginx:alpine con fallback SPA) e nginx.conf vivono in noeva-etl-ui/, che possiede il proprio ciclo di vita (è un submodule con la sua CI e le sue regole).
• Env di build da noeva-etl-ui/.env. VITE_API_BASE_URL e VITE_ETL_WORKSPACE_ID sono congelate nel bundle a build-time da Vite; lo script le legge dal .env della UI e le passa come --build-arg. Non sono configurabili a runtime.

Alternative scartate

• Statico su S3 + CloudFront. Hosting SPA più naturale, ma introduce infra (bucket/distribuzione/invalidazione cache) che oggi non esiste e diverge dal modello "tutto è un'immagine ECR eseguita in locale". Rinviabile se/quando servirà un URL pubblico.
• Bundle della UI nell'immagine del worker. Architetturalmente errato: il worker non ha server HTTP e la UI parla con noeva-server-api, non col worker.

Conseguenze

• Un deploy pubblica per default due immagini → tempo di build maggiore; --no-ui resta la via rapida per il solo worker.
• La configurazione dell'API della UI è immutabile per immagine: cambiarla richiede un nuovo build. Ambienti diversi ⇒ tag/immagini diversi.
• run-ecr.sh --ui esegue la UI in locale (nginx su http://localhost:${UI_PORT}, default 8080).
• plans.generated.json (import statico) va presente nel context: incluso via .dockerignore e rigenerato best-effort prima della build.