Migrace aplikací .NET z modelu v procesu do izolovaného pracovního modelu
Důležité
Podpora modelu v procesu skončí 10. listopadu 2026. Důrazně doporučujeme migrovat aplikace do izolovaného pracovního modelu podle pokynů v tomto článku.
Tento článek vás provede procesem bezpečné migrace aplikace funkcí .NET z modelu v procesu na izolovaný pracovní model. Další informace o rozdílech na vysoké úrovni mezi těmito modely najdete v porovnání režimu spouštění.
Tato příručka předpokládá, že vaše aplikace běží ve verzi 4.x modulu runtime Functions. Pokud ne, měli byste místo toho postupovat podle pokynů k upgradu verze hostitele:
- Migrace aplikací z Azure Functions verze 2.x a 3.x na verzi 4.x
- Migrace aplikací ze služby Azure Functions verze 1.x na verzi 4.x
Tyto příručky k migraci verzí hostitele vám také pomůžou migrovat do izolovaného pracovního modelu při práci.
Identifikace aplikací funkcí, které se mají migrovat
Pomocí následujícího skriptu Azure PowerShellu vygenerujte seznam aplikací funkcí ve vašem předplatném, které aktuálně používají model v procesu.
Skript používá předplatné, které je aktuálně nakonfigurované pro použití Azure PowerShellu. Předplatné můžete změnit tak, že nejprve spustíte Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>'
a nahradíte <YOUR SUBSCRIPTION ID>
ID předplatného, které chcete vyhodnotit.
$FunctionApps = Get-AzFunctionApp
$AppInfo = @{}
foreach ($App in $FunctionApps)
{
if ($App.Runtime -eq 'dotnet')
{
$AppInfo.Add($App.Name, $App.Runtime)
}
}
$AppInfo
Zvolte cílovou verzi .NET.
Ve verzi 4.x modulu runtime Functions cílí aplikace funkcí .NET při použití modelu v procesu na .NET 6 nebo .NET 8.
Při migraci aplikace funkcí máte možnost zvolit cílovou verzi .NET. Projekt jazyka C# můžete aktualizovat na jednu z následujících verzí rozhraní .NET, které jsou podporovány funkcemi verze 4.x:
Verze .NET | Oficiální typ zásad podpory .NET | Modelprocesu funkcí 1,2 |
---|---|---|
.NET 9 | STS (konec podpory 12. května 2026) | Izolovaný model pracovního procesu |
.NET 8 | LTS (konec podpory 10. listopadu 2026) | Model izolovaného pracovního procesu Model v procesu2 |
.NET Framework 4.8 | Zobrazit zásady | Izolovaný model pracovního procesu |
1 Izolovaný model pracovního procesu podporuje verze .NET (Long Term Support) a Standard Term Support (STS) a rozhraní .NET Framework. Model v procesu podporuje pouze verze LTS .NET, končící na .NET 8. Úplné porovnání funkcí a funkcí mezi těmito dvěma modely najdete v tématu Rozdíly mezi procesy a izolovaným pracovním procesem . NET Azure Functions.
2 Podpora modelu v procesu končí 10. listopadu 2026. Další informace najdete v tomto oznámení podpory. Pokud chcete pokračovat v plné podpoře, měli byste své aplikace migrovat do izolovaného pracovního modelu.
Tip
Doporučujeme upgradovat na .NET 8 v izolovaném pracovním modelu. To poskytuje rychlou cestu migrace k plně vydané verzi s nejdelším oknem podpory z .NET.
Tato příručka neobsahuje konkrétní příklady pro .NET 9. Pokud potřebujete tuto verzi cílit, můžete přizpůsobit příklady .NET 8.
Příprava migrace
Pokud jste to ještě neudělali, pomocí Azure PowerShellu identifikujte seznam aplikací, které je potřeba migrovat v aktuálním předplatném Azure.
Před migrací aplikace do izolovaného modelu pracovního procesu byste měli důkladně zkontrolovat obsah této příručky. Měli byste se také seznámit s funkcemi izolovaného modelu pracovního procesu a rozdíly mezi těmito dvěma modely.
Pokud chcete aplikaci migrovat, provedete následující:
- Pomocí kroků v části Migrace místního projektu proveďte migraci místního projektu do izolovaného modelu pracovního procesu.
- Po migraci projektu plně otestujte aplikaci místně pomocí verze 4.x nástrojů Azure Functions Core Tools.
- Aktualizujte aplikaci funkcí v Azure na izolovaný model.
Migrace místního projektu
Tato část popisuje různé změny, které je potřeba provést v místním projektu, aby se přesunul do izolovaného modelu pracovního procesu. Některé kroky se mění na základě vaší cílové verze .NET. Pomocí karet vyberte pokyny, které odpovídají požadované verzi. Tyto kroky předpokládají místní projekt jazyka C# a pokud vaše aplikace místo toho používá skript jazyka C# (.csx
soubory), měli byste před pokračováním převést na projektový model .
Tip
Pokud přecházíte na verzi LTS nebo STS rozhraní .NET, můžete pomocníka pro upgrade .NET použít k automatickému provádění mnoha změn uvedených v následujících částech.
Nejprve převeďte soubor projektu a aktualizujte závislosti. Jak to uděláte, zobrazí se chyby sestavení projektu. V dalších krocích provedete odpovídající změny, abyste tyto chyby odebrali.
Soubor projektu
Následující příklad je .csproj
soubor projektu, který používá .NET 8 ve verzi 4.x:
<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>
Pomocí jednoho z následujících postupů aktualizujte tento soubor XML tak, aby běžel v izolovaném pracovním modelu:
Tyto kroky předpokládají místní projekt jazyka C# a pokud vaše aplikace místo toho používá skript jazyka C# (.csx
soubory), měli byste před pokračováním převést na projektový model .
V souboru projektu XML jsou vyžadovány .csproj
následující změny:
Nastavte hodnotu
PropertyGroup
.TargetFramework
nanet8.0
.Nastavte hodnotu
PropertyGroup
.AzureFunctionsVersion
nav4
.Přidejte následující
OutputType
prvek doPropertyGroup
:<OutputType>Exe</OutputType>
V sadě
ItemGroup
.PackageReference
nahraďte odkaz naMicrosoft.NET.Sdk.Functions
balíček následujícími odkazy:<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" />
Poznamenejte si všechny odkazy na jiné balíčky v
Microsoft.Azure.WebJobs.*
oborech názvů. Tyto balíčky nahradíte v pozdějším kroku.Přidejte následující nové
ItemGroup
:<ItemGroup> <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/> </ItemGroup>
Po provedení těchto změn by aktualizovaný projekt měl vypadat jako v následujícím příkladu:
<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>
Změna cílové architektury projektu může také vyžadovat změny částí sady nástrojů mimo kód projektu. V nástroji VS Code může být například potřeba aktualizovat azureFunctions.deploySubpath
nastavení rozšíření prostřednictvím uživatelských nastavení nebo souboru projektu .vscode/settings.json
. V rámci kroků sestavení nebo kanálu CI/CD zkontrolujte všechny závislosti na verzi architektury, které můžou existovat mimo kód projektu.
Odkazy na balíčky
Při migraci na izolovaný pracovní model je potřeba změnit balíčky, na které odkazuje vaše aplikace.
Pokud jste to ještě neudělali, aktualizujte projekt tak, aby odkazovat na nejnovější stabilní verze:
V závislosti na aktivačních událostech a vazbách, které vaše aplikace používá, může být potřeba, aby odkazovala na jinou sadu balíčků. Následující tabulka uvádí nahrazení některých nejčastěji používaných rozšíření:
Scénář | Změny odkazů na balíčky |
---|---|
Trigger časovače | Přidání Microsoft.Azure.Functions.Worker.Extensions.Timer |
Vazby služby Storage | NahraditMicrosoft.Azure.WebJobs.Extensions.Storage with Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs, Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues a Microsoft.Azure.Functions.Worker.Extensions.Tables |
Vazby objektů blob | Nahrazení odkazů naMicrosoft.Azure.WebJobs.Extensions.Storage.Blobs s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs |
Vazby front | Nahrazení odkazů naMicrosoft.Azure.WebJobs.Extensions.Storage.Queues s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues |
Vazby tabulek | Nahrazení odkazů naMicrosoft.Azure.WebJobs.Extensions.Tables s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.Tables |
Vazby databáze Cosmos | Nahrazení odkazů naMicrosoft.Azure.WebJobs.Extensions.CosmosDB a/nebo Microsoft.Azure.WebJobs.Extensions.DocumentDB s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.CosmosDB |
Vazby služby Service Bus | Nahrazení odkazů naMicrosoft.Azure.WebJobs.Extensions.ServiceBus s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.ServiceBus |
Vazby služby Event Hubs | Nahrazení odkazů naMicrosoft.Azure.WebJobs.Extensions.EventHubs s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.EventHubs |
Vazby Event Gridu | Nahrazení odkazů naMicrosoft.Azure.WebJobs.Extensions.EventGrid s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.EventGrid |
Vazby služby SignalR | Nahrazení odkazů naMicrosoft.Azure.WebJobs.Extensions.SignalRService s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.SignalRService |
Odolná služba Functions | Nahrazení odkazů naMicrosoft.Azure.WebJobs.Extensions.DurableTask s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.DurableTask |
Odolná služba Functions (Zprostředkovatel úložiště SQL) |
Nahrazení odkazů naMicrosoft.DurableTask.SqlServer.AzureFunctions s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer |
Odolná služba Functions (Zprostředkovatel úložiště Netherite) |
Nahrazení odkazů naMicrosoft.Azure.DurableTask.Netherite.AzureFunctions s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite |
Vazby služby Sendgrid | Nahrazení odkazů naMicrosoft.Azure.WebJobs.Extensions.SendGrid s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.SendGrid |
Vazby Kafka | Nahrazení odkazů naMicrosoft.Azure.WebJobs.Extensions.Kafka s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.Kafka |
Vazby RabbitMQ | Nahrazení odkazů naMicrosoft.Azure.WebJobs.Extensions.RabbitMQ s nejnovější verzí Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ |
Injektáž závislostí a konfigurace spuštění |
Odebrání odkazů naMicrosoft.Azure.Functions.Extensions (Izolovaný model pracovního procesu tuto funkci poskytuje ve výchozím nastavení.) |
Úplný seznam rozšíření, která je potřeba vzít v úvahu, najdete v dokumentaci jednotlivých rozšíření k úplným pokynům k instalaci izolovaného modelu procesu. Nezapomeňte nainstalovat nejnovější stabilní verzi všech balíčků, na které cílíte.
Tip
Všechny změny verzí rozšíření během tohoto procesu můžou vyžadovat host.json
aktualizaci souboru. Nezapomeňte si přečíst dokumentaci jednotlivých rozšíření, která používáte.
Například rozšíření Service Bus má zásadní změny struktury mezi verzemi 4.x a 5.x. Další informace najdete v tématu Vazby služby Azure Service Bus pro Azure Functions.
Aplikace izolovaného Microsoft.Azure.WebJobs.*
pracovního modelu by neměla odkazovat na žádné balíčky v oborech názvů nebo Microsoft.Azure.Functions.Extensions
. Pokud na tyto odkazy máte nějaké odkazy, měly by se odebrat.
Tip
Vaše aplikace může také záviset na typech sady Azure SDK, a to buď jako součást triggerů a vazeb, nebo jako samostatná závislost. Tuto příležitost byste měli využít také k jejich aktualizaci. Nejnovější verze rozšíření Functions fungují s nejnovějšími verzemi sady Azure SDK pro .NET, téměř všechny balíčky, pro které se jedná o formulář Azure.*
.
Program.cs soubor
Při migraci na spuštění v izolovaném pracovním procesu musíte do projektu přidat Program.cs
soubor s následujícím obsahem:
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();
Tento příklad zahrnuje integraci ASP.NET Core ke zlepšení výkonu a poskytnutí známého programovacího modelu, když vaše aplikace používá triggery HTTP. Pokud nemáte v úmyslu používat triggery HTTP, můžete volání ConfigureFunctionsWebApplication
nahradit voláním ConfigureFunctionsWorkerDefaults
. Pokud to uděláte, můžete odkaz odebrat Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore
ze souboru projektu. Pokud ale chcete dosáhnout nejlepšího výkonu, a to i u funkcí s jinými typy triggerů, měli byste zachovat FrameworkReference
ASP.NET Core.
Soubor Program.cs
nahradí všechny soubory, které mají FunctionsStartup
atribut, což je obvykle Startup.cs
soubor. Na místech, kde by váš FunctionsStartup
kód odkazoval IFunctionsHostBuilder.Services
, můžete místo toho přidat příkazy v rámci .ConfigureServices()
metody HostBuilder
v souboru .Program.cs
Další informaceoch Program.cs
Mezi výše uvedené výchozí Program.cs
příklady patří nastavení integrace Application Insights pro izolovaný model pracovního procesu. Ve svém Program.cs
nástroji musíte také nakonfigurovat veškeré filtrování protokolů, které by se mělo vztahovat na protokoly pocházející z kódu v projektu. V izolovaném modelu host.json
pracovního procesu soubor řídí pouze události generované modulem runtime hostitele služby Functions. Pokud pravidla filtrování Program.cs
nenakonfigurujete, můžou se v telemetrii zobrazovat rozdíly na úrovních protokolu, které jsou k dispozici pro různé kategorie.
I když můžete registrovat vlastní zdroje konfigurace jako součást HostBuilder
projektu, mějte na paměti, že tyto zdroje se vztahují pouze na kód v projektu. Platforma vyžaduje také konfiguraci triggeru a vazby a tato konfigurace by měla být poskytována prostřednictvím nastavení aplikace, odkazů na key vault nebo funkcí odkazů na konfiguraci aplikací.
Jakmile přesunete všechno od jakéhokoli existujícího FunctionsStartup
Program.cs
souboru do souboru, můžete odstranit FunctionsStartup
atribut a třídu, na kterou byl použit.
Změny podpisu funkce
Mezi modelem v procesu a izolovaným pracovním modelem se mění některé klíčové typy. Mnoho z nich souvisí s atributy, parametry a návratové typy, které tvoří podpis funkce. Pro každou z vašich funkcí musíte provést změny v těchto parametrech:
- Atribut funkce (který také nastaví název funkce)
- Jak funkce získá
ILogger
/ILogger<T>
- Atributy a parametry triggeru a vazeb
Zbývající část této části vás provede jednotlivými kroky.
Atributy funkce
Atribut Function
v izolovaném modelu pracovního procesu nahradí FunctionName
atribut. Nový atribut má stejný podpis a jediný rozdíl je v názvu. Proto můžete pouze provést nahrazení řetězce v rámci projektu.
Protokolování
V modelu v procesu můžete do funkce zahrnout volitelný ILogger
parametr nebo můžete k získání objektu ILogger<T>
použít injektáž závislostí . Pokud aplikace už injektáž závislostí používala, fungují stejné mechanismy v izolovaném modelu pracovního procesu.
Pro všechny funkce, které závisely na parametru ILogger
metody, ale musíte provést změnu. K získání injektáže závislostí se doporučuje použít injektáž závislostí ILogger<T>
. Pomocí následujících kroků migrujte mechanismus protokolování funkce:
Do třídy funkce přidejte
private readonly ILogger<MyFunction> _logger;
vlastnost a nahraďteMyFunction
ji názvem vaší třídy funkcí.Vytvořte konstruktor pro vaši třídu funkcí, která přebírá jako
ILogger<T>
parametr:public MyFunction(ILogger<MyFunction> logger) { _logger = logger; }
Nahraďte obě instance
MyFunction
v předchozím fragmentu kódu názvem vaší třídy funkcí.V případě operací protokolování v kódu funkce nahraďte odkazy na parametr znakem
ILogger
_logger
.ILogger
Odeberte parametr z podpisu funkce.
Další informace najdete v tématu Protokolování v izolovaném modelu pracovního procesu.
Aktivační události a změny vazeb
Když jste změnili odkazy na balíčky v předchozím kroku, zavedli jste chyby pro triggery a vazby, které teď opravíte:
Odeberte všechny
using Microsoft.Azure.WebJobs;
příkazy.using Microsoft.Azure.Functions.Worker;
Přidejte příkaz.U každého atributu vazby změňte název atributu, jak je uvedeno v referenční dokumentaci, kterou najdete v indexu Podporovaných vazeb. Obecně platí, že názvy atributů se mění takto:
- Triggery obvykle zůstávají pojmenované stejným způsobem. Je to například
QueueTrigger
název atributu pro oba modely. - Vstupní vazby obvykle potřebují k jejich názvu přidat "Input". Pokud jste například použili
CosmosDB
atribut vstupní vazby v modelu procesu, atribut by nyní bylCosmosDBInput
. - Výstupní vazby obvykle vyžadují přidání výstupu do jejich názvu. Pokud jste například použili
Queue
atribut výstupní vazby v modelu procesu, tento atribut by nyní bylQueueOutput
.
- Triggery obvykle zůstávají pojmenované stejným způsobem. Je to například
Aktualizujte parametry atributu tak, aby odrážely verzi izolovaného pracovního modelu, jak je uvedeno v referenční dokumentaci vazby.
Například v modelu v procesu je výstupní vazba objektu blob reprezentována atributem
[Blob(...)]
, který obsahujeAccess
vlastnost. V izolovaném pracovním modelu by[BlobOutput(...)]
byl atribut výstupu objektu blob . Vazba již nevyžadujeAccess
vlastnost, takže parametr lze odebrat. Takže[Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")]
by se stal[BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")]
.Přesuňte výstupní vazby ze seznamu parametrů funkce. Pokud máte jenom jednu výstupní vazbu, můžete ji použít na návratový typ funkce. Pokud máte více výstupů, vytvořte novou třídu s vlastnostmi pro každý výstup a použijte atributy na tyto vlastnosti. Další informace najdete v tématu Více výstupních vazeb.
Projděte si referenční dokumentaci jednotlivých vazeb k typům, se které můžete svázat. V některých případech může být potřeba typ změnit. Pokud verze modelu v procesu použila
IAsyncCollector<T>
výstupní vazby, můžete ji nahradit vazbou na pole cílového typu:T[]
. Můžete také zvážit nahrazení výstupní vazby objektem klienta pro službu, kterou představuje, buď jako typ vazby pro vstupní vazbu, pokud je k dispozici, nebo vložením klienta sami.Pokud vaše funkce obsahuje
IBinder
parametr, odeberte ho. Nahraďte funkce objektem klienta služby, který představuje, buď jako typ vazby pro vstupní vazbu, pokud je k dispozici, nebo vložením klienta sami.Aktualizujte kód funkce tak, aby fungoval s novými typy.
local.settings.json soubor
Soubor local.settings.json se používá pouze při místním spuštění. Informace najdete v tématu Místní soubor nastavení.
Při migraci z probíhajícího procesu na spuštění v izolovaném pracovním procesu je potřeba změnit FUNCTIONS_WORKER_RUNTIME
hodnotu na dotnet-isolated. Ujistěte se, že soubor local.settings.json obsahuje alespoň následující prvky:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
}
}
Hodnota, kterou máte pro AzureWebJobsStorage, se může lišit. V rámci migrace nemusíte měnit její hodnotu.
host.json soubor
Soubor host.json
nevyžaduje žádné změny. Pokud ale vaše konfigurace Application Insights v tomto souboru pochází z projektu modelu v procesu, možná budete chtít v souboru provést další změny Program.cs
. Soubor host.json
řídí pouze protokolování z modulu runtime hostitele Functions a v izolovaném pracovním modelu pocházejí některé z těchto protokolů přímo z vaší aplikace a poskytují větší kontrolu. Podrobnosti o filtrování těchto protokolů najdete v tématu Správa úrovní protokolů v izolovaném pracovním modelu .
Jiné změny kódu
V této části jsou zvýrazněné další změny kódu, které je potřeba vzít v úvahu při práci s migrací. Tyto změny nejsou potřeba pro všechny aplikace, ale měli byste vyhodnotit, jestli jsou pro vaše scénáře relevantní.
Serializace JSON
Ve výchozím nastavení se izolovaný pracovní model používá System.Text.Json
pro serializaci JSON. Pokud chcete upravit možnosti serializátoru nebo přepnout na JSON.NET (Newtonsoft.Json
), přečtěte si tyto pokyny.
Úrovně protokolů a filtrování Application Insights
Protokoly je možné odesílat do Application Insights z modulu runtime hostitele Functions i kódu ve vašem projektu. Umožňuje host.json
konfigurovat pravidla pro protokolování hostitele, ale pro řízení protokolů pocházejících z kódu budete muset nakonfigurovat pravidla filtrování jako součást vašeho Program.cs
kódu . Podrobnosti o filtrování těchto protokolů najdete v tématu Správa úrovní protokolů v izolovaném pracovním modelu .
Ukázkové migrace funkcí
Příklad triggeru HTTP
Trigger HTTP pro model v procesu může vypadat jako v následujícím příkladu:
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"]}!");
}
}
}
Trigger HTTP pro migrovanou verzi může vypadat jako v následujícím příkladu:
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"]}!");
}
}
}
Aktualizace aplikace funkcí v Azure
Aktualizace aplikace funkcí na izolovaný model zahrnuje dvě změny, které by se měly dokončit společně, protože pokud dokončíte jenom jednu, aplikace je ve stavu chyby. Obě tyto změny také způsobí restartování procesu aplikace. Z těchto důvodů byste měli provést aktualizaci pomocí přípravného slotu. Přípravné sloty pomáhají minimalizovat výpadky vaší aplikace a umožňují otestovat a ověřit migrovaný kód s aktualizovanou konfigurací v Azure. Plně migrovanou aplikaci pak můžete nasadit do produkčního slotu prostřednictvím operace prohození.
Důležité
Pokud nasazená datová část aplikace neodpovídá nakonfigurovanému modulu runtime, bude ve stavu chyby. Během procesu migrace aplikaci umístíte do tohoto stavu, ideálně jen dočasně. Sloty nasazení pomáhají zmírnit dopad tohoto problému, protože stav chyby se vyřeší ve vašem přípravném (neprodukčním) prostředí předtím, než se změny použijí jako jedna aktualizace v produkčním prostředí. Sloty také chrání proti chybám a umožňují vám odhalit všechny další problémy před dosažením produkčního prostředí.
Během tohoto procesu se můžou stále zobrazovat chyby v protokolech pocházejících z přípravného (neprodukčního) slotu. To se očekává, i když by se měly při procházení kroků odejít. Před provedením operace prohození slotů byste měli potvrdit, že se tyto chyby přestanou vygenerovat a že vaše aplikace funguje podle očekávání.
Pomocí následujících kroků aktualizujte aplikaci funkcí na izolovaný model pracovního procesu pomocí slotů nasazení:
Pokud jste to ještě neudělali, vytvořte slot nasazení. Můžete se také seznámit s procesem prohození slotů a zajistit, abyste mohli provádět aktualizace stávající aplikace s minimálním přerušením.
Změňte konfiguraci přípravného (neprodukčního) slotu tak, aby používal izolovaný pracovní model nastavením
FUNCTIONS_WORKER_RUNTIME
nadotnet-isolated
.FUNCTIONS_WORKER_RUNTIME
by neměl být označen jako "nastavení slotu".Pokud cílíte také na jinou verzi .NET v rámci aktualizace, měli byste také změnit konfiguraci zásobníku. Postup najdete v pokynech k aktualizaci konfigurace zásobníku pro izolovaný pracovní model. Stejné pokyny použijete pro všechny budoucí aktualizace verzí .NET, které provedete.
Pokud máte nějaké automatizované zřizování infrastruktury, jako je kanál CI/CD, ujistěte se, že jsou automatizace také aktualizované, aby byly
FUNCTIONS_WORKER_RUNTIME
nastavenédotnet-isolated
a aby cílily na správnou verzi .NET.Publikujte migrovaný projekt do přípravného (neprodukčního) slotu vaší aplikace funkcí.
Pokud pomocí sady Visual Studio publikujete projekt modelu izolovaného pracovního procesu do existující aplikace nebo slotu, který používá model v procesu, můžete zároveň dokončit předchozí krok. Pokud jste předchozí krok nedokončili, Visual Studio vás vyzve k aktualizaci aplikace funkcí během nasazování. Visual Studio tuto operaci prezentuje jako jednu operaci, ale stále se jedná o dvě samostatné operace. V protokolech se můžou během dočasného stavu stále zobrazovat chyby z přípravného (neprodukčního) slotu.
Ověřte, že vaše aplikace funguje podle očekávání v přípravném (neprodukčním) slotu.
Proveďte operaci prohození slotů. Tím se použijí změny, které jste provedli v přípravném (neprodukčním) slotu v produkčním slotu. Prohození slotů probíhá jako jedna aktualizace, která zabraňuje zavedení dočasného chybového stavu v produkčním prostředí.
Ověřte, že vaše aplikace funguje podle očekávání v produkčním slotu.
Po dokončení těchto kroků se migrace dokončí a vaše aplikace běží v izolovaném modelu. Gratulujeme! Podle potřeby opakujte kroky z této příručky pro všechny ostatní aplikace, které potřebují migraci.