チュートリアル: NGINX と NGINX Plus を使用した .NET Core と Kestrel のプロキシ

説明書

次の手順では、.NET Core を使用して「Hello World」アプリをすばやく構築し、Linux 上で実行し、高度なトラフィック管理機能を備えた NGINX または NGINX Plus リバースプロキシの背後にデプロイする方法について説明します。

.NET Core、NGINX、NGINX Plus をインストールする

Microsoft Web サイトの指示に従って .NET Core をインストールします。

この例では、Ubuntu 16.04 を使用しています。以下のコマンドは執筆時点では正しいものですが、Kestrel はまだ開発中のため変更される可能性があります。必要に応じて.NET Core のドキュメントを参照してください。

$ sudo apt-get install apt-transport-https $ sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ xenial main" > /etc/apt/sources.list.d/dotnetdev.list' $ sudo apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893 $ sudo apt-get update $ sudo apt-get install dotnet-dev-1.0.0-preview2-003131

NGINX をインストールします。

$ sudo apt-get nginxをインストール

ライブアクティビティの監視、アクティブなヘルスチェック、またはその両方が必要な場合は、NGINX Plus をインストールします。 NGINX Plus 管理者ガイドの手順を参照してください。

./project.jsonファイルを編集して、Kestrel をプロジェクトの依存関係として追加します。

{ "バージョン": "1.0.0-*", "buildOptions": { "debugType": "portable", "emitEntryPoint": true }, "dependencies": {}, "frameworks": { "netcoreapp1.0": { "dependencies": { "Microsoft.NETCore.App": { "type": "platform", "version": "1.0.1" } 、 "Microsoft.AspNetCore.Server.Kestrel": "1.0.0" }, "imports": "dnxcore50" } } }

シンプルなアプリのこのコードをProgram.csという新しいファイルにコピーします。ローカルホストのポート 5000 で Kestrel を実行して、現在の日付と時刻を返します。

System を使用します。Microsoft.AspNetCore.Builder を使用します。
Microsoft.AspNetCore.Hosting を使用します。
Microsoft.AspNetCore.Http を使用します。

名前空間 ConsoleApplication
{
パブリック クラス Program
{
パブリック 静的 void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.Configure(app =>
{
app.Run(async (context) => await context.Response.WriteAsync("現在の日付: " + DateTime.Now + "n"));
})
.Build();

host.Run();
}
}
}

dotnet runコマンドを実行して .NET Core サーバーを起動します。

$ dotnet run入力が変更されたため、プロジェクト アプリ (.NETCoreApp、バージョン = v1.0) がコンパイルされます。.NETCoreApp、バージョン = v1.0 のアプリをコンパイルしています。コンパイルは成功しました。
    警告 0 件、エラー 0 件、経過時間 00:00:01.9047678 Hello World!
ホスティング環境: 本番コンテンツのルート パス: /app/bin/Debug/netcoreapp1.0 現在リッスン中: http://localhost:5000 アプリケーションが開始されました。 シャットダウンするにはCtrl+Cを押します。

curlコマンドを実行して接続と HTTP をテストします。

$ curl -v localhost:5000 * URL を再構築: localhost:5000/ * ::1 を試行中... * localhost (::1) ポート 5000 (#0) に接続しました > GET / HTTP/1.1 > ホスト: localhost:5000 > ユーザーエージェント: curl/7.47.0 > Accept: */* > < HTTP/1.1 200 OK < 日付: 2017年2月14日火曜日 19:50:59 GMT < 転送エンコーディング: チャンク < サーバー: ケストレル < 現在の日付: 02/14/17 12:50:59 PM * ホスト localhost への接続 #0 はそのまま残ります

SSL 証明書をインストールします。取得方法はいくつかあります:
- よく知られた認証局（CA）から購入する
- 企業のITグループまたはCAに生成してもらう
- 既存のIISサーバーからエクスポートする
- Let's Encryptのような無料のCAを使用する
- 自己署名証明書を直接生成する
SSL を使用したサンプル .NET Core アプリをすぐに起動できるように、このopensslコマンドを使用して自己署名証明書と関連キーを生成します。証明書とキーは NGINX の標準の場所である/etc/nginxにインストールしますが、別の場所を選択することもできます。
```
$ openssl req -x509 -subj /CN=localhost -days 365 -set_serial 2 -newkey rsa:4096 -keyout /etc/nginx/cert.key -nodes -out /etc/nginx/cert.pem 4096 ビットの RSA 秘密鍵を生成しています .........++ ............................++ 新しい秘密鍵を '/etc/nginx/cert.key' に書き込みます -----
```
HTTP 仮想サーバーのデフォルトの NGINX および NGINX Plus 構成ファイルでリバースプロキシを構成します。

NGINX および NGINX Plus の主な設定ファイルは/etc/nginx/nginx.confです。ただし、いくつかの NGINX ディストリビューション (および NGINX Plus) では、メインファイルに実際の設定をあまり置かず、代わりに/etc/nginxのサブディレクトリに小さな機能固有のファイルを作成するという規則に従います。
- nginx.orgによって提供される NGINX オープンソースビルドおよび NGINX Plus の場合、ディレクトリは/etc/nginx/conf.dで、HTTP 仮想サーバーのデフォルトファイルはdefault.confです。
- Ubuntu で配布される NGINX オープンソースビルドの場合、ディレクトリは/etc/nginx/sites-enabled で、HTTP 仮想サーバーのデフォルトファイルはdefaultです。
これらのディレクトリ内の関数固有のファイルの内容は、 includeディレクティブを使用してメイン ( nginx.conf ) ファイルに読み込まれます。次に例を示します。
```
/etc/nginx/conf.d/*.conf を含めます。/etc/nginx/sites-enabled/* を含めます。
```
システム上の HTTP 仮想サーバーのデフォルト設定ファイルがどれかわからない場合は、 /etc/nginx/nginx.confで関連するincludeディレクティブを見つけてください。

NGINX または NGINX Plus をリバースプロキシとして設定するには、HTTP 仮想サーバーのデフォルト設定ファイルに次の 3 つの設定ブロックを追加します。
- 最初のサーバーブロックは、ポート 80 で HTTP 要求を受け入れ、HTTPS 要求の仮想サーバーにリダイレクトします。
- 2 番目のサーバーブロックは、ポート 443 で HTTPS 要求を受け入れ、それらを 1 つ以上のアップストリーム (バックエンド) サーバー (ここではdotnetと呼ばれます) のグループにプロキシします。 (手順 1 で自己署名 SSL 証明書を/etc/nginx以外のディレクトリにインストールした場合は、 ssl_certificateおよびssl_certificate_keyディレクティブで正しいパスを置き換えます。)
- アップストリームブロックは、バックエンドサーバーのdotnetグループを定義します。
  
  Kestrel HTTP サーバーの実行では、 localhost:5000で Kestrel を構成しました。つまり、そのポートで IPv4 と IPv6 の両方のトラフィックをリッスンすることになります。（Kestrelを1つのプロトコルのみに設定すると、不安定になり、潜在的に502エラー。同様に、NGINX と NGINX Plus は、 localhost をIPv4 アドレスと IPv6 アドレスの両方 (127.0.0.1 と ::1) に解決します。簡単にするために、ここでは上流サーバーを次のように識別します。127.0.0.1 localhostではなく、IPv4 トラフィックのみをリッスンします。 IPv6 を含むより高度な構成に慣れている場合は、 localhost を使用できます。
```
server { listen 80 default_server;
listen [::]:80 default_server;
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;

ssl_certificate /etc/nginx/cert.pem;
ssl_certificate_key /etc/nginx/cert.key;

location / {
proxy_pass http://dotnet;
proxy_set_header Host $host;
}
}

upstream dotnet {
zone dotnet 64k;
server 127.0.0.1:5000;
}
```
このcurlコマンドを実行して、HTTPS 経由で .NET Core アプリへの接続をテストします。 (代わりにブラウザを Linux サーバーに向けることもできます。)
```
$ curl -kv https://localhost * URL を https://localhost/ に再構築しました * ::1 を試行しています... * localhost (::1) ポート 443 (#0) に接続しました...[スキップされました]... < HTTP/1.1 200 OK < サーバー: nginx/1.10.0 (Ubuntu) < 日付: 2017年2月14日火曜日 20:22:07 GMT < 転送エンコーディング: chunked < 接続: keep-alive < 現在の日付: 2017年2月14日午後1時22分07秒
```
注記： もしあなたが502不正なゲートウェイエラーは、NGINX または NGINX Plus が .NET アプリケーションに接続できないことを意味します。ポート 5000 で実行され、応答が返されていることを確認します。

nghttp2パッケージをインストールしている場合は、次のnghttpコマンドを実行して HTTP/2 経由の接続をテストすることもできます。次の例では、かなり長い出力の先頭付近にある、オレンジ色で強調表示された行を探します。
```
$ nghttp -v https://localhost [ 0.000] 接続済みネゴシエートされたプロトコル: h2 [ 0.009] SETTINGS フレームを送信 (niv=2) [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100] [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535] [ 0.009] PRIORITY フレームを送信 (dep_stream_id=0、weight=201、exclusive=0)
```

応答コードは200わかりました
アプリサーバーはKestrelであり、他のソフトウェアではない
応答の本文には「現在の日付」という語句が含まれています
アプリは1秒のタイムアウト期間内に応答します

「Hello World」アプリを実行する

任意の親ディレクトリに「Hello World」アプリをインストールして初期化します。

$ cdアプリの親ディレクトリ$ mkdir アプリ$ cd アプリ$ dotnet 復元

アプリが動作していることを確認するには、 dotnet runコマンドを実行します。

Kestrel HTTPサーバーを実行する

この時点で、.NET Core は Linux 上で実行されており、HTTP サーバーとして Kestrel を使用して動的データを提供しています。

NGINX または NGINX Plus を設定して .NET アプリケーションをリバースプロキシする

NGINX または NGINX Plus を .NET アプリケーションのリバースプロキシとして使用すると、SSL/TLS、HTTP/2 サポート、およびその他の多くの機能を使用してセキュリティを簡単に構成し、.NET Core アプリケーションが実行されているのと同じマシンでアプリケーションを高速に配信できます。以下の手順では、NGINX と NGINX Plus がすでにシステムにインストールされていることを前提としています。インストールされていない場合は、「.NET Core、NGINX、NGINX Plus のインストール」を参照してください。

NGINX Plus ライブアクティビティモニタリングとアクティブヘルスチェックを構成する

この時点で、.NET Core を使用した NGINX または NGINX Plus の基本的な構成は完了です。 NGINX または NGINX Plus は、.NET Core アプリに HTTP 処理、パッシブヘルスチェック、SSL/TLS によるセキュリティ、HTTP/2 接続を提供します。

NGINX Plus をインストールしている場合は、ライブアクティビティモニタリングとアクティブヘルスチェックという 2 つの追加機能を構成できます。

ライブアクティビティモニタリングを構成する

[編集者 – このセクションは、NGINX Plus APIを参照するように更新されました。NGINX Plus API は、ここで最初に説明した個別の拡張 Status モジュールを置き換え、廃止します。]

HTTP 仮想サーバーのデフォルトの NGINX 構成ファイルに次のサーバーブロックを追加します。統計情報と指標へのアクセスを制限することを強くお勧めします。ここでは、ローカルホストおよびローカルネットワーク上のユーザーのみにアクセスを許可します。

ライブアクティビティモニタリングの詳細については、弊社のブログの「3 つの簡単な手順で NGINX Plus のライブアクティビティをモニタリングする」およびNGINX Plus 管理者ガイドを参照してください。

server { listen 8080;
allow 127.0.0.1; # ローカルホストが統計情報にアクセスできるようにします
allow 10.3.3.0/24; # ローカルネットワークが統計情報にアクセスできるようにします
deny all; # 他の場所からのアクセスを禁止します

root /usr/share/nginx/html;

location / {
return 302 /dashboard.html;
}

location /api {
api write=on;
}

location = /dashboard.html {
root /usr/share/nginx/html;
}

# 古いダッシュボードへのリクエストをリダイレクトします
location = /status.html {
return 301 /dashboard.html;
}
}

アクティブヘルスチェックを構成する

アクティブヘルスチェックにより、NGINX Plus は正常に動作しているアプリケーションにのみトラフィックを送信することが保証されます。 NGINX Plus がアプリに定期的に送信する HTTP リクエストと、アプリが正常であると判断するために返す必要がある応答のタイプを定義します。

ここでは、アプリからの応答が次の条件を満たす必要があります。

HTTP 仮想サーバーのデフォルト構成ファイルで、メインサーバーブロック ( 「.NET アプリケーションをリバースプロキシするように NGINX または NGINX Plus を構成する」の手順 2 で定義された HTTPS トラフィックのブロック) に次のロケーションブロックを追加します。

場所 @healthcheck { proxy_pass http://dotnet;
proxy_set_header Host localhost;
health_check match=currentdate;
proxy_connect_timeout 1s;
proxy_read_timeout 1s;
}

また、サーバーブロックおよびアップストリームブロックと同じ階層レベルに次の一致ブロックを追加します。

現在の日付と一致 { ステータス 200;
ヘッダー Server = Kestrel;
本文 ~ "現在の日付";
}

組み込みのライブアクティビティモニタリングダッシュボードのUpstreamsタブで、バックエンドアプリが正常であることを確認できます (ブラウザーで//http:// nginx-plus-server-address :8080/を指定します)。

NGINX Plusのライブアクティビティ監視ダッシュボードは、NGINXがプロキシしているバックエンドの.NETアプリケーションの健全性を報告します。

NGINX 構成オプションの詳細については、 Microsoft のドキュメントを参照してください。

結論

ASP.NET を使用して開発したアプリを本番環境向けに展開する場合、NGINX と NGINX Plus はリバースプロキシに必要なトラフィック管理機能を提供します。 NGINX と NGINX Plus は、.NET Core アプリケーションへの HTTP リクエストのセキュリティ、スケーラビリティ、認証、トラフィック制限、インテリジェントなルーティングを提供します。

NGINX Plus を実際にお試しいただくには、今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、使用事例についてご相談ください。

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"

検索結果の提案

チュートリアル: NGINX と NGINX Plus を使用した .NET Core と Kestrel のプロキシ

説明書

.NET Core、NGINX、NGINX Plus をインストールする

「Hello World」アプリを実行する

Kestrel HTTPサーバーを実行する

NGINX または NGINX Plus を設定して .NET アプリケーションをリバースプロキシする

NGINX Plus ライブアクティビティモニタリングとアクティブヘルスチェックを構成する

ライブアクティビティモニタリングを構成する

アクティブヘルスチェックを構成する

結論

安全で優れたデジタル体験を提供する

チュートリアル: NGINX と NGINX Plus を使用した .NET Core と Kestrel のプロキシ

説明書

.NET Core、NGINX、NGINX Plus をインストールする

「Hello World」アプリを実行する

Kestrel HTTPサーバーを実行する

NGINX または NGINX Plus を設定して .NET アプリケーションをリバース プロキシする

NGINX Plus ライブアクティビティモニタリングとアクティブヘルスチェックを構成する

ライブアクティビティモニタリングを構成する

アクティブヘルスチェックを構成する

結論

安全で優れたデジタル体験を提供する

F5の情報を入手

NGINX または NGINX Plus を設定して .NET アプリケーションをリバースプロキシする