適用対象: .NET Core 2.1、.NET Core 3.1、.NET 5
この記事では、ホスト名を使用して Nginx で 2 つ目の Web サイトを構成する方法と、構成をテストする方法について説明します。
前提条件
このパートでは、次の項目を設定する必要があります。
- Nginx が自動的に実行され、ポート 80 で送信された要求をリッスンしています。
- Nginx はリバース プロキシとして構成され、すべての受信 HTTP 要求をポート 5000 でリッスンしている最初の ASP.NET Core アプリケーションにルーティングします (このポートで実行されているバックエンド アプリケーションとして任意の ASP.NET Core アプリケーションを使用できます)。
- その最初 ASP.NET 常に実行するように構成されたコア アプリケーションです (プロセスが停止するか、サーバーが再起動された場合は、ASP.NET Core アプリケーションが自動的に開始されます)。
- LINUX ローカル ファイアウォールが有効になっており、SSH および HTTP 受信トラフィックを許可するように構成されています。
- ポート 5001 でリッスンするように構成された 2 つ目の ASP.NET Core アプリケーション (このアプリケーションは常に実行するように構成する必要があり、また、ASP.NET Core アプリケーションのバグ対応サンプルもセットアップの 2 番目のアプリケーションとして構成する必要があります)。
このパートの目標
現在、Nginx には 1 つのサイトが構成されています。 ポート 80 から Nginx に到着した要求はすべて、そのサイトにルーティングされます。 このセットアップでは、ホスト名は関係ありません。 IP アドレスまたは IP アドレスに解決される任意のホスト名を使用します。 すべての要求は、既定の Web サイトにルーティングされます。 この既定の Web サイトはリバース プロキシとして機能し、ポート 5000 でリッスンしている最初の ASP.NET Core アプリケーションに要求をルーティングします。
このチュートリアルのこの部分では、Nginx で 2 つ目の Web サイトを作成します。 その Web サイトはリバース プロキシとしても機能し、特定のホスト名を持つ要求は、ポート 5001 でリッスンしている 2 番目の ASP.NET Core アプリケーションにルーティングされます。
また、特定のホスト名をリッスンするように Web サイトを構成します。 最後に、アクセス可能で、次のホスト名を持つ 2 つのサイトがあります。
- 最初の Web サイト:
http://myfirstwebsiteは、最初の ASP.NET Core デモ アプリケーションにトラフィックを転送します。 - 2 番目の Web サイト:
http://buggyambは、2 番目の ASP.NET Core サンプル バグのあるアプリケーションにトラフィックを転送します。
クライアント Windows コンピューターと Linux コンピューターの両方の hosts ファイルに myfirstwebsite と buggyamb を追加します。 この方法では、これらの URL を使用して新しい構成をテストできます。
これらのホスト名はデモンストレーション専用です。 このパートの演習全体で同じホスト名を一貫して使用している限り、他のホスト名を自由に使用できます。
Nginx でホスト名を使用して 2 つ目の Web を構成する
思い出すと、Nginx がサイト構成を読み込むディレクトリの 1 つは /etc/nginx/sites-enabled/ です。 現在、既定の構成ファイルが 1 つあります。 ファイルは次のスクリーンショットのようになります。
Note
次の変更が必要になるため、強調表示されている部分に注目してください。
server_name: ここで目的のホスト名を設定できます。 現在、これは_値に対して構成されています。 これは、任意のホスト名を意味します。proxy_pass: これは、特定の URL で実行されリッスンしているコア アプリケーションの実際の ASP.NET です。 要求はこの URL にルーティングされます。
ホスト ヘッダーの http://myfirstwebsiteをリッスンするように最初の Web サイトを構成します。 これを実現するには、次のスクリーンショットに示すように、/etc/nginx/sites-enabled/default 構成ファイルのserver_nameを変更します。 このファイルを編集するには、 sudo vi /etc/nginx/sites-enabled/default コマンドを使用する必要があります。
2 番目の Web サイト用の 2 つ目の Nginx 構成ファイルを作成します。 このファイルをテンプレートとして使用して、同じ構成ディレクトリにこのファイルのコピーを作成します。 ファイルに buggyamb.config という名前を付けます。
sudo cp /etc/nginx/sites-enabled/default /etc/nginx/sites-enabled/buggyamb.config
sudo vi /etc/nginx/sites-enabled/buggyamb.config コマンドを実行して、構成ファイルを編集します。 /etc/nginx/sites-enabled/buggyamb.config ファイルの最終バージョンを次に示します。
結果のセットアップには、Nginx サイト構成ディレクトリに、 buggyamb.config と default という 2 つの構成ファイルが必要です。 構成の変更を再読み込みするには、Nginx を設定する必要があります。 ただし、最初に新しい構成をテストして、変更時にエラーが発生していないことを確認する必要があります。 sudo nginx -t コマンドを実行し、構成が正しいことを確認します。 次に、 sudo nginx -s reload を実行して構成を再読み込みし、新しい変更を読み込みます。
新しい構成をテストする
myfirstwebsiteとbuggyambホスト名を正しい IP アドレスに解決するように設定します。 Linux コンピューターからサイトにアクセスすると、これらのホスト名は 127.0.0.1 に解決され、クライアント Windows コンピューターなどの外部クライアントに対して解決されます。 ホスト名は、Linux 仮想マシンのパブリック IP アドレスに解決される必要があります。 その IP アドレスは、Azure portal から取得できます。
Note
Hosts マッピングは、Linux の /etc/hosts ファイルと、Windows の C:\WINDOWS\System32\drivers\etc\hosts ファイルに格納されます。
これは Linux ホスト ファイルの内容です。
curl myfirstwebsiteコマンドとcurl buggyamb コマンドを実行して、2 つの各サイトに要求を行うことができます。
curl myfirstwebsite出力を次に示します。 応答は、最初にデプロイされ、ポート 5000 でリッスンしているコア アプリケーション ASP.NET デモンストレーションのホーム ページから HTML コンテンツを正しく表示しているようです。
curl buggyamb出力を次に示します。 これにより、ポート 5001 で実行されている、BuggyAmb サンプル アプリケーションのホーム ページの HTML コンテンツが表示されます。
ブラウザーを使用して、クライアント コンピューターから同じ URL を参照できる必要があります。 これは、hosts ファイルを正しく構成する場合にも機能します。 これは、Windows コンピューターで実行されているブラウザーから http://buggaymb を参照するときに表示されます。
この時点まで、次のセットアップが行われます。
2 つの Web サイトをホストしている Nginx:
- 最初の Web サイトでは、
myfirstwebsiteホスト ヘッダーを使用して要求をリッスンし、その要求をデモ ASP.NET Core アプリケーションにルーティングします。 このアプリケーションはポート 5000 でリッスンします。 - 2 番目の Web サイトは、
buggyambのホスト ヘッダー値を使用して受信 HTTP トラフィックをリッスンし、2 番目の ASP.NET Core サンプル バグのあるアプリケーションに要求をルーティングします。 このアプリケーションはポート 5001 でリッスンします。
- 最初の Web サイトでは、
ASP.NET コア アプリケーションはどちらも、サーバーの再起動時に自動的に再起動するサービスとして実行されているか、アプリケーションが応答を停止します。
Linux ローカル ファイアウォールが有効になっており、SSH トラフィックと HTTP トラフィックを許可するように構成されています。
トラブルシューティングのヒント
サイトを参照すると、 HTTP 502 - Bad Gateway エラー が発生する可能性があります。 "HTTP 502 - Bad Gateway" は、Nginx がバックエンド ASP.NET Core アプリケーションと通信できなかったことを意味します。 これは、バックエンド アプリケーションが実行されていない場合に発生します。
この場合、次のようになります。
- 両方の ASP.NET Core アプリケーションが異なるポートでリッスンしていることを確認します。 1 つはポート 5000 でリッスンし、もう 1 つはポート 5001 でリッスンする必要があります。
- 両方の ASP.NET Core アプリケーションが自動的に起動するように構成されていることを確認します。
systemctl statusコマンドを使用している ASP.NET Core アプリケーション サービスの状態を確認します。 実行されていない場合は、journalctlコマンドを実行してシステム ログを調べてトラブルシューティングを行います。syslogIdentifierを使用してログをフィルター処理します。- .NET Core 3.1 と .NET 5.0 の両方がインストールされていることを確認します。 1 つのサイトでは .NET Core 3.1 が使用され、もう 1 つのサイトでは .NET 5.0 が使用されます。