Перейти к содержанию

Автоматизированный установщик (install.sh)

В репозитории есть интерактивный установщик — мастер поверх того же docker-compose.yml, который используется при ручной установке. Он записывает .env, генерирует секреты и поднимает стек; сам Docker он не устанавливает (предпосылки — в обзоре установки).

./install.sh            # меню
./install.sh --dry-run  # напечатать каждую изменяющую команду, ничего не выполнять
./install.sh -h         # справка

Интерфейс — диалоги whiptail (при наличии apt устанавливается по требованию). На минимальном хосте или через серийную консоль включите текстовый fallback:

UMBRYX_INSTALL_NO_TUI=1 ./install.sh

Режимы

Установщик сегодня строит ровно один пункт меню; остальное ниже — запланировано, но не поставляется:

Режим Издание Статус Что делает
aio Core, EE поставляется Одноузловая установка «всё на этом хосте»: пишет .env, docker compose build && up для db/redis/backend/frontend/nginx
ha_seed EE не поставляется Первый HA-узел: монитор pg_auto_failover, Postgres этого узла, HAProxy + keepalived (VIP), Redis + Sentinel
ha_join EE не поставляется Второй (и далее) узел, присоединяющийся к существующему HA-кластеру
ha_app EE не поставляется Направить app-слой этого узла (backend/frontend/nginx) на работающий HA-кластер через его VIP

HA сегодня развёртывается вручную через docker-compose.ha.yml — следуйте странице HA-развёртывание; она остаётся источником истины.

HA-режимы повторяют развёртывание HA шаг за шагом — та страница остаётся источником истины.

Что спрашивает и делает режим aio

  1. Проверяет предпосылки — на хосте нужны docker, openssl, curl.
  2. База данных — имя пользователя Postgres, имя базы, пароль.
  3. Административная учётка — имя пользователя и пароль первого администратора (смените пароль после первого входа).
  4. Сеть — порт, на котором nginx отдаёт платформу (по умолчанию 3000).
  5. Окружение — production (рекомендуется: требует ENCRYPTION_KEY, строгие значения по умолчанию) или dev (ослабленные проверки, только для локальных тестов).
  6. HTTPS — в production-режиме: доступен ли экземпляр по HTTPS? Отвечайте «нет», если лишь тестируете по plain HTTP — иначе куки входа потребуют HTTPS и вы потеряете доступ (COOKIE_SECURE).
  7. Генерирует секреты — JWT_SECRET и WEBHOOK_HMAC_SECRET (случайный hex-32), ENCRYPTION_KEY (Fernet-ключ). Секреты вводятся в маскированных полях и нигде не выводятся и не логируются.
  8. Пишет .env — существующий .env предварительно резервируется и никогда не перезаписывается на месте.
  9. Собирает и запускает стек и ждёт экрана первого входа (/api/auth/setup).

Результат побайтово тот же, что при ручной установке Core — установщик лишь мастер поверх того же compose-файла.

HA-режимы: прочитать до запуска

  • Регистрация узла pg_auto_failover — одноразовое рукопожатие. Повторный запуск ha_seed/ha_join против уже настроенного кластера небезопасен.
  • Предпосылка на каждом HA-хосте: sudo sysctl -w net.ipv4.ip_nonlocal_bind=1 (установщик предлагает выполнить её сам).
  • ENCRYPTION_KEY и JWT_SECRET должны побайтово совпадать на всех app-узлах — сгенерируйте один раз на seed-узле и переиспользуйте значения везде.

Полная топология, восстановление и сворачивание: Развёртывание HA.

Замечания по безопасности

  • --dry-run печатает каждую изменяющую команду вместо её выполнения — просмотрите режим на реальном хосте, прежде чем что-то менять.
  • Отмена в любом диалоге останавливает установщик; «наполовину применённого» состояния не остаётся, кроме уже завершённых шагов (резерв .env позволяет вернуться к прежнему состоянию).
  • Установщик не запускает, не останавливает и не читает каталог данных рабочего стека — он управляет только compose-проектом этого чекаута.

После установки: Проверка — health-чеки и первый вход.