次の方法で共有


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

.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 ビルドの自動化は次の順序に従います。

  1. PRE_BUILD_SCRIPT_PATH によって指定された場合、カスタム スクリプトを実行します。
  2. NuGet の依存関係を復元するには、 dotnet restoreを実行します。
  3. 運用環境用のバイナリをビルドするには、 dotnet publishを実行します。
  4. 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 で有効な値は、ErrorWarningInfoVerbose です。 後続の各レベルには、前のレベルが含まれます。 たとえば、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-ForX-Forwarded-Proto および Startup.ConfigureServices ヘッダーを転送します。
  • ミドルウェアが App Service のロード バランサーを信頼できるようにするために、既知のネットワークにプライベート IP アドレス範囲を追加します。
  • 他のミドルウェアを呼び出す前に、UseForwardedHeadersStartup.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 サブスクリプションで認証する必要があります。 認証されると、ブラウザー内シェルが表示され、コンテナー内でコマンドを実行することができます。

SSH 接続

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