Migrowanie aplikacji z usługi Azure Functions w wersji 3.x do wersji 4.x

  • Artykuł

Usługa Azure Functions w wersji 4.x jest wysoce zgodna z poprzednimi wersjami 3.x. Większość aplikacji powinna bezpiecznie migrować do wersji 4.x bez konieczności wprowadzania znaczących zmian w kodzie. Aby uzyskać więcej informacji na temat wersji środowiska uruchomieniowego usługi Functions, zobacz Omówienie wersji środowiska uruchomieniowego usługi Azure Functions.

Ważne

Od 13 grudnia 2022 r. aplikacje funkcji działające w wersjach 2.x i 3.x środowiska uruchomieniowego usługi Azure Functions nie są już objęte wsparciem doatkowym. Aby uzyskać więcej informacji, zobacz Wycofane wersje.

Ten artykuł przeprowadzi Cię przez proces bezpiecznego migrowania aplikacji funkcji do uruchamiania w wersji 4.x środowiska uruchomieniowego usługi Functions. Ponieważ instrukcje migracji projektu są zależne od języka, pamiętaj, aby wybrać język programowania z selektora w górnej części artykułu.

Identyfikowanie aplikacji funkcji do migracji

Użyj następującego skryptu programu PowerShell, aby wygenerować listę aplikacji funkcji w subskrypcji, które są obecnie przeznaczone dla wersji 2.x lub 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

Wybierz docelową wersję platformy .NET

W wersji 3.x środowiska uruchomieniowego usługi Functions aplikacja funkcji języka C# jest przeznaczona dla platformy .NET Core 3.1 przy użyciu modelu w procesie lub platformy .NET 5 przy użyciu izolowanego modelu procesu roboczego.

Podczas migracji aplikacji funkcji możesz wybrać docelową wersję platformy .NET. Projekt języka C# można zaktualizować do jednej z następujących wersji platformy .NET obsługiwanych przez usługę Functions w wersji 4.x:

Wersja platformy .NET Typ wydania oficjalnych zasad pomocy technicznej platformy .NET Modelprzetwarzania funkcji 1,3
.NET 82 LTS Model izolowanego procesu roboczego
.NET 7 STS (koniec wsparcia 14 maja 2024 r.) Model izolowanego procesu roboczego
.NET 6 LTS (koniec wsparcia 12 listopada 2024 r.) Model izolowanego procesu roboczego,
Modelw procesie 3
.NET Framework 4.8 Zobacz zasady Model izolowanego procesu roboczego

1 Model izolowanego procesu roboczego obsługuje wersje platformy .NET (Long Term Support) i Standard Term Support (STS) oraz .NET Framework. Model w procesie obsługuje tylko wersje LTS platformy .NET. Aby zapoznać się z pełnym porównaniem funkcji i funkcjonalności między dwoma modelami, zobacz Różnice między procesem procesowym i izolowanym procesem roboczym .NET Azure Functions.

Wersja 2 .NET 8 nie jest jeszcze obsługiwana w modelu przetwarzania, chociaż jest dostępna w modelu izolowanego procesu roboczego. Aby uzyskać informacje na temat planów platformy .NET 8, w tym przyszłych opcji modelu przetwarzania, zobacz wpis Aktualizacja planu działania usługi Azure Functions.

3 Wsparcie kończy się dla modelu procesu 10 listopada 2026 r. Aby uzyskać więcej informacji, zobacz to ogłoszenie pomocy technicznej. Aby zapewnić ciągłą pełną obsługę, należy przeprowadzić migrację aplikacji do izolowanego modelu procesu roboczego.

Napiwek

Zalecamy zaktualizowanie do platformy .NET 8 w modelu izolowanego procesu roboczego. .NET 8 to w pełni wydana wersja z najdłuższym oknem obsługi z platformy .NET.

Chociaż zamiast tego można użyć modelu w procesie, nie jest to zalecane, jeśli można go uniknąć. Obsługa zostanie zakończona w modelu procesowym 10 listopada 2026 r., dlatego przed tym należy przejść do modelu izolowanego procesu roboczego. Wykonanie tej czynności podczas migracji do wersji 4.x spowoduje zmniejszenie całkowitego nakładu pracy, a izolowany model roboczy zapewni aplikacji dodatkowe korzyści, w tym możliwość łatwiejszego określania przyszłych wersji platformy .NET. Jeśli przechodzisz do modelu izolowanego procesu roboczego, asystent uaktualniania platformy .NET może również obsługiwać wiele niezbędnych zmian kodu.

Ten przewodnik nie przedstawia konkretnych przykładów dla platformy .NET 7 lub .NET 6 w modelu izolowanego procesu roboczego. Jeśli chcesz kierować te wersje, możesz dostosować przykłady modeli izolowanych procesów roboczych platformy .NET 8.

Przygotowanie do migracji

Jeśli jeszcze tego nie zrobiono, zidentyfikuj listę aplikacji, które muszą zostać zmigrowane w bieżącej subskrypcji platformy Azure przy użyciu programu Azure PowerShell.

Przed przeprowadzeniem migracji aplikacji do wersji 4.x środowiska uruchomieniowego usługi Functions należy wykonać następujące zadania:

  1. Przejrzyj listę zmian powodujących niezgodność z zakresu od 3.x do 4.x.
  2. Wykonaj kroki opisane w artykule Migrowanie projektu lokalnego, aby przeprowadzić migrację projektu lokalnego do wersji 4.x.
  3. Po przeprowadzeniu migracji projektu w pełni przetestuj aplikację lokalnie przy użyciu wersji 4.x narzędzi Azure Functions Core Tools.
  4. Uruchom moduł sprawdzania poprawności przed uaktualnieniem w aplikacji hostowanej na platformie Azure i rozwiąż wszelkie zidentyfikowane problemy.
  5. Zaktualizuj aplikację funkcji na platformie Azure do nowej wersji. Jeśli musisz zminimalizować przestoje, rozważ użycie miejsca przejściowego do przetestowania i zweryfikowania migrowanej aplikacji na platformie Azure w nowej wersji środowiska uruchomieniowego. Następnie możesz wdrożyć aplikację przy użyciu zaktualizowanych ustawień wersji w miejscu produkcyjnym. Aby uzyskać więcej informacji, zobacz Aktualizowanie przy użyciu miejsc.
  6. Opublikuj zmigrowany projekt do zaktualizowanej aplikacji funkcji.

Gdy używasz programu Visual Studio do publikowania projektu w wersji 4.x w istniejącej aplikacji funkcji w niższej wersji, podczas wdrażania zostanie wyświetlony monit o zaktualizowanie aplikacji funkcji do wersji 4.x. Ta aktualizacja używa tego samego procesu zdefiniowanego w aktualizacji bez miejsc.

Migrowanie projektu lokalnego

Instrukcje uaktualniania są zależne od języka. Jeśli język nie jest widoczny, wybierz go z selektora w górnej części artykułu.

Wybierz kartę zgodną z docelową wersją platformy .NET i żądanym modelem procesów (proces procesu w procesie przetwarzania lub izolowanym procesie roboczym).

Napiwek

Jeśli przechodzisz do wersji LTS lub STS platformy .NET przy użyciu izolowanego modelu roboczego, asystent uaktualnienia platformy .NET może służyć do automatycznego wprowadzania wielu zmian wymienionych w poniższych sekcjach.

Plik projektu

Poniższy przykład to .csproj plik projektu, który używa programu .NET Core 3.1 w wersji 3.x:

<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>

Użyj jednej z następujących procedur, aby zaktualizować ten plik XML do uruchomienia w usłudze Functions w wersji 4.x:

W tych krokach przyjęto założenie lokalnego projektu języka C#, a jeśli aplikacja używa skryptu języka C# (.csx plików), przed kontynuowaniem należy przekonwertować go na model projektu.

W pliku projektu XML wymagane .csproj są następujące zmiany:

  1. Ustaw wartość PropertyGroup.TargetFramework do net8.0.

  2. Ustaw wartość PropertyGroup.AzureFunctionsVersion do v4.

  3. Dodaj następujący OutputType element do elementu PropertyGroup:

    <OutputType>Exe</OutputType>

  4. W pliku ItemGroup.PackageReference lista, zastąp odwołanie Microsoft.NET.Sdk.Functions do pakietu następującymi odwołaniami:

      <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" />

    Zanotuj wszystkie odwołania do innych pakietów w Microsoft.Azure.WebJobs.* przestrzeniach nazw. Te pakiety zostaną zastąpione w późniejszym kroku.

  5. Dodaj następujący nowy ItemGroupelement :

    <ItemGroup>
  <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
</ItemGroup>

Po wprowadzeniu tych zmian zaktualizowany projekt powinien wyglądać podobnie do następującego przykładu:

<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>

Zmiany pakietu i przestrzeni nazw

Na podstawie modelu, do którego przeprowadzasz migrację, może być konieczne zaktualizowanie lub zmiana pakietów odwołań aplikacji. Podczas wdrażania pakietów docelowych należy zaktualizować przestrzeń nazw przy użyciu instrukcji i niektórych typów, do których się odwołujesz. Wpływ tych zmian przestrzeni nazw na using instrukcje można zobaczyć w przykładach szablonu wyzwalacza HTTP w dalszej części tego artykułu.

Jeśli jeszcze tego nie zrobiono, zaktualizuj projekt, aby odwoływać się do najnowszych stabilnych wersji:

W zależności od wyzwalaczy i powiązań używanych przez aplikację może być konieczne odwołanie do innego zestawu pakietów. W poniższej tabeli przedstawiono zamiany niektórych najczęściej używanych rozszerzeń:

Scenariusz Zmiany odwołań do pakietu
Wyzwalacz czasomierza Dodaj
Microsoft.Azure.Functions.Worker.Extensions.Timer
Powiązania magazynu Replace
Microsoft.Azure.WebJobs.Extensions.Storage
with
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues i
Microsoft.Azure.Functions.Worker.Extensions.Tables
Powiązania obiektu blob Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Powiązania kolejki Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Powiązania tabeli Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Tables
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.Tables
Powiązania usługi Cosmos DB Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.CosmosDB
i/lub
Microsoft.Azure.WebJobs.Extensions.DocumentDB
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Powiązania usługi Service Bus Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.ServiceBus
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Powiązania usługi Event Hubs Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.EventHubs
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Powiązania usługi Event Grid Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.EventGrid
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
Powiązania usługi SignalR Service Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.SignalRService
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Trwałe funkcje Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.DurableTask
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Trwałe funkcje
(Dostawca magazynu SQL)		 Zamień odwołania na
Microsoft.DurableTask.SqlServer.AzureFunctions
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Trwałe funkcje
(Dostawca magazynu Netherite)		 Zamień odwołania na
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
Powiązania usługi SendGrid Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.SendGrid
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Powiązania platformy Kafka Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.Kafka
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.Kafka
Powiązania RabbitMQ Zamień odwołania na
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
z najnowszą wersją
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Wstrzykiwanie zależności
i konfiguracja uruchamiania		 Usuń odwołania do
Microsoft.Azure.Functions.Extensions
(Model izolowanego procesu roboczego domyślnie udostępnia tę funkcję).

Zobacz Obsługiwane powiązania , aby zapoznać się z pełną listą rozszerzeń, które należy wziąć pod uwagę, i zapoznaj się z dokumentacją każdego rozszerzenia, aby uzyskać pełne instrukcje instalacji dla izolowanego modelu procesów. Pamiętaj, aby zainstalować najnowszą stabilną wersję wszystkich docelowych pakietów.

Napiwek

Wszelkie zmiany w wersjach rozszerzeń w trakcie tego procesu mogą wymagać również zaktualizowania host.json pliku. Pamiętaj, aby zapoznać się z dokumentacją każdego używanego rozszerzenia. Na przykład rozszerzenie usługi Service Bus ma zmiany powodujące niezgodność w strukturze między wersjami 4.x i 5.x. Aby uzyskać więcej informacji, zobacz Powiązania usługi Azure Service Bus dla usługi Azure Functions.

Aplikacja modelu izolowanego procesu roboczego nie powinna odwoływać się do żadnych pakietów w Microsoft.Azure.WebJobs.* przestrzeniach nazw ani Microsoft.Azure.Functions.Extensions. Jeśli masz jakiekolwiek pozostałe odwołania do tych odwołań, należy je usunąć.

Napiwek

Aplikacja może również zależeć od typów zestawu Azure SDK w ramach wyzwalaczy i powiązań lub jako zależności autonomicznej. Należy skorzystać z tej okazji, aby je również zaktualizować. Najnowsze wersje rozszerzeń usługi Functions współdziałają z najnowszymi wersjami zestawu Azure SDK dla platformy .NET, prawie wszystkich pakietów, dla których jest formularz Azure.*.

plik Program.cs

Podczas migracji do uruchomienia w izolowanym procesie roboczym należy dodać następujący plik program.cs do projektu:

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

Ten przykład obejmuje integrację ASP.NET Core w celu zwiększenia wydajności i udostępnienia znanego modelu programowania, gdy aplikacja używa wyzwalaczy HTTP. Jeśli nie zamierzasz używać wyzwalaczy HTTP, możesz zastąpić wywołanie ConfigureFunctionsWebApplication metody wywołaniem metody ConfigureFunctionsWorkerDefaults. Jeśli to zrobisz, możesz usunąć odwołanie z Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore pliku projektu. Jednak aby uzyskać najlepszą wydajność, nawet w przypadku funkcji z innymi typami wyzwalaczy, należy zachować FrameworkReference wartość na ASP.NET Core.

Plik Program.cs zastąpi dowolny plik, który ma FunctionsStartup atrybut , który jest zazwyczaj plikiem Startup.cs . W miejscach, w których FunctionsStartup kod będzie się odwoływaćIFunctionsHostBuilder.Services, można zamiast tego dodać instrukcje w .ConfigureServices() metodzie HostBuilder w pliku .Program.cs Aby dowiedzieć się więcej na temat pracy z Program.csprogramem , zobacz Start-up and configuration (Uruchamianie i konfigurowanie ) w przewodniku po izolowanym modelu procesu roboczego.

Powyższe przykłady domyślne Program.cs obejmują konfigurację integracji aplikacji Szczegółowe informacje dla izolowanego modelu procesu roboczego. W programie Program.csnależy również skonfigurować filtrowanie dzienników, które ma być stosowane do dzienników pochodzących z kodu w projekcie. W modelu host.json izolowanego procesu roboczego plik kontroluje tylko zdarzenia emitowane przez środowisko uruchomieniowe hosta usługi Functions. Jeśli nie skonfigurujesz reguł filtrowania w programie Program.cs, mogą pojawić się różnice w poziomach dziennika obecnych dla różnych kategorii w telemetrii.

Chociaż można zarejestrować niestandardowe źródła konfiguracji w ramach programu HostBuilder, należy pamiętać, że mają one zastosowanie tylko do kodu w projekcie. Konfiguracja wyzwalacza i powiązania jest również wymagana przez platformę i powinna zostać udostępniona za pośrednictwem ustawień aplikacji, odwołań do usługi Key Vault lub funkcji odwołań do usługi App Configuration.

Po przeniesieniu wszystkiego z dowolnego istniejącego FunctionsStartupProgram.cs do pliku można usunąć FunctionsStartup atrybut i klasę, do której został zastosowany.

plik local.settings.json

Plik local.settings.json jest używany tylko w przypadku uruchamiania lokalnego. Aby uzyskać informacje, zobacz Plik ustawień lokalnych.

Podczas migracji do wersji 4.x upewnij się, że plik local.settings.json zawiera co najmniej następujące elementy:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

Uwaga

Podczas migracji z uruchamiania procesu w procesie wyizolowanego procesu roboczego należy zmienić FUNCTIONS_WORKER_RUNTIME wartość na "dotnet-isolated".

plik host.json

Do pliku host.json nie są wymagane żadne zmiany. Jeśli jednak konfiguracja aplikacji Szczegółowe informacje w tym pliku z projektu modelu procesowego, może być konieczne wprowadzenie dodatkowych zmian w Program.cs pliku. Plik host.json steruje tylko rejestrowaniem ze środowiska uruchomieniowego hosta usługi Functions, a w modelu izolowanego procesu roboczego niektóre z tych dzienników pochodzą bezpośrednio z aplikacji, co zapewnia większą kontrolę. Aby uzyskać szczegółowe informacje na temat filtrowania tych dzienników, zobacz Zarządzanie poziomami dzienników w izolowanym modelu procesu roboczego.

Zmiany nazwy klasy

Niektóre klasy kluczy zmieniły nazwy między wersjami. Te zmiany są wynikiem zmian w interfejsach API platformy .NET lub różnic między procesem procesowym i izolowanym procesem roboczym. W poniższej tabeli przedstawiono kluczowe klasy platformy .NET używane przez funkcje, które mogą ulec zmianie podczas migracji:

.NET Core 3.1 .NET 5 .NET 8
FunctionName (atrybut) Function (atrybut) Function (atrybut)
ILogger ILogger ILogger, ILogger<T>
HttpRequest HttpRequestData HttpRequestData, HttpRequest (przy użyciu integracji z platformą ASP.NET Core)
IActionResult HttpResponseData HttpResponseData, IActionResult (przy użyciu integracji z platformą ASP.NET Core)
FunctionsStartup (atrybut) Zamiast tego używa Program.cs Zamiast tego używa Program.cs

Mogą również występować różnice nazw klas w powiązaniach. Aby uzyskać więcej informacji, zobacz artykuły referencyjne dotyczące określonych powiązań.

Inne zmiany kodu

W tej sekcji wyróżniono inne zmiany kodu, które należy wziąć pod uwagę podczas pracy z migracją. Te zmiany nie są wymagane przez wszystkie aplikacje, ale należy ocenić, czy istnieją odpowiednie dla Twoich scenariuszy. Pamiętaj, aby sprawdzić zmiany powodujące niezgodność między wersjami 3.x i 4.x , aby uzyskać dodatkowe zmiany, które mogą być konieczne w projekcie.

Serializacja JSON

Domyślnie izolowany model procesu roboczego jest używany System.Text.Json do serializacji JSON. Aby dostosować opcje serializatora lub przełączyć się na JSON.NET (Newtonsoft.Json), zobacz te instrukcje.

Poziomy i filtrowanie dzienników Szczegółowe informacje aplikacji

Dzienniki można wysyłać do aplikacji Szczegółowe informacje zarówno ze środowiska uruchomieniowego hosta usługi Functions, jak i kodu w projekcie. Umożliwia host.json skonfigurowanie reguł rejestrowania hosta, ale w celu kontrolowania dzienników pochodzących z kodu należy skonfigurować reguły filtrowania w ramach elementu Program.cs. Aby uzyskać szczegółowe informacje na temat filtrowania tych dzienników, zobacz Zarządzanie poziomami dzienników w izolowanym modelu procesu roboczego.

Szablon wyzwalacza HTTP

Różnice między procesem w procesie i izolowanym procesem roboczym można zobaczyć w funkcjach wyzwalanych przez protokół HTTP. Szablon wyzwalacza HTTP dla wersji 3.x (w procesie) wygląda następująco:

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

Szablon wyzwalacza HTTP dla zmigrowanej wersji wygląda następująco:

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"]}!");
        }
    }
}

Aby zaktualizować projekt do usługi Azure Functions 4.x:

  1. Zaktualizuj lokalną instalację narzędzi Azure Functions Core Tools do wersji 4.x.

  2. Zaktualizuj pakiet rozszerzeń usługi Azure Functions aplikacji do wersji 2.x lub nowszej. Aby uzyskać więcej informacji, zobacz Zmiany powodujące niezgodność.

  1. W razie potrzeby przejdź do jednej z wersji java obsługiwanych w wersji 4.x.

  2. Zaktualizuj plik aplikacji POM.xml , aby zmodyfikować FUNCTIONS_EXTENSION_VERSION ustawienie na ~4, tak jak w poniższym przykładzie:

    <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. W razie potrzeby przejdź do jednej z wersji Node.js obsługiwanych w wersji 4.x.
  1. Skorzystaj z tej okazji, aby przeprowadzić uaktualnienie do programu PowerShell 7.2, co jest zalecane. Aby uzyskać więcej informacji, zobacz Wersje programu PowerShell.
  1. Jeśli używasz języka Python 3.6, przejdź do jednej z obsługiwanych wersji.

Uruchamianie modułu sprawdzania poprawności przed uaktualnieniem

Usługa Azure Functions udostępnia moduł sprawdzania poprawności przed uaktualnieniem, który pomaga zidentyfikować potencjalne problemy podczas migracji aplikacji funkcji do wersji 4.x. Aby uruchomić moduł sprawdzania poprawności przed uaktualnieniem:

  1. W witrynie Azure Portal przejdź do aplikacji funkcji.

  2. Otwórz stronę Diagnozowanie i rozwiązywanie problemów.

  3. W obszarze Diagnostyka aplikacji funkcji rozpocznij wpisywanie Functions 4.x Pre-Upgrade Validator , a następnie wybierz ją z listy.

  4. Po zakończeniu walidacji przejrzyj zalecenia i rozwiąż wszelkie problemy w aplikacji. Jeśli musisz wprowadzić zmiany w aplikacji, sprawdź poprawność zmian w wersji 4.x środowiska uruchomieniowego usługi Functions lokalnie przy użyciu narzędzi Azure Functions Core Tools w wersji 4 lub miejsca przejściowego.

Aktualizowanie aplikacji funkcji na platformie Azure

Przed opublikowaniem zmigrowanego projektu należy zaktualizować środowisko uruchomieniowe hosta aplikacji funkcji na platformie Azure do wersji 4.x. Wersja środowiska uruchomieniowego używana przez hosta usługi Functions jest kontrolowana przez FUNCTIONS_EXTENSION_VERSION ustawienie aplikacji, ale w niektórych przypadkach należy również zaktualizować inne ustawienia. Zmiany kodu i zmiany ustawień aplikacji wymagają ponownego uruchomienia aplikacji funkcji.

Najprostszym sposobem jest zaktualizowanie bez miejsc , a następnie ponowne opublikowanie projektu aplikacji. Możesz również zminimalizować przestój w aplikacji i uprościć wycofywanie, aktualizując przy użyciu miejsc.

Aktualizowanie bez miejsc

Najprostszym sposobem aktualizacji do wersji 4.x jest ustawienie FUNCTIONS_EXTENSION_VERSION aplikacji na ~4 wartość w aplikacji funkcji na platformie Azure. Musisz wykonać inną procedurę w lokacji z miejscami.

az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>

Należy również ustawić inne ustawienie, które różni się między systemami Windows i Linux.

W przypadku uruchamiania w systemie Windows należy również włączyć platformę .NET 6.0, która jest wymagana przez wersję 4.x środowiska uruchomieniowego.

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

Platforma .NET 6 jest wymagana w przypadku aplikacji funkcji w dowolnym języku uruchomionym w systemie Windows.

W tym przykładzie zastąp <APP_NAME> ciąg nazwą aplikacji funkcji i <RESOURCE_GROUP_NAME> nazwą grupy zasobów.

Teraz możesz ponownie opublikować projekt aplikacji, który został zmigrowany do uruchomienia w wersji 4.x.

Aktualizowanie przy użyciu miejsc

Użycie miejsc wdrożenia to dobry sposób aktualizowania aplikacji funkcji do środowiska uruchomieniowego w wersji 4.x z poprzedniej wersji. Za pomocą miejsca przejściowego możesz uruchomić aplikację w nowej wersji środowiska uruchomieniowego w miejscu przejściowym i przełączyć się do środowiska produkcyjnego po weryfikacji. Miejsca zapewniają również sposób zminimalizowania przestojów podczas aktualizacji. Jeśli musisz zminimalizować przestój, wykonaj kroki opisane w temacie Minimalna aktualizacja przestoju.

Po zweryfikowaniu aplikacji w zaktualizowanym miejscu możesz zamienić aplikację i nowe ustawienia wersji na środowisko produkcyjne. Ta zamiana wymaga ustawienia WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w miejscu produkcyjnym. Sposób dodawania tego ustawienia wpływa na ilość przestojów wymaganych do aktualizacji.

Aktualizacja Standardowa

Jeśli aplikacja funkcji z włączoną obsługą miejsca może obsługiwać przestój pełnego ponownego uruchamiania, możesz zaktualizować WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS ustawienie bezpośrednio w miejscu produkcyjnym. Ponieważ zmiana tego ustawienia bezpośrednio w miejscu produkcyjnym powoduje ponowne uruchomienie, które ma wpływ na dostępność, rozważ wykonanie tej zmiany w czasie ograniczonego ruchu. Następnie możesz zamienić zaktualizowaną wersję z miejsca przejściowego.

Polecenie Update-AzFunctionAppSetting cmdlet programu PowerShell nie obsługuje obecnie miejsc. Musisz użyć interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal.

  1. Użyj następującego polecenia, aby ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w miejscu produkcyjnym:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0  -g <RESOURCE_GROUP_NAME>  -n <APP_NAME>

    W tym przykładzie zastąp <APP_NAME> ciąg nazwą aplikacji funkcji i <RESOURCE_GROUP_NAME> nazwą grupy zasobów. To polecenie powoduje ponowne uruchomienie aplikacji w miejscu produkcyjnym.

  2. Użyj następującego polecenia, aby również ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS w miejscu przejściowym:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  3. Użyj następującego polecenia, aby zmienić FUNCTIONS_EXTENSION_VERSION i zaktualizować miejsce przejściowe do nowej wersji środowiska uruchomieniowego:

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  4. Wersja 4.x środowiska uruchomieniowego usługi Functions wymaga platformy .NET 6 w systemie Windows. W systemie Linux aplikacje platformy .NET muszą również zostać zaktualizowane do platformy .NET 6. Użyj następującego polecenia, aby środowisko uruchomieniowe było uruchamiane na platformie .NET 6:

    W przypadku uruchamiania w systemie Windows należy również włączyć platformę .NET 6.0, która jest wymagana przez wersję 4.x środowiska uruchomieniowego.

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

    Platforma .NET 6 jest wymagana w przypadku aplikacji funkcji w dowolnym języku uruchomionym w systemie Windows.

    W tym przykładzie zastąp <APP_NAME> ciąg nazwą aplikacji funkcji i <RESOURCE_GROUP_NAME> nazwą grupy zasobów.

  5. Jeśli projekt kodu wymaga aktualizacji do uruchomienia w wersji 4.x, wdróż te aktualizacje w miejscu przejściowym teraz.

  6. Przed zamianą upewnij się, że aplikacja funkcji działa poprawnie w zaktualizowanym środowisku przejściowym.

  7. Użyj następującego polecenia, aby zamienić zaktualizowane miejsce przejściowe na środowisko produkcyjne:

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

Minimalna aktualizacja przestojów

Aby zminimalizować przestój w aplikacji produkcyjnej, możesz zamienić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS ustawienie z miejsca przejściowego na środowisko produkcyjne. Następnie można zamienić zaktualizowaną wersję z wstępnie zainstalowanego miejsca przejściowego.

  1. Użyj następującego polecenia, aby ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w miejscu przejściowym:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  2. Użyj następujących poleceń, aby zamienić miejsce na nowe ustawienie w środowisku produkcyjnym, a jednocześnie przywrócić ustawienie wersji w miejscu przejściowym.

    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łędy z miejsca przejściowego mogą wystąpić w czasie między zamianą a wersją środowiska uruchomieniowego przywracaną w środowisku przejściowym. Ten błąd może wystąpić, ponieważ podczas WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 zamiany FUNCTIONS_EXTENSION_VERSION ustawienie jest usuwane tylko w środowisku przejściowym. Bez ustawienia wersji miejsce jest w złym stanie. Zaktualizowanie wersji w miejscu przejściowym bezpośrednio po zamianie powinno przywrócić miejsce do dobrego stanu i w razie potrzeby przywrócić zmiany. Jednak każde wycofanie zamiany wymaga również bezpośredniego usunięcia WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 z środowiska produkcyjnego przed zamianą, aby zapobiec tym samym błędom w środowisku produkcyjnym widocznym w środowisku przejściowym. Ta zmiana ustawienia produkcyjnego spowoduje ponowne uruchomienie.

  3. Użyj następującego polecenia, aby ponownie ustawić WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 w miejscu przejściowym:

    az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

    W tym momencie oba miejsca mają WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 ustawione.

  4. Użyj następującego polecenia, aby zmienić FUNCTIONS_EXTENSION_VERSION i zaktualizować miejsce przejściowe do nowej wersji środowiska uruchomieniowego:

    az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

  5. Wersja 4.x środowiska uruchomieniowego usługi Functions wymaga platformy .NET 6 w systemie Windows. W systemie Linux aplikacje platformy .NET muszą również zostać zaktualizowane do platformy .NET 6. Użyj następującego polecenia, aby środowisko uruchomieniowe było uruchamiane na platformie .NET 6:

    W przypadku uruchamiania w systemie Windows należy również włączyć platformę .NET 6.0, która jest wymagana przez wersję 4.x środowiska uruchomieniowego.

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

    Platforma .NET 6 jest wymagana w przypadku aplikacji funkcji w dowolnym języku uruchomionym w systemie Windows.

    W tym przykładzie zastąp <APP_NAME> ciąg nazwą aplikacji funkcji i <RESOURCE_GROUP_NAME> nazwą grupy zasobów.

  6. Jeśli projekt kodu wymaga aktualizacji do uruchomienia w wersji 4.x, wdróż te aktualizacje w miejscu przejściowym teraz.

  7. Przed zamianą upewnij się, że aplikacja funkcji działa poprawnie w zaktualizowanym środowisku przejściowym.

  8. Użyj następującego polecenia, aby zamienić zaktualizowane i wstępne miejsce przejściowe na środowisko produkcyjne:

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

Zmiany powodujące niezgodność między 3.x i 4.x

Poniżej przedstawiono kluczowe zmiany powodujące niezgodność, o których należy pamiętać przed uaktualnieniem aplikacji 3.x do wersji 4.x, w tym zmian powodujących niezgodność języka. Aby uzyskać pełną listę, zobacz Problemy z usługą Azure Functions w usłudze GitHub z etykietą Zmiana powodująca niezgodność: zatwierdzona.

Jeśli język programowania nie jest widoczny, wybierz go w górnej części strony.

Środowisko uruchomieniowe

  • Serwery proxy usługi Azure Functions to starsza funkcja dla wersji 1.x do 3.x środowiska uruchomieniowego usługi Azure Functions. Obsługę serwerów proxy usługi Functions można ponownie włączyć w wersji 4.x, aby można było pomyślnie zaktualizować aplikacje funkcji do najnowszej wersji środowiska uruchomieniowego. Jak najszybciej należy przełączyć się na integrację aplikacji funkcji z usługą Azure API Management. Usługa API Management umożliwia korzystanie z pełniejszego zestawu funkcji do definiowania i zabezpieczania interfejsów API opartych na usłudze Functions oraz zarządzania nimi i zarabiania na nich. Aby uzyskać więcej informacji, zobacz Integracja usługi API Management. Aby dowiedzieć się, jak ponownie włączyć obsługę serwerów proxy w usłudze Functions w wersji 4.x, zobacz Ponowne włączanie serwerów proxy w usłudze Functions w wersji 4.x.

  • Rejestrowanie w usłudze Azure Storage przy użyciu narzędzia AzureWebJobsDashboard nie jest już obsługiwane w wersji 4.x. Zamiast tego należy użyć Szczegółowe informacje aplikacji. (#1923)

  • Usługa Azure Functions 4.x wymusza teraz minimalne wymagania dotyczące wersji rozszerzeń. Zaktualizuj do najnowszej wersji rozszerzeń, których dotyczy problem. W przypadku języków non-.NET zaktualizuj pakiet do rozszerzenia w wersji 2.x lub nowszej. (#1987)

  • Domyślne i maksymalne limity czasu są teraz wymuszane w wersji 4.x dla aplikacji funkcji działających w systemie Linux w planie Zużycie. (#1915)

  • Usługa Azure Functions 4.x używa Azure.Identity i Azure.Security.KeyVault.Secrets dla dostawcy usługi Key Vault i wycofała korzystanie z usługi Microsoft.Azure.KeyVault. Aby uzyskać więcej informacji na temat konfigurowania ustawień aplikacji funkcji, zobacz opcję Key Vault w repozytoriach tajnych. (#2048)

  • Teraz nie można uruchomić aplikacji funkcji, które współużytkują konta magazynu, gdy ich identyfikatory hostów są takie same. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące identyfikatora hosta. (#2049)

  • Usługa Azure Functions 4.x obsługuje aplikacje procesowe i izolowane platformy .NET 6.

  • InvalidHostServicesException jest teraz błędem krytycznym. (#2045)

  • EnableEnhancedScopes jest domyślnie włączona. (#1954)

  • Usuń HttpClient jako zarejestrowaną usługę. (#1911)

  • Użyj modułu ładującego z jedną klasą w języku Java 11. (#1997)

  • Zatrzymaj ładowanie plików jar procesu roboczego w środowisku Java 8. (#1991)

  • Node.js w wersji 10 i 12 nie są obsługiwane w usłudze Azure Functions 4.x. (#1999)

  • Serializacja danych wyjściowych w aplikacjach Node.js została zaktualizowana w celu rozwiązania poprzednich niespójności. (#2007)

  • Zaktualizowano domyślną liczbę wątków. Mogą mieć to wpływ na funkcje, które nie są bezpieczne wątkowo lub mają duże użycie pamięci. (#1962)

  • Język Python 3.6 nie jest obsługiwany w usłudze Azure Functions 4.x. (#1999)

  • Transfer pamięci udostępnionej jest domyślnie włączony. (#1973)

  • Zaktualizowano domyślną liczbę wątków. Mogą mieć to wpływ na funkcje, które nie są bezpieczne wątkowo lub mają duże użycie pamięci. (#1962)

Następne kroki

Dowiedz się więcej o wersjach usługi Functions