Přeskočit obsah

Admin App Onboarding — vylepšení vendor wizard flow

Status: draft Verze spec: 0.1 Aktualizováno: 2026-05-26 Související: apps-gateway.md, per-app-container.md, vendor-onboarding.md

1. Cíl

Snížit ruční SSH/SQL kroky při onboardingu nové vendor aplikace z 5 na 0.

Aktuální stav (2026-05-26):

POST /admin/app-management/create (volá launcher2 Vendoři tab → "+ Nová aplikace") už dělá:

  • ✅ apps DB row + alpha channel subscription pro publishera
  • ✅ Gitea repo + push template skeletonu (vendor team grant)
  • ✅ S3 bucket app-<slug> + public-read policy
  • ✅ Inject APPDIST_S3_* secrets do Gitea repo
  • ✅ Container port auto-allocate v range 8101–8199 (_allocate_container_port)
  • ❌ gateway_enabled defaultně false — gateway routing neaktivní
  • ❌ _publish_apps_changed po DB commit se NEvolá (i když funkce existuje)

Chybí E2E flow: Po push vendora do master + úspěšném CI deploy musí super_admin manuálně:

UPDATE apps SET gateway_enabled=true, is_public=true WHERE slug='<slug>';

curl -X POST http://127.0.0.1:8100/admin/refresh

Toto je single-point-of-failure (zapomenutý flip = neviditelná app).

2. Roadmap

Fáze 1 — Backend toggle endpoint (1h)

Endpoint:

PUT /admin/app-management/{slug}/gateway
Body: {"enabled": true}
Auth: super_admin only

Side-effects: - UPDATE apps SET gateway_enabled=?, is_public=? WHERE slug=? (pokud enabled=true, is_public taky true — gateway visibility requirement) - await _publish_apps_changed(slug, "gateway_toggled") — Redis pubsub trigger pro apps-gateway cache refresh (<1s)

Plus v existujícím create_app po db.commit() taky volat _publish_apps_changed(body.slug, "created") — gateway dostane signál i když gateway_enabled zatím false, ať si pre-cache zbytek metadat.

Akceptační kritéria: - 200 OK + {"slug", "gateway_enabled", "is_public"} po toggle - 404 pokud slug neexistuje - 403 pokud caller není super_admin - Apps-gateway cache aktualizovaná do 1s (sledovatelné v gateway logu) - Toleruje Redis výpadek (pubsub publish failuje warning-level, DB commit OK)

Fáze 2 — Launcher2 UI toggle v admin Aplikace tabu (1h)

V launcher2 admin "Aplikace" (super_admin only) — seznam apps s per-row toggle switch "Gateway".

  • Načíst stav z GET /admin/app-management/list (gateway_enabled boolean)
  • Switch click → PUT /admin/app-management/{slug}/gateway s opačnou hodnotou
  • Visual feedback během requestu (disabled switch, spinner)
  • Toast/status text po success/error

Akceptační kritéria: - Toggle viditelný JEN pro super_admin (per user.system_role) - Toggle disabled (read-only) pokud app.has_backend == false (gateway nemá smysl bez backend kontejneru) - Click responzivnost — switch reflektuje stav okamžitě, rollback na error

Fáze 3 — Pubsub trigger v create_app ✅ implementováno v rámci Fáze 1

Drobnost přidruženo k Fázi 1 (1 řádek kódu).

Fáze 4 — Port auto-assign ✅ HOTOVO

_allocate_container_port() v backend/app/routers/app_management.py:67 už existuje a běží — rezervuje první volný port v range 8101-8199 pro has_backend=true apps. Nic se zde nemění.

Fáze 5 — Post-deploy health verify ✅ HOTOVO

Po gateway_enabled=true flip backend spustí FastAPI BackgroundTasks → services/health_probe.py::probe_app_health(slug). Polluje http://127.0.0.1:8100/<slug>/health (apps-gateway loopback) každé 2s, max 15 cyklů (~30s). Výsledek do apps DB:

  • health_status — ok / down / unknown (degraded rezervováno)
  • last_health_check_at — UTC timestamp
  • last_health_error — popis chyby (HTTP code, connect error, timeout)

Při flip enable se sloupce resetují (unknown + clear error). Probe běží po HTTP response (žádný blocking ze strany endpointu).

Migrace nepotřebná — sloupce health_status, last_health_check_at, last_health_error přidány už v migraci 020 (apps-gateway columns).

UI: V launcher2 admin "Aplikace" seznamu se per row zobrazí badge: - ✅ gateway zelený — health OK - ⏳ gateway šedý — unknown (probe běží / nikdy nebyla) - ⚠ gateway oranžový — degraded (rezervováno) - ❌ gateway červený — down (probe failed)

Badge se zobrazuje jen pokud gateway_enabled=true.

Akceptační kritéria — splněna: - ✅ BackgroundTasks neblokuje HTTP response endpointu - ✅ Probe respektuje 30s timeout - ✅ health_status reflektuje skutečný stav do ~30s po flipu - ✅ DB update tolerantní k výpadkům (try/except, log warning) - ✅ Badge v admin UI se barví podle stavu

3. E2E flow po Fázi 1+2

Nový vendor onboarding (jediný klik + jeden následný klik):

  1. Super_admin → launcher2 "Vendoři" → "+ Nová aplikace" → vyplnit slug/jméno → klik "Vytvořit". Backend vytvoří DB row + Gitea repo + S3 bucket + port rezervace. gateway_enabled=false.
  2. Vendor naklonuje repo, pushne kód, Gitea Actions postaví image + deploy přes backend.yml (vzor app-legal commit 3c3c7d3).
  3. Super_admin → launcher2 "Aplikace" → najde novou app v seznamu → klik toggle "Gateway". Backend flipne gateway_enabled=true + is_public=true + Redis pubsub. Gateway cache refresh <1s.
  4. Test: curl http://192.168.1.55/apps/<slug>/health → 200.

Zde žádný SSH/SQL od super_admin.

4. Související