Развёртывание админки
Используйте это руководство после подключения к приложению.
База, аккаунты, бизнес-правила и миграции остаются под управлением вашего приложения.
Настроить аккаунты и сессии
Подключите авторизацию своего приложения и задайте, кто может
просматривать, создавать, изменять и удалять записи. PasswordAuth.single_user()
подходит для локального знакомства, но автоматически не подключает аккаунты приложения.
Передайте в secret_key постоянное случайное значение длиной не менее 32 байт из
хранилища секретов. Используйте одно значение во всех workers с общими сессиями.
Разворачивайте приложение через HTTPS и сохраняйте secure_cookies=True;
False в самостоятельном примере нужен для локального HTTP.
См. сессии и защиту запросов.
Проверить модели и правила записи
Автоматическое обнаружение открывает модели адаптера. Перед выдачей доступа проверьте
выбранные таблицы, видимые и редактируемые поля, разрешённые операции.
Настройки таблиц и полей действуют на сервере и в интерфейсе.
Выберите способ доступа, который выполняет правила вашего приложения:
| Режим | Что выполняется при изменении записей |
|---|---|
| Нативный адаптер ORM | Сохранение через ORM, Python defaults и поддерживаемые хуки ORM |
| SQL reflection | Ограничения, значения по умолчанию и триггеры самой БД |
| Сервисный адаптер | Валидация, авторизация и операции записи вашего сервиса |
SQL reflection не вызывает Python-хуки ORM и правила сервисного слоя. Используйте
сервисы приложения, если запись должна проходить через
существующую бизнес-логику. Проверьте матрицу совместимости и ограничения
для своей пары адаптера и СУБД.
Сохранить служебные данные админки
Бизнес-записи остаются в базе приложения. История действий использует отдельное
служебное хранилище, по умолчанию .quite-admin/state.sqlite3.
Для SQLite нужен постоянный доступный для записи volume. Также можно настроить
описанное в документации хранилище PostgreSQL/MySQL. Репликам с общим состоянием админки
нужно одно хранилище: отдельные файлы внутри контейнеров не разделяют данные.
Выберите уровень записи и срок хранения истории под свои задачи. По умолчанию
записываются завершённые изменения, срок хранения — 90 дней. Проверьте
поведение при сбоях и гарантии сохранности, включите бизнес-данные
и служебное хранилище в резервное копирование.
Сохранить startup и shutdown приложения
Создайте mount до запуска приложения. mount_fastapi() и mount_litestar()
сохраняют lifespan хоста и закрывают служебные ресурсы админки при shutdown.
Инициализация и закрытие собственных engines, ORM-клиентов и пулов остаются у хоста.
Сохраняйте миграции в процессе развёртывания. После миграции при необходимости обновите
метаданные SQL reflection. В интеграциях описаны lifecycle, пути mount
и префиксы reverse proxy. Настройте таймауты и параллелизм чтения,
если админка использует общий с приложением пул соединений.
Проверить развёрнутое приложение
Проверьте вход, права, характерную запись через свои бизнес-правила, историю действий
и URL админки за прокси. Подключите логирование приложения для разбора сбоев.
При обновлении сверяйтесь с гарантиями API и
совместимостью зависимостей.
Изменения и инструкции миграции — в changelog.