Azure App Service 向けの ASP.NET Core アプリを構成する

[アーティクル]
08/13/2024

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 バージョンを 8.0 に設定するには、Cloud Shell で次のコマンドを実行します。

az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|8.0"

ビルドの自動化のカスタマイズ

Note

MSBuild または SCM_DO_BUILD を使用した Windows App Service での .NET 9 (STS) アプリのビルドはまだサポートされていません。これらのビルドシナリオのサポートは、最初の GA の日付より後で、2024 年 12 月 4 日までにはサポートされます。 Visual Studio、Visual Studio Code、GitHub Actions、Azure DevOps を使用して App Service の外部にビルドするデプロイは完全にサポートされています。

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

接続シークレットをまったく必要としない、より安全な接続オプションを検討してください。詳細については、「Azure App Service から Azure サービスとデータベースへの安全な接続」を参照してください。

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 を構成する」を参照してください。

URL の書き換えまたはリダイレクトを行う

URL の書き換えまたはリダイレクトを行うには、ASP.NET Core 内で URL 書き換えミドルウェアを使用します。

ブラウザーで SSH セッションを開く

コンテナーとの直接 SSH セッションを開くには、アプリが実行されている必要があります。

ブラウザーに次の URL を貼り付け、<app-name> をお使いのアプリの名前に置き換えます。

https://<app-name>.scm.azurewebsites.net/webssh/host

まだ認証されていない場合、接続するには Azure サブスクリプションで認証する必要があります。認証されると、ブラウザー内シェルが表示され、コンテナー内でコマンドを実行することができます。

SSH 接続

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 に知らせます。

次のステップ

チュートリアル:ASP.NET Core アプリと SQL Database

App Service Linux の FAQ

または、その他のリソースを参照してください。

環境変数とアプリ設定のリファレンス

次の方法で共有

Azure App Service 向けの ASP.NET Core アプリを構成する

サポートされている .NET Core ランタイムバージョンを表示する

.NET Core バージョンを表示する

.NET Core バージョンを設定する

ビルドの自動化のカスタマイズ

環境変数へのアクセス

マルチプロジェクトソリューションをデプロイする

診断ログにアクセスする

例外の詳細ページを表示する

HTTPS セッションを検出する

URL の書き換えまたはリダイレクトを行う

ブラウザーで SSH セッションを開く

ログの robots933456

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure App Service 向けの ASP.NET Core アプリを構成する

サポートされている .NET Core ランタイム バージョンを表示する

.NET Core バージョンを表示する

.NET Core バージョンを設定する

ビルドの自動化のカスタマイズ

環境変数へのアクセス

マルチ プロジェクト ソリューションをデプロイする

診断ログにアクセスする

例外の詳細ページを表示する

HTTPS セッションを検出する

URL の書き換えまたはリダイレクトを行う

ブラウザーで SSH セッションを開く

ログの robots933456

次のステップ

フィードバック

その他のリソース

サポートされている .NET Core ランタイムバージョンを表示する

マルチプロジェクトソリューションをデプロイする