注
.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 のバージョンを確認するには、Kudu サイトに移動します。
Azure portal でアプリに移動し、 開発ツール>Advanced Tools を選択します。 [Go] \(移動) を選択します。 Kudu で、CMD または PowerShell のデバッグ コンソールを選択します。
ブラウザー ベースのコンソールで次のコマンドを実行します。
dotnet --info
.NET Core バージョンを表示する
現在の .NET Core バージョンを表示するには、 Azure 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 バージョンを 8.0 に設定するには、 Cloud Shell で次のコマンドを実行します。
az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|8.0"
App Service の古いランタイムはどうなりますか?
古いランタイムは、保守組織によって非推奨になったり、重大な脆弱性が見つかったりします。 そのため、ポータルの作成ページと構成ページから削除されます。 古いランタイムがポータルから非表示になっている場合、そのランタイムをまだ使用しているアプリは引き続き実行されます。
ポータルに表示されなくなった古いランタイム バージョンのアプリを作成する場合は、Azure CLI、ARM テンプレート、または Bicep を使用します。 これらのデプロイの代替手段を使用すると、ポータルで削除されたが、引き続きサポートされている非推奨のランタイムを作成できます。
ランタイムが App Service プラットフォームから完全に削除された場合、Azure サブスクリプション所有者は削除前に電子メール通知を受け取ります。
ビルド オートメーションのカスタマイズ
ビルド自動化を有効にして Git または ZIP パッケージを使用してアプリをデプロイする場合、App Service ビルドの自動化は次の順序に従います。
-
PRE_BUILD_SCRIPT_PATH
によって指定された場合、カスタム スクリプトを実行します。 - NuGet の依存関係を復元するには、
dotnet restore
を実行します。 - 運用環境用のバイナリをビルドするには、
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 の値を使用すると、運用設定を使用して運用環境でアプリを実行できます。 接続文字列も同じように機能します。 このメソッドを使用すると、コード リポジトリの外部にアプリケーション シークレットを保持し、コードを変更せずに適切な値にアクセスできます。
注
接続シークレットを必要としない、より安全な接続オプションを検討することもできます。 詳細については、「Azure App Service から Azure サービスとデータベースへの安全な接続」を参照してください。
の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 で特定の階層型構成設定をオーバーライドするには、キーにアプリ設定名を同じ区切り形式で設定します。
Azure 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 などの App Service デプロイ エンジンにデプロイする場合、または ビルドオートメーションを有効にした ZIP デプロイでは、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 秒後にもう一度確認してください。
ログ ストリーミングをいつでも停止するには、Ctrl+ キーを押します。
App Service のコア アプリ ASP.NET トラブルシューティングの詳細については、「 Azure App Service と IIS での ASP.NET Core のトラブルシューティング」を参照してください。
詳細な例外ページにアクセスする
ASP.NET Core アプリが Visual Studio デバッガーで例外を生成すると、ブラウザーに詳細な例外ページが表示されますが、App Service では、そのページは汎用の "HTTP 500" または "要求の処理中にエラーが発生しました" に置き換えられます。App Service で詳細な例外ページを表示するには、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 を構成します。
-
ForwardedHeadersOptions
でミドルウェアを構成して、X-Forwarded-For
でX-Forwarded-Proto
およびStartup.ConfigureServices
ヘッダーを転送します。 - ミドルウェアが App Service のロード バランサーを信頼できるようにするために、既知のネットワークにプライベート IP アドレス範囲を追加します。
- 他のミドルウェアを呼び出す前に、
UseForwardedHeaders
でStartup.Configure
メソッドを呼び出します。
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 を構成する」を参照してください。
URL の書き換えまたはリダイレクトを行う
URL を書き換えたりリダイレクトしたりするには、 ASP.NET Core で URL 書き換えミドルウェアを使用します。
ブラウザーで SSH セッションを開く
コンテナーとの直接 SSH セッションを開くには、アプリが実行されている必要があります。
az webapp ssh コマンドを使用します。
まだ認証されていない場合、接続するには Azure サブスクリプションで認証する必要があります。 認証されると、ブラウザー内シェルが表示され、コンテナー内でコマンドを実行することができます。
注
/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 に知らせます。