私は、NGINX を実行している Azure ホスト VM 上で、systemd ベースのサービスとして実行されている .NET Core アプリを使用しています (VM は開発環境として稼働しています)。Azure DNS を使用して、サーバー IP を指す A レコードを設定しました。myapplication.mycompany.com
ブラウザーに指定されたホスト名 ( ) を入力すると、NGINX のウェルカム ページが表示されます。
アプリケーションのバージョン番号を返すはずの URL を入力すると、404 が表示されます。
myapplication.mycompany.com/version.txt
を実行するとsystemctl status myservicename
、.NET Core サービスが開始され、メイン サービスが次のように実行されていることがわかります。
CGroup: /system.slice/myservicename.service
└─...PID... /usr/bin/dotnet /var/aspnetcore/myservicename/myservice.dll
を見てみると/var/aspnetcore/myservicename/wwwroot
、ファイルがありますversion.txt
curl -v localhost:5000
302 found
を返すServer: Kestrel
ので、信じるKestrelがポート5000でサービスを提供していること
NGINXの設定を見ると生産VM (非常によく似たイメージで、.NET Core サービスの同等のインスタンスを実行しています) では、Kestrel に特別な接続を行っているようなものは見当たりません。次のコマンドを使用して NGINX 構成を確認します。
cat /etc/nginx/nginx.conf
cat /etc/nginx/conf.d
(これらのファイルは開発 VM 上のファイルと同一です)
.NET Core アプリへのリクエストをルーティングするための構成を確認するには、どこを確認すればよいですか? また、リクエスト時に 404 の原因となる明らかなものはありますか...hostname.../version.txt
?
アップデート
NGINX Web サーバーにはいくつかの主要な設定があることがわかったので/etc/nginx/sites-available/default
、ホスト名と一致するサーバー名の設定を追加しました。
server {
listen 80;
server_name myapplication.mycompany.com;
訪問すると、myapplication.mycompany.com/version.txt
まだ次のメッセージが表示されます404
:
答え1
ウェブサイトの可用性を決定する 2 つの設定ファイルがあることがわかりました。
/etc/nginx/sites-available/default
/etc/nginx/sites-enabled/default
どちらも、NGINX サーバー上で利用可能かつ有効になっている Web サイトを判別するために、同様のルーティングを構成する必要があります。
両方の構成ファイルでは、NGINX がリクエストをリッスンするために使用するポート (80) を設定し、Azure DNS ホスト名を NGINX Web サーバーにリンクする server_name を設定します。
server {
listen 80;
server_name myapplication.mycompany.com;
この構成では、リクエストがKestrelにリバースプロキシ(基本的には「転送」)される方法も決定され、リクエストは.NET Core MVCルーティングを介してアプリによって処理されます。
location / {
... cacheing stuff
proxy_pass <http://localhost:5000;>