パート 2.2 - Nginx をインストールし、リバース プロキシ サーバーとして構成する
適用対象: .NET Core 2.1、.NET Core 3.1、.NET 5
この記事では、Nginx をインストールし、リバース プロキシ サーバーとして構成する方法について説明します。
このパートの演習に従うには、1 つの ASP.NET Core Web アプリケーションを作成し、 /var フォルダーにデプロイする必要があります。
前のパートでは、.NET CLI ツールを使用して ASP.NET Core Web アプリケーションを作成し、アプリケーションを /var フォルダーにデプロイしました。 また、HTTP 要求のポート 5000 でリッスンするようにアプリケーションが構成され、HTTPS リダイレクトが削除されました。
この時点で、クライアントはアプリケーションに接続するときにポート番号を指定する必要があります (たとえば、 http://localhost:5000)。 ただし、これは目的の動作ではありません。
このパートの目標は次のとおりです。
- クライアントは、ポート番号を指定しなくても移動できる必要があります。 たとえば、クライアントは
http://localhostを使用して接続する必要があります。 - 何らかの理由で停止した場合、またはコンピューターの再起動後に Web アプリケーションが自動的に起動します。
次のセクションでは、Nginx をプロキシ サーバーとして使用して、ポート 80 に対して行われた HTTP 要求を代わりに .NET アプリケーションにルーティングします。 また、自動的に起動するようにアプリケーションを構成します。
Nginx は、一般的で軽量で高速な Web サーバーです。 Linux と Windows の両方で実行でき、リバース プロキシ サーバーとして構成できます。
Nginx は、 daemon として実行されます。 デーモンは、バックグラウンドで実行されるサービスの代替用語です。 Windows で実行されるサービスと同様に、デーモンは起動時に自動起動するように構成できます。 デーモンとして実行するように ASP.NET Core アプリケーションを構成します。
Nginx のインストールは簡単です。 sudo apt install nginx コマンドを実行して、Ubuntu 仮想マシンにプログラムをインストールします。
インストールが完了したら、 whereis nginx を実行して、プログラムがインストールされている場所を検出します。 出力を調べることで、Nginx 構成ファイルが配置されている場所を確認できます。 次のスクリーンショットは、構成ファイルが /etc/nginx フォルダーにあることを示しています。
注意
Ubuntu または Debian 以外のディストリビューションを実行する場合は、同等のパッケージ マネージャーのインストール コマンドまたは手順については、 非公式の Nginx インストール ドキュメントを参照してください。
Nginx が実行されていることが表示されない場合は、 sudo systemctl start nginxを実行して明示的に開始できます。 この演習では Nginx の systemctl コマンドを示しますが、これらのコマンドを使用して、デーモンとして自動的に起動するように Web アプリケーションを構成します。
インストールが完了すると、Nginx は自動的に起動するように既に構成されています。 Nginx はデーモンとして実行されます。 デーモンの状態は、 systemctl を使用して確認できます。
systemctl コマンドは、サービスの状態の表示、サービスの開始と停止などのタスクの "サービス" を管理するために使用されます。 使用可能なパラメーターには、開始、停止、再起動、有効化、無効化、状態があります。 Nginx の状態を確認するには、 systemctl status nginxを実行します。
このコマンドを実行すると、有用な情報が生成されます。 このスクリーンショットに示すように、Nginx は active (running) 状態であり、Nginx インスタンスのプロセス ID は 8539 です。 また、 enabled ステートメントと vendor preset: enabled ステートメントにも注目してください。 Enabled は、マシンの再起動時にこのデーモンが起動することを意味し、 vendor preset: enabled は Nginx がインストールされたときに既定で有効になっていることを意味します。 そのため、サーバーの起動時に Nginx が自動的に起動します。
既定では、Nginx はポート 80 でリッスンします。 実行されているため、localhost を参照するときに Nginx のメイン ページにアクセスできる必要があります。 curlを使用して、curl localhostを実行して Nginx をテストします。 次のスクリーンショットの黄色で強調表示されたテキストは、Nginx の既定の Web ページを示しています。 したがって、Nginx は次を実行しています。
サービスまたはデーモンは、 systemctl コマンドを使用して管理できます。 変更を開始、停止、または変更するには、スーパーユーザー アクセスが必要です。 そのため、これらのコマンドに sudo プレフィックスを追加する必要があります。
デーモンの再起動が必要になる場合があります。 デーモンを再起動するには、 sudo systemctl restart <daemon_name>実行します。 Nginx を再起動するには、 sudo systemctl restart nginxを実行します。 プロセス ID への変更を監視するには、このコマンドを実行する前と実行後に Nginx の状態を確認してください。
デーモンを停止するには、 sudo systemctl stop <daemon_name>を実行します。 Nginx を停止するには、 sudo systemctl stop nginxを実行し、 systemctl status nginx をもう一度実行して Nginx の状態を確認します。 今回は、サービスは非アクティブ (配信不能) として表示されますが、引き続き有効になります。 つまり、サービスは実行されていませんが、サーバーの再起動後に自動的に開始されます。
注意
systemctl status コマンドには、デーモンの以前のログ エントリの数行も表示されます。
Nginx を停止した後、もう一度 curl localhost 実行します。
注意
ポート 80 の着信トラフィックを何もリッスンしていないため、接続は拒否されます。
デーモンの無効化は、デーモンの停止とは異なります。 無効になっているデーモンが実行されている可能性がありますが、サーバーの再起動後に自動的に起動することはありません。 Nginx デーモンを無効にするには、 sudo systemctl disable nginx実行し、Nginx の状態を確認します。
このスクリーンショットは、Nginx が実行されておらず、無効になっていることを示しています。 これは、再起動後に Nginx が自動的に起動しないことを意味します。
デーモンを起動するには、 sudo systemctl start <daemon_name>を実行します。 Nginx を開始するには、 sudo systemctl start nginxを実行し、サービスの状態をもう一度確認します。
このスクリーンショットは、Nginx が開始されているが、まだ無効になっていることを示しています。 サービスは実行中ですが、Nginx は無効なサービスであるため、再起動後に自動的に開始されません。
サービスを有効にすると、再起動後に自動的に開始されます。 Nginx を有効にするには、 sudo systemctl enable nginx実行し、Nginx の状態をもう一度確認します。
このスクリーンショットは、Nginx が実行されており、サーバーの再起動後に開始されることを示しています。
Nginx サービスを開始、停止、再起動する方法を学習したので、次に、ポート 80 で行われた要求をポート 5000 でリッスンしている ASP.NET Core アプリケーションにルーティングするように Nginx をリバース プロキシとして構成します。
必要な構成を次に示します。 重要な部分の一部が強調表示されています。
http {
map $http_connection $connection_upgrade {
"~*Upgrade" $http_connection;
default keep-alive;
}
server {
listen 80;
server_name _;
location / {
proxy_pass http://localhost:5000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
}
この構成は、次の内容を示します。
- Nginx は、すべての要求 (ディレクティブ:
listen 80) についてポート 80 でリッスンします。 - Nginx は要求を
http://localhost:5000にルーティングします (ディレクティブ:proxy_pass http://localhost:5000)
注意
コード内の server_name _ 行。 これは catch-all ディレクティブとして使用されます。 server_nameの詳細については、公式ドキュメントを参照してください。
構成の変更は簡単に表示されます。 このコードを使用して、構成ファイルの server ディレクティブ セクションを置き換えます。 しかし、構成ファイルはどこにありますか?
プライマリ Nginx 構成ファイルが /etc/nginx/nginx.conf。 構成を調べるには、 cat /etc/nginx/nginx.conf コマンドを使用し、サーバー ディレクティブを検索します。
構成をスクロールしてサーバー ディレクティブを見つけます。 見つからないと思うはずです。 必要な構成変更を構成ファイル内のどこかに配置できます。 ただし、元の構成ファイルを置き換えたくないのが理想的です。 これは、サーバーの正常な起動を妨げる可能性のある構成エラーの発生を防ぐためです。 serverセクションはメイン構成ファイルに含まれません。 構成ファイルをスクロールし続ける場合は、いくつかの include ディレクティブがあることがわかります。
インクルード ディレクティブを使用すると、メイン構成ファイルに含めるチャンクに分割することで、構成を管理しやすくなります。 メイン構成ファイルはシンプルに保ち、一部の特定の構成部分を他のファイルに移動できます。 このスクリーンショットで強調表示されている行は、次の内容を示しています。
- Nginx は、/etc/nginx/conf.d ディレクトリにある各 .conf ファイルから構成を読み込みます。
- Nginx は、 /etc/nginx/sites-enabled ディレクトリにある各ファイルから構成を読み込みます。
これらのディレクトリを調べると、 /etc/nginx/conf.d に構成ファイルが見つかりません。 ただし、 /etc/nginx/sites-enabled には 1 つのファイルがあります。
既定の構成ファイルは、探している構成をホストするための主要な候補のように見えます。 cat /etc/nginx/sites-enabled/defaultを使用して /etc/nginx/sites-enabled/default ファイルを調べると、既定のサーバー ディレクティブが次のコード内に配置されていることがわかります。
そのため、構成を変更するには、 /etc/nginx/sites-enabled/default ファイルを編集する必要があります。
Startup.cs ファイルを編集して、ASP.NET パイプラインから HTTPS リダイレクトを削除するときにファイルを編集する方法について説明しました。 ここで、vi をもう一度使用して nginx 構成ファイルを変更します。
ヒント
変更するファイルは常にバックアップしてください。 編集後に問題が発生した場合は、そのコピーを使用してファイルを以前の状態に復元できます。 この場合は、 cp /etc/nginx/sites-enabled/default ~/nginx-default-backup を実行して、構成ファイルをホーム ディレクトリにコピーします。 バックアップ ファイル名が nginx-default-backupされます。 バックアップが元のファイルと同じディレクトリに作成されなかったことに注意してください。 これは、Nginx がそのディレクトリからすべての構成ファイルを読み込み、2 つの異なるバージョンのサーバー ディレクティブを読み込んで構成を中断したくないためです。
次のスクリーンショットに示すように、 sudo vi /etc/nginx/sites-enabled/default を実行して構成ファイルを編集し、サーバー ディレクティブを置き換えます。
vi を使用してファイルを編集するためのヒントとテクニックを次に示します。
- 方向キーを使用して上下にスクロールできます。
- 編集モードにするには、 Insert または I キーを押します。 編集モードの間は、左下隅に --INSERT-- メッセージが表示されます。
- 編集モードでは、キーボードを使用して文字を一度に 1 つずつ削除できます。
- 編集モードでは、コピー操作と貼り付け操作がほとんどのターミナルと連携します。 そのため、この記事の内容をコピーして vi に貼り付けることができます。
- 編集モードを終了するには、 Esc キーを押します。
- 通常モードでは、より簡単に行を削除できます。 通常モードで、削除する行の先頭に移動し、「 dd」と入力します。
ddコマンドは、行全体を削除します。 5ddを入力して、一度に 5 行を削除することもできます。 ただし、このオプションは、追加のコンテンツを削除しないように注意して使用する必要があります。 - Vim / Viの記事で行を削除する方法 viで複数の行を削除する方法を学ぶのに適しています。
- vi を終了して変更を保存するには、「 :wq!」と入力し、 Enter キーを押します。 ここで、コロン (
:) はコマンドを実行していることを意味し、wは変更を書き込み、qは終了を意味し、!は変更をオーバーライドすることを意味します。 - 変更を保存せずに終了するには、「 :q!」と入力し、 Enter キーを押します。
変更が保存され、これらの変更を有効にするには Nginx サービスを再起動する必要があります。 サービスを再起動する前に、 sudo nginx -t コマンドを実行して構成ファイルをテストできます。 このコマンドを実行すると、Nginx は構成ファイルの構文を確認し、構成ファイルで参照されているファイルを開こうとします。
ここでわかるように、変更された構成ファイルは正しいように見えます。
変更を有効にするには、Nginx を再起動する必要があります。
sudo systemctl restart nginx
再起動後、http://localhost への要求を行うときに、ASP.NET Core アプリケーションからの応答が表示されます。Nginx はポート 80 に対する要求のリバース プロキシとして機能する必要があるためです。
変更を有効にするには Nginx サービスを再起動し、 curl localhostを実行して localhost に要求を行います。 ただし、このコマンドは失敗します。 次の手順では、 wget localhostを実行し、問題の原因に関するいくつかのヒントを検索します。
前のスクリーンショットでは、次の情報が表示されます。
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 502 Bad Gateway
2020-12-27 21:15:53 ERROR 502: Bad Gateway.
1 行目と 2 行目は、localhost を解決し、 127.0.0.1:80 ソケットで接続できることを示しています。 したがって、Nginx が実行されている必要があります。 これを確認するには、 systemctl status nginx コマンドを実行します。
3 行目は、問題の原因を示します。 HTTP 502 無効なゲートウェイエラー メッセージが表示されます。 HTTP 502 Bad Gateway はプロキシに関連しています。 これは、リバース プロキシがバックエンド アプリケーションに接続できなかったことを意味します。 この場合は、ASP.NET Core Web アプリケーションが実行され、ポート 5000 で要求をリッスンしている必要があります。 Web アプリケーションも実行されているかどうかを確認する必要があります。
トラブルシューティングを開始するには、前と同じ netstat コマンドを実行します。 今回は、grep を使用してアプリケーションのポート 5000 をフィルター処理します。 次に、netstat -tlp | grep 5000 を実行します。
このサンプル出力は、ポート 5000 で何もリッスンしていないことを示しています。 したがって、これは、ポート 5000 でリッスンしているプロセスが見つからないため、Nginx からの HTTP 502 応答の原因です。
解決策は、ASP.NET Core アプリケーションを起動することです。 ただし、先に進む前に、この問題をトラブルシューティングするための別の方法を確認できます。 すべての問題が、数行のログ コンテンツを見て根本原因を見つけるのと同じくらい簡単に修正できるわけではありません。 場合によっては、他のシステム ログとアプリケーション ログを詳しく調べる必要があります。
Linux で ASP.NET Core アプリケーションを設定するときに Nginx と密接に連携するため、Nginx とオペレーティング システムがトラブルシューティングのために提供するログの種類を学習することをお勧めします。
cat /etc/nginx/nginx.confをもう一度実行し、logging settingsを探すと、次のことがわかります。
これは、Nginx にアクセス ログとエラー ログの 2 種類のログがあることを示しています。 これらは、 /var/log/nginx/ ディレクトリに格納されます。
アクセス ログは IIS ログ ファイルに似ています。 コンテンツを簡単に検査すると、次のスクリーンショットのようになります。
アクセス ログには、既に知っていた HTTP 502 応答状態以外の新しい情報は表示されません。 cat /var/log/nginx/error.logを実行してエラー ログを調べることもできます。 これらは、問題の原因についてさらに多くを明らかにします。
Nginx はクライアントから要求を取得できますが、http://127.0.0.1:5000のupstream サーバーと、そのポートで実行されリッスンしている必要がある ASP.NET Core アプリケーションに接続することはできません。
この問題を回避するには、ASP.NET Core アプリケーションを手動で起動します。 2 番目のターミナル セッションを使用してサーバーに接続し、前と同様に ASP.NET Core アプリケーションを実行します。
ASP.NET Core アプリケーションの実行中に、もう一方のターミナル セッションに切り替えて、同じ curl localhost コマンドを実行します。 これで、Nginx の背後で実行されている ASP.NET Core アプリケーションにアクセスできるようになりました。 次のスクリーンショットは、localhost に要求を行い、要求が Nginx によって処理され、バックエンド アプリケーションにルーティングされ、ASP.NET Core アプリケーションから応答を受信したことを示しています。
これで、Linux で実行されている ASP.NET Core アプリケーションのリバース プロキシとして動作するように Nginx を構成しました。
ただし、再起動後に ASP.NET Core アプリケーションが起動しない場合、結果は何になりますか? Web アプリケーションがクラッシュし、実行されていないことに気付くまで起動しない場合はどうなるでしょうか。 プロセスの終了を再起動するたびに、ASP.NET Core アプリケーションを起動する必要がありますか?
パート 2.3 - ASP.NET Core アプリケーションを自動的に起動するように構成する
サードパーティの情報に関する免責事項
この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。