План: сервер Tucktag на Oracle Cloud (OCI), CI/CD из GitHub, доступ из IntelliJ

Черновик для владельца (msg 2265, 2026-10-15). После одобрения он станет seed и пойдёт по конвейеру. Факты об OCI — из моих знаний на середину 2026 года. Пункты с «проверить» воркер сверит с документацией Oracle до начала работ.

Что у нас есть

• Сервер: Spring Boot, Java 25, PostgreSQL 18. Есть Dockerfile и compose.yaml для разработки.
• Настройки сервера — переменные окружения TUCKTAG_* (база, ключи, Google, Telegram, Firebase).
• Есть чек-лист запуска в прод: docs/ops/runbooks/RUNBOOK-05 (домен, TLS, секреты, Google, Telegram webhook, Firebase).
• В репозитории нет GitHub Actions.

Целевая схема

 GitHub (push в main)
   │ 1. тесты сервера (unit)
   │ 2. сборка образа linux/arm64
   │ 3. образ → GHCR (реестр GitHub)
   │ 4. деплой: ждёт твоего «Approve» (environment production)
   ▼
 OCI VM (Ampere A1, Ubuntu, Always Free)
   ├─ Caddy :443  → HTTPS (Let's Encrypt), домен
   ├─ tucktag-server :8080 (только внутри)
   ├─ PostgreSQL :5432 (только внутри)
   └─ ночной pg_dump → OCI Object Storage
 IntelliJ ── SSH-туннель ──► база, логи, отладка

Фаза 0. Решения (твои)

1. Домен для сервера. Нужен для HTTPS и Google-входа.
2. Как CI попадает на VM (см. Фаза 4): SSH из GitHub (рекомендую) или VM сама забирает образ.
3. Что значит «подключаться из IntelliJ» (см. Фаза 5).
4. Перевести аккаунт OCI на Pay-As-You-Go. Рекомендую: бесплатные лимиты остаются, Oracle не забирает «простаивающую» VM. Ставим бюджет-алерт на 1 $.

Фаза 1. Аккаунт и сеть OCI (делаешь ты в консоли, я даю шаги)

1. Проверь домашний регион. Его нельзя сменить. Ampere A1 там бывает «Out of capacity» — тогда пробуем позже или другой домен доступности.
2. Включи MFA на аккаунт.
3. Создай compartment tucktag.
4. Создай VCN мастером «VCN with Internet Connectivity».
5. Security List: вход только 22 (SSH), 80 и 443. Порт 5432 и 8080 наружу НЕ открываем.

Фаза 2. VM (ты в консоли, дальше воркер по SSH — только с твоей командой)

1. Instance: shape VM.Standard.A1.Flex, 4 OCPU, 24 GB RAM (весь бесплатный лимит — проверить), образ Ubuntu 24.04, диск 100–150 GB (лимит 200 GB на все диски).
2. Добавь свой SSH-ключ. Вход по паролю выключен.
3. Зарезервируй публичный IP (Reserved Public IP), направь на него DNS домена.
4. На VM: Docker и compose, пользователь deploy без sudo-пароля только для docker, fail2ban, автообновления безопасности.
5. Ловушка: образы Ubuntu в OCI закрывают порты в iptables на самой VM. Нужно открыть 80 и 443 и там, не только в Security List.

Фаза 3. Прод-конфиг в репозитории (воркер, отдельная ветка)

1. server/compose.prod.yaml: postgres, server (образ из GHCR по тегу), caddy. Лимиты памяти. Тома для базы, builds, holiday-media.
2. server/Caddyfile: домен → server:8080, HTTPS автоматически.
3. Секреты: файл .env только на VM (права 600). В git — только .env.example. Свежие прод-секреты по RUNBOOK-05 §2.3.
4. Новый runbook: RUNBOOK-07 «OCI»: создание VM, деплой, откат, восстановление базы.

Фаза 4. CI/CD в GitHub (воркер)

1. .github/workflows/server.yml:
   • на PR и push: unit-тесты сервера (*UnitTests, *ModularityTests);
   • на push в main: сборка образа linux/arm64 → GHCR, тег = версия + коммит;
   • job deploy: environment production с обязательным одобрением (ты нажимаешь «Approve»).
2. Деплой (вариант А, рекомендую): SSH на VM под deploy → docker compose pull && up -d → проверка /actuator/health → при провале откат на прошлый тег. Вариант Б: VM сама опрашивает GHCR. Нет входа SSH из GitHub, но нет и кнопки одобрения в GitHub.
3. Сборка arm64: раннер GitHub ubuntu-24.04-arm (проверить: бесплатен ли он для приватного репозитория). Запасной путь — buildx с QEMU (медленно, ~3–5x).
4. Секреты GitHub: SSH-ключ деплоя, host. Прод-секреты сервера в GitHub не кладём.
5. Ограничение: пуш workflow-файлов в GitHub — только по твоему слову, по нашим правилам пуша.

Фаза 5. IntelliJ (выбери, что нужно)

1. База: Database tool window → PostgreSQL через SSH-туннель (порт 5432 наружу закрыт). Только чтение по умолчанию: отдельный пользователь БД с правами read-only.
2. Логи и контейнеры: плагин Docker → подключение к Docker на VM по SSH.
3. Отладка: Remote JVM Debug через SSH-туннель на порт 5005. JDWP включаем только на время отладки — это дыра, если оставить.
4. Терминал и файлы: SSH-конфигурация в IntelliJ (терминал, SFTP).
5. Remote Development (Gateway): IDE-бэкенд на VM. Не рекомендую на прод-VM: он ест 2–4 GB RAM рядом с сервером.

Фаза 6. Бэкапы и наблюдение

1. Ночной pg_dump → OCI Object Storage (бесплатно 20 GB — проверить), хранение 14 дней.
2. Раз в месяц — проверка восстановления на копии.
3. Бэкап загрузочного диска (бесплатно до 5 — проверить).
4. Алерт: OCI Monitoring или внешний пинг /actuator/health; сообщение в Telegram.

Риски

• Ampere A1 может не создаться из-за нехватки мощности в регионе.
• Always Free без Pay-As-You-Go: Oracle может забрать VM при низкой нагрузке 7 дней.
• База на той же VM: потеря VM = восстановление из бэкапа. Платная управляемая PostgreSQL в OCI не бесплатна.
• Образ должен быть arm64: проверить все зависимости (Temurin 25 — есть arm64).

Кто что делает