Назначение: Требования. Продукт: ShariX Open.

Для кого: Оператор развёртывания · Администратор · Разработчик · Нейросеть.

Темы: Эксплуатация → Среда · Эксплуатация → Установка.

Перед установкой ShariX Open нужно подготовить сервер, определить используемые внешние службы и получить параметры подключения. Эта страница помогает выяснить, что уже готово, чего не хватает и у кого запросить недостающие сведения.

Точные команды установки находятся в инструкции установки и обновления. Актуальный список зависимостей находится в коде той версии, которую вы устанавливаете. Ниже указано, в каких файлах его искать.

При обновлении существующей установки дополнительно нужны сведения о её текущей версии и резервные копии БД, загруженных файлов и локальной конфигурации. Для нового сервера важно определить, какие части инфраструктуры администратор уже подготовил.

Ресурсы сервера зависят от включённых модулей, объёма данных, фоновых задач и предполагаемой нагрузки. Проверенного универсального минимума RAM, CPU и диска эта страница не устанавливает.

В репозитории sharix-open-webapp-base используются следующие файлы:

Дополнительный модуль может иметь собственный requirements.txt. Поэтому установка только корневого списка не всегда подготавливает всю сборку. Состав включённых модулей определяется конфигурацией, а специальные условия подключения описываются в README соответствующего модуля.

Точные версии и имена системных пакетов проверяйте по выбранному commit. Копировать сюда весь список библиотек не нужно: после изменения кода такая копия быстро устареет.

Если БД, LDAP или другая служба находится вне устанавливаемого приложения, нужны реальные параметры именно этой службы.

• Для БД: адрес и порт, имя базы, учётная запись, необходимые права и способ безопасного получения пароля.
• Для LDAP: адрес и протокол подключения, базовая область поиска (Base DN), данные служебной учётной записи и условия защищённого соединения.
• Для сайта: домен, адрес приложения, способ подключения внешнего HTTPS и ответственный за сетевые настройки.
• Для дополнительных модулей: параметры только тех интеграций, которые действительно включаются в этой установке.

Имена параметров и место их сохранения сверяйте с описанием конфигурации и примерами файлов выбранной версии. Реальные пароли и ключи в Wiki не размещаются.

Установщик ShariX Open выполняет действия, предусмотренные его фазами и настройками. В частности, подготовка системных инструментов, установка Python-зависимостей, миграции БД, регистрация служб и запуск приложения — разные шаги. Их порядок и учётные записи указаны в инструкции установки.

Установщик может рассчитывать на уже работающую внешнюю БД или LDAP. Если их нет, сначала нужно согласовать и выполнить подготовку инфраструктуры. Установка клиентской утилиты, создание файла конфигурации и готовность внешнего сервера — три разных результата.

На планёрке 29 октября первоначальная установка была остановлена из-за нехватки сведений и неподготовленной среды. Этот случай показал, какие пояснения нужны человеку; он не подтверждает успешное прохождение всей установки.

Следующие пункты описывают пожелания к удобству и требования к доработке сценария. Они не означают, что каждая возможность уже реализована.

1. Объяснить исходное состояние. Сначала спросить, новая это установка или обновление, что уже подготовлено и какие службы используются.
2. Объяснять запрашиваемые значения. Для каждого параметра указать, зачем он нужен, откуда его взять и где он будет сохранён. Для случайного ключа предложить безопасную генерацию; адрес внешнего LDAP нужно получить у администратора.
3. Использовать уже введённые данные. Если человек ввёл имя БД и пользователя, следующие шаги должны использовать эти значения. Просьба повторно переносить их вручную в другой блок команд создаёт лишнюю возможность ошибиться.
4. Показывать, под кем выполняется действие. Отличать личный вход, deploy и runtime. Не заставлять человека угадывать, когда нужно сменить пользователя.
5. Объяснять выбор режима. Например, что даёт диагностический режим и чем он отличается от обычной работы сайта. DEBUG=True не должен служить исправлением раздачи статики; её настройка описана отдельно.
6. Предупреждать о записи. Перед существенным изменением показать, что будет сделано, и сохранить заданные локальные настройки. Секреты не выводить в общий отчёт.
7. Помогать продолжить после остановки. Сообщить последний успешный шаг, причину остановки и действие, необходимое для продолжения. Повтор всего установщика не должен подменять выяснение причины одного отказа.

Проверяют последовательно: зависимости подготовлены в нужном окружении; конфигурация содержит значения этой установки; необходимые миграции завершены; службы зарегистрированы и запущены под нужными пользователями; приложение отвечает и выполняет выбранный пользовательский сценарий.

Результат каждого шага фиксируется отдельно. Если подготовка завершилась, а запуск нет, нужно разбирать запуск. Если служба запущена, но HTTP-проверка не получила ответа, сохраняют это предупреждение и выясняют сетевые условия. Если работает только отдельный участок, его не выдают за проверку всей цепочки. Подробные критерии — проверка изменений и приёмка.

Сверены опубликованные исходники. Это анализ кода, а не подтверждение успешной установки на конкретном сервере.

• sharix-open-webapp-base: requirements.txt.
• sharix-open-webapp-base: constraints.txt.
• sharix-open-webapp-base: bin/install.sh.
• sharix-open-webapp-base: bin/install_system_dependencies.sh.
• sharix-open-webapp-base: bin/utils/assembly_requirements.sh.
• sharix-open-webapp-base: bin/check_acceptance.sh.