3.9 KiB
Развёртывание
После копирования .env.example обязательно заполните STANDALONE_TENANT_ID идентификатором организации (ULID) из Krona Business Platform. Значения по умолчанию нет; прежняя заглушка 01J00000000000000000000000 не подходит для Compose или пилота. Для первого запуска deploy/pilot/setup.sh передайте этот ID через переменную окружения: установщик проверит его и сохранит в своём .env. При повторном запуске проверяется существующий .env. Для уже заполненного пилота нельзя просто заменить ID: сначала нужна резервная копия, проверка восстановления и перенос tenant-данных.
Локально скопируйте .env.example в .env и выполните docker compose up --build. Compose последовательно проверит PostgreSQL, создаст или обновит отдельную роль krona_staff_app с NOSUPERUSER NOBYPASSRLS, выполнит миграции ролью krona_migrator и только затем запустит приложение. Runtime-контейнер не получает пароль или URL мигратора. Redis и object storage не включаются до появления реального сценария очередей или файлов.
Для обновления старого Docker volume, созданного версией с ролью krona_staff, задайте в .env POSTGRES_MIGRATION_USER=krona_staff и прежний POSTGRES_MIGRATION_PASSWORD, затем выполните обычный docker compose up --build. Сохраняйте эту роль владельцем миграций для данного volume: автоматического переименования владельца существующей базы нет, а перенос владения требует отдельного DBA-плана с повторной настройкой default privileges.
Production: один stateless app container/process, отдельный PostgreSQL, TLS/reverse proxy, secret manager и централизованные logs/metrics/traces. Приложению выдаётся только роль без SUPERUSER и BYPASSRLS; миграционный URL хранится отдельно и не передаётся runtime-контейнеру. /api/v1/staff/live проверяет процесс, /api/v1/staff/ready — обязательные зависимости, /api/v1/staff/version — release и runtime mode. Container работает non-root, read-only filesystem.
HA сейчас не требуется. Для будущего scale-out: общий PostgreSQL/Redis/S3, несколько API/worker nodes, leader election для scheduler, outbox relay и идемпотентные consumers. Локальные вложения запрещены. Linux и Windows deployment сохраняют паритет на уровне Node/container contract.
Миграции запускаются отдельным one-shot job до rollout, учитываются в schema_migrations вместе с SHA-256 исходного SQL и защищены advisory lock. Для старых записей без checksum первый запуск фиксирует текущую версию как доверенную базовую; последующие изменения применённого SQL блокируются. Down откатывает только последнюю миграцию и требует backup плюс ALLOW_MIGRATION_DOWN=true.