#nb proxy の設計意図

コアプロセスについてのみ話す場合は、次の 3 つのコマンドを覚えておくだけで十分です。

nb proxy nginx use docker
nb proxy nginx generate --env test2 --host c.local.nocobase.com
nb proxy nginx reload

ほとんどのシナリオでは、nb proxy を使用して行うことは、基本的に次の 3 つの手順です。

1. まず、use を使用して、現在のプロバイダーの実行モードを選択します。
2. 次に、generate を使用して、環境とドメイン名に従ってエントリ構成を生成します。
3. 最後に reload を使用して構成を有効にします

Caddy を使用している場合は、コマンド内の nginx を caddy に置き換えるだけです。 Nginx がマシンに直接インストールされている場合は、docker を local に置き換えるだけです。

これは、nb proxy のこの層が最も提供したいエクスペリエンスでもあります。最初に Nginx や Caddy の設定の詳細に入る必要はなく、固定されたプロセスに従って入り口に接続するだけです。

#最初にこれら 3 つの項目を覚えておくだけで十分なのはなぜですか?

nb proxy によって解決される問題は実際には非常に収束するため、 ** アプリケーションに安定した外部アクセスの入り口を与えます。 **

実稼働環境のデプロイの概要 をすでに参照している場合は、次のように nb app autostart とは別に覚えておいてください。

• nb app autostart は「マシンの再起動後にアプリケーションの実行を再開する方法」を担当します。
• nb proxy は「アプリケーションが Nginx または Caddy を介して安定した外部アクセスを提供する方法」を担当します。

したがって、最も一般的な展開プロセスでは、nb proxy には多くの労力は必要ありません。ほとんどの場合は次のとおりです。

• 動作モードの選択
• 構成の生成
• リロードが有効になります

十分。

#この 3 つのステップは何をしているのでしょうか?

#use

use は、「現在のエージェントをどのように管理するか」という問題を解決します。

例えば：

• nb proxy nginx use docker
• nb proxy nginx use local

最初に現在のプロバイダーのデフォルトのドライバーを選択すると考えることができます。次のコマンド start、reload、および status はこのように機能します。

#generate

generate は、「現在の環境に応じてエントリ構成をレンダリングする」という問題を解決します。

例えば：

nb proxy nginx generate --env test2 --host c.local.nocobase.com

このステップでは、env 内の情報とエントリー層に必要なパラメーターを組み合わせて、使用可能なプロキシ構成を生成します。通常、ここで最も重要な入力は次のとおりです。

• --env: どの CLI 管理環境を公開するか
• --host: どのドメイン名にバインドするか

つまり、generate はプロセスのステータスではなく、構成製品を管理します。

#reload

reload は、「新しく生成された構成を真に有効にする」という問題を解決します。

nb proxy nginx reload

この分離には、構成の生成とプロセスのアクションが混在しないという直接的な利点があります。ドメイン名、ポート、またはパブリック パスを変更する場合は、最初に再生成してから、変更を有効にするかどうかを決定します。プロセス全体がより明確になります。

#use → generate → reload として設計する必要がある理由

これらの 3 つのステップは、入口層の 3 つの最も安定したアクションに対応しているためです。

• 最初にエージェントの実行方法を決定します。
• 次に、どの環境に対してどのエントリを生成するかを決定します。 -最後に設定を有効にします

これらすべての手順をブラック ボックス コマンドに組み込むと、表面上のコマンドが少なくなったように見えます。ただし、問題が発生すると、ドライバーが間違って選択されたのか、構成が正しく生成されなかったのか、またはエージェントがリロードされなかったのかを判断するのは困難です。

このように分解すると、調査の道はよりまっすぐになります。

• use 間違っていたらドライバーを切ってください
• generate は正しくありません。構成を再生成します。
• 構成は正しいですが、まだ有効になっていません。reload だけです。

#個別の nb proxy が必要な理由

nb proxy が統合したいのは特定の Nginx 設定ファイルではなく、エントリー層の共通アクションだからです。

あなたが本当に気にすることは、通常、次のことではありません。

-設定ファイルはどのパスにありますか?

• Nginx と Caddy のコマンドの違い
• ローカルと Docker の操作上の違い

あなたがもっと心配していることは次のとおりです。

• この環境を公開するにはどうすればよいですか?
• ドメイン名を変更するにはどうすればよいですか?
• 新しい設定を有効にするにはどうすればよいですか?

nb proxy は、これらのアクションを同じ CLI エントリのセットに統合します。このように、最初にコアプロセスを覚えていれば、ほとんどのシナリオをすでにカバーできます。詳細のトラブルシューティングを続けたい場合、または特別な構成が必要な場合にのみ、プロバイダーの独自のページを参照してください。

＃＃ 全体

• nb proxy 精神の中心的な使い方は use → generate → reload
• ほとんどのユーザーは、これら 3 つのコマンドを覚えておけば十分です
• その設計の焦点は、すべての詳細を隠すことではなく、まず最も一般的な入口レベルのプロセスを修正することです。

特定のコマンドを引き続き確認したい場合は、nb proxy に直接移動できます。正式な入り口に接続する準備ができている場合は、引き続き リバース プロキシ を確認することもできます。