Azure App Service 向けの ASP.NET Core アプリを構成する
Note
.NET Framework での ASP.NET については、「Azure App Service 向けの ASP.NET アプリを構成する」を参照してください ASP.NET Core アプリが Windows または Linux のカスタム コンテナーで実行される場合は、「Azure App Service のカスタム コンテナーを構成する」をご覧ください。
ASP.NET Core アプリは、コンパイル済みバイナリとして Azure App Service にデプロイする必要があります。 Visual Studio 発行ツールではソリューションがビルドされてからコンパイル済みバイナリが直接デプロイされますが、App Service 展開エンジンではまずコード リポジトリがデプロイされ、その後にバイナリがコンパイルされます。
このガイドでは、ASP.NET Core 開発者向けに主要な概念と手順を説明します。 Azure App Service を初めて使用する場合は、まず ASP.NET Core クイックスタートと ASP.NET Core と SQL Database のチュートリアルに従ってください。
サポートされている .NET Core ランタイム バージョンを表示する
App Service でサポートされているすべての .NET Core バージョンが Windows インスタンスに既にインストールされています。 使用可能な .NET Core ランタイムと SDK のバージョンを表示するには、https://<app-name>.scm.azurewebsites.net/DebugConsole に移動し、ブラウザーベースのコンソールで次のコマンドを実行します。
dotnet --info
.NET Core バージョンを表示する
現在の .NET Core バージョンを表示するには、Cloud Shell で次のコマンドを実行します。
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
サポートされているすべての .NET Core バージョンを表示するには、Cloud Shell で次のコマンドを実行します。
az webapp list-runtimes --os linux | grep DOTNET
.NET Core バージョンを設定する
ASP.NET Core プロジェクトのプロジェクト ファイルにターゲット フレームワークを設定します。 詳細については、.NET Core ドキュメントの「使用する .NET Core バージョンを選択する」を参照してください。
.NET Core バージョンを 3.1 に設定するには、Cloud Shell で次のコマンドを実行します。
az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|3.1"
ビルドの自動化のカスタマイズ
Git を使用するか、ビルドの自動化を有効にした zip パッケージを使用してアプリをデプロイする場合、App Service のビルドの自動化によって、次の手順が実行されます。
PRE_BUILD_SCRIPT_PATHによって指定された場合、カスタム スクリプトを実行します。dotnet restoreを実行して、NuGet の依存関係を復元します。dotnet publishを実行して、運用環境用のバイナリを構築します。POST_BUILD_SCRIPT_PATHによって指定された場合、カスタム スクリプトを実行します。
PRE_BUILD_COMMAND および POST_BUILD_COMMAND は、既定では空の環境変数です。 ビルド前のコマンドを実行するには、PRE_BUILD_COMMAND を定義します。 ビルド後のコマンドを実行するには、POST_BUILD_COMMAND を定義します。
次の例では、一連のコマンドに対して 2 つの変数をコンマ区切りで指定しています。
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PRE_BUILD_COMMAND="echo foo, scripts/prebuild.sh"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings POST_BUILD_COMMAND="echo foo, scripts/postbuild.sh"
ビルドの自動化をカスタマイズするためのその他の環境変数については、「Oryx の構成」を参照してください。
Linux 上で App Service によって ASP.NET Core アプリが実行されビルドされる方法に関する詳細については、Oryx ドキュメントの .NET Core アプリが検出されビルドされる方法に関するページを参照してください。
環境変数へのアクセス
App Service では、アプリ コードの外部でアプリ設定を指定できます。 次に、標準の ASP.NET Core 依存関係の挿入パターンを使用して、任意のクラスでこれらにアクセスできます。
using Microsoft.Extensions.Configuration;
namespace SomeNamespace
{
public class SomeClass
{
private IConfiguration _configuration;
public SomeClass(IConfiguration configuration)
{
_configuration = configuration;
}
public SomeMethod()
{
// retrieve nested App Service app setting
var myHierarchicalConfig = _configuration["My:Hierarchical:Config:Data"];
// retrieve App Service connection string
var myConnString = _configuration.GetConnectionString("MyDbConnection");
}
}
}
たとえば、App Service と appsettings.json で同じ名前のアプリ設定を構成した場合は、App Service の値が appsettings.json の値よりも優先されます。 ローカルの appsettings.json 値ではアプリをローカルでデバッグできますが、App Service の値では実稼働設定の実稼働でアプリを実行できます。 接続文字列は同じように機能します。 これにより、コード リポジトリの外部にアプリケーション シークレットを保存し、コードを変更することなく適切な値にアクセスできます。
Note
appsettings. json の階層型の構成データは、Linux から .NET Core で標準の __ (ダブルアンダースコア) 区切り記号を使用してアクセスすることに注意してください。 App Service で特定の階層型構成設定をオーバーライドするには、キーにアプリ設定名を同じ区切り形式で設定します。 Cloud Shell で次の例を実行できます。
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My__Hierarchical__Config__Data="some value"
注意
appsettings. json の階層型の構成データは、.NET Core に標準の : 区切り記号を使用してアクセスされることに注意してください。 App Service で特定の階層型構成設定をオーバーライドするには、キーにアプリ設定名を同じ区切り形式で設定します。 Cloud Shell で次の例を実行できます。
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My:Hierarchical:Config:Data="some value"
マルチ プロジェクト ソリューションをデプロイする
Visual Studio ソリューションに複数のプロジェクトが含まれている場合、Visual Studio の発行プロセスには、デプロイするプロジェクトの選択が既に含まれています。 ビルド自動化を有効にした状態で、Git や ZIP デプロイなどを使用して App Service 展開エンジンにデプロイすると、App Service 展開エンジンは、App Service アプリとして検出された最初の Web サイトまたは Web アプリケーション プロジェクトを選択します。 PROJECT アプリ設定を指定することで、App Service で使用するプロジェクトを指定できます。 たとえば、 Cloud Shell で次のコマンドを実行します。
az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PROJECT="<project-name>/<project-name>.csproj"
診断ログにアクセスする
ASP.NET Core には、App Service 用の組み込みのログ プロバイダーが用意されています。 プロジェクトの Program.cs で、次の例に示すように、ConfigureLogging 拡張メソッドを使用してそのプロバイダーをアプリケーションに追加します。
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureLogging(logging =>
{
logging.AddAzureWebAppDiagnostics();
})
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
その後、標準の .NET Core パターンを使用して、ログを構成して生成できます。
App Service のアプリケーション コード内から生成されたコンソール ログにアクセスするには、Cloud Shell で次のコマンドを実行して、診断ログを有効にします。
az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose
--level で有効な値は、Error、Warning、Info、および Verbose です。 後続の各レベルには、前のレベルが含まれます。 たとえば、Error にはエラー メッセージのみが含まれ、Verbose にはすべてのメッセージが含まれます。
診断ログがオンになったら、次のコマンドを実行して、ログのストリームを確認します。
az webapp log tail --resource-group <resource-group-name> --name <app-name>
コンソール ログがすぐに表示されない場合は、30 秒以内にもう一度確認します。
Note
https://<app-name>.scm.azurewebsites.net/api/logs/docker で、ブラウザーからログ ファイルを検査することもできます。
任意のタイミングでログのストリーミングを停止するには、Ctrl+C と入力します。
App Service での ASP.NET Core アプリのトラブルシューティングの詳細については、「Azure App Service と IIS での ASP.NET Core のトラブルシューティング」を参照してください
例外の詳細ページを表示する
Visual Studio デバッガーで ASP.NET Core アプリの実行中に例外が発生すると、ブラウザーに例外の詳細ページが表示されますが、App Service ではそのページは汎用の HTTP 500 エラーまたは「要求の処理中にエラーが発生しました。」メッセージに置き換わります。 App Service で例外の詳細ページを表示するには、Cloud Shell で次のコマンドを実行してアプリ設定 ASPNETCORE_ENVIRONMENT をアプリに追加します。
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASPNETCORE_ENVIRONMENT="Development"
HTTPS セッションの検出
App Service では、TLS または SSL 終了がネットワーク ロード バランサーで発生するため、すべての HTTPS リクエストは暗号化されていない HTTP リクエストとしてアプリに到達します。 ユーザー要求が暗号化されるかどうかをアプリのロジックで認識する必要がある場合は、Startup.cs で Forwarded Headers Middleware を構成します。
Startup.ConfigureServicesで、X-Forwarded-ForヘッダーとX-Forwarded-Protoヘッダーを転送するように ForwardedHeadersOptions を使ってミドルウェアを構成します。- ミドルウェアが App Service のロード バランサーを信頼できるようにするために、既知のネットワークにプライベート IP アドレス範囲を追加します。
- 他のミドルウェアを呼び出す前に、
Startup.Configure内で UseForwardedHeaders メソッドを呼び出します。
3 つの要素をすべてまとめると、次の例のようなコードになります。
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
// These three subnets encapsulate the applicable Azure subnets. At the moment, it's not possible to narrow it down further.
options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:10.0.0.0"), 104));
options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:192.168.0.0"), 112));
options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:172.16.0.0"), 108));
});
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseForwardedHeaders();
...
app.UseMvc();
}
詳細については、「プロキシ サーバーとロード バランサーを使用するために ASP.NET Core を構成する」を参照してください。
ブラウザーで SSH セッションを開く
コンテナーとの直接 SSH セッションを開くには、アプリが実行されている必要があります。
ブラウザーに次の URL を貼り付け、<app-name> をお使いのアプリの名前に置き換えます。
https://<app-name>.scm.azurewebsites.net/webssh/host
まだ認証されていない場合、接続するには Azure サブスクリプションで認証する必要があります。 認証されると、ブラウザー内シェルが表示され、コンテナー内でコマンドを実行することができます。
Note
/home ディレクトリの外部で行ったすべての変更は、コンテナー自体に格納され、アプリの再起動後には保持されません。
ローカル コンピューターからリモート SSH セッションを開くには、「リモート シェルから SSH セッションを開く」を参照してください。
ログの robots933456
コンテナー ログで次のメッセージが表示されることがあります。
2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"
このメッセージは無視してかまいません。 /robots933456.txt は、コンテナーが要求を処理できるかどうかを調べるために App Service が使用するダミーの URL パスです。 404 応答は、パスが存在しないことを示すだけですが、コンテナーが正常であり、要求に応答できる状態であることを App Service に知らせます。
次のステップ
または、その他のリソースを参照してください。