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

注意

.NET Framework の ASP.NET については、「Azure App Service 向けの ASP.NET アプリを構成する」を参照してくださいFor ASP.NET in .NET Framework, see Configure an ASP.NET app for Azure App Service

ASP.NET Core アプリは、コンパイル済みバイナリとして Azure App Service にデプロイする必要があります。ASP.NET Core apps must be deployed to Azure App Service as compiled binaries. Visual Studio 発行ツールではソリューションがビルドされてからコンパイル済みバイナリが直接デプロイされますが、App Service 展開エンジンではまずコード リポジトリがデプロイされ、その後にバイナリがコンパイルされます。The Visual Studio publishing tool builds the solution and then deploys the compiled binaries directly, whereas the App Service deployment engine deploys the code repository first and then compiles the binaries.

このガイドでは、ASP.NET Core 開発者向けに主要な概念と手順を説明します。This guide provides key concepts and instructions for ASP.NET Core developers. Azure App Service を初めて使用する場合は、まず ASP.NET Core クイックスタートASP.NET Core と SQL Database のチュートリアルに従ってください。If you've never used Azure App Service, follow the ASP.NET Core quickstart and ASP.NET Core with SQL Database tutorial first.

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

App Service でサポートされているすべての .NET Core バージョンが Windows インスタンスに既にインストールされています。In App Service, the Windows instances already have all the supported .NET Core versions installed. 使用可能な .NET Core ランタイムと SDK のバージョンを表示するには、https://<app-name>.scm.azurewebsites.net/DebugConsole に移動し、ブラウザーベースのコンソールで次のコマンドを実行します。To show the .NET Core runtime and SDK versions available to you, navigate to https://<app-name>.scm.azurewebsites.net/DebugConsole and run the following command in the browser-based console:

dotnet --info

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

現在の .NET Core バージョンを表示するには、Cloud Shell で次のコマンドを実行します。To show the current .NET Core version, run the following command in the Cloud Shell:

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

サポートされているすべての .NET Core バージョンを表示するには、Cloud Shell で次のコマンドを実行します。To show all supported .NET Core versions, run the following command in the Cloud Shell:

az webapp list-runtimes --linux | grep DOTNETCORE

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

ASP.NET Core プロジェクトのプロジェクト ファイルにターゲット フレームワークを設定します。Set the target framework in the project file for your ASP.NET Core project. 詳細については、.NET Core ドキュメントの「使用する .NET Core バージョンを選択する」を参照してください。For more information, see Select the .NET Core version to use in .NET Core documentation.

.NET Core バージョンを 3.1 に設定するには、Cloud Shell で次のコマンドを実行します。Run the following command in the Cloud Shell to set the .NET Core version to 3.1:

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

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

ビルドの自動化を有効にして Git または zip パッケージを使用してアプリをデプロイする場合、App Service のビルドの自動化によって、次の手順が実行されます。If you deploy your app using Git or zip packages with build automation turned on, the App Service build automation steps through the following sequence:

  1. PRE_BUILD_SCRIPT_PATH によって指定された場合、カスタム スクリプトを実行します。Run custom script if specified by PRE_BUILD_SCRIPT_PATH.
  2. dotnet restore を実行して、NuGet の依存関係を復元します。Run dotnet restore to restore NuGet dependencies.
  3. dotnet publish を実行して、運用環境用のバイナリを構築します。Run dotnet publish to build a binary for production.
  4. POST_BUILD_SCRIPT_PATH によって指定された場合、カスタム スクリプトを実行します。Run custom script if specified by POST_BUILD_SCRIPT_PATH.

PRE_BUILD_COMMAND および POST_BUILD_COMMAND は、既定では空の環境変数です。PRE_BUILD_COMMAND and POST_BUILD_COMMAND are environment variables that are empty by default. ビルド前のコマンドを実行するには、PRE_BUILD_COMMAND を定義します。To run pre-build commands, define PRE_BUILD_COMMAND. ビルド後のコマンドを実行するには、POST_BUILD_COMMAND を定義します。To run post-build commands, define POST_BUILD_COMMAND.

次の例では、一連のコマンドに対して 2 つの変数をコンマ区切りで指定しています。The following example specifies the two variables to a series of commands, separated by commas.

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 の構成」を参照してください。For additional environment variables to customize build automation, see Oryx configuration.

Linux 上で App Service によって ASP.NET Core アプリが実行されビルドされる方法に関する詳細については、Oryx ドキュメントの .NET Core アプリが検出されビルドされる方法に関するページを参照してください。For more information on how App Service runs and builds ASP.NET Core apps in Linux, see Oryx documentation: How .NET Core apps are detected and built.

環境変数へのアクセスAccess environment variables

App Service では、アプリ コードの外部でアプリ設定を指定できます。In App Service, you can set app settings outside of your app code. 次に、標準の ASP.NET Core 依存関係の挿入パターンを使用して、任意のクラスでこれらにアクセスできます。Then you can access them in any class using the standard ASP.NET Core dependency injection pattern:

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 の値よりも優先されます。If you configure an app setting with the same name in App Service and in appsettings.json , for example, the App Service value takes precedence over the appsettings.json value. ローカルの appsettings.json 値ではアプリをローカルでデバッグできますが、App Service の値では実稼働設定の製品内でアプリを実行できます。The local appsettings.json value lets you debug the app locally, but the App Service value lets your run the app in product with production settings. 接続文字列は同じように機能します。Connection strings work in the same way. これにより、コード リポジトリの外部にアプリケーション シークレットを保存し、コードを変更することなく適切な値にアクセスできます。This way, you can keep your application secrets outside of your code repository and access the appropriate values without changing your code.

注意

appsettings. json階層型の構成データは、.NET Core に標準の : 区切り記号を使用してアクセスされることに注意してください。Note the hierarchical configuration data in appsettings.json is accessed using the : delimiter that's standard to .NET Core. App Service で特定の階層型構成設定をオーバーライドするには、キーにアプリ設定名を同じ区切り形式で設定します。To override a specific hierarchical configuration setting in App Service, set the app setting name with the same delimited format in the key. Cloud Shell で次の例を実行できます。you can run the following example in the Cloud Shell:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My:Hierarchical:Config:Data="some value"

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

Visual Studio ソリューションに複数のプロジェクトが含まれている場合、Visual Studio の発行プロセスには、デプロイするプロジェクトの選択が既に含まれています。When a Visual Studio solution includes multiple projects, the Visual Studio publish process already includes selecting the project to deploy. ビルド自動化を有効にした状態で、Git や ZIP デプロイなどを使用して App Service 展開エンジンにデプロイすると、App Service 展開エンジンは、App Service アプリとして検出された最初の Web サイトまたは Web アプリケーション プロジェクトを選択します。When you deploy to the App Service deployment engine, such as with Git or with ZIP deploy, with build automation turned on, the App Service deployment engine picks the first Web Site or Web Application Project it finds as the App Service app. PROJECT アプリ設定を指定することで、App Service で使用するプロジェクトを指定できます。You can specify which project App Service should use by specifying the PROJECT app setting. たとえば、Cloud Shell で以下を実行します。For example, run the following in the Cloud Shell:

az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PROJECT="<project-name>/<project-name>.csproj"

診断ログにアクセスするAccess diagnostic logs

ASP.NET Core には、App Service 用の組み込みのログ プロバイダーが用意されています。ASP.NET Core provides a built-in logging provider for App Service. プロジェクトの Program.cs で、次の例に示すように、ConfigureLogging 拡張メソッドを使用してそのプロバイダーをアプリケーションに追加します。In Program.cs of your project, add the provider to your application through the ConfigureLogging extension method, as shown in the following example:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureLogging(logging =>
        {
            logging.AddAzureWebAppDiagnostics();
        })
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });

その後、標準の .NET Core パターンを使用して、ログを構成して生成できます。You can then configure and generate logs with the standard .NET Core pattern.

App Service のアプリケーション コード内から生成されたコンソール ログにアクセスするには、Cloud Shell で次のコマンドを実行して、診断ログを有効にします。To access the console logs generated from inside your application code in App Service, turn on diagnostics logging by running the following command in the Cloud Shell:

az webapp log config --resource-group <resource-group-name> --name <app-name> --application-logging true --level Verbose

--level で有効な値は、ErrorWarningInfo、および Verbose です。Possible values for --level are: Error, Warning, Info, and Verbose. 後続の各レベルには、前のレベルが含まれます。Each subsequent level includes the previous level. たとえば、Error にはエラー メッセージのみが含まれ、Verbose にはすべてのメッセージが含まれます。For example: Error includes only error messages, and Verbose includes all messages.

診断ログがオンになったら、次のコマンドを実行して、ログのストリームを確認します。Once diagnostic logging is turned on, run the following command to see the log stream:

az webapp log tail --resource-group <resource-group-name> --name <app-name>

コンソール ログがすぐに表示されない場合は、30 秒以内にもう一度確認します。If you don't see console logs immediately, check again in 30 seconds.

注意

https://<app-name>.scm.azurewebsites.net/api/logs/docker で、ブラウザーからログ ファイルを検査することもできます。You can also inspect the log files from the browser at https://<app-name>.scm.azurewebsites.net/api/logs/docker.

任意のタイミングでログのストリーミングを停止するには、Ctrl+C と入力します。To stop log streaming at any time, type Ctrl+C.

App Service での ASP.NET Core アプリのトラブルシューティングの詳細については、「Azure App Service と IIS での ASP.NET Core のトラブルシューティング」を参照してくださいFor more information on troubleshooting ASP.NET Core apps in App Service, see Troubleshoot ASP.NET Core on Azure App Service and IIS

例外の詳細ページを表示するGet detailed exceptions page

Visual Studio デバッガーで ASP.NET Core アプリの実行中に例外が発生すると、ブラウザーに例外の詳細ページが表示されますが、App Service ではそのページの代わりに汎用の HTTP 500 エラーが表示されるか、「 要求の処理中にエラーが発生しました。When your ASP.NET Core app generates an exception in the Visual Studio debugger, the browser displays a detailed exception page, but in App Service that page is replaced by a generic HTTP 500 error or An error occurred while processing your request. メッセージが表示されます。message. App Service で例外の詳細ページを表示するには、Cloud Shell で次のコマンドを実行してアプリ設定 ASPNETCORE_ENVIRONMENT をアプリに追加します。To display the detailed exception page in App Service, Add the ASPNETCORE_ENVIRONMENT app setting to your app by running the following command in the Cloud Shell.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASPNETCORE_ENVIRONMENT="Development"

HTTPS セッションの検出Detect HTTPS session

App Service では、SSL 終了がネットワーク ロード バランサーで発生するため、すべての HTTPS リクエストは暗号化されていない HTTP リクエストとしてアプリに到達します。In App Service, SSL termination happens at the network load balancers, so all HTTPS requests reach your app as unencrypted HTTP requests. ユーザー要求が暗号化されるかどうかをアプリのロジックで認識する必要がある場合は、 Startup.cs で Forwarded Headers Middleware を構成します。If your app logic needs to know if the user requests are encrypted or not, configure the Forwarded Headers Middleware in Startup.cs :

  • Startup.ConfigureServices で、X-Forwarded-For ヘッダーと X-Forwarded-Proto ヘッダーを転送するように ForwardedHeadersOptions を使ってミドルウェアを構成します。Configure the middleware with ForwardedHeadersOptions to forward the X-Forwarded-For and X-Forwarded-Proto headers in Startup.ConfigureServices.
  • ミドルウェアが App Service のロード バランサーを信頼できるようにするために、既知のネットワークにプライベート IP アドレス範囲を追加します。Add private IP address ranges to the known networks, so that the middleware can trust the App Service load balancer.
  • 他のミドルウェアを呼び出す前に、Startup.Configure 内で UseForwardedHeaders メソッドを呼び出します。Invoke the UseForwardedHeaders method in Startup.Configure before calling other middleware.

3 つの要素をすべてまとめると、次の例のようなコードになります。Putting all three elements together, your code looks like the following example:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    services.Configure<ForwardedHeadersOptions>(options =>
    {
        options.ForwardedHeaders =
            ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
        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 を構成する」を参照してください。For more information, see Configure ASP.NET Core to work with proxy servers and load balancers.

ブラウザーで SSH セッションを開くOpen SSH session in browser

コンテナーとの直接 SSH セッションを開くには、アプリが実行されている必要があります。To make open a direct SSH session with your container, your app should be running.

ブラウザーに次の URL を貼り付け、<app-name> をお使いのアプリの名前に置き換えます。Paste the following URL into your browser and replace <app-name> with your app name:

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

まだ認証されていない場合、接続するには Azure サブスクリプションで認証する必要があります。If you're not yet authenticated, you're required to authenticate with your Azure subscription to connect. 認証されると、ブラウザー内シェルが表示され、コンテナー内でコマンドを実行することができます。Once authenticated, you see an in-browser shell, where you can run commands inside your container.

SSH 接続

注意

/home ディレクトリの外部で行ったすべての変更は、コンテナー自体に格納され、アプリの再起動後には保持されません。Any changes you make outside the /home directory are stored in the container itself and don't persist beyond an app restart.

ローカル コンピューターからリモート SSH セッションを開くには、「リモート シェルから SSH セッションを開く」を参照してください。To open a remote SSH session from your local machine, see Open SSH session from remote shell.

ログの robots933456robots933456 in logs

コンテナー ログで次のメッセージが表示されることがあります。You may see the following message in the container logs:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

このメッセージは無視してかまいません。You can safely ignore this message. /robots933456.txt は、コンテナーが要求を処理できるかどうかを調べるために App Service が使用するダミーの URL パスです。/robots933456.txt is a dummy URL path that App Service uses to check if the container is capable of serving requests. 404 応答は、パスが存在しないことを示すだけですが、コンテナーが正常であり、要求に応答できる状態であることを App Service に知らせます。A 404 response simply indicates that the path doesn't exist, but it lets App Service know that the container is healthy and ready to respond to requests.

次のステップNext steps