次の方法で共有


Azure Functions バージョン 3.x からバージョン 4.x にアプリを移行する

重要

2022 年 12 月 13 日の時点で、Azure Functions ランタイムのバージョン 2.x と 3.x で実行されている関数アプリは、延長サポートの終了に達しました。 詳細については、廃止されたバージョンに関する記事を参照してください。

Azure Functions バージョン 4.x はバージョン 3.x と高い下位互換性を持っています。 ほとんどのアプリでは、コードを大幅に変更する必要なく、4.x に安全に移行されるはずです。 Functions ランタイム バージョンの詳細については、「Azure Functions ランタイム バージョンの概要を参照してください。

重要

従量課金プランで Linux で 有効期間終了 v3 ランタイム を実行している関数アプリは、2026 年 9 月 30 日以降も実行を停止します。 サービスの中断を回避するには、 アプリを v4 ランタイムに移行します

従量課金プランで Linux で関数アプリをホストするオプションは、2028 年 9 月 30 日に廃止されます。 Linux 従量課金プランでは、新しい機能や 言語バージョンは取得されません。 従量課金プランのWindowsで実行されているアプリは、現在影響を受けません。 提供終了日より前に、アプリを Flex 従量課金プランに移行します

この記事では、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# 関数アプリはインプロセス モデルを使用してコア 3.1 .NET、分離されたワーカー モデルを使用して .NET 5 をターゲットにします。

関数アプリを移行する場合は、.NETのターゲット バージョンを選択できます。 C# プロジェクトを、Functions バージョン 4.x でサポートされている次のいずれかのバージョンの.NETに更新できます。

.NET バージョン .NET 公式サポート ポリシーリリースの種類 関数処理モデル1、2
.NET 10 LTS (サポート終了 2028 年 11 月 14 日) 分離ワーカー モデル
.NET 9 STS (サポート終了 2026 年 11 月 10 日)3 分離ワーカー モデル
.NET 8 LTS (2026 年 11 月 10 日にサポート終了) 孤立労働者モデル
インプロセス モデル2
.NET Framework 4.8 ポリシーを参照 分離ワーカー モデル

1 このisolated worker modelでは、.NETの長期サポート (LTS) バージョンとStandard Term Support (STS) バージョン、そして.NET Frameworkがサポートされます。 in-process モデルは、.NETの LTS リリースのみをサポートし、.NET 8 で終わっています。 2 つのモデル間の機能や特徴の完全な比較については、インプロセスと分離ワーカープロセス間の違い - .NET Azure Functionsを参照してください。

2 インプロセス モデルのサポートは、2026 年 11 月 10 日に終了します。 詳細については、こちらのサポートに関するお知らせを参照してください。 完全なサポートを受け続けるには、分離ワーカー モデルにアプリを移行する必要があります。

3 .NET 9 以前は、2026 年 5 月 12 日のサポート終了日が予定されていました。 .NET 9 サービス期間中、.NET チームは STS バージョンのサポートを 24 か月に延長し、.NET 9 から始まります。 詳細については、 ブログの投稿を参照してください。

ヒント

分離ワーカー モデルでは、.NET 8 に更新することをお勧めします。 .NET 8 は、.NETからサポート期間が最も長い完全にリリースされたバージョンです。

インプロセス モデルを代わりに使用することもできますが、回避できる場合は、このアプローチをお勧めしません。 インプロセス モデルの場合は、サポートは 2026 年 11 月 10 日に終了するため、その前に分離ワーカー モデルに移行する必要があります。 これにより、バージョン 4.x に移行すると、必要な作業の合計が減少し、分離されたワーカー モデルによってアプリ追加の利点が得られます。これには、将来のバージョンの.NETをより簡単にターゲットにする機能が含まれます。 分離ワーカー モデルに移行する場合は、.NET Upgrade Assistant で必要なコード変更の多くを処理することもできます。

このガイドでは、.NET 10 (プレビュー) または .NET 9 の具体的な例を示していません。 これらのバージョンのいずれかをターゲットにする必要がある場合は、.NET 8 つの例を調整できます。

移行を準備する

まだ行っていない場合は、Azure PowerShellを使用して、現在のAzure サブスクリプションで移行する必要があるアプリの一覧を特定します。

Functions ランタイムのバージョン 4.x にアプリを移行する前に、次のタスクを実行する必要があります。

  1. 3.x から 4.x までの破壊的変更の一覧を確認します。
  2. ローカル プロジェクトを移行する」の手順を完了してローカル プロジェクトをバージョン 4.x に移行します。
  3. プロジェクトを移行した後、Azure Functions Core Tools のバージョン 4.x を使用して、アプリをローカルで完全にテストします。
  4. Azureでホストされているアプリでアップグレード前検証コントロールを実行し、特定された問題を解決します。
  5. Azureの関数アプリを新しいバージョンに更新します。 ダウンタイムを最小限に抑える必要がある場合は、タグ付けスロットを使用して、新しいランタイム バージョンで移行されたアプリをAzureでテストおよび検証することを検討してください。 その後、更新されたバージョン設定を使用してアプリを運用スロットにデプロイできます。 詳細については、「スロットを使用した更新」を参照してください。
  6. 移行したプロジェクトを更新された関数アプリに発行します。

Visual Studioを使用してバージョン 4.x プロジェクトを下位バージョンの既存の関数アプリに発行すると、デプロイ時に関数アプリをバージョン 4.x に更新Visual Studio許可するように求められます。 この更新では、「スロットなしの更新」で定義されているのと同じプロセスが使用されます。

ローカル プロジェクトを移行する

アップグレード手順は言語によって異なります。 目的の言語が表示されていない場合は、記事の上部にあるセレクターから選択します。

ターゲット バージョンの.NETと目的のプロセス モデル (インプロセスまたは分離ワーカー プロセス) に一致するタブを選択します。

ヒント

分離ワーカー モデルを使用して LTS または STS バージョンの.NETに移行する場合は、.NET Upgrade Assistant を使用して、次のセクションで説明する変更の多くを自動的に行うことができます。

プロジェクトファイル

次の例は、バージョン 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 プロジェクト ファイルでは、次の変更が必要です。

  1. PropertyGroup の値を設定します。 TargetFramework から net8.0

  2. PropertyGroup の値を設定します。 AzureFunctionsVersion から v4

  3. 次の OutputType 要素を PropertyGroup に追加します。

    <OutputType>Exe</OutputType>
    
  4. 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.* 名前空間内の他のパッケージへの参照を書き留めます。 これらのパッケージは後の手順で置き換えます。

  5. 次の新しい 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
ストレージバインディング Microsoft.Azure.WebJobs.Extensions.Storage
Microsoft.Azure.WebJobs.Extensions.Storage

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
サービス バス ブリッジング への参照を
Microsoft.Azure.WebJobs.Extensions.ServiceBus
の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Event Hubs のバインド への参照を
Microsoft.Azure.WebJobs.Extensions.EventHubs
の最新バージョンに置き換えます
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
イベントグリッドのバインディング への参照を
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
(分離ワーカー モデルでは、この機能が既定で提供されます)

検討するべき拡張機能の全一覧については、「サポートされているバインド」を参照し、分離プロセス モデルの完全なインストール手順については、各拡張機能のドキュメントを参照してください。 対象としているすべてのパッケージの最新の安定バージョンをインストールするようにしてください。

ヒント

このプロセス中に拡張機能のバージョンを変更するとき、場合によっては、host.json ファイルの更新も必要になります。 使用する各拡張機能のドキュメントを必ず読んでください。 たとえば、Service Bus拡張機能では、バージョン 4.x と 5.x の間の構造に破壊的変更があります。 詳細については、Azure Functions の Azure Service Bus バインディングを参照してください。

分離ワーカー モデル アプリケーションでは、Microsoft.Azure.WebJobs.* 名前空間または Microsoft.Azure.Functions.Extensions 内のパッケージを参照しないでください。 これらへの参照が何か残っている場合は、それらを削除する必要があります。

ヒント

また、アプリは、トリガーとバインドの一部として、またはスタンドアロンの依存関係として、Azure SDKの種類に依存する場合もあります。 この機会を利用して、これらも同様に更新する必要があります。 Functions 拡張機能の最新バージョンは、.NET の Azure SDK の最新バージョンで動作し、ほとんどのパッケージは 形式です。

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();

この例にはASP.NET Core統合が含まれており、アプリで HTTP トリガーを使用する場合にパフォーマンスを向上させ、使い慣れたプログラミング モデルを提供します。 HTTP トリガーを使用しない場合は、 ConfigureFunctionsWebApplication の呼び出しを ConfigureFunctionsWorkerDefaultsの呼び出しに置き換えることができます。 その場合は、プロジェクト ファイルから Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore への参照を削除できます。 ただし、パフォーマンスを最大限に高めるには、他のトリガーの種類の関数であっても、FrameworkReferenceを ASP.NET Coreしておく必要があります。

Program.cs ファイルは、FunctionsStartup属性を持つファイル (通常はStartup.cs ファイル) を置き換えます。 FunctionsStartupコードがIFunctionsHostBuilder.Servicesを参照する場所では、代わりにProgram.csの.ConfigureServices()HostBuilder メソッド内にステートメントを追加できます。 Program.csの操作の詳細については、分離ワーカー モデル ガイドのスタートアップと構成に関するページを参照してください。

前に説明した既定 のProgram.cs 例には、 Application Insights のセットアップが含まれます。 Program.csでは、プロジェクト内のコードからのログに適用する必要があるログ フィルター処理も構成する必要があります。 分離ワーカー モデルでは、 host.json ファイルは Functions ホスト ランタイムによって出力されるイベントのみを制御します。 Program.csでフィルター規則を構成しない場合は、テレメトリのさまざまなカテゴリに対してログ レベルの違いが表示されることがあります。

カスタム構成ソースは HostBuilderの一部として登録できますが、これらは同様にプロジェクト内のコードにのみ適用されます。 プラットフォームにはトリガーとバインドの構成も必要です。これは、アプリケーション設定Key Vault参照、または App Configuration references 機能を通じて提供する必要があります。

既存の 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"
    }
}

インプロセスの実行から分離ワーカー プロセスでの実行に移行する場合は、FUNCTIONS_WORKER_RUNTIME 値を "dotnet-isolated" に変更する必要があります。

host.json ファイル

host.json ファイルに変更は必要ありません。 ただし、インプロセス モデル プロジェクトからこのファイル内の Application Insights 構成を行う場合は、 Program.cs ファイルに他の変更を加える必要があります。 host.json ファイルが制御するのは、Functions ホスト ランタイムからのログだけであり、分離ワーカー モデルでは、これらのログの一部はアプリケーションから直接取得されるため、より詳細な制御が可能になります。 これらのログをフィルター処理する方法の詳細については、「分離ワーカー モデルでのログ レベルの管理」を参照してください。

クラス名の変更

一部のキー クラスは、バージョン間で名前が変更されました。 これらの変更は、.NET API の変更、またはインプロセスと分離ワーカー プロセスの違いのいずれかになります。 次の表は、移行時に変更される可能性がある Functions で使用される主要な.NET クラスを示しています。

.NET Core 3.1 .NET 5 .NET 8
FunctionName (属性) Function (属性) Function (属性)
ILogger ILogger ILoggerILogger<T>
HttpRequest HttpRequestData HttpRequestDataHttpRequest (ASP.NET Core 統合を使用)
IActionResult HttpResponseData HttpResponseDataIActionResult (ASP.NET Core 統合を使用)
FunctionsStartup (属性) 代わりに Program.cs を使用します 代わりに Program.cs を使用します

バインドにクラス名の違いがある場合もあります。 詳しくは、特定の結合についての参考記事をご覧ください。

その他のコード変更

このセクションでは、移行を行う際に考慮する必要があるその他のコード変更に焦点を当てます。 これらの変更はすべてのアプリケーションで必要なわけではありませんが、シナリオに関連するかどうかを評価する必要があります。 プロジェクトに加える必要があるその他の変更については、 必ず 3.x から 4.x の間の破壊的 変更を確認してください。

JSON シリアル化

既定では、分離されたワーカー モデルでは、JSON シリアル化に System.Text.Json が使用されます。 シリアライザー のオプションをカスタマイズしたり、JSON に切り替えたりするには.NET (Newtonsoft.Json) を参照してください 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 に更新するには:

  1. Azure Functions Core Tools のローカル インストールをバージョン 4.x に更新します。

  2. アプリの Azure Functions 拡張機能バンドル を 2.x 以上に更新します。 詳細については、破壊的変更に関する記事を参照してください。

  1. 必要に応じて、バージョン 4.x でサポートされている Java バージョンのいずれかに移動します。

  2. 次の例のように、アプリの 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>
    
  1. 必要に応じて、 バージョン 4.x でサポートされている Node.js バージョンのいずれかに移動します。
  1. この機会に PowerShell 7.2 にアップグレードすることをお勧めします。 詳細については、「PowerShell のバージョン」を参照してください。
  1. Python 3.6 を使用している場合は、サポートされているバージョンのいずれかに移動します。

アップグレード前検証コントロールを実行する

Azure Functionsには、関数アプリを 4.x に移行するときの潜在的な問題を特定するのに役立つアップグレード前検証コントロールが用意されています。 アップグレード前検証コントロールを実行するには、次の手順に従います。

  1. Azure ポータルで、関数アプリに移動します。

  2. [問題の診断と解決] ページを開きます。

  3. [関数アプリの診断] で、Functions 4.x Pre-Upgrade Validator の入力を開始し、一覧から選択します。

  4. 検証が完了したら、推奨事項を確認し、アプリの問題に対処します。 アプリに変更を加える必要がある場合は、Functions ランタイムのバージョン 4.x に対して変更を検証するようにしてください。その際、Azure Functions Core Tools v4 をローカルで使用するか、ステージング スロットを使用する方法があります。

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 8.0 も有効にする必要があります。

az functionapp config set --net-framework-version v8.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 ポータルを使用する必要があります。

  1. 運用スロットに 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> をリソース グループの名前に置き換えます。 このコマンドを実行すると、運用スロットで実行されているアプリが再起動します。

  2. ステージング スロットにも 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>
    
  3. 次のコマンドを使用して、FUNCTIONS_EXTENSION_VERSION を変更し、ステージング スロットを新しいランタイム バージョンに更新します。

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  4. Functions ランタイムのバージョン 4.x には、Windowsで .NET 6 が必要です。 Linux では、.NET アプリも .NET 6 に更新する必要があります。 ランタイムを .NET 6 で実行できるように、次のコマンドを使用します。

    Windowsで実行する場合は、ランタイムのバージョン 4.x で必要な .NET 8.0 も有効にする必要があります。

    az functionapp config set --net-framework-version v8.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
    

    .NET 6 は、Windowsで実行されている任意の言語の関数アプリに必要です。

    この例では、<APP_NAME> を関数アプリの名前に、<RESOURCE_GROUP_NAME> をリソース グループの名前に置き換えます。

  5. コード プロジェクトでバージョン 4.x で実行する更新プログラムが必要な場合は、ここでそれらの更新プログラムをステージング スロットにデプロイします。

  6. 入れ替える前に、更新されたステージング環境で関数アプリが正しく実行されていることを確認します。

  7. 更新されたステージング スロットを運用環境と入れ替えるには、次のコマンドを使用します。

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
    

最小ダウンタイムの更新

運用アプリのダウンタイムを最小限に抑えるには、ステージング スロットから運用環境に WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS 設定を入れ替えます。 その後、事前ウォーミング済みのステージング スロットから更新済みのバージョンに入れ替えできます。

  1. ステージング スロットに 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>
    
  2. 次のコマンドを使用して、スロットと新しい設定を運用環境で入れ替え、同時にステージング スロットのバージョン設定を復元します。

    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 を直接削除する必要もあります。 この運用環境設定の変更により、再起動が発生します。

  3. ステージング スロットにもう一度 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 が設定されています。

  4. 次のコマンドを使用して、FUNCTIONS_EXTENSION_VERSION を変更し、ステージング スロットを新しいランタイム バージョンに更新します。

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>
    
  5. Functions ランタイムのバージョン 4.x には、Windowsで .NET 6 が必要です。 Linux では、.NET アプリも .NET 6 に更新する必要があります。 ランタイムを .NET 6 で実行できるように、次のコマンドを使用します。

    Windowsで実行する場合は、ランタイムのバージョン 4.x で必要な .NET 8.0 も有効にする必要があります。

    az functionapp config set --net-framework-version v8.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
    

    .NET 6 は、Windowsで実行されている任意の言語の関数アプリに必要です。

    この例では、<APP_NAME> を関数アプリの名前に、<RESOURCE_GROUP_NAME> をリソース グループの名前に置き換えます。

  6. コード プロジェクトでバージョン 4.x で実行する更新プログラムが必要な場合は、ここでそれらの更新プログラムをステージング スロットにデプロイします。

  7. 入れ替える前に、更新されたステージング環境で関数アプリが正しく実行されていることを確認します。

  8. 更新済みで事前ウォーミング済みのステージング スロットを運用環境と入れ替えるには、次のコマンドを使用します。

    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 にアップグレードする前に注意すべき重要な破壊的変更を次に示します。 完全な一覧については、「Breaking Change: Approved というラベルのAzure Functions GitHub問題を参照してください。

プログラミング言語が表示されていない場合は、ページ上部から選択してください。

ランタイム

  • Azure Functions プロキシは、Azure Functions ランタイムのバージョン 1.x から 3.x の機能でした。 この機能はバージョン 4.x ではサポートされていません。 詳細については、Azure Functions を使用した Serverless REST API に関するページを参照してください。

  • AzureWebJobsDashboard を使用したAzure Storageへのログ記録は、4.x ではサポートされなくなりました。 その代わりに Application Insights を使用する必要があります。 (#1923)

  • Azure Functions 4.x では、拡張機能のminimum バージョンの要件が適用されるようになりました。 影響を受ける拡張機能の最新バージョンに更新します。 .NET以外の言語の場合は、拡張バンドル バージョン2.x以降に更新してください。 (#1987)

  • 従量課金プランにおいて Linux で実行される関数アプリの 4.x で、既定および最大のタイムアウトが適用されるようになりました。 (#1915)

  • Azure Functions 4.x では、Key Vault プロバイダーに対して Azure.IdentityAzure.Security.KeyVault.Secrets が使用され、Microsoft.Azure.KeyVault の使用が非推奨になりました。 関数アプリの設定を構成する方法の詳細については、Manage キー ストレージのKey Vault オプションを参照してください。 (#2048)

  • ストレージ アカウントを共有する関数アプリは、ホスト ID が同じ場合、起動に失敗するようになりました。 詳細については、「ホスト ID に関する考慮事項」を参照してください。 (#2049)

  • Azure Functions 4.x では、.NETの新しいバージョンがサポートされています。 バージョンの完全な一覧については、「Supported languages in Azure Functions」を参照してください。

  • InvalidHostServicesException は致命的なエラーになります。 (#2045)

  • EnableEnhancedScopes は既定で有効になっています。 (#1954)

  • 登録済みサービスとして HttpClient を削除します。 (#1911)

  • Java 11 で単一クラス ローダーを使用します。 (#1997)

  • Java 8 でワーカー jar の読み込みを停止します。 (#1991)

  • Node.js バージョン 10 と 12 は、Azure Functions 4.x ではサポートされていません。 (#1999)

  • 以前の不整合に対処するために、Node.js アプリの出力シリアル化が更新されました。 (#2007)

  • 既定のスレッド数が更新されました。 スレッド セーフではない関数やメモリ使用量が多い関数は、影響を受ける可能性があります。 (#1962)
  • Python 3.6 は、Azure Functions 4.x ではサポートされていません。 (#1999)

  • 共有メモリ転送は、既定で有効になっています。 (#1973)

  • 既定のスレッド数が更新されました。 スレッド セーフではない関数やメモリ使用量が多い関数は、影響を受ける可能性があります。 (#1962)

次のステップ