Запуск платформы

В репозитории есть единый Docker-образ приложения, но его наличие не подтверждает готовность production-развёртывания.

Перед запуском проверяем сохранность данных и поведение при сбое, а не только открытие главной.

Ниже — результат чтения файлов на базе f96ae27. Образ и production Compose в этой задаче не запускались.

Существующая сборка

Dockerfile собирает API на Node 22, две Nuxt SPA и nginx. Bun 1.3.14 устанавливает зависимости. В runtime остаются Node, nginx, Git и Chromium для Playwright; отдельного процесса Nuxt для каждой панели нет.

Внешний TLS → nginx :8080
               ├─ /          → статический app
               ├─ /admin/    → статический admin
               ├─ /api/      → NestJS :3333
               ├─ /mcp       → NestJS
               └─ /health    → NestJS

Это маршруты существующего контейнера. Они не реализуют целевой маршрутизатор клиентских доменов.

docker/start.sh сначала запускает prisma migrate deploy, затем API в фоне и nginx на переднем плане. Production Compose описывает web и PostgreSQL, связывает порт web с loopback хоста и предполагает внешний TLS-прокси. Конфигурация этого прокси и его работа здесь не подтверждены.

Что проверить до использования

Данные PostgreSQL. В docker-compose.prod.yml указан postgres:18, но named volume смонтирован в /var/lib/postgresql/data. Официальный образ начиная с 18 использует другую структуру и рекомендует монтирование в /var/lib/postgresql. Это несогласованность конфигурации: перед использованием нужно проверить фактический PGDATA, исправить mount и провести тест сохранности после пересоздания. Для существующей базы сначала нужна резервная копия и проверенный перенос, а не простая смена пути. Документация образа.

Завершение API. Комментарий в docker/start.sh обещает завершение контейнера при падении API, но скрипт запускает API в фоне и ждёт nginx. Нет явного ожидания завершения дочернего API-процесса. Это требует проверки с принудительным падением и корректного управления процессами. Наличие healthcheck само по себе не подтверждает автоматическое восстановление.

Очереди. Текущая работа копирования остаётся в памяти API. До запуска нескольких реплик нужно вынести задания в устойчивое хранилище и проверить конкуренцию исполнителей. Предлагаемая модель.

Файлы. Local-драйвер требует постоянного диска; запись в файловую систему временного контейнера недостаточна. S3-драйвер реализован, но production Compose сейчас передаёт параметры local и не перечисляет S3 credentials. Для S3 их нужно явно доставить в runtime и проверить запись/чтение; одной смены STORAGE_DRIVER недостаточно.

Почему это ещё не инструкция «запустить одной командой»

До размещения приложения нужно подтвердить TLS, доступ к базе и файлам, резервное копирование, миграции, завершение процессов и работу после перезапуска. Перечисленные недостатки зафиксированы, но продуктовая конфигурация в этой документационной задаче не изменялась.

Источники: Dockerfile, docker-compose.prod.yml, docker/start.sh, docker/nginx.conf. Порядок релиза.