適用対象: .NET Core 2.1、.NET Core 3.1、.NET 5
この記事では、2 つの ASP.NET Core アプリケーションをサイド バイ サイドで実行し、さまざまなポートでリッスンし、受信要求を処理する方法について説明します。
前提条件
チュートリアルのこの部分を完了するには、次の項目を設定する必要があります。
- .NET Core 3.1 SDK と .NET 5.0 SDK の両方がインストールされています。
- Nginx が自動的に実行され、ポート 80 で送信された要求をリッスンしています。
- リバース プロキシとして構成された Nginx と、すべての要求を ASP.NET Core アプリケーションにルーティングする (ポート 5000 でリッスンしています)。
- サーバーの再起動後またはプロセスの停止後に自動的に起動するように実行および構成されている 1 つの ASP.NET Core アプリケーション。
- SSH および HTTP トラフィックを許可するように有効および構成されている Linux ローカル ファイアウォール。
- /var/buggyamb_v1.1 ディレクトリにダウンロードおよび抽出されるコア アプリケーション ASP.NET バグのサンプル。
このシリーズで使用された最初の ASP.NET Core デモ アプリケーションは、ASP.NET Core 5.0 アプリケーションです。 2 つ目のアプリケーションは、ASP.NET Core 3.1 アプリケーションです。 .NET Core 3.1 SDK と .NET 5.0 SDK の両方がインストールされていない場合は、続行する前に不足している SDK をインストールしてください。
Note
dotnet --info コマンドを実行すると、インストールされているバージョンのランタイムと SDK を確認できます。 .NET Core のインストールについては、このシリーズの前の部分で説明しました。
このパートの目標
このパートの最後には、サイド バイ サイドで実行され、異なるポートでリッスンし、受信要求を処理する 2 つの ASP.NET Core アプリケーションが用意されています。
このパートで実行するアクションのほとんどは似ています。2 つ目の ASP.NET Core アプリケーション用のサービス ファイルを作成して、サーバーが再起動されたときやプロセスが停止するたびに開始できるようにします。
2 つ目のアプリケーションを実行する
実行されている最初のアプリケーションに似たサービスとして 2 つ目のアプリケーションを実行します。 サービス ファイルを作成する前に、正しく実行されていることを確認してください。
前の章では、テスト デバッグ アプリケーションを /var/buggyamb_v1.1/ ディレクトリにコピーし、 dotnet /var/buggyamb_v1.1/BuggyAmb.dll コマンドを使用してアプリケーションを実行するように指示されたことを思い出してください。 次のエラー メッセージを受け取ることがあります。
System.IO.IOException: アドレス
http://127.0.0.1:5000: 既に使用されているアドレスにバインドできませんでした。
このメッセージごとに、別のプロセスで既にポート 5000 が使用されています。 当たり前です。 しかし、どのプロセスがポートを使用しているかをどのように学習できますか? sudo netstat -tulpn | grep 5000 コマンドを実行します。 次のスクリーンショットでは、PID が 12536 され、プロセス名が dotnetされています。 ほとんどの場合、プロセス ID が異なることがわかります。
次の手順では、ポート 5000 でリッスンしている dotnet プロセスによってホストされているコア アプリケーション ASP.NET を理解します。 cat /proc/12536/cmdline コマンドを実行すると、次のスクリーンショットのような結果を取得できます。
これは、このシリーズで構成された最初の ASP.NET Core アプリケーションです。 ポート 5000 でリッスンしています。 そのため、新しい ASP.NET Core バグのあるアプリケーションは、同じポートでリッスンできません。
Note
ここで何か新しいことを学びました。 /proc という名前のディレクトリがあります。 このディレクトリの内容を一覧表示すると、その時点で実行されている各 PID の名前が付けられたディレクトリが表示されます。 各サブフォルダーには、コマンド ラインやメモリや CPU 情報など、各プロセスのプロパティを取得するために使用できるファイルがいくつかあります。 ここでは、ツールとプロセスについて説明するため、この点に焦点を当てないでください。
ポート競合の問題の解決策は、最初のアプリケーションの実行を停止することではありません。 目標は両方のアプリケーションを同時に実行することです。そのため、ソリューションは実際には別のポートで 2 つ目の ASP.NET Core アプリケーションを実行することです。
別のポートでリッスンするように第 2 ASP.NET Core アプリケーションを構成する
この目標を達成するには、さまざまな方法があります。
UseUrls()を使用して、Program.csでポートを設定します。これは、ポートがアプリケーションでハードコーディングされていることを意味します。 構成ファイルからポートを読み取ることができますが、アプリケーションを変更して再度コンパイルする必要はありません。 したがって、このトレーニングはこのソリューションに焦点を当てません。- コマンド ライン引数: アプリケーションの実行時に
--urlsパラメーターを使用します。 - 環境変数: 環境変数の使用をリッスンするための URL を設定します。 これを実現するには、
DOTNET_URLSまたはASPNETCORE_URLS環境変数の名前を使用します。
環境変数とコマンド ライン引数のどちらの方法も考慮する必要があるオプションです。 次のスクリーンショットに示すように、 --urls オプションをテストしてみてください。
目的は、サービスとしてアプリケーションを実行することです。 そのためには、環境変数を設定できるサービス ファイルが必要です。 前に示したように実行可能コマンドを設定することも、環境変数を設定することもできます。 次の例では、環境変数を使用して、代替ポートでリッスンするようにアプリケーションを構成します。
2 番目のアプリケーションのサービス ユニット ファイルを作成する
サービス ユニット ファイルでは、次のサービス定義を使用します。 2 番目のアプリケーションは、 /var/buggyamb_v1.1 ディレクトリで実行されることに注意してください。
Note
Environment=ASPNETCORE_URLS=http://localhost:5001行は、ASPNETCORE_URLSという名前の環境変数を宣言し、ポート 5001 でリッスンするようにアプリケーションに指示します。
[Unit]
Description=BuggyAmb is a really buggy application
[Service]
WorkingDirectory=/var/buggyamb_v1.1/
ExecStart=/usr/bin/dotnet /var/buggyamb_v1.1/BuggyAmb.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=buggyamb-identifier
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Development
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
Environment=ASPNETCORE_URLS=http://localhost:5001
[Install]
WantedBy=multi-user.target
サービス ファイル名は buggyamb.service になり、 /etc/systemd/system/ ディレクトリに作成されます。 前と同じように、vi エディターを使用し、 sudo vi /etc/systemd/system/buggyamb.service コマンドを実行してサービス定義ファイルを作成します。 この構成をコピーして貼り付け、保存します。 ここでも、 ASPNETCORE_URLS 環境変数を設定する方法に注意してください。
これで、デーモンとして実行するように、バグのある ASP.NET Core Web アプリケーションを構成しました。 これはトレーニングの開始時に述べたように目標を達成するのに十分ですか? sudo systemctl enable buggyamb.serviceコマンドとsudo systemctl start buggyamb.service コマンドを実行して、サービスを有効にして開始します。 次のスクリーンショットに示すように、 systemctl status buggyamb.serviceを実行してサービスの状態を確認します。
これで、BuggyAmb アプリケーションが期待どおりに動作するかどうかを確認できます。 次のスクリーンショットに示すように、 curl localhost:5001 コマンドを実行して、Console に[Welcome]\(バグ\) HTML のウェルカム ページが表示されるようにします。
アプリケーションはポート 5001 でリッスンしているため、クライアントからまだテストできません。 ファイアウォール設定では、このポートは許可されません。 Nginx はポートをインターネットに公開しないため、ポート 80 でリッスンするように Nginx を構成し、受信 HTTP 要求が特定のホスト名を使用して行われるときに、トラフィックを BuggyAmb にルーティングできます。 たとえば、ホスト名 ( http://buggyamb または http://buggyweb) を使用できます。 必要な他のホスト名を使用することもできます。
現時点では、2 つ目の ASP.NET Core アプリケーションを最初のデモ アプリケーションとサイド バイ サイドで実行することを目標としています。 次の章では、このパートで説明するように Nginx を引き続き構成します。