Migrace aplikací ze služby Azure Functions verze 1.x na verzi 4.x
Důležité
Modul runtime Azure Functions nepodporuje Javu verze 1.x. Možná chcete migrovat aplikaci v Javě z verze 3.x na verzi 4.x. Pokud migrujete aplikaci funkcí verze 1.x, vyberte výše jazyk C# nebo JavaScript.
Důležité
TypeScript nepodporuje modul runtime Azure Functions verze 1.x. Možná chcete migrovat aplikaci TypeScript z verze 3.x na verzi 4.x. Pokud migrujete aplikaci funkcí verze 1.x, vyberte výše jazyk C# nebo JavaScript.
Důležité
Modul runtime Azure Functions nepodporuje PowerShell verze 1.x. Možná chcete migrovat aplikaci PowerShellu z verze 3.x na verzi 4.x. Pokud migrujete aplikaci funkcí verze 1.x, vyberte výše jazyk C# nebo JavaScript.
Důležité
Modul runtime Azure Functions nepodporuje Python verze 1.x. Možná chcete migrovat aplikaci v Pythonu z verze 3.x na verzi 4.x. Pokud migrujete aplikaci funkcí verze 1.x, vyberte výše jazyk C# nebo JavaScript.
Důležité
Podpora pro modul runtime Azure Functions verze 1.x skončí 14. září 2026. Důrazně doporučujeme migrovat aplikace na verzi 4.x podle pokynů v tomto článku.
Tento článek vás provede procesem bezpečné migrace aplikace funkcí, aby běžela ve verzi 4.x modulu runtime Služby Functions. Vzhledem k tomu, že pokyny pro migraci projektů jsou závislé na jazyce, nezapomeňte zvolit vývojový jazyk ze selektoru v horní části článku.
Pokud používáte modul runtime verze 1.x ve službě Azure Stack Hub, přečtěte si nejprve důležité informace o službě Azure Stack Hub .
Identifikace aplikací funkcí, které se mají migrovat
Pomocí následujícího skriptu PowerShellu vygenerujte seznam aplikací funkcí ve vašem předplatném, které aktuálně cílí na verzi 1.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 '*1*')
{
$AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
}
}
$AppInfo
Zvolte cílovou verzi .NET.
Ve verzi 1.x modulu runtime Functions cílí aplikace funkcí C# na rozhraní .NET Framework.
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 | Preview3 | Izolovaný model pracovního procesu |
.NET 8 | LTS (konec podpory 10. listopadu 2026) | Model izolovaného pracovního procesu Model v procesu2 |
.NET 6 | LTS (konec podpory 12. listopadu 2024) | 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.
3 Podrobnosti o podpoře, aktuálních omezeních a pokynech k používání verze Preview najdete v izolovaném pracovním modelu v izolovaném pracovním modelu .
Tip
Pokud vaše aplikace nezávisí jenom na knihovně nebo rozhraní API dostupné pro .NET Framework, doporučujeme aktualizovat na .NET 8 v izolovaném pracovním modelu. Řada aplikací ve verzi 1.x cíl .NET Framework je pouze proto, že byla k dispozici při jejich vytvoření. Další funkce jsou k dispozici pro novější verze .NET a pokud vaše aplikace není nucena zůstat v rozhraní .NET Framework kvůli závislosti, měli byste cílit na novější verzi. .NET 8 je plně vydaná verze s nejdelším oknem podpory z .NET.
I když se místo toho můžete rozhodnout použít model v procesu, nedoporučuje se to, pokud se tomu dá vyhnout. Podpora modelu v procesu skončí 10. listopadu 2026, takže před tím budete muset přejít na izolovaný model pracovního procesu. Při migraci na verzi 4.x se sníží celková požadovaná úsilí a izolovaný pracovní model poskytne vaší aplikaci další výhody, včetně možnosti snadněji cílit na budoucí verze .NET. Pokud přecházíte na model izolovaného pracovního procesu, pomocník pro upgrade platformy .NET může také zpracovat řadu nezbytných změn kódu za vás.
Tato příručka neobsahuje konkrétní příklady pro .NET 6. 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 modulu runtime Functions verze 4.x byste měli provést následující úlohy:
- Zkontrolujte seznam změn chování po verzi 1.x. Migrace z verze 1.x na verzi 4.x může také ovlivnit vazby.
- Proveďte kroky v části Migrace místního projektu a proveďte migraci místního projektu na verzi 4.x.
- Po migraci projektu plně otestujte aplikaci místně pomocí verze 4.x nástrojů Azure Functions Core Tools.
- Aktualizujte aplikaci funkcí v Azure na novou verzi. Pokud potřebujete minimalizovat výpadky, zvažte použití přípravného slotu k otestování a ověření migrované aplikace v Azure na nové verzi modulu runtime. Pak můžete aplikaci nasadit s aktualizovaným nastavením verze do produkčního slotu. Další informace najdete v tématu Aktualizace pomocí slotů.
- Publikujte migrovaný projekt do aktualizované aplikace funkcí.
Když pomocí sady Visual Studio publikujete projekt verze 4.x do existující aplikace funkcí v nižší verzi, zobrazí se výzva k tomu, aby visual Studio během nasazování aktualizovalo aplikaci funkcí na verzi 4.x. Tato aktualizace používá stejný proces definovaný v aktualizaci bez slotů.
Migrace místního projektu
Následující části popisují aktualizace, které musíte provést v souborech projektu jazyka C#, aby bylo možné spouštět v některé z podporovaných verzí .NET ve službě Functions verze 4.x. Zobrazené aktualizace jsou společné pro většinu projektů. Kód projektu může vyžadovat aktualizace, které nejsou uvedené v tomto článku, zejména při použití vlastních balíčků NuGet.
Migrace aplikace funkcí jazyka C# z verze 1.x na verzi 4.x modulu runtime Functions vyžaduje, abyste v kódu projektu udělali změny. Mnohé z těchto změn jsou výsledkem změn v jazyce C# a rozhraních .NET API.
Zvolte kartu, která odpovídá vaší cílové verzi .NET a požadovanému modelu procesu (v procesu nebo izolovanému pracovnímu procesu).
Tip
Pokud přecházíte na verzi LTS nebo STS .NET pomocí izolovaného pracovního modelu, můžete pomocníka s upgradem .NET použít k automatickému provádění mnoha změn uvedených v následujících částech.
Soubor projektu
Následující příklad je .csproj
soubor projektu, který běží na verzi 1.x:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net48</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
</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>
Pomocí jednoho z následujících postupů aktualizujte tento soubor XML tak, aby běžel ve službě Functions verze 4.x:
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ěny balíčků a oborů názvů
Na základě modelu, na který migrujete, možná budete muset aktualizovat nebo změnit balíčky, na které odkazuje vaše aplikace. Když použijete cílové balíčky, musíte aktualizovat obor názvů příkazů using a některé typy, na které odkazujete. Účinek těchto změn using
oboru názvů můžete zobrazit na příkazy v příkladech šablony triggeru HTTP dále v tomto článku.
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.*
.
Vazby Notification Hubs a Mobile Apps jsou podporovány pouze ve verzi 1.x modulu runtime. Při upgradu na verzi 4.x modulu runtime je potřeba tyto vazby odebrat ve prospěch práce s těmito službami přímo pomocí jejich sad SDK.
Program.cs soubor
Ve většině případů migrace vyžaduje, abyste do projektu přidali následující soubor 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();
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.
host.json soubor
Nastavení v souboru host.json platí na úrovni aplikace funkcí místně i v Azure. Ve verzi 1.x je soubor host.json prázdný nebo obsahuje některá nastavení, která platí pro všechny funkce v aplikaci funkcí. Další informace najdete v tématu Host.json v1. Pokud soubor host.json obsahuje hodnoty nastavení, zkontrolujte případné změny ve formátu host.json v2.
Chcete-li spustit na verzi 4.x, musíte přidat "version": "2.0"
do souboru host.json. Měli byste také zvážit přidání logging
do konfigurace, jak je znázorněno v následujících příkladech:
{
"version": "2.0",
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"excludedTypes": "Request"
},
"enableLiveMetricsFilters": true
}
}
}
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 .
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í. Ve verzi 1.x má soubor local.settings.json pouze dvě požadované hodnoty:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
"AzureWebJobsDashboard": "AzureWebJobsStorageConnectionStringValue"
}
}
Při migraci na verzi 4.x se ujistěte, že soubor local.settings.json obsahuje alespoň následující prvky:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
}
}
Poznámka:
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.
Změny názvu třídy
Některé klíčové třídy změnily názvy mezi verzí 1.x a verzí 4.x. Tyto změny jsou výsledkem změn v rozhraních .NET API nebo rozdílech mezi procesem v procesu a izolovaným pracovním procesem. Následující tabulka označuje klíčové třídy .NET používané funkcemi, které by se mohly při migraci změnit:
Verze 1.x | .NET 8 |
---|---|
FunctionName (atribut) |
Function (atribut) |
TraceWriter |
ILogger<T> , ILogger |
HttpRequestMessage |
HttpRequestData , HttpRequest (s využitím integrace ASP.NET Core) |
HttpResponseMessage |
HttpResponseData , IActionResult (s využitím integrace ASP.NET Core) |
V vazbách můžou být také rozdíly mezi názvy tříd. Další informace najdete v referenčních článcích pro konkrétní vazby.
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í. Nezapomeňte zkontrolovat změny chování po verzi 1.x a zjistit další změny, které možná budete muset provést v projektu.
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 .
Šablona triggeru HTTP
Většina změn kódu mezi verzí 1.x a verzí 4.x se dá zobrazit ve funkcích aktivovaných protokolem HTTP. Šablona triggeru HTTP pro verzi 1.x vypadá jako v následujícím příkladu:
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Host;
namespace Company.Function
{
public static class HttpTriggerCSharp
{
[FunctionName("HttpTriggerCSharp")]
public static async Task<HttpResponseMessage>
Run([HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post",
Route = null)]HttpRequestMessage req, TraceWriter log)
{
log.Info("C# HTTP trigger function processed a request.");
// parse query parameter
string name = req.GetQueryNameValuePairs()
.FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
.Value;
if (name == null)
{
// Get request body
dynamic data = await req.Content.ReadAsAsync<object>();
name = data?.name;
}
return name == null
? req.CreateResponse(HttpStatusCode.BadRequest,
"Please pass a name on the query string or in the request body")
: req.CreateResponse(HttpStatusCode.OK, "Hello " + name);
}
}
}
Šablona triggeru HTTP ve verzi 4.x vypadá 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 projektu na Azure Functions 4.x:
Aktualizujte místní instalaci nástrojů Azure Functions Core Tools na verzi 4.x.
Přejděte na jednu z Node.js verzí podporovaných ve verzi 4.x.
Přidejte do host.json oba
version
prvky,extensionBundle
aby vypadalo jako v následujícím příkladu:{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[3.3.0, 4.0.0)" } }
Element
extensionBundle
je povinný, protože po verzi 1.x jsou vazby zachovány jako externí balíčky. Další informace najdete v tématu Balíčky rozšíření.Aktualizujte soubor local.settings.json tak, aby obsahuje alespoň následující prvky:
{ "IsEncrypted": false, "Values": { "AzureWebJobsStorage": "UseDevelopmentStorage=true", "FUNCTIONS_WORKER_RUNTIME": "node" } }
Nastavení
AzureWebJobsStorage
může být emulátor úložiště Azurite nebo skutečný účet úložiště Azure. Další informace naleznete v tématu Emulátor místního úložiště.
Aktualizace aplikace funkcí v Azure
Před publikováním migrovaného projektu musíte aktualizovat modul runtime hostitele aplikace funkcí v Azure na verzi 4.x. Verze modulu runtime používaná hostitelem Služby Functions je řízena FUNCTIONS_EXTENSION_VERSION
nastavením aplikace, ale v některých případech se musí aktualizovat i jiná nastavení. Změny kódu i změny nastavení aplikace vyžadují restartování aplikace funkcí.
Nejjednodušší způsob je aktualizovat bez slotů a pak znovu publikovat projekt aplikace. Můžete také minimalizovat výpadky aplikace a zjednodušit vrácení zpět aktualizací pomocí slotů.
Aktualizace bez slotů
Nejjednodušší způsob, jak aktualizovat verzi 4.x, je nastavit FUNCTIONS_EXTENSION_VERSION
nastavení aplikace na ~4
vaši aplikaci funkcí v Azure. Na webu s sloty musíte postupovat jinak .
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
Musíte také nastavit jiné nastavení, které se liší mezi Windows a Linuxem.
Při spouštění ve Windows musíte také povolit .NET 6.0, což vyžaduje verze 4.x modulu runtime.
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
.NET 6 se vyžaduje pro aplikace funkcí v libovolném jazyce běžícím ve Windows.
V tomto příkladu nahraďte <APP_NAME>
názvem vaší aplikace funkcí a <RESOURCE_GROUP_NAME>
názvem skupiny prostředků.
Teď můžete znovu publikovat projekt aplikace, který byl migrován, aby běžel ve verzi 4.x.
Aktualizace pomocí slotů
Použití slotů nasazení je dobrým způsobem, jak aktualizovat aplikaci funkcí na modul runtime v4.x z předchozí verze. Pomocí přípravného slotu můžete aplikaci spustit na nové verzi modulu runtime v přípravném slotu a po ověření přepnout do produkčního prostředí. Sloty také poskytují způsob, jak minimalizovat výpadky během aktualizace. Pokud potřebujete minimalizovat výpadky, postupujte podle kroků v aktualizaci minimálního výpadku.
Po ověření aplikace v aktualizovaném slotu můžete aplikaci a nastavení nové verze prohodit do produkčního prostředí. Toto prohození vyžaduje nastavení WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
v produkčním slotu. Způsob přidání tohoto nastavení má vliv na množství výpadků potřebných pro aktualizaci.
Standardní aktualizace
Pokud vaše aplikace funkcí s podporou slotu dokáže zpracovat výpadek úplného restartování, můžete nastavení aktualizovat WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS
přímo v produkčním slotu. Vzhledem k tomu, že změna tohoto nastavení přímo v produkčním slotu způsobí restartování, které ovlivňuje dostupnost, zvažte tuto změnu v době omezeného provozu. Potom můžete prohodit aktualizovanou verzi z přípravného slotu.
Rutina Update-AzFunctionAppSetting
PowerShellu v současné době nepodporuje sloty. Musíte použít Azure CLI nebo Azure Portal.
K nastavení
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
v produkčním slotu použijte následující příkaz:az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
V tomto příkladu nahraďte
<APP_NAME>
názvem vaší aplikace funkcí a<RESOURCE_GROUP_NAME>
názvem skupiny prostředků. Tento příkaz způsobí restartování aplikace spuštěné v produkčním slotu.K nastavení
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS
v přípravném slotu použijte následující příkaz:az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Pomocí následujícího příkazu změňte
FUNCTIONS_EXTENSION_VERSION
a aktualizujte přípravný slot na novou verzi modulu runtime:az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Verze 4.x modulu runtime Functions vyžaduje .NET 6 ve Windows. V Linuxu musí aplikace .NET také aktualizovat na .NET 6. Pomocí následujícího příkazu spusťte modul runtime v .NET 6:
Při spouštění ve Windows musíte také povolit .NET 6.0, což vyžaduje verze 4.x modulu runtime.
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
.NET 6 se vyžaduje pro aplikace funkcí v libovolném jazyce běžícím ve Windows.
V tomto příkladu nahraďte
<APP_NAME>
názvem vaší aplikace funkcí a<RESOURCE_GROUP_NAME>
názvem skupiny prostředků.Pokud projekt kódu vyžadoval, aby se všechny aktualizace spouštěly ve verzi 4.x, nasaďte tyto aktualizace do přípravného slotu.
Před prohozením ověřte, že vaše aplikace funkcí funguje správně v aktualizovaném přípravném prostředí.
K prohození aktualizovaného přípravného slotu do produkčního prostředí použijte následující příkaz:
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
Minimální aktualizace výpadků
Pokud chcete minimalizovat výpadky v produkční aplikaci, můžete nastavení prohodit WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS
z přípravného slotu do produkčního prostředí. Potom můžete prohodit aktualizovanou verzi z předem připraveného přípravného slotu.
Pomocí následujícího příkazu nastavte
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
v přípravném slotu:az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Pomocí následujících příkazů prohodíte slot s novým nastavením do produkčního prostředí a zároveň obnovíte nastavení verze v přípravném slotu.
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>
Během doby mezi prohozením a obnovou verze modulu runtime při přípravném slotu se můžou zobrazit chyby z přípravného slotu. K této chybě může dojít, protože během
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
prohození dojde k odebráníFUNCTIONS_EXTENSION_VERSION
nastavení v přípravné fázi. Bez nastavení verze je váš slot ve špatném stavu. Aktualizace verze v přípravném slotu hned po prohození by měla slot vrátit zpět do dobrého stavu a v případě potřeby zavolat vrácení změn zpět. Jakékoli vrácení prohození ale také vyžaduje, abyste před přepnutím zpět odebraliWEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
přímo z produkčního prostředí, abyste zabránili stejným chybám v produkčním prostředí, které se projeví v přípravném prostředí. Tato změna v produkčním nastavení by pak způsobila restartování.K opětovnému nastavení
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
v přípravném slotu použijte následující příkaz:az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
V tuto chvíli se oba sloty nastavily
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
.Pomocí následujícího příkazu změňte
FUNCTIONS_EXTENSION_VERSION
a aktualizujte přípravný slot na novou verzi modulu runtime:az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Verze 4.x modulu runtime Functions vyžaduje .NET 6 ve Windows. V Linuxu musí aplikace .NET také aktualizovat na .NET 6. Pomocí následujícího příkazu spusťte modul runtime v .NET 6:
Při spouštění ve Windows musíte také povolit .NET 6.0, což vyžaduje verze 4.x modulu runtime.
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
.NET 6 se vyžaduje pro aplikace funkcí v libovolném jazyce běžícím ve Windows.
V tomto příkladu nahraďte
<APP_NAME>
názvem vaší aplikace funkcí a<RESOURCE_GROUP_NAME>
názvem skupiny prostředků.Pokud projekt kódu vyžadoval, aby se všechny aktualizace spouštěly ve verzi 4.x, nasaďte tyto aktualizace do přípravného slotu.
Před prohozením ověřte, že vaše aplikace funkcí funguje správně v aktualizovaném přípravném prostředí.
K prohození aktualizovaného a předzbrojeného přípravného slotu do produkčního prostředí použijte následující příkaz:
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
Změny chování po verzi 1.x
Tato část obsahuje podrobnosti o změnách provedených po verzi 1.x v chování triggerů i vazeb i v základních funkcích a chováních funkcí.
Změny triggerů a vazeb
Počínaje verzí 2.x musíte nainstalovat rozšíření pro konkrétní triggery a vazby používané funkcemi ve vaší aplikaci. Jedinou výjimkou pro tyto triggery HTTP a časovače, které nevyžadují rozšíření. Další informace naleznete v tématu Registrace a instalace rozšíření vazeb.
V function.json nebo atributech funkce mezi verzemi je také několik změn. Například vlastnost Event Hubs path
je nyní eventHubName
. Odkazy na dokumentaci pro každou vazbu najdete v existující tabulce vazeb.
Změny funkcí a funkcí
Několik funkcí bylo odebráno, aktualizováno nebo nahrazeno po verzi 1.x. Tato část podrobně popisuje změny, které se zobrazí v novějších verzích po použití verze 1.x.
Ve verzi 2.x byly provedeny následující změny:
Klíče pro volání koncových bodů HTTP se vždy ukládají zašifrované ve službě Azure Blob Storage. Ve verzi 1.x byly klíče ve výchozím nastavení uložené ve službě Soubory Azure. Když migrujete aplikaci z verze 1.x na verzi 2.x, stávající tajné kódy, které jsou ve službě Soubory Azure, se resetují.
Modul runtime verze 2.x neobsahuje integrovanou podporu pro poskytovatele webhooků. Tato změna byla provedena kvůli zlepšení výkonu. Triggery HTTP můžete dál používat jako koncové body pro webhooky.
Pokud chcete zlepšit monitorování, řídicí panel WebJobs na portálu, který toto nastavení použil
AzureWebJobsDashboard
, se nahradí Aplikace Azure lication Insights, který toto nastavení používáAPPINSIGHTS_INSTRUMENTATIONKEY
. Další informace najdete v tématu Monitorování azure Functions.Všechny funkce v aplikaci funkcí musí sdílet stejný jazyk. Při vytváření aplikace funkcí musíte pro aplikaci zvolit zásobník modulu runtime. Zásobník modulu runtime je určen
FUNCTIONS_WORKER_RUNTIME
hodnotou v nastavení aplikace. Tento požadavek byl přidán, aby se zlepšila stopa a čas spuštění. Při místním vývoji musíte toto nastavení zahrnout také do souboru local.settings.json.Výchozí časový limit pro funkce v plánu služby App Service se změní na 30 minut. Časový limit můžete ručně změnit zpět na neomezený pomocí nastavení functionTimeout v host.json.
Omezení souběžnosti HTTP se ve výchozím nastavení implementují pro funkce plánu Consumption s výchozím nastavením 100 souběžných požadavků na instanci. Toto chování můžete změnit v
maxConcurrentRequests
nastavení v souboru host.json.Z důvodu omezení .NET Core byla odebrána podpora funkcí skriptu F# (
.fsx
souborů). Kompilované funkce jazyka F# (.fs) se stále podporují.Formát adresy URL triggerů event Gridu byl změněn tak, aby postupoval takto:
https://{app}/runtime/webhooks/{triggerName}
Názvy některých předdefinovaných vlastních metrik se po verzi 1.x změnily.
Duration
byla nahrazena znakemMaxDurationMs
,MinDurationMs
aAvgDurationMs
.Success Rate
byl také přejmenován naSuccess Rate
.
Důležité informace o službě Azure Stack Hub
App Service ve službě Azure Stack Hub nepodporuje verzi 4.x služby Azure Functions. Při plánování migrace z verze 1.x ve službě Azure Stack Hub můžete zvolit jednu z následujících možností:
- Pomocí pokynů v tomto článku proveďte migraci na verzi 4.x hostované ve veřejném cloudu Azure Functions. Místo upgradu stávající aplikace byste vytvořili novou aplikaci s použitím verze 4.x a pak do ní nasadíte upravený projekt.
- Přejděte na WebJobs hostované v plánu služby App Service ve službě Azure Stack Hub.