nb アプリの設計意図
nb app 関連のコマンドは、基本的にさまざまなプロセス管理方法に基づいて調整され、一連の安定したアプリケーション管理入口に統合されます。この目的は、日常の運用および保守中の頭の使い方を一連のコマンドに収束させようとすることです。
現在、CLI でサポートされているアプリケーション プロセス管理方法には主に次のものがあります。
- ドッカー -PM2
将来、スーパーバイザーなど、さらに多くのメソッドをサポートする必要がある場合は、この層で引き続き調整を行っていきます。外界に公開される高頻度コマンドの入り口は変わりません。
なぜ nb app に統一する必要があるのか
プロセス管理はさまざまな方法で実装できますが、ほとんどのユーザーにとって本当に関心があるのは、最下層で使用されるものではなく、「アプリケーションを起動したい」、「ログを読みたい」、「アプリケーションをアップグレードしたい」という具体的なアクションです。
根本的な違いが直接明らかになった場合、ユーザーはまず現在使用している動作モードを判断し、次に対応する一連の動作方法を覚えておく必要があります。 nb app に統合された後、これらの高頻度アクションは一連の安定した入り口に収束します。
学習コストを削減する
プロセス管理ソリューションが異なれば、動作方法も異なります。
- Docker には Docker のコマンド システムがあります
- PM2にはPM2コマンドシステムがあります
- スーパーバイザにも独自の設定方法があります
これらの違いが直接露呈すると、ユーザーは複数の使用方法を学ぶ必要があり、アップグレード、再起動、ログのトラブルシューティングなどの高頻度のシナリオで重要な手順を見逃しやすくなります。
nb app として統合された後は、日常的な管理のほとんどは 1 セットのコマンドを習得するだけで済みます。
ビジネスプロセスを統合する
アプリケーションのライフサイクル管理は、単なるプロセス管理ではありません。
起動、アップグレード、停止などのプロセスでは、多くの場合、CLI は次のような追加ロジックを処理する必要があります。
- 環境検査
- 設定処理
- データ移行
- バージョンアップ
- ログ管理
nb app を統合入口として使用することで、これらのプロセスの動作の一貫性を確保できます。将来的に能力を拡張し続ける場合、新しい運用と保守の入り口を学び直す必要はありません。
nb app autostart が依然として必要なのはなぜですか?
統合されたプロセス管理の入口を設けた後、プロセス全体を完了させるために、「自己開始型管理」機能の別の層を追加する必要があります。これが nb app autostart が存在する理由です。
一般的な使用法は次のとおりです。
この一連の命令の焦点は、対外的に統一を維持し続けることである。言い換えれば、nb app のこの層におけるユーザーの頭の中では、最下位層が Docker、PM2、または将来サポートされる可能性のあるその他のメソッドであるかどうかを気にする必要はありません。外部の統一操作方法は次のようになります。
run このレイヤーは何に適応しますか?
nb app autostart は、次の 2 つのレベルの責任にも分かれています。
enable/disableは、特定の環境で自動起動が許可されているかどうかを管理します。runは、システム起動フェーズ中に自動起動が有効になっているすべての環境をプルアップする役割を果たします。
つまり、CLI は、システムの自動起動メカニズムへのアクセスを提供するための統合された run エントリも提供します。
ここで適用されるのは、スーパーバイザーなどのアプリケーション プロセス マネージャーではなく、systemd、launchd などのシステム起動メカニズム、およびホスト起動スクリプトです。
## 全体
nb app関連コマンドは、基本的に、さまざまなプロセス管理方法の上にある適応層です。外部的に統一された後は、ユーザーの精神的な混乱を軽減できます。- プロセス管理の実装は、Docker、PM2、Supervisor などで可能です。現在、Docker と PM2 がサポートされています
- 異なるプロセス管理方法のセルフスタート構成は異なるため、プロセス全体を完了するには、統合された
nb app autostart機能のセットが必要です。
引き続き毎日の操作を確認したい場合は、アプリケーションの管理 に直接移動できます。アプリケーションを正式な環境にデプロイする準備ができている場合は、引き続き 実稼働環境のデプロイメント を参照してください。

