將 .NET 應用程式從內含式模型遷移至隔離的背景工作角色模型
重要
內含式模型支援將於 2026 年 11 月 10 日結束。 強烈建議您遵循本文中的指示,將應用程式移轉至隔離式背景工作角色模型。
本文將逐步引導您完成將 .NET 函數應用程式從內含式模型安全地遷移至隔離背景工作角色模型的程序。 若要了解這些模型之間的高階差異,請參閱執行模式比較。
本指南假設您的應用程式是在 Functions 執行階段 4.x 版上執行。 若非如此,您應該改為遵循升級主機版本的指南:
這些主機版本移轉指南也會協助您在處理隔離背景工作角色模型時,移轉至隔離的背景工作角色模型。
識別要移轉的函數應用程式
使用下列 Azure PowerShell 指令碼,以在您的訂用帳戶中產生目前使用內含式模型的函數應用程式清單。
指令碼會使用 Azure PowerShell 目前設定要使用的訂用帳戶。 您可以先執行 Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>'
,並以您想要評估的訂用帳戶識別碼取代 <YOUR SUBSCRIPTION ID>
,以變更訂用帳戶。
$FunctionApps = Get-AzFunctionApp
$AppInfo = @{}
foreach ($App in $FunctionApps)
{
if ($App.Runtime -eq 'dotnet')
{
$AppInfo.Add($App.Name, $App.Runtime)
}
}
$AppInfo
選擇您的目標 .NET 版本
在 Functions 執行時間 4.x 版上,當您使用進程內模型時,.NET 函式應用程式會以 .NET 6 或 .NET 8 為目標。
當移轉函數應用程式時,您有機會選擇 .NET 的目標版本。 您可以將 C# 專案更新為下列其中一個 Functions 4.x 版可支援的 .NET 版本:
.NET 版本 | .NET 官方支援原則版本類型 | Functions 處理序模型1、2 |
---|---|---|
.NET 9 | STS (終止支援 2026 年 5 月 12 日) | 隔離式背景工作角色模型 |
.NET 8 | LTS (2026 年 11 月 10 日終止支援) | 隔離式背景工作角色模型、 同處理序模型2 |
.NET Framework 4.8 | 請參閱原則 | 隔離式背景工作角色模型 |
1 隔離式背景工作角色模型支援 .NET 的長期支援 (LTS) 和標準期限支援 (STS) 版本,以及 .NET Framework。 同處理序模型僅支援 .NET 的 LTS 版本,結尾為 .NET 8。 如需兩個模型之間的完整特性和功能比較,請參閱內含式和隔離式背景工作處理序 .NET Azure Functions 之間的差異。
2 同處理序模型的支援會於 2026 年 11 月 10 日結束。 如需詳細資訊,請參閱此支援公告。 如需持續的完整支援,您應該將應用程式移轉至隔離式背景工作角色模型。
提示
建議您在隔離的背景工作角色模型上升級至 .NET 8。 這會提供完整發行版本的快速移轉路徑,以及 .NET 所提供最長的支援時間範圍。
本指南未提供 .NET 9 的特定範例。 如果您需要以該版本為目標,可以調整 .NET 8 範例。
為移轉做準備
如果您尚未這麼做,請使用 Azure PowerShell 來識別需要在目前 Azure 訂用帳戶中移轉的應用程式清單。
將應用程式移轉至隔離的背景工作模型之前,您應該徹底檢閱本指南的內容。 您也應該自行熟悉隔離背景工作模型的功能,以及兩個模型之間的差異。
若要遷移應用程式,您將:
- 遵循移轉本機專案中的步驟,將本機專案移轉至隔離的背景工作模型。
- 移轉專案之後,請使用 4.x 版的 Azure Functions Core Tools,在本機完整測試應用程式。
- 將 Azure 中的函數應用程式更新為隔離模型。
遷移本機專案
本節概述您需要對本機專案進行的各種變更,以將其移至隔離的背景工作角色模型。 某些步驟會根據您的目標 .NET 版本而變更。 使用索引標籤來選取符合所需版本的指示。 這些步驟假設本機 C# 專案,如果您的應用程式改用 C# 指令碼 (.csx
檔案),您應該先轉換成專案模型,然後再繼續進行。
提示
如果您要移至 .NET 的 LTS 或 STS 版本,可以使用 .NET 升級小幫手來自動進行下列各節所述的許多變更。
首先,轉換專案檔並更新相依性。 如您所見,您會看到專案的建置錯誤。 在後續步驟中,您將進行對應的變更,以移除這些錯誤。
專案檔
下列範例是使用 .csproj
4.x 版 .NET 8 的項目檔:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
<RootNamespace>My.Namespace</RootNamespace>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
</Project>
使用下列其中一個程序來更新此 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>
在專案程式碼之外,變更專案的目標架構可能需要變更工具鏈的元件。 例如,在 VS Code 中,您可能需要透過使用者設定或專案的 .vscode/settings.json
檔案來更新 azureFunctions.deploySubpath
延伸模組設定。 在建置步驟或 CI/CD 管道中,檢查可能存在於專案程式碼外之架構版本的任何相依性。
套件參考
移轉至隔離的背景工作角色模型時,您需要變更應用程式參考的套件。
如果您尚未這麼做,請更新專案以參考最新穩定版本的:
根據應用程式所使用的觸發程序和繫結,您的應用程式可能需要參考一組不同的套件。 下表顯示一些最常用延伸模組的取代項目:
案例 | 套件參考的變更 |
---|---|
計時器觸發程序 | 加 Microsoft.Azure.Functions.Worker.Extensions.Timer |
儲存體繫結 | ReplaceMicrosoft.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 |
事件中樞繫結 | 將參考取代為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 |
長期函式 | 將參考取代為Microsoft.Azure.WebJobs.Extensions.DurableTask 最新版本的 Microsoft.Azure.Functions.Worker.Extensions.DurableTask |
長期函式 (SQL 儲存體提供者) |
將參考取代為Microsoft.DurableTask.SqlServer.AzureFunctions 最新版本的 Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer |
長期函式 (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
檔案。 請務必閱讀您使用的每個延伸模組的文件。
例如,服務匯流排延伸模組在 4.x 和 5.x 版之間的結構有重大變更。 如需詳細資訊,請參閱 Azure Functions 的 Azure 服務匯流排繫結 (部分機器翻譯)。
隔離式背景工作角色模型應用程式不應該參考 Microsoft.Azure.WebJobs.*
命名空間或 Microsoft.Azure.Functions.Extensions
中的任何套件。 如果您有任何對這些項目的其餘參考,則應該移除這些參考。
提示
您的應用程式也可能相依於 Azure SDK 類型,無論是作為觸發程式和繫結的一部分,還是獨立相依性。 您也應該利用這個機會來更新這些項目。 最新版的 Functions 延伸模組會與適用於 .NET 的 Azure SDK 最新版本搭配運作,其幾乎所有套件的格式都是 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();
此範例包含 ASP.NET Core 整合,以改善效能,並在您的應用程式使用 HTTP 觸發程序時提供熟悉的程式設計模型。 如果您不打算使用 HTTP 觸發程序,可以將對 ConfigureFunctionsWebApplication
的呼叫取代為對 ConfigureFunctionsWorkerDefaults
的呼叫。 如果這樣做,您可以從專案檔中移除對 Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore
的參考。 不過,為了獲得最佳效能,甚至是其他觸發程序類型的函式,您也應該保留對 ASP.NET Core 的 FrameworkReference
。
Program.cs
檔案會取代具有 FunctionsStartup
屬性的任何檔案,通常為 Startup.cs
檔案。 在 FunctionsStartup
程式碼參考 IFunctionsHostBuilder.Services
的位置,您可以改為在 Program.cs
中 HostBuilder
的 .ConfigureServices()
方法內新增陳述式。 若要深入了解如何使用 Program.cs
,請參閱隔離的背景工作角色模型指南中的啟動和設定。
以上預設 Program.cs
範例包括設定隔離背景工作角色模型的 Application Insights 整合 (部分機器翻譯)。 在您的 Program.cs
中,您也必須設定任何應套用至專案中程式碼所產生記錄的任何記錄篩選。 在隔離的背景工作角色模型中,host.json
檔案只會控制 Functions 主機執行階段發出的事件。 如果您未在 Program.cs
中設定篩選規則,可能會看到遙測中各種類別的記錄層級差異。
雖然您可以將自訂設定來源註冊為 HostBuilder
的一部分,但請注意,這些同樣僅適用於您專案中的程式碼。 平台也需要觸發和繫結設定,這應該透過應用程式組態 (部分機器翻譯)、Key Vault 參考 (部分機器翻譯),或應用程式組態參考 (部分機器翻譯) 功能來提供。
一旦您將現有 FunctionsStartup
中的所有內容移至 Program.cs
檔案之後,就可以刪除 FunctionsStartup
屬性及其套用的類別。
函式簽章變更
一些主要類型會在內含式模型與隔離的背景工作角色模型之間變更。 其中許多都與組成函式簽章的屬性、參數和傳回型別有關。 針對每個函式,您必須對下列項目進行變更:
- 函式屬性 (也會設定函式的名稱)
- 函式如何取得
ILogger
/ILogger<T>
- 觸發程序與繫結屬性和參數
本節的其餘部分會引導您完成每個步驟。
函式屬性
隔離背景工作模型中的 Function
屬性會取代 FunctionName
屬性。 新的屬性具有相同的簽章,唯一的差異在於名稱。 因此,您可以跨專案執行字串取代。
記錄
在內含式模型中,您可以在函式中包含選用 ILogger
參數,或使用相依性插入來取得 ILogger<T>
。 如果您的應用程式已經使用相依性插入,則相同的機制會在隔離的背景工作角色模型中運作。
不過,對於仰賴 ILogger
方法參數的任何 Functions,您必須進行變更。 建議您使用相依性插入來取得 ILogger<T>
。 使用下列步驟來遷移函式的記錄機制:
在您的函式類別中,新增
private readonly ILogger<MyFunction> _logger;
屬性,並將MyFunction
取代為函式類別的名稱。為您的函式類別建立建構函式,其接受
ILogger<T>
做為參數:public MyFunction(ILogger<MyFunction> logger) { _logger = logger; }
將上述程式碼片段中的這兩個
MyFunction
執行個體取代為函式類別的名稱。若要記錄函式程式碼中的作業,請將
ILogger
參數的參考取代為_logger
。從函式簽章中移除
ILogger
參數。
若要深入了解,請參閱在隔離的背景工作角色模型中記錄。
觸發程序和繫結變更
當您在上一個步驟中變更套件參考時,即引進了觸發程序和繫結的錯誤,您現在將修正:
移除任何
using Microsoft.Azure.WebJobs;
陳述式。新增
using Microsoft.Azure.Functions.Worker;
陳述式。針對每個繫結屬性,變更屬性的名稱,如其參考文件中所指定,您可以在支援的繫結索引中找到該名稱。 一般而言,屬性名稱會變更,如下所示:
- 觸發程序通常會維持以相同方式命名。 例如,
QueueTrigger
是這兩個模型的屬性名稱。 - 輸入繫結通常需要將「輸入」新增至其名稱。 例如,如果您在內含式模型中使用
CosmosDB
輸入繫結屬性,此屬性現在會是CosmosDBInput
。 - 輸出繫結通常需要將「輸出」新增至其名稱。 例如,如果您在內含式模型中使用
Queue
輸出繫結屬性,此屬性現在會是QueueOutput
。
- 觸發程序通常會維持以相同方式命名。 例如,
更新屬性參數以反映隔離的背景工作角色模型版本,如繫結的參考文件中所指定。
例如,在內含式模型中,Blob 輸出繫結是由包含
Access
屬性 (property) 的[Blob(...)]
屬性 (attribute) 來表示。 在隔離的背景工作角色模型中,Blob 輸出屬性會是[BlobOutput(...)]
。 繫結不再需要Access
屬性,因此可以移除該參數。 因此,[Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")]
將成為[BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")]
。將輸出繫結移出函式參數清單。 如果您只有一個輸出繫結,您可以將此套用至函式的傳回型別。 如果您有多個輸出,請為每個輸出建立具有屬性 (property) 的新類別,並將屬性 (attribute) 套用至這些屬性 (property)。 若要深入了解,請參閱多個輸出繫結。
請參閱每個繫結的參考文件,以取得其可讓您繫結的目標類型。 在某些情況下,您可能需要變更類型。 針對輸出繫結,如果內含式模型版本使用
IAsyncCollector<T>
,則您可以將此取代為繫結至目標類型的陣列:T[]
。 您也可以考慮將輸出繫結取代為其所代表服務的用戶端物件,可以是輸入繫結 (若有) 的繫結類型,或自行插入用戶端。如果您的函式包含
IBinder
參數,請將其移除。 將功能取代為其所代表服務的用戶端物件,可以是輸入繫結 (若有) 的繫結類型,或自行插入用戶端。更新函式程式碼以使用任何新類型。
local.settings.json 檔案
local.settings.json 檔案只有在本機執行時才會使用。 如需詳細資訊,請參閱本機設定檔。
從執行同處理序移轉以在隔離式背景工作處理序中執行時,您需要將 FUNCTIONS_WORKER_RUNTIME
值變更為 "dotnet-isolated"。 請確定 local.settings.json 檔案具有至少有下列元素:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
}
}
您為 `AzureWebJobsStorage` 設定的值可能不同。 您不需要在移轉過程中變更其值。
host.json 檔案
您的 host.json
檔案不需要變更。 不過,如果此檔案中的 Application Insights 組態來自您的同處理序模型專案,您可能需要在您的 Program.cs
檔案中進行其他變更。 此 host.json
檔案只會控制來自 Functions 主機執行階段的記錄,而隔離的背景工作角色模型中,這些記錄中其中有一些會直接來自您的應用程式,讓您有更多控制權。 如需如何篩選這些記錄的詳細資料,請參閱在隔離的背景工作模型中管理記錄層級。
其他程式碼變更
本節會醒目提示當您完成移轉時所要考量的其他程式碼變更。 並非所有應用程式都需要這些變更,但您應該評估是否有任何變更與案例相關。
JSON 序列化
根據預設,隔離的背景工作角色模型會使用 System.Text.Json
進行 JSON 序列化。 若要自訂序列化程式選項或切換至 JSON.NET (Newtonsoft.Json
),請參閱這些指示。
Application Insights 記錄層級和篩選
您可以從 Functions 主機執行階段和專案中的程式碼將記錄傳送至 Application Insights。 host.json
可讓您設定主機記錄的規則,但若要控制來自程式碼的記錄,您必須將篩選規則設定為 Program.cs
的一部分。 如需如何篩選這些記錄的詳細資料,請參閱在隔離的背景工作模型中管理記錄層級。
範例函式移轉
HTTP 觸發程序範例
內含式模型的 HTTP 觸發程序看起來可能如下列範例所示:
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;
namespace Company.Function
{
public static class HttpTriggerCSharp
{
[FunctionName("HttpTriggerCSharp")]
public static IActionResult Run(
[HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
}
}
}
移轉後版本的 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 中更新函數應用程式
將函式應用程式更新至隔離的模型牽涉到兩項應該一起完成的變更,因為如果您只完成一項,應用程式會處於錯誤狀態。 這兩項變更也會導致應用程式程序重新啟動。 基於這些理由,您應該使用預備位置來執行更新。 預備位置有助於將應用程式的停機時間降到最低,並可讓您使用 Azure 中更新的組態來測試及驗證已移轉的程式碼。 然後,您可以透過交換作業,將完全遷移的應用程式部署至生產位置。
重要
當應用程式的已部署承載不符合設定的執行階段時,它會處於錯誤狀態。 在移轉過程中,您會將應用程式置於此狀態,理想情況下只是暫時。 部署位置有助於減輕此影響,因為在將變更當作單一更新套用至生產環境之前,錯誤狀態將會您的預備 (非生產) 環境中解決。 位置也會防範任何錯誤,並可讓您在達到生產之前偵測任何其他問題。
在此過程中,您可能在記錄中看到來自預備 (非生產) 位置的錯誤。 這是預期的,雖然當您繼續進行步驟時,這些錯誤應會消失。 執行位置交換作業之前,您應該先確認這些錯誤停止引發,而且您的應用程式如預期般運作。
使用下列步驟,使用部署位置將函式應用程式更新為隔離的背景工作模型:
如果您尚未建立部署位置,請建立部署位置。 您可能也想要自行熟悉位置交換程序,並確保您可在最少中斷的情況下對現有應用程式進行更新。
將
FUNCTIONS_WORKER_RUNTIME
應用程式設定設為dotnet-isolated
,以將預備 (非生產) 位置的組態變更為使用隔離的背景工作模型。FUNCTIONS_WORKER_RUNTIME
應該 不要標示為「位置設定」。如果您的目標也是以不同版本的 .NET 作為更新的一部分,則也應該變更堆疊組態。 若要這麼做,請參閱更新隔離背景工作模型的堆疊組態的指示。 您會對您所做的任何未來 .NET 版本更新使用相同的指示。
如果您有任何自動化基礎結構佈建,例如 CI/CD 管線,請確定自動化也會更新,讓
FUNCTIONS_WORKER_RUNTIME
設定為dotnet-isolated
,並以正確的 .NET 版本為目標。將移轉的專案發佈至函式應用程式的預備 (非生產) 位置。
如果您使用 Visual Studio 將隔離的背景工作模型專案發佈至使用內含式模型的現有應用程式或位置,它也可同時為您完成上一個步驟。 如果您未完成上一個步驟,Visual Studio 會提示您在部署期間更新函式應用程式。 Visual Studio 會將此呈現為單一作業,但這些仍是兩個不同的作業。 在臨時狀態期間,您可能會在記錄中看到來自預備 (非生產) 位置的錯誤。
確認您的應用程式在預備 (非生產) 位置內如預期般運作。
執行位置交換作業。 這會將您在預備 (非生產) 位置所做的變更套用至生產位置。 位置交換會以單一更新的形式發生,以避免在生產環境中引入臨時錯誤狀態。
確認您的應用程式在生產位置內如預期般運作。
完成這些步驟後,移轉就會完成,而您的應用程式會在隔離的模型上執行。 恭喜! 視需要針對需要移轉的任何其他應用程式重複本指南中的步驟。