Sdílet prostřednictvím

Migrace aplikací jazyka C# z modelu v procesu do izolovaného pracovního modelu

Důležité

Podpora modelu v procesu končí 10. listopadu 2026. Důrazně doporučujeme migrovat aplikace do izolovaného pracovního modelu podle pokynů v tomto článku.

Tento článek vás provede procesem bezpečné migrace aplikace funkcí .NET z modelu v procesu na izolovaný pracovní model. Další informace o rozdílech na vysoké úrovni mezi těmito modely najdete v porovnání režimu spouštění.

Tato příručka předpokládá, že vaše aplikace běží ve verzi 4.x modulu runtime Functions. Pokud ne, měli byste k upgradu verze hostitele použít následující příručky. Tyto příručky pro migraci verzí hostitele vám také pomohou migrovat na izolovaný pracovní model, když je budete postupně procházet.

V případě podpory tento článek využívá integraci ASP.NET Core v izolovaném modelu pracovního procesu, který zlepšuje výkon a poskytuje známý programovací model, když vaše aplikace používá triggery HTTP.

Identifikace funkčních aplikací pro migraci

Pomocí následujícího skriptu Azure PowerShellu vygenerujte seznam aplikací funkcí ve vašem předplatném, které aktuálně používají model v procesu.

Skript používá předplatné, které je aktuálně nakonfigurované pro použití Azure PowerShellu. Předplatné můžete změnit tak, že nejprve spustíte Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' a nahradíte <YOUR SUBSCRIPTION ID> ID předplatného, které chcete vyhodnotit.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

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

$AppInfo

Zvolte cílovou verzi .NET.

Ve verzi 4.x prostředí Functions vaše aplikace funkcí .NET cílí při použití in-process modelu na .NET 6 nebo .NET 8.

Při migraci aplikace funkcí máte možnost zvolit cílovou verzi .NET. Projekt jazyka C# můžete aktualizovat na jednu z následujících verzí rozhraní .NET, které jsou podporovány funkcemi verze 4.x:

Verze .NET Oficiální zásady podpory .NET typ vydání Modelprocesu funkcí 1,2
.NET 9 STS (konec podpory 12. května 2026) Izolovaný model pracovního procesu
.NET 8 LTS (konec podpory 10. listopadu 2026) Model izolovaného pracovníka
Model pro zpracování2
.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 charakteristik mezi dvěma modely najdete v tématu Rozdíly mezi procesy v procesu a izolovaným pracovním procesem .NET Azure Functions.

2 Podpora modelu v procesu končí 10. listopadu 2026. Další informace najdete v tomto oznámení podpory. Pokud chcete pokračovat v plné podpoře, měli byste své aplikace migrovat do izolovaného pracovního modelu.

Tip

Doporučujeme upgradovat na .NET 8 v izolovaném pracovním modelu. To poskytuje rychlé přechodové řešení k plně zveřejněné verzi, která má nejdelší dobu podpory od .NET.

Tato příručka neobsahuje konkrétní příklady pro .NET 9. Pokud se potřebujete zaměřit na tuto verzi, můžete přizpůsobit příklady .NET 8.

Příprava migrace

Před migrací aplikace do izolovaného modelu pracovního procesu byste měli důkladně zkontrolovat obsah této příručky. Měli byste se také seznámit s funkcemi izolovaného modelu pracovního procesu a rozdíly mezi těmito dvěma modely.

Migrace aplikace:

  1. Pomocí kroků v části Migrace místního projektu proveďte migraci místního projektu do izolovaného modelu pracovního procesu.
  2. Po migraci projektu plně otestujte aplikaci místně pomocí verze 4.x nástrojů Azure Functions Core Tools.
  3. Aktualizujte aplikaci funkcí v Azure na izolovaný model.

Migrace místního projektu

Tato část popisuje různé změny, které je potřeba provést v místním projektu, aby se přesunul do izolovaného modelu pracovního procesu. Některé kroky se mění na základě vaší cílové verze .NET. Pomocí záložek vyberte pokyny, které odpovídají požadované verzi.

Tip

Pokud přecházíte na verzi LTS nebo STS rozhraní .NET, můžete pomocníka pro upgrade .NET použít k automatickému provádění mnoha změn uvedených v následujících částech.

Nejprve převeďte soubor projektu a aktualizujte závislosti. Jak to děláte, zobrazí se chyby sestavení projektu. V dalších krocích provedete odpovídající změny, abyste tyto chyby odebrali.

Soubor projektu

Následující příklad je soubor projektu .csproj , který používá .NET 8 ve verzi 4.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.1.1" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Pomocí jednoho z následujících postupů aktualizujte tento soubor XML tak, aby běžel v izolovaném pracovním modelu:

Tyto kroky předpokládají místní projekt jazyka C#; Pokud vaše aplikace místo toho používá skript jazyka C# (soubory .csx ), měli byste před pokračováním převést na projektový model .

V souboru projektu XML .csproj jsou vyžadovány následující změny:

  1. Nastavte hodnotu PropertyGroup. TargetFramework na net8.0.

  2. Nastavte hodnotu PropertyGroup. AzureFunctionsVersion na v4.

  3. Přidejte následující OutputType prvek do PropertyGroup:

    <OutputType>Exe</OutputType>

  4. V sadě ItemGroup. PackageReference seznam, nahraďte odkaz na balíček Microsoft.NET.Sdk.Functions 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.

  5. Přidejte následující nové ItemGroup:

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

Po provedení těchto změn by aktualizovaný projekt měl vypadat jako v následujícím příkladu:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <RootNamespace>My.Namespace</RootNamespace>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
    <!-- Other packages may also be in this list -->
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
  </ItemGroup>
</Project>

Změna cílové architektury projektu může také vyžadovat změny částí sady nástrojů mimo kód projektu. Například ve VS Code možná budete muset aktualizovat azureFunctions.deploySubpath nastavení rozšíření v uživatelských nastaveních nebo v souboru .vscode/settings.json projektu. Zkontrolujte všechny závislosti na verzi frameworku, které mohou existovat mimo kód projektu, v rámci kroků sestavení nebo kanálu CI/CD.

Odkazy na balíčky

Při migraci na izolovaný pracovní model je potřeba změnit balíčky, na které odkazuje vaše aplikace.

Pokud jste to ještě neudělali, aktualizujte projekt, aby odkazoval 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
Spouštěč časovače Přidat
Microsoft.Azure.Functions.Worker.Extensions.Timer
Vazby služby Storage Nahradit
Microsoft.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 blobů Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Vazby front Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Vazby tabulek Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.Tables
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.Tables
Vazby databáze Cosmos Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.CosmosDB
a/nebo
Microsoft.Azure.WebJobs.Extensions.DocumentDB
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Vazby na Service Bus Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.ServiceBus
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Vazby služby Event Hubs Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.EventHubs
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Vazby Event Gridu Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.EventGrid
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
Vazby služby SignalR Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.SignalRService
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Durable Functions Nahrazení odkazů na
Microsoft.Azure.WebJobs.Extensions.DurableTask
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Funkce Durable
(Zprostředkovatel úložiště SQL)		 Nahraďte odkazy na
Microsoft.DurableTask.SqlServer.AzureFunctions
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Odolná služba Functions
(Zprostředkovatel úložiště Netherite)		 Nahraďte odkazy na
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
SendGrid propojení Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.SendGrid
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Propojení Kafka Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.Kafka
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.Kafka
Propojení RabbitMQ Nahraďte odkazy na
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
s nejnovější verzí
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Injektáž závislostí
a nastavení spuštění		 Odstranit odkazy na
Microsoft.Azure.Functions.Extensions
(Izolovaný model pracovního procesu tuto funkci poskytuje ve výchozím nastavení.)

Viz Podporované vazby pro úplný seznam rozšíření, která je potřeba zvážit, a konzultujte dokumentaci jednotlivých rozšíření pro úplné pokyny 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 vašeho izolovaného modelu by neměla odkazovat na žádné balíčky v oborech názvů Microsoft.Azure.WebJobs.* nebo Microsoft.Azure.Functions.Extensions. Pokud máte nějaké zbývající odkazy na tyto, měly by být odstraněny.

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 jsou kompatibilní s nejnovějšími verzemi sady Azure SDK pro .NET, přičemž téměř všechny tyto balíčky mají určitou podobu Azure.*.

Program.cs soubor

Při migraci na spuštění v izolovaném pracovním procesu musíte do projektu přidat soubor Program.cs s následujícím obsahem:

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

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

host.Run();

Tento příklad zahrnuje integraci ASP.NET Core ke zlepšení výkonu a poskytnutí známého programovacího modelu, když vaše aplikace používá triggery HTTP. Pokud nemáte v úmyslu používat triggery HTTP, můžete volání ConfigureFunctionsWebApplication nahradit voláním ConfigureFunctionsWorkerDefaults. Pokud to uděláte, můžete ze souboru projektu odebrat odkaz na Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore. 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í libovolný soubor, který má FunctionsStartup atribut, což je obvykle Startup.cs soubor. Na místech, kde by váš FunctionsStartup kód odkazoval na IFunctionsHostBuilder.Services, můžete přidat příkazy přímo do metody .ConfigureServices() v HostBuilder ve vašem Program.cs. Další informace o práci s Program.cs najdete v tématu Spuštění a konfigurace v průvodci izolovaným pracovním modelem.

Mezi výchozí Program.cs příklady, které jsme dříve popsali, patří nastavení Application Insights. V Program.cs musíte také nakonfigurovat veškeré filtrování protokolu, které by se mělo vztahovat na protokoly pocházející z kódu v projektu. V izolovaném modelu pracovního procesu host.json soubor řídí pouze události generované modulem runtime hostitele Služby Functions. Pokud v Program.cs nenakonfigurujete pravidla filtrování, můžou se v telemetrických datech zobrazovat rozdíly v úrovních protokolu pro různé kategorie.

I když můžete registrovat vlastní zdroje konfigurace jako součást projektu HostBuilder, platí to podobně pouze pro kód v projektu. Platforma také potřebuje konfiguraci triggeru a vazby, která by se měla poskytovat prostřednictvím nastavení aplikace, odkazů na Key Vault nebo odkazů na konfiguraci aplikací .

Po přesunutí všech existujících FunctionsStartup souborů do souboru Program.cs můžete atribut odstranit FunctionsStartup a třídu, na kterou byl použit.

Změny podpisu funkce

Mezi modelem v procesu a izolovaným pracovním modelem se mění některé klíčové typy. Mnoho z nich souvisí s atributy, parametry a návratové typy, které tvoří podpis funkce. Pro každou z vašich funkcí musíte provést změny v těchto parametrech:

  • Atribut funkce, který také nastaví název funkce
  • Jak funkce získá ILogger/ILogger<T>
  • Atributy a parametry triggeru a vazeb

Zbývající část této části vás provede jednotlivými kroky.

Atributy funkce

Atribut Function v izolovaném modelu pracovního procesu nahradí FunctionName atribut. Nový atribut má stejný podpis a jediný rozdíl je v názvu. Proto můžete pouze provést nahrazení řetězce v rámci projektu.

Protokolování

V modelu v procesu můžete zahrnout volitelný ILogger parametr pro funkci, nebo můžete použít injektáž závislostí k získání ILogger<T>. Pokud aplikace už injektáž závislostí používala, fungují stejné mechanismy v izolovaném modelu pracovního procesu.

Pro všechny funkce, které závisely na parametru ILogger metody, ale musíte provést změnu. Doporučujeme, abyste k získání ILogger<T> použili injektáž závislostí. Pomocí následujících kroků migrujte mechanismus protokolování funkce:

  1. Do třídy funkce přidejte private readonly ILogger<MyFunction> _logger; vlastnost a nahraďte MyFunction ji názvem vaší třídy funkcí.

  2. Vytvořte konstruktor pro vaši třídu funkcí, který přijímá ILogger<T> jako parametr.

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

    Nahraďte obě instance MyFunction v předchozím fragmentu kódu názvem vaší třídy funkcí.

  3. V případě operací protokolování v kódu funkce nahraďte odkazy na parametr ILogger parametrem _logger.

  4. ILogger Odeberte parametr z podpisu funkce.

Další informace najdete v tématu Protokolování v izolovaném modelu pracovního procesu.

Změny spouštěčů a vazeb

Když jste změnili odkazy na balíčky v předchozím kroku, zavedli jste chyby pro triggery a vazby, které teď můžete opravit:

  1. Odeberte všechny using Microsoft.Azure.WebJobs; příkazy.

  2. Přidejte příkaz using Microsoft.Azure.Functions.Worker;.

  3. U každého atributu vazby změňte název atributu, jak je uvedeno v referenční dokumentaci, kterou najdete v indexu Podporovaných vazeb. Obecně platí, že názvy atributů se mění takto:

    • Triggery obvykle zůstávají pojmenované stejným způsobem. Je to například QueueTrigger název atributu pro oba modely.
    • Vstupní vazby obvykle potřebují Input přidat do jejich názvu. Pokud jste například použili CosmosDB atribut vstupní vazby v modelu procesu, atribut by nyní byl CosmosDBInput.
    • Do názvů výstupních vazeb je obvykle třeba přidat Output. Pokud jste například použili Queue atribut výstupní vazby v modelu procesu, tento atribut by nyní byl QueueOutput.

  4. Aktualizujte parametry atributu tak, aby odrážely verzi izolovaného pracovního modelu, jak je specifikováno v referenční dokumentaci vazby.

    Například v modelu v procesu je výstupní vazba objektu blob reprezentována atributem [Blob(...)] , který obsahuje Access vlastnost. V izolovaném pracovním modelu by atribut výstupu objektu blob byl [BlobOutput(...)]. Vazba již nevyžaduje Access vlastnost, takže parametr lze odebrat. Takže [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] by se stal [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

  5. Přesuňte výstupní vazby ze seznamu parametrů funkce. Pokud máte jenom jednu výstupní vazbu, můžete ji použít na návratový typ funkce. Pokud máte více výstupů, vytvořte novou třídu s vlastnostmi pro každý výstup a použijte atributy na tyto vlastnosti. Další informace najdete v tématu Více výstupních vazeb.

  6. Projděte si referenční dokumentaci jednotlivých vazeb k typům, se které můžete svázat. V některých případech může být potřeba typ změnit. Pokud verze modelu v procesu použila IAsyncCollector<T>výstupní vazby, můžete ji nahradit vazbou na pole cílového typu: T[]. Můžete také zvážit nahrazení výstupní vazby objektem klienta pro službu, kterou představuje, buď jako typ vazby pro vstupní vazbu, pokud je k dispozici, nebo vložením klienta sami.

  7. Pokud vaše funkce obsahuje IBinder parametr, odeberte ho. Nahraďte funkce objektem klienta služby, který představuje, buď jako typ vazby pro vstupní vazbu, pokud je k dispozici, nebo vložením klienta sami.

  8. Aktualizujte kód funkce tak, aby fungoval s novými typy.

local.settings.json soubor

Soubor local.settings.json se používá pouze při místním spuštění. Pro informace se podívejte do souboru místních nastavení.

Při migraci z běžící aplikace na spuštění v izolovaném pracovním procesu je potřeba změnit hodnotu FUNCTIONS_WORKER_RUNTIME na dotnet-isolated. Ujistěte se, že soubor local.settings.json obsahuje alespoň následující prvky:

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

Hodnota, pro AzureWebJobsStorage kterou máte, se může lišit. V rámci migrace nemusíte měnit její hodnotu.

soubor host.json

V souboru host.json se nevyžadují žádné změny. Pokud je však vaše konfigurace Application Insights v tomto souboru z projektu modelu v procesu, možná budete chtít provést další změny v souboru Program.cs . Soubor host.json řídí protokolování pouze z modulu runtime hostitele Služby Functions a v izolovaném pracovním modelu pocházejí některé z těchto protokolů přímo z vaší aplikace a poskytují větší kontrolu. Podrobnosti o filtrování těchto protokolů najdete v tématu Správa úrovní protokolů v izolovaném pracovním modelu .

Jiné změny kódu

V této části jsou zvýrazněné další změny kódu, které je potřeba vzít v úvahu při práci s migrací. Tyto změny nejsou potřeba pro všechny aplikace, ale měli byste vyhodnotit, jestli jsou pro vaše scénáře relevantní.

Serializace JSON

Ve výchozím nastavení používá izolovaný pracovní model system.Text.Json pro serializaci JSON. Pokud chcete přizpůsobit možnosti serializátoru nebo přepnout na JSON.NET (Newtonsoft.Json), přečtěte si téma Přizpůsobení serializace JSON.

Application Insights: úrovně protokolů a filtrování

Protokoly je možné odesílat do Application Insights jak z modulu runtime hostitele Functions, tak z kódu ve vašem projektu. host.json umožňuje konfigurovat pravidla pro protokolování hostitele, ale pokud chcete mít kontrolu nad protokoly pocházejícími z vašeho kódu, je potřeba nakonfigurovat pravidla filtrování jako součást Program.cs. Podrobnosti o filtrování těchto protokolů najdete v tématu Správa úrovní protokolů v izolovaném pracovním modelu .

Ukázkové migrace funkcí

Příklad triggeru HTTP

Trigger HTTP pro model v procesu může vypadat jako v následujícím příkladu:

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace Company.Function
{
    public static class HttpTriggerCSharp
    {
        [FunctionName("HttpTriggerCSharp")]
        public static IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Trigger HTTP pro migrovanou verzi může vypadat jako v následujícím příkladu:

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

namespace Company.Function
{
    public class HttpTriggerCSharp
    {
        private readonly ILogger<HttpTriggerCSharp> _logger;

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

        [Function("HttpTriggerCSharp")]
        public IActionResult Run(
            [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
        {
            _logger.LogInformation("C# HTTP trigger function processed a request.");

            return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
        }
    }
}

Aktualizace aplikace funkcí v Azure

Aktualizace aplikace funkcí na izolovaný model zahrnuje dvě změny, které by se měly dokončit společně, protože pokud dokončíte jenom jednu, aplikace je ve stavu chyby. Obě tyto změny také způsobí restartování procesu aplikace. Z těchto důvodů byste měli provést aktualizaci pomocí přípravného slotu. Přípravné sloty pomáhají minimalizovat výpadky vaší aplikace a umožňují otestovat a ověřit migrovaný kód s aktualizovanou konfigurací v Azure. Plně migrovanou aplikaci pak můžete nasadit do produkčního slotu prostřednictvím operace výměny.

Důležité

Pokud nasazená datová část aplikace neodpovídá nakonfigurovanému runtime, je v chybovém stavu. Během procesu migrace umístíte aplikaci do tohoto stavu, ideálně pouze dočasně. Sloty nasazení pomáhají zmírnit účinek tohoto problému, protože stav chyby se vyřeší ve vašem přípravném (neprodukčním) prostředí před tím, než se změny použijí jako jedna aktualizace v produkčním prostředí. Sloty také chrání před chybami a umožňují vám odhalit všechny další problémy před nasazením do produkčního prostředí.

Během tohoto procesu se mohou v protokolech stále zobrazovat chyby, které pocházejí z vašeho přípravného (neprodukčního) slotu. To se očekává, i když by měly zmizet, jak budete pokračovat v krocích. Před provedením operace prohození slotů byste měli potvrdit, že se tyto chyby přestanou vygenerovat a že vaše aplikace funguje podle očekávání.

Pomocí slotů nasazení aktualizujte funkční aplikaci na izolovaný model pracovníka podle následujících kroků:

  1. Vytvořte slot nasazení, pokud jste to ještě neudělali. Můžete se také seznámit s procesem výměny slotů a zajistit, že budete schopni provádět aktualizace stávající aplikace s minimálním rušením.

  2. Změňte konfiguraci přípravného (neprodukčního) slotu tak, aby používal izolovaný pracovní model nastavením FUNCTIONS_WORKER_RUNTIME na dotnet-isolated. FUNCTIONS_WORKER_RUNTIME by nemělo být označeno jako slotové nastavení.

    Pokud v rámci aktualizace také cílíte na jinou verzi .NET, měli byste rovněž změnit konfiguraci stacku. Pro více informací viz Aktualizace konfigurace stacku. Stejné pokyny můžete použít pro všechny budoucí aktualizace verzí .NET, které provedete.

    Pokud máte nějaké automatizované zřizování infrastruktury, jako je kanál CI/CD, ujistěte se, že jsou automatizace také aktualizované, aby byly FUNCTIONS_WORKER_RUNTIME nastavené dotnet-isolated a aby cílily na správnou verzi .NET.

  3. Publikujte migrovaný projekt do přípravného (neprodukčního) slotu vaší aplikace funkcí.

    Pokud pomocí sady Visual Studio publikujete projekt modelu izolovaného pracovního procesu do existující aplikace nebo slotu, který používá model v procesu, můžete zároveň dokončit předchozí krok. Pokud jste předchozí krok nedokončili, Visual Studio vás vyzve k aktualizaci aplikace funkcí během nasazování. Visual Studio tuto operaci prezentuje jako jednu operaci, ale stále se jedná o dvě samostatné operace. V protokolech se mohou během přechodného stavu stále zobrazovat chyby z přípravného (neprodukčního) prostředí.

  4. Ověřte, že vaše aplikace funguje podle očekávání v přípravném (neprodukčním) slotu.

  5. Proveďte operaci prohození slotů, abyste použili změny provedené ve vašem testovacím (neprodukčním) slotu na produkční slot. Prohození slotů se provádí jako jediná aktualizace, která brání vzniku dočasného chybového stavu v produkčním prostředí.

  6. Ověřte, že vaše aplikace funguje podle očekávání v produkčním slotu.

Po dokončení těchto kroků se migrace dokončí a vaše aplikace běží v izolovaném modelu. Gratulujeme! Podle potřeby opakujte kroky z této příručky pro všechny ostatní aplikace, které potřebují migraci.

Další krok

Další informace o izolovaném modelu pracovního procesu