フロントエンドとバックエンドを分離した nginx 構成を展開するための完全な手順

序文

決まり文句です。ここでは、フロントエンドとバックエンドの分離についての私の理解についてお話しします。単純な分離は、元の MVC ビュー レイヤーを削除して、独立したサーブレット サービスにするだけです。サーブレットは http で接続されます。ここでのビュー サーブレット コンテナーは、Tomcat、Apache、Nginx、IIS などの任意のサーバー側サービスにすることができます。ここでは、よく使われる Nginx を例に簡単に説明します。

需要分析

需要分析から始めましょう。

• 単一プロジェクト
  • 単一プロジェクトとは、フロントエンド サービスがサーバー上に展開され、www.xxx.com => index.html が単一のポイントになることを意味します。
• 複数のプロジェクト
  • マルチプロジェクトとは、1 つのサーバーが複数のフロントエンド サービスと共にデプロイされ、www.xxx.com/a => a.html、www.xxx.com/b => b.html などが複数のサイトを指すことができることを意味します。
• エージェントをリクエストします。
• Cookie ドメインの書き換え。
• Cookie パスのオーバーライド。

ヒント: 設定を個別に処理できるように、ここに conf.d/*.conf を記述することをお勧めします。

パブリック構成

サーバ{
 listen 80; # ポートの設定 server_name _; # ドメイン名の設定 charset utf-8; # エンコーディング access_log /xxx/log/nginx_access.log main; # 成功ログ error_log /xxx/log/nginx_error.log error; # エラーログ index index.html; # ファイルの検索順序 set $root /xxx/nginx/; # 変数設定、パブリックパスの設定 # その他の場所
}

/xxx/log/nginx_access.log および /xxx/log/nginx_error.log の下に対応するファイルを手動で作成してください。 nginx reload を初めて実行するときにエラーが発生する場合があります。

set の $root パスは絶対パスであり、access_log と error_log も絶対パスです。

単一プロジェクト構成

ディレクトリ構造

nginx
|----- インデックス.html
|----- ユーザー.html

場所の設定

位置 / {
	ルート $root;
}

最も単純なルート パス ベースの構成は次のようになります。ここでは、場所を経由するパスを構成し、$root フォルダー内の index.html ファイルを指定するだけです。

マルチプロジェクト構成

ディレクトリ構造

nginx
|----- ア
    |----- インデックス.html
|----- バ
    |----- インデックス.html

複数の場所の構成

場所 ^~ /a {
  エイリアス $root/a;
}

場所 ^~ /b {
  エイリアス $root/b;
}

位置 / {
  ルート $root;
}

コピーキャット プロジェクト間の唯一の違いは、ルートとエイリアスの違いです。ルートはファイルの絶対一致パスを参照しますが、エイリアスは相対一致を参照します。 root は http、server、location で設定できますが、alias は location でのみ設定できます。正規表現 ^~ も追加しました。/a または /b に一致する場合、場所のパスが何であっても、リソースの実際のパスは alias で指定されたパスである必要があります。この方法では、/a と /b のパスを一致させて、固定パスにジャンプすることができます。これは、SPA スタイルのフロントエンド プロジェクトでは非常に便利です。なぜなら、コア ファイルとして実際に存在するのは index.html ファイルが 1 つだけだからです (リソース ファイルは別の問題です)。この方法では、常に index.html にジャンプして、ブラウザを手動で更新したときに、ルート パスに基づいてサーバーの他のパスにあるリソースが検索されないようにすることができます。次に、spa のルート パスを設定し、/b が一致する必要があります。

なぜそのような需要があるのでしょうか?フロントエンドは軽量であり、このメカニズムを使用してサーバーを節約し、同じ種類のビジネスを集約します。 admin.xxxx.com/a => 運用管理デスク、admin.xxxx.com/b => ERP 管理デスクのように。管理ドメイン名の下のサブパスを切り取るだけです。シンプルで軽量。

リクエスト転送

場所 ^~ /api {
  proxy_pass http://api.xxx.com/;
}

これは非常に簡単です。/api リクエストを正規表現と照合し、proxy_pass 属性を通じてリクエストを http://api.xxx.com に送信します。あなたはできる

クッキードメインを変更する

セキュリティ上の理由から、特定の Cookie ドメイン属性を設定することがありますが、これは nginx 転送にはあまり適していません。もちろん解決策はあり、それは非常に簡単です。

位置 {
  proxy_cookie_domain <このドメインのドメイン> <変更するドメイン>;
}

クッキーパスを変更する

API インターフェースに転送し直すと、API ドメイン名が Cookie を取得できない場合があります。ドメインに加えて、Cookie パスの可能性もあります。もちろん解決策は簡単です

位置 {
  proxy_cookie_path <このドメインのパス> <変更するパス>;
}

その後の最適化

これは、nginx の設定の最も簡単な例にすぎません。gzip の有効化、キャッシュ設定、リソース リクエストをマージするためのプラグイン、50 倍、40 倍のページの設定、モバイルと PC のジャンプの判断などの設定もあります。nginx は、やはり非常に強力です。

要約する

以上がこの記事の全内容です。この記事の内容が皆様の勉強や仕事に何らかの参考学習価値をもたらすことを願います。123WORDPRESS.COM をご愛顧いただき、誠にありがとうございます。