☁️ Облачный стенд для хакатона — архитектура и план

О чём это

Проект эфемерного публичного стенда на Oracle Cloud под хакатон «Dice Chess AI» (23–24.07.2026): играть/смотреть партии против AI-ботов + витрина статистики. Облако = одноразовый клон демо-поверхности, независимый от homelab и домашнего интернета во время выступления. Настоящий прод остаётся на aurora (см. dicechess-analytics на aurora — деплой и sizing); сюда мы кладём снапшот данных, а не второй источник истины.

Статус — черновик/обсуждение. Варианты дорабатываем в отдельной сессии. Механика облака уже проверена на KCP-прогоне — см. Oracle Cloud — журнал настройки (CLI, авторизация, сеть).

Зачем облако, а не homelab

  • Публичность — чистый URL, который открывают жюри, без проброса домашней сети.
  • Независимость — во время демо не зависим от домашнего аплинка/питания.
  • Изоляция — не рискуем настоящим продом на aurora.
  • Одноразовость — поднял → показал → terminate. Стоит центы (см. бюджет ниже).

Охват (scope B): play + боты + аналитика

Полный нарратив темы «Dice Chess AI»: посетитель играет против oracle-ботов и тут же видит почему модель сильная (openings explorer, winrate-by-position).

Ключевой плюс

Бо́льшая часть уже существует как docker-compose (у play-api свой compose, у analytics — db+api+ui). Стенд — это редеплой того же compose на публичную VM + обёртка наружу (прокси/TLS/снапшот), а не стройка с нуля.

Архитектура: одна A1.Flex VM

flowchart TD
  U["Игрок / жюри"] -->|HTTPS| C["Caddy · авто-TLS"]
  C -->|"play.домен"| PF["play-frontend · статика"]
  C -->|"/api + WS"| PA["play-api · JVM"]
  C -->|"stats.домен"| AU["analytics-ui · статика"]
  C -->|"/api"| AA["analytics-api · JVM"]
  PA --> PDB[("Postgres · play")]
  AA --> ADB[("Postgres · analytics · снапшот")]
  B["oracle-боты 1/2/3 + KCP · JVM+ONNX"] -->|"вызовы"| PA
  subgraph VM["Одна A1.Flex VM · docker-compose · aarch64"]
    C
    PF
    PA
    AU
    AA
    PDB
    ADB
    B
  end

Всё — JVM / статика / Postgres, то есть arch-нейтрально; ONNX-боты уже работают на arm64 (rpi4), так что Ampere A1 (aarch64) подходит без эмуляции.

КомпонентЧто этоАрх / форматНаружу
CaddyОбратный прокси + авто-TLS (Let’s Encrypt)любой:443
play-frontendSvelteKit adapter-staticстатикачерез Caddy
play-apiИгровой сервер + WebSocketJVM (arm64 образ)через Caddy
Postgres [play]Партии/сессии playarm64внутр.
analytics-uiСтатистика/openings explorerстатика (или arm64 образ)через Caddy
analytics-apiREST над БД игрJVM (arm64 образ)через Caddy
Postgres [analytics]Снапшот игрarm64внутр.
oracle-боты 1/2/3 + KCPONNX-value-ботыarm64 (как на rpi4)внутр. → play-api

Почему это влезает в €250

РесурсКонфиг€/мес (24/7)
A1.Flex4 OCPU / 24 GB~€50
A1.Flex8 OCPU / 48 GB~€100
Block storage (БД+тома)~50 GB~€1
Egress10 ТБ/мес бесплатно€0

Реально за окно хакатона (пара недель тестов + событие) — ~€25–50 из €250. Подробнее про биллинг: Oracle Cloud — раннбук.

Что нетривиально (разовые задачи)

  1. 🔴 arm64-образы для play-api / analytics-api / analytics-ui (docker buildx --platform linux/arm64 или CI-матрица). analytics-ui сейчас amd64-only → пересобрать под arm64 либо отдавать статикой. Боты уже arm64. Единственное на критическом пути — начинать заранее.
  2. Снапшот данных: pg_dump игр с aurora → restore в облако. Решить: вся история (~140k партий) или курированный срез.
  3. DNS + TLS: поддомен jc.id.lv → public IP инстанса → Caddy сам берёт сертификат.
  4. Секреты / вход: redirect-URI Google-OAuth под новый домен — либо запустить analytics-ui в анонимном read-only режиме, чтобы не возиться с логином на публичном демо.

План по фазам

Фаза 0 — подготовка (заранее, вне критического пути)

  • arm64-образы play-api / analytics-api / analytics-ui.
  • docker-compose.hackathon.yaml + Caddyfile + bootstrap-скрипт в репо (воспроизводимо, как Oracle-журнал).
  • Скрипт pg_dump (aurora) → restore (облако).
  • Поддомен jc.id.lv + подготовка DNS.

Фаза 1 — генеральная репетиция (~за неделю)

launch VM → bootstrap → compose up → restore данных → DNS+TLS → сквозной smoke (сыграть партию против бота, открыть статистику) → terminate. Проверяет весь стенд за ~час.

Фаза 2 — событие

Поднять из готовых артефактов за ~10 мин (или держать с репетиции). Мониторить логи/ресурсы.

Фаза 3 — после

terminate инстанса (сеть VCN остаётся, в простое бесплатна).

Открытые решения (обсудить в отдельной сессии)

  • Объём данных: полная история vs курированный срез (свежие/высокорейтинговые) — чтобы дамп был лёгкий, а openings explorer выглядел богато. Склоняюсь к срезу.
  • Вход в аналитику: анонимный read-only (проще, ничего не светим) vs полноценный OAuth с новым доменом.
  • Размер VM: 4 OCPU/24 GB для демо с запасом; 8 — только при многих одновременных партиях.
  • IaC: bootstrap-скрипт + compose (быстро, как сейчас) vs Terraform (декларативно, легче teardown/повтор).

Следующий шаг

Когда возьмёмся — оформить как issue-цепочку (по PR: arm64-образы → compose хакатона → скрипты снапшота/bootstrap → репетиция). Начинать с arm64-образов (критический путь).

Связанные заметки