Nginnx作業における詳細な配置

一、背景紹介
背景：会社の既存プロジェクトモデル1、フロントエンドプロジェクトはLinux環境ディレクトリ/usr/local/nginx/demo1、demo 1の下にindex.htmlとstaticフォルダ（いくつかの静的リソースを含む）を保存します。
nginx.com nfでは、次のように構成されている。

http {
	include mine.types;
	default_type application/octer-stream;
	client_max_body_size 10M;

	sendfile on;

	upstream demo_channel {
		#                
		# 8091      zuul    
		server 10.137.128.120:8091 weight=1;
		server 10.137.128.122.8091 weighr=1;
		server 10.137.128.123.8091 weighr=1;
	}

	......
}

server {
    listen 80;
    server_name localhost;

    #     
	location / {
		root demo1;
		try_files $uri $uri/  /index.html;
		index index.html index.html;
	}

	location /user {
		proxy_pass  http://demo1_channel;
	}

	location /backend {
		proxy_pass  http://demo1_channel;
	}

	location /case {
		proxy_pass  http://demo1_channel;
	}

	......
}

会社は全部で4台のサーバーを持っています。フロントエンドプロジェクトは10.137..128.121に展開されています。他のバックエンドサービスは120、122、123に配置されています。ブラウザがアドレスhttp://10.137.128.122:80にアクセスすると、要求はlocation /にマッチングされます。ロフトにアクセスして配置されたパスにログアウトを加えて配置されたパス、すなわち要求はdemo1/の下の静的リソースに要求されます。
フロントエンドのvueプロジェクトはどうやってバックグラウンドインターフェースにアクセスしますか？Vueプロジェクトにはインターフェースパスが配置されています。フロントエンドプロジェクトの配置の総パスはhttp://10.137.128.122:80/です。そして、異なるマイクロサービスを要求する時には、異なるマイクロサービス名（Vueでも書きます。）を追加します。http://10.137.128.122:80/case、http://10.137.128.122:80/userなど、ブラウザがフロントエンドプロジェクトにアクセスする時にこれらのパスを要求すると、Ngix構成のlocation /case location /userによってブロックされます。したがって、proxy_passに転送された後に構成されるパスを要求する。
この経路会社は、upstream demo_channel { ... }を構成し、重みに応じて要求を異なるサーバに転送し、負荷の均衡を実現する。すなわち、バックグラウンドサービスを実際に要求する経路は10.137.128.120:8091/case/...または10.137.128.122:8091/user/...である。また、バックグラウンドにZuulが配置されているので、すべてのマイクロサービスインターフェースは、ZuulゲートウェイのIPアドレスとエンドスローガン（ここでは8091）とマイクロサービス名を加えてアクセスできます。つまり、フロントエンドはhttp://10.137.128.122:80/ で、異なるサーバの異なるマイクロサービスに対するインターフェース方法を要求することができます。
二、フロントエンドの設定
追加：単独モジュールを追加して、ゲートウェイを配置しないで、独立した先端が必要です。
方法1：異なるポートを構成し、server{ listen ; ...}と同様に、元の構成と同様に、ポートを交換するだけで、アクセス時には現在構成されているポートを使用します。
しかし、社内ネットワークは80ポートでしかアクセスできないので、新しいプロジェクトを元の80ポートに配置するしかないです。配置ファイルは以下の通りです。

server {
    listen 80;
    server_name localhost;

    #     
	location / {
		root demo1;
		try_files $uri $uri/  /index.html;
		index index.html index.html;
	}

	#     demo2
	location /demo2 {
		root demo2;
		try_files $uri $uri/  /index.html;
		index index.html index.html;
	}
	......
}

ブラウザアクセスアドレスは、ロカモーションの後に構成された経路マッチングに従って、/demo2に先にマッチングし、/にアクセスすると、http://10.137.128.122:80/demo2にマッチングし、つまり、要求の先端リソース経路がroot＋locationの後に配置された経路、つまりlocation /demo2ディレクトリの下の静的リソースであるため、demo 2プロジェクトの配置経路はdemo2/demo2である。
外にもう1階のdemo 2ディレクトリを作りたくないので、以前のように配置したいと思っていましたが、2つの/usr/local/nginx/demo2/demo2があってはいけません。配置ファイルは許可されていません。
したがって、{ location / }を使用することができます。構成ファイルは以下の通りです。

server {
  	......
	#     demo2
	location /demo2 {
		alias demo2/;
		try_files $uri $uri/  /index.html;
		index index.html index.html;
	}
	......
}

aliasとrootの違いは、aliasを使用する場合、フロントエンドリソースを要求するときには、location後のパス、すなわちaliasを要求しないときは、http://10.137.128.122:80/demo2下の静的リソースのみを要求することである。
注意:

aliasを使う時、ディレクトリ名の後に必ず/usr/local/nginx/demo2を追加してください。rootは追加できます。

aliasはlocationブロックにしかありません。rootはlocationに入れなくてもいいです。

三、バックエンドインターフェースサーバの逆プロキシを設定する
フロントエンドの設定が終わったら、開発機で正常にアクセスできます。バックグラウンドインターフェースを要求しても大丈夫です。結果、お客様に渡した時、いつも/を報告しました。その後、バックグラウンドインターフェースが要求されないかもしれません。お客様のコンピュータは80ポートしか訪問できません。フロントエンドだけを配置しました。フロントエンドとの接続時に、フロントエンドがVueプロジェクトにデッドバックした要求バックグラウンドインターフェースアドレスはnetwork errorであり、クライアントがこの住所を要求できないはずである。
インターフェースサーバのインバースプロキシを追加するように設定します。Ngixプロファイルは以下の通りです。

server {
    listen 80;
    server_name localhost;

	......
	#     
	location /entryCase {
		#         ，   SpringBoot  
		proxy_pass http://10.137.128.120:9092/entryCase;
		proxy_read_timeout 30s;
	}
	......
}

Vueフロントエンド項目の要求インターフェースアドレスはhttp://10.137.128.120:9092に変更され、ユーザがホームリソースにアクセスした後、ある操作を行った後、ブラウザ送信要求はhttp://10.137.128.121:80であり、このサービス名もフロントエンドコードの中で書き込みが完了したもので、この経路はnginx.comに配置されたhttp://10.137.128.121:80/entryCase/...に一致し、nginxというリバースプロキシによってproxy_に行く。パス後に配置されたパス要求データは、クライアントに戻ります。
この設定を完了しました。全体のプロファイルは以下の通りです。

server {
    listen 80;
    server_name localhost;

    #     
	location / {
		root demo1;
		try_files $uri $uri/  /index.html;
		index index.html index.html;
	}

	#     demo2
	location /demo2 {
		alias demo2/;
		#try_files $uri $uri/  /index.html;
		index index.html index.html;
	}

	#     
	location /entryCase {
		#         ，   SpringBoot  
		proxy_pass http://10.137.128.120:9092/entryCase;
		proxy_read_timeout 30s;
	}

	......
}

四、Complement
1.nginx.com nfを修正したら、（Linux環境）を再読み込みしてください。

location /entryCase、構成ファイルの修正が正常かどうかをテストする。

/usr/local/nginx/sbin/nginx -tは、NFinxプロファイルを再読み込みする。

2.Locationマッチングルール

フロントエンド開発nginx常用機能を把握するserver&locationマッチング規則

3.Proxy_パスの設定
このフロントエンド要求のバックグラウンドサービスのアドレスは、/usr/local/nginx/sbin/nginx -s reload、例えば、get方法を要求するhttp://10.137.128.121:80/entryCase/...、Ngixプロファイルに配置可能なproxy_。パスには二つの種類があります

http://10.137.128.121:80/entryCase/get

proxy_pass http://10.137.128.120:9092

以上の2つは、正確にproxy_pass http://10.137.128.120:9092/entryCaseに要求することができる。

nginxのproxy_pass詳細解