Migrowanie aplikacji w języku C# z modelu wewnątrzprocesowego do izolowanego modelu roboczego

Ten artykuł przeprowadzi Cię przez proces bezpiecznego migrowania aplikacji funkcji .NET z modelu in-process do modelu odizolowanego pracownika. Aby dowiedzieć się więcej o najważniejszych różnicach między tymi modelami, zobacz porównanie trybu wykonywania.

W tym przewodniku założono, że aplikacja działa w wersji 4.x środowiska uruchomieniowego usługi Functions. Jeśli nie, skorzystaj z poniższych poradników, aby zaktualizować wersję hosta. Te przewodniki migracji wersji hosta ułatwiają również migrację do izolowanego modelu procesu roboczego podczas pracy z nimi.

• Migruj aplikacje z Azure Functions w wersji 2.x i 3.x do wersji 4.x
• Migrowanie aplikacji z usługi Azure Functions w wersji 1.x do wersji 4.x

Jeśli jest obsługiwany, ten artykuł korzysta z integracji ASP.NET Core w modelu izolowanego procesu roboczego, który poprawia wydajność i udostępnia znany model programowania, gdy aplikacja korzysta z wyzwalaczy HTTP.

Identyfikowanie aplikacji funkcji do migracji

Użyj następującego skryptu Azure PowerShell, aby wygenerować listę aplikacji funkcji w ramach subskrypcji, które obecnie używają modelu przetwarzania.

Skrypt używa subskrypcji, z której Azure PowerShell jest obecnie skonfigurowany do korzystania. Możesz zmienić subskrypcję, najpierw uruchamiając Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' i zastępując <YOUR SUBSCRIPTION ID> identyfikatorem subskrypcji, którą chcesz ocenić.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.Runtime -eq 'dotnet')
     {
          $AppInfo.Add($App.Name, $App.Runtime)
     }
}

$AppInfo

Wybierz docelową wersję .NET

Podczas migracji do modelu izolowanego pracownika wybierz cel na podstawie tego, czy Twoja aplikacja funkcyjna i jej zależności mogą działać na .NET (dawniej .NET Core):

• Jeśli Twoja aplikacja i jej zależności mogą działać na .NET, celuj w .NET 10.
• Jeśli Twoja aplikacja zależy od bibliotek lub API dostępnych tylko w .NET Framework, celuj w .NET Framework 4.8.

Przygotowanie do migracji

Zanim przeniesiesz aplikację na model izolowanego pracownika, dokładnie zapoznaj się z treścią tego przewodnika. Zapoznaj się także z cechami modelu izolowanego pracownika oraz różnicami między nimi.

Aby przeprowadzić migrację aplikacji:

1. Przeprowadź migrację projektu lokalnego do izolowanego modelu procesu roboczego, wykonując kroki opisane w artykule Migrowanie projektu lokalnego.
2. Po migracji projektu w pełni przetestuj aplikację lokalnie, korzystając z wersji 4.x Azure Functions Core Tools.
3. Aktualizuj aplikację funkcji w Azure do izolowanego modelu.

Migrowanie projektu lokalnego

Ta sekcja opisuje różne zmiany, które musisz wprowadzić w swoim lokalnym projekcie, aby przenieść go do modelu izolowanego pracownika. Niektóre kroki zmieniają się na podstawie wersji docelowej .NET. Użyj zakładek, aby wybrać instrukcje pasujące do żądanej wersji.

Najpierw przekonwertuj plik projektu i zaktualizuj zależności. Kiedy to robisz, zobaczysz błędy kompilacji dla projektu. W kolejnych krokach wprowadzisz odpowiednie zmiany, aby usunąć te błędy.

plik projektu

Poniższy przykład pokazuje plik projektu .csproj, który używa .NET 8 w wersji 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>

Użyj jednej z następujących procedur, aby zaktualizować ten plik XML do uruchomienia w izolowanym modelu procesu roboczego:

<Project Sdk="Azure.Functions.Sdk/1.0.0">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <RootNamespace>My.Namespace</RootNamespace>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.52.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="2.1.0" />
    <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>

<Project Sdk="Azure.Functions.Sdk/1.0.0">
  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.1.0" />
    <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>
    <Folder Include="Properties\" />
  </ItemGroup>
</Project>

Zmiana struktury docelowej projektu może również wymagać zmian w częściach łańcucha narzędzi poza kodem projektu. Na przykład w programie VS Code może być konieczne zaktualizowanie azureFunctions.deploySubpath ustawienia rozszerzenia za pomocą ustawień użytkownika lub pliku .vscode/settings.json projektu. Sprawdź, czy nie ma zależności od wersji platformy, które mogą istnieć poza kodem projektu, na przykład w ramach kroków budowania lub potoku CI/CD.

Odwołania do pakietu

Podczas migracji do modelu izolowanego pracownika zmień pakiety, do których odwołuje się aplikacja.

Jeśli jeszcze tego nie zrobiłeś, zaktualizuj swój projekt, aby korzystać z najnowszych stabilnych wersji:

• Microsoft.Azure. Functions.Worker
• Azure. Functions.Sdk jako projekt SDK

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

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.

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

plik Program.cs

Podczas migracji do działania w izolowanym procesie roboczym dodaj plik Program.cs do swojego projektu z następującą zawartością:

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

using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;

namespace Company.FunctionApp
{
    internal class Program
    {
        static void Main(string[] args)
        {
            FunctionsDebugger.Enable();

            var host = new HostBuilder()
                .ConfigureFunctionsWorkerDefaults()
                .ConfigureServices(services => {
                    services.AddApplicationInsightsTelemetryWorkerService();
                    services.ConfigureFunctionsApplicationInsights();
                })
                .Build();
            host.Run();
        }
    }
}

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

Opisane wcześniej domyślne przykłady pliku Program.cs konfigurują usługę Application Insights przy użyciu zestawu SDK usługi Application Insights. Aby uzyskać konfigurację Application Insights opartą na OpenTelemetry, opisaną w przewodniku po modelu pracownika izolowanym, zobacz Application Insights. W Program.cs należy również skonfigurować filtrowanie dzienników, które ma dotyczyć dzienników pochodzących z kodu w projekcie. W modelu izolowanego procesu roboczego plik host.json kontroluje tylko zdarzenia emitowane przez środowisko uruchomieniowe hosta usługi Functions. Jeśli nie skonfigurujesz reguł filtrowania w Program.cs, mogą wystąpić różnice w poziomach dziennika dostępnych dla różnych kategorii w twojej telemetrii.

Chociaż można zarejestrować niestandardowe źródła konfiguracji jako część HostBuilder, mają podobne zastosowanie tylko do kodu w projekcie. Platforma wymaga również konfiguracji wyzwalacza i powiązania, a powinna zostać udostępniona za pośrednictwem ustawień aplikacji, odwołań do Key Vault lub odwołań do konfiguracji aplikacji.

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

Zmiany podpisu funkcji

Niektóre kluczowe typy zmieniają się między modelem procesu a izolowanym modelem roboczym. Wiele z tych zmian odnosi się do atrybutów, parametrów i typów zwrotów, które tworzą sygnaturę funkcyjną. Dla każdej z Twoich funkcji wprowadź zmiany w:

• Atrybut funkcji, który również ustawia nazwę funkcji
• Jak funkcja uzyskuje element ILogger/ILogger<T>
• Wyzwalanie i wiązanie atrybutów i parametrów

W pozostałej części tej sekcji przedstawiono poszczególne kroki.

Atrybuty funkcji

Atrybut Function w izolowanym modelu procesu roboczego zastępuje atrybut FunctionName. Nowy atrybut ma ten sam podpis, a jedyną różnicą jest nazwa. Możesz więc wykonać zamianę ciągu znaków w całym projekcie.

Rejestrowanie danych

W modelu przetwarzania można dołączyć opcjonalny ILogger parametr funkcji lub użyć iniekcji zależności, aby uzyskać element ILogger<T>. Jeśli aplikacja już używała wstrzykiwania zależności, te same mechanizmy działają w izolowanym modelu roboczym.

Jednak w przypadku wszystkich funkcji, które opierały się na parametrze ILogger metody, należy wprowadzić zmianę. Użyj wstrzykiwania zależności, aby uzyskać element ILogger<T>. Wykonaj następujące kroki, aby przeprowadzić migrację mechanizmu rejestrowania funkcji:

1. W klasie funkcji dodaj private readonly ILogger<MyFunction> _logger; właściwość, zastępując MyFunction nazwą swojej klasy funkcji.

2. Utwórz konstruktor dla klasy funkcji, który przyjmuje ILogger<T> parametr jako parametr:

   public MyFunction(ILogger<MyFunction> logger) {
       _logger = logger;
   }
   

   Zastąp oba wystąpienia MyFunction w poprzednim fragmencie kodu nazwą klasy funkcji.

3. W przypadku operacji rejestrowania w kodzie funkcji zastąp odwołania do parametru ILogger parametrem _logger.

4. ILogger Usuń parametr z sygnatury funkcji.

Aby dowiedzieć się więcej, zobacz Rejestrowanie w modelu izolowanego procesu roboczego.

Wyzwalanie i wiązanie zmian

Po zmianie odwołań do pakietu w poprzednim kroku wprowadzono błędy wyzwalaczy i powiązań, które można teraz naprawić:

1. Usuń wszystkie wyrażenia using Microsoft.Azure.WebJobs;.

2. Dodaj instrukcję using Microsoft.Azure.Functions.Worker;.

3. Dla każdego atrybutu powiązania zmień nazwę atrybutu zgodnie z opisem w dokumentacji referencyjnej, którą można znaleźć w indeksie Obsługiwane powiązania . Ogólnie rzecz biorąc, nazwy atrybutów zmieniają się w następujący sposób:

   • Wyzwalacze zwykle pozostają nazwane w taki sam sposób. Na przykład QueueTrigger to nazwa atrybutu dla obu modeli.
   • Powiązania wejściowe zwykle wymagają dodania Input do nazwy. Jeśli na przykład użyto atrybutu powiązania wejściowego CosmosDB w modelu przetwarzania, atrybut będzie teraz .CosmosDBInput
   • Powiązania wyjściowe zwykle wymagają Output dodania do ich nazwy. Jeśli na przykład użyto atrybutu powiązania wyjściowego Queue w modelu przetwarzania, ten atrybut będzie teraz .QueueOutput

4. Zaktualizuj parametry atrybutu, aby odzwierciedlały izolowane wersje modelu procesu roboczego, jak określono w dokumentacji referencyjnej powiązania.

   Na przykład w modelu przetwarzania danych wiązanie wyjściowe obiektu blob jest reprezentowane przez [Blob(...)] atrybut zawierający Access właściwość. W modelu izolowanego procesu roboczego atrybut wyjściowy obiektu blob to [BlobOutput(...)]. Powiązanie nie wymaga już właściwości Access, więc możesz usunąć ten parametr. Dlatego [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] staje się [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

5. Przenieś powiązania wyjściowe z listy parametrów funkcji. Jeśli masz tylko jedno przypisanie wyjściowe, możesz zastosować to wiązanie do typu return funkcji. Jeśli masz wiele danych wyjściowych, utwórz nową klasę z właściwościami dla poszczególnych danych wyjściowych i zastosuj atrybuty do tych właściwości. Aby dowiedzieć się więcej, zobacz Wiele powiązań wyjściowych.

6. Zapoznaj się z dokumentacją referencyjną każdego powiązania, aby dowiedzieć się, do jakich typów można je przypisać. W niektórych przypadkach może być konieczne zmianę typu. Dla wiązań wyjściowych, jeśli wersja modelu w procesie używała typu IAsyncCollector<T>, możesz zastąpić ten typ wiązaniem z tablicą typu docelowego: T[]. Można również rozważyć zastąpienie powiązania wyjściowego obiektem klienta reprezentującym tę usługę, jako typ powiązania dla powiązania wejściowego, jeśli jest dostępne, lub samodzielnie wstrzykując klienta.

7. Jeśli funkcja zawiera IBinder parametr, usuń go. Zastąp funkcjonalność obiektem klienta reprezentującym usługę, jako typ powiązania dla powiązania wejściowego, jeśli jest to możliwe, lub poprzez własnoręczne wstrzyknięcie klienta.

8. Zaktualizuj kod funkcji, aby pracować z dowolnymi nowymi typami.

Przejdź na asynchroniczne strumieniowe operacje wejścia/wyjścia HTTP

Jeśli funkcja wyzwalana przez HTTP korzysta z integracji z ASP.NET Core, zastąp synchroniczne odczyty i zapisy do strumieni HTTP zażądań i odpowiedzi metodami asynchronicznymi. Operacje synchroniczne mogą zakończyć się niepowodzeniem z użyciem InvalidOperationException: Synchronous operations are disallowed. Na przykład zastąp ReadToEnd na ReadToEndAsync, Write na WriteAsync, WriteString na WriteStringAsync i Flush na FlushAsync.

Gdy oczekujesz na te operacje, oznacz metodę funkcji jako i async opakuj jej typ zwrotu w .Task<T> Na przykład zmień IActionResult na Task<IActionResult> lub MultiResponse na Task<MultiResponse>. ASP.NET Core domyślnie nie zezwala na synchroniczne operacje wejścia/wyjścia dla żądań i odpowiedzi, ponieważ synchroniczne operacje wejścia/wyjścia mogą powodować wyczerpanie puli wątków. Jeśli zależność lub serializator nie obsługuje asynchronicznego I/O, zobacz serializację JSON z integracją ASP.NET Core, gdzie znajdziesz instrukcje umożliwiające synchroniczne I/O (AllowSynchronousIO) jako opcję kompatybilności.

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 z uruchamiania procesu w procesie wyizolowanego procesu roboczego należy zmienić FUNCTIONS_WORKER_RUNTIME wartość na dotnet-isolated. Upewnij się, że Twój plik local.settings.json zawiera co najmniej następujące elementy:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
    }
}

Wartość, dla AzureWebJobsStorage której masz wartość, może być inna. Nie musisz zmieniać jej wartości w ramach migracji.

plik host.json

Do pliku host.json nie są wymagane żadne zmiany. Jeśli jednak konfiguracja usługi Application Insights znajduje się w tym pliku z projektu modelu przetwarzania, możesz wprowadzić więcej zmian w pliku Program.cs . Plik host.json kontroluje jedynie logowanie z czasów uruchomienia hosta Functions. W modelu izolowanego pracownika część tych logów pochodzi bezpośrednio z Twojej aplikacji, co daje 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.

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.

Serializacja JSON

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

Ponieważ model w procesie używał biblioteki Newtonsoft.Json, sprawdź także atrybuty serializacji we wszystkich typach, z którymi są powiązane funkcje. System.Text.Json ignoruje atrybuty takie jak [JsonProperty] i [JsonIgnore] pochodzące z Newtonsoft.Json. Wiąże dotkniętą właściwość z jej wartością domyślną bez zgłaszania błędu. Albo zastąp je odpowiednikami System.Text.Json , takimi jak [JsonPropertyName], albo skonfiguruj Newtonsoft.Json dla warstwy obsługującej ten ładunek.

Poziomy logów i filtrowanie w Application Insights

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

Przykład migracji wyzwalacza HTTP

Poniższy przykład porównuje funkcję wyzwalaną przez HTTP przed i po migracji z modelem izolowanego pracownika.

Wyzwalacz HTTP dla modelu przetwarzania może wyglądać podobnie do następującego przykładu:

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

Wyzwalacz HTTP dla zmigrowanej wersji może wyglądać podobnie do następującego przykładu:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public class HttpTriggerCSharp(ILogger<HttpTriggerCSharp> 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"]}!");
        }
    }
}

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Extensions.Logging;
using System.Net;

namespace Company.Function
{
    public class HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
    {
        [Function("HttpTriggerCSharp")]
        public HttpResponseData Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequestData req)
        {
            logger.LogInformation("C# HTTP trigger function processed a request.");

            var response = req.CreateResponse(HttpStatusCode.OK);
            response.Headers.Add("Content-Type", "text/plain; charset=utf-8");

            response.WriteString($"Welcome to Azure Functions, {req.Query["name"]}!");

            return response;
        }
    }
}

Zaktualizuj funkcjonalną aplikację na platformie Azure

Po migracji lokalnego projektu zaktualizuj konfigurację aplikacji funkcjonalnej i wdroż przeniesiony kod, aby zakończyć przejście do modelu izolowanego pracownika.

Zanim opublikujesz swój przeniesiony projekt

Zanim opublikujesz zaktualizowany projekt kodu, zaplanuj wykonanie tych dwóch zmian razem:

• Zmień FUNCTIONS_WORKER_RUNTIME ustawienia aplikacji na dotnet-isolated.
• Publikuj przeniesiony projekt izolowanego pracownika do swojej aplikacji Function.

Każda zmiana uruchamia aplikację od nowa. Po wykonaniu pierwszej zmiany wdrożony kod i skonfigurowane runtime nie pokrywają się, co powoduje błąd niezgodności runtime/payload (AZFD0013), dopóki nie wykonasz drugiej zmiany.

Gdy to możliwe, użyj slotu przejściowego podczas migracji. Gniazdo przejściowe zapewnia następujące korzyści:

• Zapobiega przedostaniu się do środowiska produkcyjnego tymczasowego stanu błędu wynikającego z niedopasowania kodu i środowiska uruchomieniowego.
• Pozwala przetestować przeniesiony kod i konfigurację przed przeniesieniem ich do produkcji.

Możesz zauważyć błędy w logach slotów przydziałowych podczas wykonywania tych dwóch zmian. Zanim wymienisz gniazdo, upewnij się, że błędy ustąpiły i że aplikacja działa zgodnie z oczekiwaniami.

Aktualizuj swoją aplikację funkcjonalną, używając slotów

Wykonaj następujące kroki, aby zaktualizować aplikację funkcji do modelu izolowanego procesu roboczego przy użyciu gniazda przejściowego:

1. Utwórz miejsce wdrożenia, jeśli jeszcze tego nie zrobiono. Możesz również zapoznać się z procesem zamiany slotów i upewnić się, że jesteś w stanie wprowadzać aktualizacje do istniejącej aplikacji z minimalnymi zakłóceniami.

2. Zmień konfigurację miejsca przeznaczonego na etapy przejściowe (nieprodukcyjnego), aby używać izolowanego modelu procesu roboczego, ustawiając FUNCTIONS_WORKER_RUNTIME jako ustawienie aplikacji na dotnet-isolated. Nie oznaczaj FUNCTIONS_WORKER_RUNTIMEjako ustawienia slotu.

   Jeśli w aktualizacji celujesz też w inną wersję .NET, zmień konfigurację stosu. Aby to zrobić, zapoznaj się z Aktualizowaniem konfiguracji stosu. Możesz użyć tych samych instrukcji dla każdej przyszłej .NET aktualizacji wersji, które wprowadzisz.

   Jeśli masz jakiekolwiek zautomatyzowane aprowizowanie infrastruktury, takie jak potok CI/CD, upewnij się, że zaktualizowano również mechanizmy automatyzacji, tak aby wartość FUNCTIONS_WORKER_RUNTIME pozostała ustawiona na dotnet-isolated i aby były one ukierunkowane na prawidłową wersję .NET.

3. Opublikuj zmigrowany projekt na wersję przejściową (nieprodukcyjną) swojej aplikacji funkcji.

   Jeśli używasz Visual Studio do publikowania izolowanego projektu modelu procesu roboczego w istniejącej aplikacji lub miejscu, które korzysta z modelu w procesie, może również wykonać poprzedni krok w tym samym czasie. Jeśli poprzedni krok nie został ukończony, Visual Studio wyświetli monit o zaktualizowanie function app podczas wdrażania. Visual Studio prezentuje tę aktualizację jako jedną operację, ale są to nadal dwie oddzielne operacje. Możesz nadal widzieć błędy w swoich dziennikach z slotu przejściowego (nieprodukcyjnego) w stanie przejściowym.

4. Upewnij się, że aplikacja działa zgodnie z oczekiwaniami w miejscu przejściowym (nieprodukcyjnym).

5. Wykonaj operację zamiany miejsca , aby zastosować zmiany wprowadzone w miejscu przejściowym (nieprodukcyjnym) do miejsca produkcyjnego. Zamiana slotów odbywa się jako pojedyncza aktualizacja, która pozwala uniknąć wprowadzenia tymczasowego stanu błędu w środowisku produkcyjnym.

6. Upewnij się, że aplikacja działa zgodnie z oczekiwaniami w środowisku produkcyjnym.

Po wykonaniu tych kroków migracja zostanie ukończona, a aplikacja zostanie uruchomiona w modelu izolowanym. Gratulacje! Powtórz kroki opisane w tym przewodniku w razie potrzeby dla innych aplikacji, które wymagają migracji.

Następny krok