Azure Functions バージョン 3.x からバージョン 4.x にアプリを移行する
Azure Functions バージョン 4.x は、バージョン 3.x との下位互換性が高くなっています。 ほとんどのアプリでは、コードを大幅に変更する必要なく、4.x に安全に移行されるはずです。 Functions ランタイム バージョンの詳細については、「Azure Functions ランタイム バージョンの概要」をご覧ください。
重要
2022 年 12 月 13 日より、Azure Functions ランタイムのバージョン 2.x と 3.x で実行されている関数アプリでは、延長サポートは終了しています。 詳細については、廃止されたバージョンに関する記事を参照してください。
この記事では、Functions ランタイムのバージョン 4.x で実行するように関数アプリを安全に移行するプロセスについて説明します。 プロジェクトの移行手順は言語によって異なるため、記事の上部にあるセレクターから開発言語を選んでください。
移行する関数アプリを特定する
次の PowerShell スクリプトを使用して、現在バージョン 2.x または 3.x を対象とするサブスクリプション内の関数アプリの一覧を生成します。
$Subscription = '<YOUR SUBSCRIPTION ID>'
Set-AzContext -Subscription $Subscription | Out-Null
$FunctionApps = Get-AzFunctionApp
$AppInfo = @{}
foreach ($App in $FunctionApps)
{
if ($App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"] -like '*3*')
{
$AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
}
}
$AppInfo
ターゲットの .NET バージョンを選択する
Functions ランタイムのバージョン 3.x では、C# 関数アプリはインプロセス モデルを使用して .NET Core 3.1 をターゲットにするか、分離ワーカー モデルを使用して .NET 5 をターゲットにします。
関数アプリを移行すると、.NET のターゲット バージョンを選択できます。 C# プロジェクトを Functions バージョン 4.x でサポートされている次のいずれかのバージョンの .NET に更新できます。
| .NET バージョン | .NET 公式サポート ポリシー のリリースの種類 | Functions プロセス モデル1、3 |
|---|---|---|
| .NET 82 | LTS | 分離ワーカー モデル |
| .NET 7 | STS (2024 年 5 月 14 日にサポート終了) | 分離ワーカー モデル |
| .NET 6 | LTS (2024 年 11 月 12 日にサポート終了) | 分離ワーカー モデル、 インプロセス モデル3 |
| .NET Framework 4.8 | ポリシーを参照 | 分離ワーカー モデル |
1分離ワーカー モデルでは、.NET の長期サポート (LTS) と標準期間サポート (STS) の各バージョンと、.NET Framework がサポートされます。 インプロセス モデルでは、.NET の LTS リリースのみがサポートされます。 2 つのプロセス モデル間の完全な機能の比較については、インプロセスと分離ワーカー プロセスの .NET Azure Functions の違いに関するページを参照してください。
2 .NET 8 はインプロセス モデルではまだサポートされていませんが、分離ワーカー モデルでは使用できます。 インプロセス モデルの今後のオプションを含む .NET 8 プランの詳細については、Azure Functions ロードマップの更新の投稿を参照してください。
3 インプロセス モデルのサポートは、2026 年 11 月 10 日に終了します。 詳細については、こちらのサポートに関するお知らせを参照してください。 完全なサポートを継続するには、分離 worker モデルにアプリを移行する必要があります。
ヒント
分離ワーカー モデルでは .NET 8 に更新することをお勧めします。 .NET 8 は、.NET から最長のサポート期間を持つ完全にリリースされたバージョンです。
インプロセス モデルを代わりに使用することもできますが、回避できる場合は推奨されません。 インプロセス モデルの場合は、サポートは 2026 年 11 月 10 日に終了するため、その前に分離ワーカー モデルに移行する必要があります。 バージョン 4.x に移行する際にこれを行うことで、必要な作業の合計を減らすことができます。また、分離ワーカー モデルは、将来のバージョンの .NET をより簡単にターゲットにできるなど、アプリにさらなるベネフィットをもたらします。 分離ワーカー モデルに移行する場合は、 .NET アップグレード アシスタントで必要なコード変更の多くを自動的に処理することもできます。
このガイドでは、分離ワーカー モデルでの .NET 7 または .NET 6 の具体的な例については説明しません。 これらのバージョンをターゲットにする必要がある場合は、.NET 8 の分離ワーカー モデルの例を適応させることができます。
移行を準備する
まだ実行していない場合は、Azure PowerShell を使用して、現在の Azure サブスクリプションで移行する必要があるアプリの一覧を特定します。
Functions ランタイムのバージョン 4.x にアプリを移行する前に、次のタスクを実行する必要があります。
- 3.x から 4.x までの破壊的変更の一覧を確認します。
- 「ローカル プロジェクトを移行する」の手順を完了してローカル プロジェクトをバージョン 4.x に移行します。
- プロジェクトを移行したら、Azure Functions Core Tools のバージョン 4.x を使用して、アプリをローカルで完全にテストします。
- Azure でホストされているアプリでアップグレード前検証ツールを実行し、特定された問題をすべて解決します。
- Azure の関数アプリを新しいバージョンに更新します。 ダウンタイムを最小限に抑える必要がある場合は、ステージング スロットを使用して、新しいランタイム バージョンで移行したアプリを Azure でテストおよび検証することを検討してください。 その後、更新されたバージョン設定を使用してアプリを運用スロットにデプロイできます。 詳細については、「スロットを使用した更新」を参照してください。
- 移行したプロジェクトを更新された関数アプリに発行します。
Visual Studio を使用してバージョン 4.x プロジェクトを下位バージョンの既存の関数アプリに発行する場合は、デプロイ時に Visual Studio で関数アプリをバージョン 4.x に更新するように求められます。 この更新では、「スロットなしの更新」で定義されているのと同じプロセスが使用されます。
ローカル プロジェクトを移行する
アップグレード手順は言語によって異なります。 目的の言語が表示されていない場合は、記事の上部にあるセレクターから選択します。
.NET のターゲット バージョンと目的のプロセス モデル (インプロセスまたは分離ワーカー プロセス) に一致するタブを選択します。
ヒント
分離ワーカー モデルを使用して LTS または STS バージョンの .NET に移行する場合は、.NET アップグレード アシスタント を使用して、次のセクションで説明する多くの変更を自動的に行うことができます。
プロジェクト ファイル
次の例は、バージョン 3.x で .NET Core 3.1 を使用する .csproj プロジェクト ファイルです。
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.13" />
</ItemGroup>
<ItemGroup>
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
</Project>
Functions バージョン 4.x で実行するようにこの XML ファイルを更新するには、次のいずれかの手順に従います。
以下の手順はローカル C# プロジェクトを想定しています。代わりに C# スクリプト (.csx ファイル) がアプリで使用されている場合、プロジェクト モデルに変換してから続行してください。
.csproj XML プロジェクト ファイルには、次の変更を加える必要があります。
PropertyGroupの値を設定します。TargetFrameworkからnet8.0。PropertyGroupの値を設定します。AzureFunctionsVersionからv4。次の
OutputType要素をPropertyGroupに追加します。<OutputType>Exe</OutputType>ItemGroupで。PackageReferenceリストで、Microsoft.NET.Sdk.Functionsへのパッケージ参照を次の参照に置き換えます。<FrameworkReference Include="Microsoft.AspNetCore.App" /> <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" /> <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />Microsoft.Azure.WebJobs.*名前空間内の他のパッケージへの参照を書き留めます。 これらのパッケージは後の手順で置き換えます。次の新しい
ItemGroupを追加します。<ItemGroup> <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/> </ItemGroup>
これらの変更を行うと、更新されたプロジェクトは次の例のようになります。
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
<RootNamespace>My.Namespace</RootNamespace>
<OutputType>Exe</OutputType>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
<!-- Other packages may also be in this list -->
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
<ItemGroup>
<Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
</ItemGroup>
</Project>
パッケージと名前空間の変更
移行先のモデルに基づいて、アプリケーションが参照するパッケージを更新または変更する必要がある場合があります。 ターゲット パッケージを採用する場合は、using ステートメントの名前空間と参照する一部の型を更新する必要がある場合があります。 これらの名前空間の変更が using ステートメントに及ぼす影響については、この記事で後ほど紹介する HTTP トリガー テンプレートの例で確認できます。
まだ更新していない場合、次に示すものの最新の安定バージョンを参照するようにプロジェクトを更新します。
アプリが使用するトリガーとバインドによっては、アプリは別のパッケージ セットを参照する必要がある場合があります。 次の表に、最も一般的に使用されるいくつかの拡張機能の置換を示します。
| シナリオ | パッケージ参照の変更 |
|---|---|
| タイマー トリガー | 追加 Microsoft.Azure.Functions.Worker.Extensions.Timer |
| Storage のバインド | ReplaceMicrosoft.Azure.WebJobs.Extensions.Storagewith Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs、 Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues、 Microsoft.Azure.Functions.Worker.Extensions.Tables |
| BLOB のバインド | 次のMicrosoft.Azure.WebJobs.Extensions.Storage.Blobsへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs |
| キューのバインド | 次のMicrosoft.Azure.WebJobs.Extensions.Storage.Queuesへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues |
| テーブルのバインド | 次のMicrosoft.Azure.WebJobs.Extensions.Tablesへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.Tables |
| Cosmos DB のバインド | 次のMicrosoft.Azure.WebJobs.Extensions.CosmosDBおよび/または Microsoft.Azure.WebJobs.Extensions.DocumentDBへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.CosmosDB |
| Service Bus のバインド | 次のMicrosoft.Azure.WebJobs.Extensions.ServiceBusへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.ServiceBus |
| Event Hubs のバインド | 次のMicrosoft.Azure.WebJobs.Extensions.EventHubsへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.EventHubs |
| Event Grid のバインド | 次のMicrosoft.Azure.WebJobs.Extensions.EventGridへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.EventGrid |
| SignalR Service のバインド | 次のMicrosoft.Azure.WebJobs.Extensions.SignalRServiceへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.SignalRService |
| Durable Functions | 次のMicrosoft.Azure.WebJobs.Extensions.DurableTaskへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.DurableTask |
| Durable Functions (SQL ストレージ プロバイダー) |
次のMicrosoft.DurableTask.SqlServer.AzureFunctionsへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer |
| Durable Functions (Netherite ストレージ プロバイダー) |
次のMicrosoft.Azure.DurableTask.Netherite.AzureFunctionsへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite |
| SendGrid のバインド | 次のMicrosoft.Azure.WebJobs.Extensions.SendGridへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.SendGrid |
| Kafka のバインド | 次のMicrosoft.Azure.WebJobs.Extensions.Kafkaへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.Kafka |
| RabbitMQ のバインド | 次のMicrosoft.Azure.WebJobs.Extensions.RabbitMQへの参照を、次の最新バージョンに置き換えます Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ |
| 依存関係の挿入 とスタートアップ構成 |
次への参照を削除しますMicrosoft.Azure.Functions.Extensions(分離ワーカー モデルでは、この機能が既定で提供されます) |
検討するべき拡張機能の全一覧については、「サポートされているバインド」を参照し、分離プロセス モデルの完全なインストール手順については、各拡張機能のドキュメントを参照してください。 対象としているすべてのパッケージの最新の安定バージョンをインストールするようにしてください。
分離ワーカー モデル アプリケーションでは Microsoft.Azure.WebJobs.* 名前空間や Microsoft.Azure.Functions.Extensions 内のどのパッケージも参照するべきではありません。 これらへの参照が何か残っている場合は、それらを削除する必要があります。
ヒント
アプリは、トリガーとバインドの一部として、またはスタンドアロンの依存関係として、Azure SDK の種類にも依存している場合があります。 この機会を利用して、これらも同様に更新する必要があります。 Functions 拡張機能の最新バージョンは、Azure SDK for .NET (ほとんどすべてのパッケージの形式は Azure.* です) の最新バージョンで動作します。
Program.cs ファイル
分離ワーカー プロセスで実行できるよう移行する場合は、次の program.cs ファイルをプロジェクトに追加する必要があります。
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
var host = new HostBuilder()
.ConfigureFunctionsWebApplication()
.ConfigureServices(services => {
services.AddApplicationInsightsTelemetryWorkerService();
services.ConfigureFunctionsApplicationInsights();
})
.Build();
host.Run();
この例には、パフォーマンスを向上させ、アプリで HTTP トリガーを使用するときに使い慣れたプログラミング モデルを提供するための ASP.NET コア統合が含まれています。 HTTP トリガーを使用しない場合は、ConfigureFunctionsWebApplication の呼び出しを ConfigureFunctionsWorkerDefaults の呼び出しに置き換えることができます。 そうすると、プロジェクト ファイルから Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore への参照を削除できます。 ただし、最適なパフォーマンスを得るために、他のトリガー型がある関数の場合でも、FrameworkReference を ASP.NET Core に保持する必要があります。
Program.cs ファイルで置換されるファイルに FunctionsStartup 属性がある場合は、通常は Startup.cs ファイルです。 FunctionsStartup コードが IFunctionsHostBuilder.Services を参照する場所で、代わりに HostBuilder の .ConfigureServices() メソッド内のステートメントを Program.cs に追加できます。 Program.cs の操作については、分離ワーカー モデル ガイドの「スタートアップと構成」をご覧ください。
上記の既定の Program.cs 例には、分離ワーカー モデル用の Application Insights 統合のセットアップが含まれます。 お使いの Program.cs で、プロジェクト内のコードからのログに適用する必要があるログのフィルター処理も構成する必要があります。 分離ワーカー モデルでは、host.json ファイルは Functions ホスト ランタイムによって出力されるイベントのみを制御します。 Program.cs でフィルター規則を構成しない場合は、テレメトリでさまざまなカテゴリに対して存在するログ レベルの違いが表示されることがあります。
HostBuilder の一部としてカスタム構成ソースを登録することはできますが、これらは同様にプロジェクト内のコードにのみ適用されることに注意してください。 トリガーとバインドの構成もプラットフォームで必要です。これは、アプリケーション設定、Key Vault 参照、またはApp Configuration 参照機能を使用して提供する必要があります。
既存の FunctionsStartup から Program.cs ファイルへすべてを移動すると、FunctionsStartup 属性と、それが適用されていたクラスを削除できます。
local.settings.json ファイル
local.settings.json ファイルは、ローカルで実行している場合にのみ使用されます。 詳細については、「ローカル設定ファイル」を参照してください。
バージョン 4.x に移行するときは、local.settings.json ファイルに少なくとも次の要素が含まれていることを確認します。
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
}
}
Note
インプロセスの実行から分離ワーカー プロセスでの実行に移行する場合は、FUNCTIONS_WORKER_RUNTIME 値を "dotnet-isolated" に変更する必要があります。
host.json ファイル
host.json ファイルに変更は必要ありません。 ただし、インプロセス モデル プロジェクトからこのファイル内の Application Insights 構成を行う場合は、Program.cs ファイルに追加の変更を加える必要があります。 host.json ファイルは、Functions ホスト ランタイムからのログのみを制御し、分離ワーカー モデルでは、これらのログの一部はアプリケーションから直接取得されるため、より詳細な制御が可能になります。 これらのログをフィルター処理する方法の詳細については、「分離ワーカー モデルでのログ レベルの管理」を参照してください。
クラス名の変更
一部のキー クラスは、バージョン間で名前が変更されました。 これらの変更は、.NET API の変更、またはインプロセスと分離 worker プロセスの違いのいずれかの結果によるものです。 次の表は、移行するときに変更される可能性がある、Functions によって使用されている主要な .NET クラスを示しています。
| .NET Core 3.1 | .NET 5 | .NET 8 |
|---|---|---|
FunctionName (属性) |
Function (属性) |
Function (属性) |
ILogger |
ILogger |
ILogger、ILogger<T> |
HttpRequest |
HttpRequestData |
HttpRequestData、HttpRequest (ASP.NET Core 統合を使用) |
IActionResult |
HttpResponseData |
HttpResponseData、IActionResult (ASP.NET Core 統合を使用) |
FunctionsStartup (属性) |
代わりに Program.cs を使用します |
代わりに Program.cs を使用します |
バインドにクラス名の違いがある場合もあります。 詳細については、特定のバインドの参照記事を参照してください。
その他のコード変更
このセクションでは、移行を行う際に考慮する必要があるその他のコード変更について説明します。 これらの変更はすべてのアプリケーションで必要なわけではありませんが、シナリオに関連があるかどうかを評価する必要があります。 3.x から 4.x の破壊的変更で、プロジェクトに加える必要があるその他の変更がないかを確認してください。
JSON シリアル化
既定では、分離されたワーカー モデルは JSON シリアル化に System.Text.Json を使用します。 シリアライザー オプションをカスタマイズしたり、JSON.NET (Newtonsoft.Json) に切り替えたりするには、次の手順を参照してください。
Application Insights のログ レベルとフィルター処理
ログは、Functions ホスト ランタイムとプロジェクト内のコードの両方から Application Insights に送信できます。 host.json では、ホスト ログの規則を構成できますが、コードからのログを制御するには、Program.cs の一部としてフィルター規則を構成する必要があります。 これらのログをフィルター処理する方法の詳細については、「分離ワーカー モデルでのログ レベルの管理」を参照してください。
HTTP トリガー テンプレート
インプロセスと分離ワーカー プロセスの違いは、HTTP によってトリガーされる関数で確認できます。 バージョン 3.x (インプロセス) の HTTP トリガー テンプレートは、次の例のようになります。
using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;
namespace Company.Function
{
public static class HttpTriggerCSharp
{
[FunctionName("HttpTriggerCSharp")]
public static async Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post", Route = null)] HttpRequest req,
ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
string name = req.Query["name"];
string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
dynamic data = JsonConvert.DeserializeObject(requestBody);
name = name ?? data?.name;
string responseMessage = string.IsNullOrEmpty(name)
? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
: $"Hello, {name}. This HTTP triggered function executed successfully.";
return new OkObjectResult(responseMessage);
}
}
}
移行されたバージョンの HTTP トリガー テンプレートは、次の例のようになります。
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;
namespace Company.Function
{
public class HttpTriggerCSharp
{
private readonly ILogger<HttpTriggerCSharp> _logger;
public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
{
_logger = logger;
}
[Function("HttpTriggerCSharp")]
public IActionResult Run(
[HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
{
_logger.LogInformation("C# HTTP trigger function processed a request.");
return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
}
}
}
プロジェクトを Azure Functions 4.x に更新するには、次の手順に従います。
Azure Functions Core Tools のローカル インストールをバージョン 4.x に更新します。
アプリの Azure Functions 拡張機能バンドルを 2.x 以上に更新します。 詳細については、破壊的変更について参照してください。
必要に応じて、バージョン 4.x でサポートされている Java バージョンのいずれかに移動します。
次の例のように、アプリの
POM.xmlファイルを更新してFUNCTIONS_EXTENSION_VERSIONの設定を~4に変更します。<configuration> <resourceGroup>${functionResourceGroup}</resourceGroup> <appName>${functionAppName}</appName> <region>${functionAppRegion}</region> <appSettings> <property> <name>WEBSITE_RUN_FROM_PACKAGE</name> <value>1</value> </property> <property> <name>FUNCTIONS_EXTENSION_VERSION</name> <value>~4</value> </property> </appSettings> </configuration>
- 必要に応じて、 バージョン 4.x でサポートされている Node.js バージョンのいずれかに移動します。
- この機会に PowerShell 7.2 にアップグレードすることをお勧めします。 詳細については、「PowerShell のバージョン」を参照してください。
- Python 3.6 使用している場合は、いずれかのサポートされているバージョンに移行します。
アップグレード前検証コントロールを実行する
Azure Functions は、関数アプリを 4.x に移行するときに発生する可能性のある問題を特定するのに役立つアップグレード前検証コントロールを提供します。 アップグレード前検証コントロールを実行するには、次の手順に従います。
Azure portal で関数アプリに移動します。
[問題の診断と解決] ページを開きます。
[関数アプリの診断] で、
Functions 4.x Pre-Upgrade Validatorの入力を開始し、一覧から選択します。検証が完了したら、推奨事項を確認し、アプリの問題に対処します。 アプリに変更を加える必要がある場合は、ローカルで Azure Functions Core Tools v4 を使用するか、ステージング スロットを使用して、Functions ランタイムのバージョン 4.x に対して変更を検証してください。
Azure で関数アプリを更新する
移行したプロジェクトを発行する前に、Azure の関数アプリ ホストのランタイムをバージョン 4.x に更新する必要があります。 Functions ホストで使用されるランタイム バージョンは FUNCTIONS_EXTENSION_VERSION アプリケーション設定によって制御されますが、場合によっては他の設定も更新する必要があります。 コードの変更もアプリケーション設定の変更も、関数アプリを再起動する必要があります。
最も簡単な方法は、スロットなしで更新してから、アプリ プロジェクトを再発行することです。 また、スロットを使用して更新することで、アプリのダウンタイムを最小限に抑え、ロールバックを簡略化することもできます。
スロットなしで更新する
v4.x に更新する最も簡単な方法は、Azure の関数アプリで FUNCTIONS_EXTENSION_VERSION アプリケーション設定を ~4 に設定することです。 スロットがあるサイトでは、別の手順に従う必要があります。
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
別の設定も必要ですが、これは Windows と Linux とで異なります。
Windows で実行する場合は、ランタイムのバージョン 4.x で必要な .NET 6.0 も有効にする必要があります。
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
.NET 6 は、Windows で実行されているすべての言語の関数アプリに必要です。
この例では、<APP_NAME> を関数アプリの名前に、<RESOURCE_GROUP_NAME> をリソース グループの名前に置き換えます。
これで、バージョン 4.x で実行するように移行されたアプリ プロジェクトを再発行できるようになりました。
スロットを使って更新する
デプロイ スロットの使用は、関数アプリを以前のバージョンから v4.x ランタイムに更新するのに適しています。 ステージング スロットを使用すると、ステージング スロットの新しいランタイム バージョンでアプリを実行し、検証後に運用環境に切り替えることができます。 スロットは、更新中のダウンタイムを最小限に抑える方法も提供します。 ダウンタイムを最小限に抑える必要がある場合は、「最小ダウンタイムの更新」の手順に従ってください。
更新されたスロットでアプリを確認したら、アプリと新しいバージョンの設定を運用環境に入れ替えられます。 この入れ替えには、運用スロットでの WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 の設定が必要です。 この設定をどのように追加するかで、更新に必要なダウンタイムの量に影響します。
標準的な更新
スロット対応関数アプリが完全再起動のダウンタイムを処理できる場合は、運用スロットで WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS 設定を直接更新できます。 運用スロットでこの設定を直接変更すると、可用性に影響する再起動が発生するため、トラフィックが減少した時点でこの変更を行うことを検討してください。 その後、ステージング スロットから更新されたバージョンに入れ替えできます。
現在、Update-AzFunctionAppSetting PowerShell コマンドレットはスロットをサポートしていません。 Azure CLI または Azure portal を使用する必要があります。
運用スロットに
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0を設定するには、次のコマンドを使用します。az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>この例では、
<APP_NAME>を関数アプリの名前に、<RESOURCE_GROUP_NAME>をリソース グループの名前に置き換えます。 このコマンドを実行すると、運用スロットで実行されているアプリが再起動します。ステージング スロットにも
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONSを設定するには、次のコマンドを使用します。az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>次のコマンドを使用して、
FUNCTIONS_EXTENSION_VERSIONを変更し、ステージング スロットを新しいランタイム バージョンに更新します。az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>Windows では、Functions ランタイムのバージョン 4.x には .NET 6 が必要です。 Linux では、.NET アプリも .NET 6 に更新する必要があります。 .NET 6 でランタイムを実行できるように、次のコマンドを使用します。
Windows で実行する場合は、ランタイムのバージョン 4.x で必要な .NET 6.0 も有効にする必要があります。
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>.NET 6 は、Windows で実行されているすべての言語の関数アプリに必要です。
この例では、
<APP_NAME>を関数アプリの名前に、<RESOURCE_GROUP_NAME>をリソース グループの名前に置き換えます。コード プロジェクトでバージョン 4.x で実行する更新プログラムが必要な場合は、ここでそれらの更新プログラムをステージング スロットにデプロイします。
入れ替える前に、更新されたステージング環境で関数アプリが正しく実行されていることを確認します。
更新されたステージング スロットを運用環境と入れ替えるには、次のコマンドを使用します。
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
最小ダウンタイムの更新
運用アプリのダウンタイムを最小限に抑えるには、ステージング スロットから運用環境に WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS 設定を入れ替えます。 その後、事前に警告されたステージング スロットから更新されたバージョンに入れ替えできます。
ステージング スロットに
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0を設定するには、次のコマンドを使用します。az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>次のコマンドを使用して、スロットと新しい設定を運用環境で入れ替え、同時にステージング スロットのバージョン設定を復元します。
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~3 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>入れ替えとステージング時のランタイム バージョンの復元の間に、ステージング スロットからエラーが表示される場合があります。 このエラーは、入れ替え中にステージングに
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0のみしかないと、ステージングのFUNCTIONS_EXTENSION_VERSION設定が削除されるために発生する可能性があります。 バージョン設定がないと、スロットの状態が正しくありません。 入れ替えの直後にステージング スロットのバージョンを更新すると、スロットが適切な状態に戻り、必要に応じて変更をロールバックします。 ただし、入れ替えのロールバックでは、ステージングで見られる運用環境で同じエラーが発生しないように、入れ替えを元に戻す前に運用環境からWEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0を直接削除する必要もあります。 この運用環境設定の変更により、再起動が発生します。ステージング スロットにもう一度
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0を設定するには、次のコマンドを使用します。az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>この時点で、両方のスロットで
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0が設定されています。次のコマンドを使用して、
FUNCTIONS_EXTENSION_VERSIONを変更し、ステージング スロットを新しいランタイム バージョンに更新します。az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>Windows では、Functions ランタイムのバージョン 4.x には .NET 6 が必要です。 Linux では、.NET アプリも .NET 6 に更新する必要があります。 .NET 6 でランタイムを実行できるように、次のコマンドを使用します。
Windows で実行する場合は、ランタイムのバージョン 4.x で必要な .NET 6.0 も有効にする必要があります。
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>.NET 6 は、Windows で実行されているすべての言語の関数アプリに必要です。
この例では、
<APP_NAME>を関数アプリの名前に、<RESOURCE_GROUP_NAME>をリソース グループの名前に置き換えます。コード プロジェクトでバージョン 4.x で実行する更新プログラムが必要な場合は、ここでそれらの更新プログラムをステージング スロットにデプロイします。
入れ替える前に、更新されたステージング環境で関数アプリが正しく実行されていることを確認します。
更新され、事前警告されたステージング スロットを運用環境と入れ替えるには、次のコマンドを使用します。
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
3.x と 4.x の間の破壊的変更
言語固有の破壊的変更を含め、3.x アプリを 4.x にアップグレードする前に注意すべき重要な破壊的変更を次に示します。 完全な一覧については、破壊的変更: 承認済みに関する Azure Functions GitHub の問題を参照してください。
プログラミング言語が表示されていない場合は、ページ上部から選択してください。
ランタイム
Azure Functions プロキシは、Azure Functions ランタイムのバージョン 1.x から 3.x 用のレガシ機能です。 Functions プロキシのサポートは、バージョン 4.x で再度有効にすることができるため、関数アプリを最新のランタイム バージョンに正常に更新することができます。 できるだけ早く、関数アプリと Azure API Management の統合に切り替える必要があります。 API Management では、Functions ベースの API の定義、セキュリティ保護、管理、収益化のためのより完全な機能セットを利用できます。 詳しくは、「API Management 統合」をご覧ください。 Functions バージョン 4.x でプロキシのサポートを再度有効にする方法については、「Functions v4.x でプロキシを再度有効にする」を参照してください。
AzureWebJobsDashboard を使用した Azure Storage へのログ記録は、4.x ではサポートされなくなりました。 その代わりに Application Insights を使用する必要があります。 (#1923)
Azure Functions 4.x では、拡張機能の最小バージョン要件が適用されるようになりました。 影響を受ける拡張機能の最新バージョンに更新します。 .NET 以外の言語では、拡張機能バンドル バージョン 2.x 以降に更新してください。 (#1987)
従量課金プランにおいて Linux で実行される関数アプリの 4.x で、既定および最大のタイムアウトが適用されるようになりました。 (#1915)
Azure Functions 4.x では、Key Vault プロバイダーに
Azure.IdentityとAzure.Security.KeyVault.Secretsが使用され、Microsoft.Azure.KeyVault の使用は非推奨となりました。 関数アプリ設定の構成方法の詳細については、「シークレット リポジトリ」の Key Vault オプションを参照してください。 (#2048)ストレージ アカウントを共有する関数アプリは、ホスト ID が同じ場合、起動に失敗するようになりました。 詳細については、「ホスト ID に関する考慮事項」を参照してください。 (#2049)
- 既定のスレッド数が更新されました。 スレッド セーフではない関数やメモリ使用量が多い関数は、影響を受ける可能性があります。 (#1962)