Развёртывание Baserow в Yandex Cloud через OpenNix
OpenNix публикует Baserow HA как Cloud Apps-продукт для маркетплейса Yandex Cloud: развёртывание на собственной инфраструктуре без ручной установки зависимостей, с двумя профилями - облегчённым для оценки и отказоустойчивым для рабочей нагрузки - вместо облачного сервиса baserow.io.
Два профиля развёртывания
Продукт разворачивается в одном из двух профилей:
- dev - одна виртуальная машина со встроенными PostgreSQL и Redis. Подходит для оценки и тестирования, но представляет собой единую точку отказа - не предназначен для продуктивной нагрузки.
- prod (рекомендуемый) - два stateless-узла приложения за сетевым балансировщиком, а всё состояние вынесено во внешние управляемые сервисы: Managed Service for PostgreSQL (база данных), Managed Service for Redis/Valkey (кэш и очередь фоновых задач) и S3-совместимый бакет Object Storage (загруженные файлы). Поскольку узлы не хранят данных, любой из них можно пересоздать без потери информации.
Ниже описан путь развёртывания профиля prod - именно он даёт отказоустойчивость и годится для реальных рабочих пространств.
Перед развёртыванием: секреты Lockbox
Форма развёртывания принимает не пароли, а секреты Yandex Lockbox - пароль в открытом виде нигде не вводится. Перед развёртыванием нужно создать три обязательных секрета: пароль базы данных, пароль Redis и ключ подписи Django, а при необходимости - четвёртый, с TLS-сертификатом.
yc lockbox secret create --name baserow-db-password --folder-id <FOLDER_ID> \
--payload '[{"key":"password","text_value":"'"$(openssl rand -hex 24)"'"}]'
yc lockbox secret create --name baserow-redis-password --folder-id <FOLDER_ID> \
--payload '[{"key":"password","text_value":"'"$(openssl rand -hex 24)"'"}]'
yc lockbox secret create --name baserow-secret-key --folder-id <FOLDER_ID> \
--payload '[{"key":"secret-key","text_value":"'"$(openssl rand -base64 48)"'"}]'TLS-сертификат оператора - необязательный секрет; без него каждый узел обслуживает самоподписанный сертификат Caddy:
yc lockbox secret create --name baserow-tls --folder-id <FOLDER_ID> \
--payload '[{"key":"tls-cert","text_value":"<полная цепочка PEM>"},{"key":"tls-key","text_value":"<приватный ключ PEM>"}]'Параметры запуска в маркетплейсе
При развёртывании форма маркетплейса запрашивает:
| Параметр | Что задаёт |
|---|---|
| Префикс имени | Префикс для всех создаваемых ресурсов (используется, например, в имени S3-бакета - должен быть уникальным) |
| Подсеть | Подсеть для узлов и управляемых сервисов |
| Публичный URL | Адрес вида https://..., под который выпускается TLS и формируются ссылки |
| Секреты БД / Redis / Django | Секреты Lockbox, созданные на предыдущем шаге |
| Секрет TLS | Необязательный секрет Lockbox с сертификатом оператора |
| Размер узлов | vCPU, память и диск на узел |
| Число воркеров | Количество воркеров gunicorn и Celery на узел |
| Managed PostgreSQL | Версия, класс хостов и размер диска кластера |
| Managed Redis (Valkey) | Версия, класс хостов и размер диска кластера |
Что создаётся при развёртывании
После завершения развёртывания в каталоге (folder) появляются: кластер Managed Service for PostgreSQL, кластер Managed Service for Redis (Valkey), S3-бакет для файлов, два вычислительных узла, целевая группа и сетевой балансировщик с публичным IP-адресом. Сервисный аккаунт продукта получает только точечные роли lockbox.payloadViewer и storage.editor - без файлов-ключей и без широких прав редактирования каталога.
Первый вход
- Откройте публичный URL, указанный при развёртывании (или IP-адрес сетевого балансировщика) в браузере. Без собственного TLS-сертификата браузер покажет предупреждение о самоподписанном сертификате Caddy - это ожидаемо.
- На открывшейся странице Baserow создайте первую учётную запись через обычную форму регистрации веб-интерфейса - административные учётные данные не выдаются на этапе развёртывания инфраструктуры, секреты Lockbox используются только для подключения к базе данных, Redis и подписи сессий.
- Создайте первое рабочее пространство и переходите к статье «Быстрый старт с Baserow» , если ещё не проходили её.
Отказоустойчивость и обслуживание
В профиле prod узлы приложения не хранят данных и заменяемы: потеря одного узла не приводит к потере данных, потому что база, кэш и файлы находятся во внешних управляемых сервисах. Планировщик периодических задач Celery beat работает ровно на одном узле - за это отвечает демон-лидер, который удерживает advisory-lock в PostgreSQL и автоматически передаёт роль другому узлу при сбое, так что задачи никогда не выполняются дважды. Резервное копирование базы данных и Redis выполняется штатными средствами Managed Service for PostgreSQL и Managed Service for Redis, независимо от версии Baserow на узлах приложения.
Что дальше
Дальше стоит изучить основные понятия Baserow и полезный набор горячих клавиш для ежедневной работы.