Приложение запускается автоматически

В NocoBase CLI nb app autostart используется для управления тем, «какие среды могут запускаться автоматически» и «как равномерно извлекать эти среды после запуска системы».

Если вы собираетесь официально запустить приложение, размещенное с помощью CLI, на сервере, обычно это шаг по умолчанию в производственной среде.

Почему nb app autostart все еще нужен?

Эта проблема очень распространена.

Когда многие люди увидят это впервые, они подумают, что раз на нижнем уровне уже есть Docker, PM2 или в самой системе уже есть systemd, то зачем нам еще один уровень nb app autostart.

Причина в том, что эти слои на самом деле не решают одну и ту же проблему:

  • Такие возможности, как Docker, PM2 и Supervisor, решают проблему «как обычно работают приложения и как управлять процессами приложений».
  • Такие возможности, как systemd, launchd и сценарии запуска хоста, решают проблему «какую команду запускать при запуске системы?»
  • nb app autostart решает проблему «на уровне NocoBase CLI, как единообразно управлять тем, каким окружениям разрешено запускаться автоматически, и как их подтягивать после запуска системы»

Другими словами, CLI не устраняет необходимость в Docker, PM2 или Supervisor. Вместо этого он унифицированно адаптирует различные методы управления процессами, а затем объединяет их в стабильный набор самозапускающихся порталов управления, чтобы уменьшить психические заболевания пользователя.

Когда система запускает этот уровень, он продолжает передаваться systemd, launchd или сценарию запуска хоста. Они отвечают за выполнение при запуске машины:

nb app autostart run

Затем эта команда запустит все приложения, у которых включен автозапуск.

Без этого уровня, если базовый метод работы отличается, вам необходимо запомнить соответствующие процессы самозапускающейся конфигурации и восстановления Docker, PM2 или других методов. После добавления nb app autostart вам просто нужно продолжать помнить тот же набор привычек использования NocoBase CLI.

Если вы хотите сначала понять, почему этот дизайн разбит таким образом, продолжайте читать [замысел дизайна приложения nb](../cli-design/nb-app-design-intent.md#Почему-nb-app-autostart все еще нужен).

Каковы обязанности этой группы команд?

Наиболее часто используемые из них:

  • nb app autostart enable
  • nb app autostart disable
  • nb app autostart list
  • nb app autostart run

Если вы посмотрите только на два наиболее распространенных уровня ответственности, вы можете понять это так:

  • enable / disable отвечают за управление тем, разрешает ли определенная среда автоматический запуск.
  • run отвечает за подтягивание всех окружений, у которых включен самозапуск, на этапе запуска системы.

Сначала включите флаг автозапуска для текущего окружения:

nb app autostart enable

Если вы хотите работать с чем-то отличным от текущего окружения, вы можете указать это явно:

nb app autostart enable --env app1 --yes

После его включения вы можете проверить, какие среды были помечены как самозапускающиеся:

nb app autostart list

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

nb app autostart run

Если вы хотите видеть основной результат запуска при устранении неполадок, вы можете добавить:

nb app autostart run --verbose

Если вы больше не хотите, чтобы env запускался вместе с системой, вы также можете отменить эту отметку:

nb app autostart disable --env app1 --yes

Каково его отношение к Docker, PM2 и systemd?

Здесь есть граница, которую легко спутать.

nb app Этот уровень решает проблему того, «как работает приложение». Нижний уровень может адаптироваться к различным методам работы, таким как Docker и PM2, и может расширяться в будущем.

nb app autostart Этот уровень решает проблему «как получить среду, которая обеспечивает автоматический запуск после запуска машины». Это больше похоже на предоставление стабильной точки входа для механизма запуска хоста, а не на замену конкретного инструмента управления процессами.

другими словами:

  • Такие возможности, как Docker, PM2 и Supervisor, более близки к тому, как работают приложения.
  • systemd, launchd, сценарий запуска хоста, ближе к уровню запуска системы.

Вот почему в формальной среде вам обычно необходимо подключить nb app autostart run к собственному процессу запуска системы, например systemd, launchd, сценариям запуска контейнерной платформы или другим механизмам автозапуска хоста, которые вы уже используете.

Область применения

nb app autostart применяется только к средам выполнения, управляемым через CLI, то есть:

  • local
  • docker

Если эта среда представляет собой только удаленное соединение API или не является приложением, работающим под управлением CLI на текущем компьютере, то этот набор команд не подходит для самостоятельного запуска.

##Практика по умолчанию

В большинстве случаев достаточно следующей последовательности:

  1. Сначала убедитесь, что приложение можно нормально запустить на текущем компьютере.
  2. Выполните nb app autostart enable --env <name> --yes.
  3. Подключите nb app autostart run к системе, чтобы начать процесс.
  4. Перезагрузите компьютер или вручную выполните run, чтобы проверить, нормально ли он восстанавливается.

Если вам все еще нужно настроить рабочий входной уровень, продолжайте просматривать обратный прокси.

Связанные команды

nb app autostart enable --env app1 --yes
nb app autostart disable --env app1 --yes
nb app autostart list
nb app autostart run
nb app autostart run --verbose

Ссылки по теме