Перейти к основному содержимому

Деплой

Развёртывание — Docker Compose: три собираемых образа (catalog-backend, catalog-web, catalog-cms) плюс postgres, redis, meilisearch, minio.

Приложение настраивает себя само​

Цель — один и тот же образ разворачивается на новом сервере для новой компании без ручных шагов, специфичных для конкретного магазина:

  • Миграции прогоняет одноразовый сервис migrate (medusa db:migrate) до старта backend. Рантайм-образ схему не мигрирует сам, поэтому на свежей БД без этого шага backend падает на каждом module loader с «relation … does not exist».
  • Администратор создаётся сервисом backend-init (scripts/init-admin.sh → medusa user) из ADMIN_EMAIL/ADMIN_PASSWORD. Повторный запуск безопасен, дубля не будет.
  • Sales channel по умолчанию и publishable key создаёт сам Medusa core (createDefaultsWorkflow) при каждом старте, если их ещё нет. Отдельный сид не нужен.
  • Витрина забирает publishable key в рантайме через GET /catalog/config — на первом деплое ключа ещё не существует на момент сборки.

npm run backend:seed — демо-каталог этого магазина. На боевом развёртывании новой компании его запускать не нужно.

Порядок​

  1. Заполнить .env (см. Переменные окружения) — обязательно сменить все секреты и ADMIN_PASSWORD.
  2. docker compose up -d --build.
  3. Дождаться, пока migrate завершится, а backend станет healthy.
  4. Проверить docker compose ps и /health.

:::note Сборка образа backend Используется BuildKit-кэш npm (--mount=type=cache). Не запускайте несколько docker build параллельно — они дерутся за кэш. Детали — docs/specs/_archive/auto-paint-store/stack.md. :::

:::warning Перед публикацией наружу Появился TLS-прокси — переключите SESSION_COOKIE_SECURE на true, иначе вход покупателя молча сломается. И смените пароль администратора: значение из репозитория паролем не является. :::

Проверка после выкатки: логи обязательны​

Зелёный статус деплоя и визуальный осмотр страницы не считаются проверкой. Логи ловят то, что не видно глазом: перехваченные error boundary исключения, сбои SSR, ошибки соседних сервисов.

Витрина логирует клиентские ошибки структурно (apps/web/app/api/client-errors/route.ts + ClientErrorListener):

[storefront] level=ERROR event=client_error method=… path=… message=… stack=…

Порядок:

  1. Дождаться завершения выкатки.
  2. Пройти проверяемый сценарий на живом стенде.
  3. Запросить event=client_error за период вокруг выкатки и убедиться, что ошибки прекратились именно после времени деплоя.

:::danger Отсутствие ошибок за минуту ничего не доказывает Если трафика не было, пустой лог — не подтверждение. Проверка фикса — это сравнение: записи были до выкатки и исчезли после. Такого подтверждения не даёт ни сборка, ни ручной осмотр. :::

Контейнеры в логах называются catalog-main-<hash>-web-1, -backend-1, -postgres-1, -redis-1, -meilisearch-1, -cms-1, -migrate-1. Хеш меняется при пересоздании стека — берите актуальный из метки service_name.

Что сейчас не работает​

:::warning E2E-набор переписывается заново Прежний apps/e2e (Playwright) был полностью нерабочим и удалён. Новый набор под витрину Next.js разрабатывается по плану в docs/specs/e2e-automation/. :::