アプリケーションが自動的に起動します
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、またはホスト起動スクリプトに引き渡されます。これらは、マシンの起動時に以下を実行する責任があります。
このコマンドは、自動起動が有効になっているすべてのアプリケーションを起動します。
この層がないと、基盤となる操作方法が異なると、Docker、PM2、またはその他の方法のそれぞれの自動開始構成と回復プロセスを覚えておく必要があります。 nb app autostart を追加した後は、同じ NocoBase CLI の使用習慣を覚え続けるだけで済みます。
まず、この設計がこのように分解される理由を知りたい場合は、[nb アプリの設計意図](../cli-design/nb-app-design-intent.md#Why is-nb-app-autostart それでも必要な理由) を読み続けてください。
このコマンド グループの役割は何ですか?
最も一般的に使用されるものは次のとおりです。
nb app autostart enablenb app autostart disablenb app autostart listnb app autostart run
最も一般的な 2 つの責任レベルに注目すると、次のように理解できます。
enable/disableは、特定の環境で自動起動が許可されているかどうかを管理します。runは、システム起動フェーズ中に自動起動が有効になっているすべての環境をプルアップする役割を果たします。
まず、現在の環境の自動開始フラグを有効にします。
現在の環境以外のものを操作したい場合は、それを明示的に指定できます。
これを有効にすると、どの環境が自己起動としてマークされているかを確認できます。
システムの起動後、次のコマンドを実行して、自動起動が有効になっているすべての環境をプルアップする必要があります。
トラブルシューティング時に基礎となる起動出力を確認したい場合は、以下を追加できます。
システムで env を開始したくない場合は、このマークをキャンセルすることもできます。

