パート 2.3 - ASP.NET Core アプリケーションを自動的に起動するように構成する
適用対象: .NET Core 2.1、.NET Core 3.1、.NET 5
この記事では、ASP.NET Core アプリケーションを構成して、サーバーの再起動後にアプリケーションが自動的に起動されるようにする方法について説明します。
前提条件
このパートの演習に従うには、ASP.NET Core Web アプリケーションを Linux にインストールしてデプロイする必要があります。
また、ポート 80 からバックエンド ASP.NET Core アプリケーションに要求をルーティングするために、Nginx Web サーバーをリバース プロキシとして構成する必要があります。
このパートの目標
このシリーズの前の部分では、Nginx をリバース プロキシとして構成する方法と、HTTP 502 プロキシ エラーのトラブルシューティングを行う方法を示しました。 HTTP 502 応答コードの原因は、Nginx がトラフィックを転送しようとしたときに、バックエンド ASP.NET Core アプリケーションが実行されなかったことが原因です。
この問題は、ASP.NET Core アプリケーションを手動で実行することで一時的に解決されました。 しかし、アプリケーションがクラッシュした場合はどうでしょうか。 または、サーバーを再起動する必要がありますか? ASP.NET Core アプリケーションを毎回手動で再起動することは、実用的なソリューションではありません。 そのため、このセクションでは、アプリケーションがクラッシュした後に起動するように Linux を構成します。
ここまで、Nginx と ASP.NET Core が連携するように構成しました。 Nginx はポート 80 でリッスンし、ポート 5000 でリッスンする ASP.NET Core アプリケーションに要求をルーティングします。 Nginx は自動的に起動しますが、ASP.NET Core アプリケーションは、サーバーが再起動されるたびに手動で起動する必要があります。 それ以外の場合は、ASP.NET Core アプリケーションが正常に終了するか、クラッシュします。
IIS をプロキシとして使用して ASP.NET Core を実行すると、IIS ASP.NET Core Module (ANCM) によってプロセス管理が処理され、ASP.NET Core プロセスが自動的に開始されます。 もう 1 つのオプションは、Windows で ASP.NET Core をサービスとして実行して、コンピューターの起動後すぐに自動開始機能を構成できるようにすることです。
ASP.NET Core アプリケーションのサービス ファイルを作成する
"サービス" または "デーモン" の管理には、 systemctl
コマンドが使用されていることを思い出してください。 デーモンは、Windows サービスと同様の概念です。 このようなサービスは、システムの起動時に自動的に再起動できます。
サービス ファイルとは
Linux では、プロセスの終了時にデーモンの動作を制御するために使用される ".service" 拡張子を持つユニット構成ファイルもあります。 これらは、 service ファイル、 unit ファイル、および サービス ユニット ファイルとも呼ばれます。
これらのサービス ファイルは、次のいずれかのディレクトリにあります。
- /usr/lib/systemd/: ダウンロードしたアプリケーションのサービス ファイルを格納します
- /etc/systemd/system/: システム管理者によって作成されたサービス ファイルを格納します
Nginx サービス ファイルを調べます。 パッケージ マネージャーを使用してインストールされます。 その構成ファイルは、 /usr/lib/systemd/system/ フォルダーにある必要があります。 systemctl status nginx
コマンドを実行すると、サービス ファイルの場所も表示されます。
これは、Nginx サービス ファイルの外観です。
ASP.NET Core アプリケーションのサンプル サービス ファイル
次のユニット ファイルのコンテンツの例は、Nginx Host ASP.NET Core on Linux から取得します。
[Unit]
Description=Example .NET Web API App running on Ubuntu
[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
[Install]
WantedBy=multi-user.target
このコンテンツの重要な側面を次に示します。
WorkingDirectory
は、アプリケーションを発行するディレクトリです。ExecStart
は、アプリケーションを起動する実際のコマンドです。Restart=always
は自明です。 このプロセスは、手動またはクラッシュのどちらによっても、何らかの理由で停止した場合に常に開始されます。RestartSec=10
も自明です。 プロセスが停止すると、10 秒が経過した後に開始されます。SyslogIdentifier
が重要です。 "システム ログ識別子" を意味します。 デーモンに関する情報は、この名前でシステム ログに記録されます。 この識別子を使用して、プロセスの PID を見つけることもできます。User
は、サービスを管理するユーザーです。 システムに存在し、アプリケーション ファイルの適切な所有権を持っている必要があります。- サービス ファイルには、任意の数の環境変数を設定できます。
Note
www-data
ユーザーは、システム内の特別なユーザーです。 このアカウントを使用できます。 Linux でユーザーのアクセス許可を実践するための新しいユーザーを作成します。 ただし、別の Linux ユーザーを作成したくない場合は、 www-data
を使用しても問題ありません。
ASP.NET Core アプリケーションのサービス ファイルを作成する
vi
を使用して、サービス ファイルを作成および編集します。 サービス ファイルは、 /etc/systemd/system/ フォルダーに移動します。 このシリーズでは、最初のアプリケーションを /var/firstwebapp/ フォルダーに発行したことを覚えておいてください。 したがって、 WorkingDirectory はこのフォルダーを指す必要があります。
最終的な構成ファイルを次に示します。
[Unit]
Description=My very first ASP.NET Core applications running on Ubuntu
[Service]
WorkingDirectory=/var/firstwebapp/
ExecStart=/usr/bin/dotnet /var/firstwebapp/AspNetCoreDemo.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=myfirstapp-identifier
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Development
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
[Install]
WantedBy=multi-user.target
sudo vi /etc/systemd/system/myfirstwebapp.service
を実行し、最終的な構成を貼り付けて、ファイルを保存します。
これで、ASP.NET Core Web アプリケーションをデーモンとして実行するために必要な構成が完了します。
Web アプリケーションがサービスとして構成されたので、 systemctl status myfirstwebapp.service
を実行して状態を確認できます。 次のスクリーンショットに示すように、アプリケーションは無効になっており (システムの再起動後に自動的に開始されません)、現在実行中ではありません。
サービスを開始するには、 sudo systemctl start myfirstwebapp.service
コマンドを実行し、状態をもう一度確認します。 今回は、実行中のサービスが表示され、その横にプロセス ID が表示されます。 コマンド出力には、新しく作成されたサービスのシステム ログからの最後の数行も表示され、サービスが http://localhost:5000
リッスンしていることを示しています。
Web アプリケーションが予期せず停止した場合、10 秒後に自動的に再開されます。
最後の手順が 1 つあります。サービスは実行されていますが、有効になっていません。 "有効" は、サーバーの起動後に自動的に開始されることを意味します。 これが目的の最終的な構成です。 次のコマンドを実行して、サービスが有効になっていることを確認します。
sudo systemctl enable myfirstwebapp.service
これは、サーバーの再起動またはプロセスの終了後に自動的に開始するように構成されているため、ASP.NET Core アプリケーションのマイルストーンです。
コア アプリケーション ASP.NET 自動的に再起動するかどうかをテストする
次のパートに進む前に、すべてが期待どおりに動作していることを確認してください。 現在の構成は次のとおりです。
- Nginx は自動的に実行され、ポート 80 で送信された要求をリッスンします。
- Nginx はリバース プロキシとして構成され、ASP.NET Core アプリケーションに要求をルーティングします。 アプリケーションはポート 5000 でリッスンしています。
- ASP.NET Core アプリケーションは、サーバーの再起動後、またはプロセスが停止またはクラッシュした場合に自動的に起動するように構成されます。
そのため、ASP.NET Core サービスが停止するたびに、10 秒で再起動する必要があります。 この動作をテストするには、プロセスを強制的に停止します。 10 秒後に再び開始することが期待できます。
Note
ASP.NET Core アプリケーションの現在のプロセス ID。 ここで示されている試行のプロセス ID は、プロセスが強制終了される前に 5084 でした。 ASP.net Core アプリケーションのプロセス ID を見つけるには、 systemctl status myfirstwebapp.service
コマンドを実行します。
プロセスを強制的に停止するには、次のコマンドを実行します。
sudo kill -9 <PID>
Note
9
ここに信号の種類があります。 man
信号コマンドによると、9
はSIGKILL(キル信号)である。 このトピックの詳細については、"kill and signal" の man
コマンドを使用してヘルプ ページを開くことができます。
kill
コマンドの直後に systemctl status myfirstwebapp.service
コマンドを実行し、約 10 秒間待ってから、同じコマンドをもう一度実行します。
このスクリーンショットでは、次の情報を確認できます。
- 強制終了する前は、ASP.NET Core プロセスのプロセス ID は 5084 でした。
- サービスの状態は、PID 5084 を使用するプロセスが強制終了され、自動再起動が構成されているため再びアクティブ化されていることを示しました。
- 数秒後、新しいプロセス (PID 5181) が開始されました。
curl localhost
を使用してサイトにアクセスしようとすると、ASP.NET Core アプリケーションがまだ応答していることがわかります。
次のステップ
パート 2.3.1 - [省略可能] 別のユーザーで自動的に起動するように Linux で ASP.NET Core アプリケーションを構成する。