Sdílet prostřednictvím

Průvodce spuštěním azure Functions v C# v izolovaném pracovním modelu

Tento článek představuje práci se službou Azure Functions v .NET pomocí izolovaného pracovního modelu. Tento model umožňuje zaměření projektu na verze .NET nezávisle na ostatních komponentách běhového prostředí. Informace o podporovaných verzích .NET najdete v části Podporované verze.

Pomocí následujících odkazů můžete hned začít vytvářet funkce izolovaného pracovního modelu .NET.

Začínáme Koncepty Ukázky

Další informace o nasazení projektu izolovaného modelu pracovního procesu do Azure najdete v tématu Nasazení do Azure Functions.

Výhody izolovaného modelu pracovního procesu

Funkce knihovny tříd .NET můžete spouštět ve dvou režimech: buď ve stejném procesu jako hostitel prostředí runtime Functions (v procesu in-process), nebo v izolovaném pracovním procesu. Když se funkce .NET spouštějí v izolovaném pracovním procesu, můžete využít následující výhody:

  • Méně konfliktů: Vzhledem k tomu, že vaše funkce běží v samostatném procesu, sestavení použitá v aplikaci nejsou v konfliktu s různými verzemi stejných sestavení používaných hostitelským procesem.
  • Úplné řízení procesu: Řídíte spuštění aplikace, což znamená, že můžete spravovat použité konfigurace a spustit middleware.
  • Standardní injektáž závislostí: Vzhledem k tomu, že máte úplnou kontrolu nad procesem, můžete použít aktuální chování .NET pro injektáž závislostí a začlenit middleware do vaší aplikace funkcí.
  • Flexibilita verze .NET: Spuštění mimo hostitelský proces znamená, že vaše funkce se můžou spouštět ve verzích .NET, které modul runtime služby Functions nativně nepodporuje, včetně rozhraní .NET Framework.

Pokud máte existující aplikaci funkcí jazyka C#, která běží v procesu, musíte aplikaci migrovat, abyste mohli tyto výhody využít. Další informace najdete v tématu Migrace aplikací .NET z modelu v procesu do izolovaného pracovního modelu.

Komplexní porovnání mezi těmito dvěma režimy najdete v tématu Rozdíly mezi procesem v procesu a izolovaným pracovním procesem .NET Azure Functions.

Podporované verze

Verze runtime Functions podporují konkrétní verze rozhraní .NET. Další informace o verzích functions najdete v přehledu verzí modulu runtime Azure Functions. Podpora verzí také závisí na tom, zda vaše funkce běží v procesu nebo izolovaném pracovním procesu.

Poznámka:

Informace o tom, jak změnit verzi modulu runtime funkcí používanou vaší funkční aplikací, vizte v části zobrazit a aktualizovat aktuální verzi modulu runtime.

Následující tabulka ukazuje nejvyšší úroveň rozhraní .NET nebo .NET Framework, kterou je možné použít s konkrétní verzí funkcí.

Verze modulu runtime služby Functions Izolovaný model pracovního procesu Model v procesu4
Funkce 4.x1 .NET 105
.NET 9.0
.NET 8.0
.NET Framework 4.82		 .NET 8.0
Funkce 1.x3 Není k dispozici .NET Framework 4.8

1 .NET 6 bylo dříve podporováno na obou modelech, ale dosáhlo konce oficiální podpory 12. listopadu 2024. Rozhraní .NET 7 bylo dříve podporováno v izolovaném modelu pracovních procesů, ale dosáhlo konce oficiální podpory 14. května 2024.

2 Proces sestavení také vyžaduje sadu .NET SDK.

3 Podpora pro verzi 1.x modulu runtime Azure Functions končí 14. září 2026. Další informace najdete v tomto oznámení podpory. Pokud chcete pokračovat v plné podpoře, měli byste migrovat aplikace na verzi 4.x.

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

5 V plánu Consumption nemůžete spouštět aplikace .NET 10 v Linuxu. Pokud chcete spustit v Linuxu, měli byste místo toho použít plán Flex Consumption.

Pro nejnovější zprávy o nových verzích Azure Functions, včetně odstranění konkrétních starších podverzí, sledujte oznámení služby Azure App Service.

Struktura projektu

Projekt .NET pro Azure Functions, který používá izolovaný model pracovního procesu, je v podstatě projekt konzolové aplikace .NET, který cílí na podporovaný modul runtime .NET. Následující soubory jsou základní soubory vyžadované v jakémkoli izolovaném projektu .NET:

  • Soubor projektu jazyka C# (.csproj), který definuje projekt a závislosti.
  • Program.cs soubor, který je vstupním bodem aplikace.
  • Všechny soubory kódu definující vaše funkce.
  • host.json soubor, který definuje konfiguraci sdílenou funkcemi v projektu.
  • local.settings.json soubor, který definuje proměnné prostředí používané vaším projektem při místním spuštění na počítači.

Kompletní příklady najdete v ukázkovém projektu .NET 8 a ukázkovém projektu .NET Framework 4.8.

Odkazy na balíčky

Projekt .NET pro Azure Functions, který používá izolovaný model pracovního procesu, používá jedinečnou sadu balíčků pro základní funkce i rozšíření vazeb.

Základní balíčky

Ke spuštění funkcí .NET v izolovaném pracovním procesu potřebujete následující balíčky:

Minimální verze těchto balíčků závisí na vaší cílové verzi .NET:

Verze .NET Microsoft.Azure.Functions.Worker Microsoft.Azure.Functions.Worker.Sdk
.NET 10 2.50.0 nebo novější 2.0.5 nebo novější
.NET 9 2.0.0 nebo novější 2.0.0 nebo novější
.NET 8 1.16.0 nebo novější 1.11.0 nebo novější
.NET Framework 1.16.0 nebo novější 1.11.0 nebo novější

Verze 2.x

Verze 2.x základních balíčků mění podporované architektury a přinášejí podporu nových rozhraní .NET API z těchto novějších verzí. Při aktualizaci na verze 2.x mějte na paměti následující změny:

  • Počínaje verzí 2.0.0 sady Microsoft.Azure.Functions.Worker.Sdk:
    • Sada SDK obsahuje výchozí konfigurace pro sestavení kontejnerů sady SDK.
    • Sada SDK obsahuje podporu pro dotnet run, pokud je nainstalován Azure Functions Core Tools. Ve Windows nainstalujte nástroje Core Tools prostřednictvím jiného mechanismu než NPM.
  • Počínaje verzí 2.0.0 Microsoft.Azure.Functions.Worker:
    • Tato verze přidává podporu pro IHostApplicationBuilder. Mezi příklady v tomto průvodci patří karty, které ukazují alternativy pomocí IHostApplicationBuilder. Tyto příklady vyžadují verze 2.x.
    • Ověření rozsahu poskytovatele služeb je ve výchozím nastavení zahrnuté, pokud běží ve vývojovém prostředí. Toto chování odpovídá ASP.NET Core.
    • Tato EnableUserCodeException možnost je ve výchozím nastavení povolená. Vlastnost je nyní označena jako zastaralá.
    • Tato IncludeEmptyEntriesInMessagePayload možnost je ve výchozím nastavení povolená. Pokud je tato možnost povolena, spouštěcí datové pakety, které představují kolekce, vždy obsahují prázdné položky. Například, pokud je zpráva odeslána bez obsahu, v string[] pro údaje spouštěče se stále nachází prázdná položka. Zahrnutí prázdných položek usnadňuje křížový odkaz s poli metadat, na která může funkce odkazovat. Toto chování můžete zakázat nastavením IncludeEmptyEntriesInMessagePayload na false v WorkerOptions konfiguraci služby.
    • Třída ILoggerExtensions je přejmenována na FunctionsLoggerExtensions. Přejmenování zabraňuje nejednoznačné chybě volání při použití LogMetric() v ILogger instanci.
    • U aplikací, které používají HttpResponseData, WriteAsJsonAsync() už metoda nenastaví stavový kód na 200 OK. V 1.x toto chování přerodí další kódy chyb, které jste nastavili.
  • Verze 2.x odstraňují podporu .NET 5 TFM.

Balíčky rozšíření

Vzhledem k tomu, že funkce izolovaného pracovního procesu .NET používají různé typy vazeb, vyžadují jedinečnou sadu balíčků rozšíření vazeb.

Tyto balíčky rozšíření najdete v části Microsoft.Azure.Functions.Worker.Extensions.

Spuštění a konfigurace

Při použití izolovaného modelu pracovníka máte přístup ke spuštění vaší funkční aplikace, která je obvykle v Program.cs. Zodpovídáte za vytváření a spouštění vlastní instance hostitele. V takovém případě máte také přímý přístup ke konfiguračnímu kanálu pro vaši aplikaci. S izolovaným pracovním procesem .NET Functions můžete mnohem snadněji přidávat konfigurace, vkládat závislosti a spouštět vlastní middleware.

Aby bylo možné použít vaši aplikaci IHostApplicationBuilder, musí používat verzi 2.x nebo novější základních balíčků.

Následující kód ukazuje příklad pipeline IHostApplicationBuilder:

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Logging.Services.Configure<LoggerFilterOptions>(options =>
    {
        // The Application Insights SDK adds a default logging filter that instructs ILogger to capture only Warning and more severe logs. Application Insights requires an explicit override.
        // Log levels can also be configured using appsettings.json. For more information, see https://learn.microsoft.com/azure/azure-monitor/app/worker-service#ilogger-logs
        LoggerFilterRule defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName
            == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
        if (defaultRule is not null)
        {
            options.Rules.Remove(defaultRule);
        }
    });

var host = builder.Build();

Před voláním Build() na tomto objektu IHostApplicationBuilder byste měli:

  • Pokud chcete použít integraci ASP.NET Core, zavolejte builder.ConfigureFunctionsWebApplication().
  • Pokud píšete aplikaci pomocí jazyka F#, možná budete muset zaregistrovat některá rozšíření vazeb. Pokud plánujete používat tato rozšíření v aplikaci F#, podívejte se do dokumentace k nastavení rozšíření Blobs, rozšíření Tables a rozšíření Cosmos DB.
  • Nakonfigurujte všechny služby nebo konfiguraci aplikace, které váš projekt vyžaduje. Podrobnosti najdete v části Konfigurace .
  • Pokud plánujete používat Application Insights, musíte volat AddApplicationInsightsTelemetryWorkerService() a ConfigureFunctionsApplicationInsights() proti vlastnosti tvůrce Services . Podrobnosti najdete v Application Insights .

Pokud váš projekt cílí na rozhraní .NET Framework 4.8, je nutné přidat FunctionsDebugger.Enable(); také před vytvořením nástroje HostBuilder. Měl by to být první řádek vaší Main() metody. Další informace naleznete v tématu Ladění při cílení na rozhraní .NET Framework.

IHostApplicationBuilder se používá k sestavení a vrácení plně inicializované IHost instance, kterou spustíte asynchronně pro spuštění aplikace funkcí.

await host.RunAsync();

Konfigurace

Typ používaného tvůrce určuje způsob konfigurace aplikace.

FunctionsApplication.CreateBuilder() Pomocí této metody přidejte nastavení potřebná ke spuštění aplikace funkcí. Tato metoda zahrnuje následující funkce:

  • Výchozí sada převaděčů
  • Nastavte výchozí JsonSerializerOptions tak, aby ignorovala velikost písmen u názvů vlastností.
  • Integrace s protokolováním Azure Functions
  • Middleware a funkce výstupní vazby
  • Middleware pro vykonávání funkcí
  • Výchozí podpora gRPC
  • Použijte jiné výchozí hodnoty z Host.CreateDefaultBuilder().

Máte přístup ke kanálu tvůrce, takže během inicializace můžete nastavit jakékoli konfigurace specifické pro aplikaci. Metody rozšíření můžete volat u vlastnosti buildera Configuration a přidat tak všechny zdroje konfigurace vyžadované vaším kódem. Další informace o konfiguraci aplikace najdete v tématu Konfigurace v ASP.NET Core.

Tyto konfigurace se vztahují pouze na vytvořený pracovní kód. Nemají přímý vliv na konfiguraci hostitele nebo triggerů a vazeb Functions. Pokud chcete provést změny hostitele funkcí nebo konfigurace triggeru a vazby, použijte souborhost.json.

Poznámka:

Vlastní zdroje konfigurace se nedají použít pro konfiguraci aktivačních událostí a vazeb. Konfigurace triggeru a vazby musí být dostupná pro platformu Functions, a ne jenom kód aplikace. Tuto konfiguraci můžete poskytnout prostřednictvím nastavení aplikace, odkazů služby Key Vault nebo odkazů na konfiguraci aplikací.

Injektáž závislostí

Izolovaný pracovní model používá standardní mechanismy .NET pro vkládání služeb.

Při použití IHostApplicationBuilder použijte jeho Services vlastnost k přístupu k IServiceCollection. Následující příklad injektuje závislost singletonové služby:

builder.Services.AddSingleton<IHttpResponderService, DefaultHttpResponderService>();

Tento kód vyžaduje using Microsoft.Extensions.DependencyInjection;. Další informace najdete v tématu Injektáž závislostí v ASP.NET Core.

Registrace klientů Azure

Použijte vkládání závislostí k interakci s jinými službami Azure Klienty ze sady Azure SDK pro .NET můžete vložit pomocí balíčku Microsoft.Extensions.Azure . Po instalaci balíčku zaregistrujte klienty voláním AddAzureClients() na kolekci služeb v Program.cs. Následující příklad nakonfiguruje pojmenovaného klienta pro objekty blob Azure:

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddAzureClients(clientBuilder =>
        {
            clientBuilder.AddBlobServiceClient(builder.Configuration.GetSection("MyStorageConnection"))
                .WithName("copierOutputBlob");
        });

builder.Build().Run();

Následující příklad ukazuje, jak můžete pomocí této registrace a typů sad SDK zkopírovat obsah objektů blob jako datový proud z jednoho kontejneru do druhého pomocí injektovaného klienta:

using Microsoft.Extensions.Azure;
using Microsoft.Extensions.Logging;

namespace MyFunctionApp
{
    public class BlobCopier
    {
        private readonly ILogger<BlobCopier> _logger;
        private readonly BlobContainerClient _copyContainerClient;

        public BlobCopier(ILogger<BlobCopier> logger, IAzureClientFactory<BlobServiceClient> blobClientFactory)
        {
            _logger = logger;
            _copyContainerClient = blobClientFactory.CreateClient("copierOutputBlob").GetBlobContainerClient("samples-workitems-copy");
            _copyContainerClient.CreateIfNotExists();
        }

        [Function("BlobCopier")]
        public async Task Run([BlobTrigger("samples-workitems/{name}", Connection = "MyStorageConnection")] Stream myBlob, string name)
        {
            await _copyContainerClient.UploadBlobAsync(name, myBlob);
            _logger.LogInformation($"Blob {name} copied!");
        }

    }
}

V tomto příkladu se ILogger<T> získá také prostřednictvím injektování závislostí, takže se zaregistruje automaticky. Další informace o možnostech konfigurace pro protokolování najdete v tématu Protokolování.

Návod

Příklad používá textový řetězec pro název klienta v Program.cs i ve funkci. Místo toho zvažte použití sdíleného konstantního řetězce definovaného ve třídě funkce. Můžete například přidat public const string CopyStorageClientName = nameof(_copyContainerClient); a potom odkazovat na BlobCopier.CopyStorageClientName na obou místech. Podobným způsobem můžete definovat název oddílu konfigurace s funkcí místo v Program.cs.

Middleware

Izolovaný pracovní model také podporuje registraci middlewaru, a to znovu pomocí modelu podobného tomu, co existuje v ASP.NET. Tento model umožňuje vložit logiku do kanálu vyvolání a před a po spuštění funkcí.

ConfigureFunctionsWorkerDefaults metoda rozšíření má přetížení, které vám umožní zaregistrovat vlastní middleware, jak vidíte v následujícím příkladu.

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

var builder = FunctionsApplication.CreateBuilder(args);

// Register our custom middlewares with the worker
builder
    .UseMiddleware<ExceptionHandlingMiddleware>()
    .UseMiddleware<MyCustomMiddleware>()
    .UseWhen<StampHttpHeaderMiddleware>((context) =>
    {
        // We want to use this middleware only for http trigger invocations.
        return context.FunctionDefinition.InputBindings.Values
                        .First(a => a.Type.EndsWith("Trigger")).Type == "httpTrigger";
    });

builder.Build().Run();

Metoda UseWhen rozšíření zaregistruje middleware, který se spouští podmíněně. Je nutné předat predikát, který této metodě vrátí logickou hodnotu. Middleware se účastní kanálu zpracování vyvolání, když predikát vrátí true.

Následující metody rozšíření na FunctionContext usnadňují práci s middlewarem v izolovaném modelu.

metoda Popis
GetHttpRequestDataAsync Získá instanci HttpRequestData když je vyvolán HTTP triggerem. Tato metoda vrátí instanci ValueTask<HttpRequestData?>, která je užitečná, když chcete číst data zpráv, jako jsou hlavičky požadavku a soubory cookie.
GetHttpResponseData Získá instanci HttpResponseData když je vyvolán HTTP triggerem.
GetInvocationResult Získá instanci InvocationResult, která představuje výsledek aktuálního spuštění funkce. Value Pomocí vlastnosti získejte nebo nastavte hodnotu podle potřeby.
GetOutputBindings Získá položky výstupních vazeb pro aktuální spuštění funkce. Každá položka v výsledku této metody je typu OutputBindingData. Vlastnost můžete použít Value k získání nebo nastavení hodnoty podle potřeby.
BindInputAsync Vytvoří vazbu pro položku vstupní vazby požadované instance BindingMetadata. Tuto metodu použijte například v případě, že máte funkci se vstupní vazbou BlobInput , kterou musí váš middleware použít.

Tento příklad ukazuje implementaci middlewaru HttpRequestData , která čte instanci a aktualizuje HttpResponseData instanci během provádění funkce:

internal sealed class StampHttpHeaderMiddleware : IFunctionsWorkerMiddleware
{
    public async Task Invoke(FunctionContext context, FunctionExecutionDelegate next)
    {
        var requestData = await context.GetHttpRequestDataAsync();

        string correlationId;
        if (requestData!.Headers.TryGetValues("x-correlationId", out var values))
        {
            correlationId = values.First();
        }
        else
        {
            correlationId = Guid.NewGuid().ToString();
        }

        await next(context);

        context.GetHttpResponseData()?.Headers.Add("x-correlationId", correlationId);
    }
}

Tento middleware kontroluje přítomnost konkrétní hlavičky požadavku (x-correlationId). Pokud je hlavička přítomná, middleware použije hodnotu hlavičky k nastavení hlavičky odpovědi. V opačném případě vygeneruje novou hodnotu GUID a použije tuto hodnotu pro razítko hlavičky odpovědi.

Návod

Vzor zobrazený dříve, kdy se nastavují hlavičky odpovědí po await next(context), nemusí spolehlivě fungovat ve všech scénářích. Tento problém platí zejména v případě, že používáte integraci ASP.NET Core nebo v určitých konfiguracích modulu runtime, ve kterých už byl stream odpovědí odeslán. Pokud chcete zajistit správné nastavení hlaviček, zvažte načtení odpovědi z context.GetInvocationResult().Value a nastavení hlaviček před vrácením odpovědi z funkce, místo abyste se pokoušeli je upravovat v middlewaru po dokončení provádění funkce.

Kompletní příklad použití vlastního middlewaru v aplikaci funkcí najdete v ukázce vlastních referenčních informací k middlewaru.

Přizpůsobení serializace JSON

Model izolovaného pracovníka používá System.Text.Json ve výchozím nastavení. Chování serializátoru můžete přizpůsobit konfigurací služeb v rámci souboru Program.cs . Tato část popisuje serializaci pro obecné účely a nemá vliv na serializaci JSON triggeru HTTP s integrací ASP.NET Core, kterou musíte nakonfigurovat samostatně.

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services.Configure<JsonSerializerOptions>(jsonSerializerOptions =>
    {
        jsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;
        jsonSerializerOptions.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;
        jsonSerializerOptions.ReferenceHandler = ReferenceHandler.Preserve;

        // override the default value
        jsonSerializerOptions.PropertyNameCaseInsensitive = false;
    });

builder.Build().Run();

Chcete-li použít JSON.NET (Newtonsoft.Json) pro serializaci, nainstalujte Microsoft.Azure.Core.NewtonsoftJson balíček. Potom v registraci služby znovu přiřaďte Serializer vlastnost ke WorkerOptions konfiguraci. Následující příklad ukazuje tuto konfiguraci pomocí ConfigureFunctionsWebApplication, ale funguje také pro ConfigureFunctionsWorkerDefaults:

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services.Configure<WorkerOptions>(workerOptions =>
    {
        var settings = NewtonsoftJsonObjectSerializer.CreateJsonSerializerSettings();
        settings.ContractResolver = new CamelCasePropertyNamesContractResolver();
        settings.NullValueHandling = NullValueHandling.Ignore;

        workerOptions.Serializer = new NewtonsoftJsonObjectSerializer(settings);
    });

builder.Build().Run();

Metody rozpoznané jako funkce

Metoda funkce je veřejná metoda veřejné třídy s atributem Function použitým na metodu a atribut trigger použitý na vstupní parametr, jak je znázorněno v následujícím příkladu:

[Function(nameof(QueueInputOutputFunction))]
[QueueOutput("output-queue")]
public string[] QueueInputOutputFunction([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)

Atribut triggeru určuje typ triggeru a vytvoří vazbu vstupních dat na parametr metody. Předchozí ukázková funkce se aktivuje pomocí zprávy fronty a zpráva fronty se předá metodě v parametru myQueueItem.

Atribut Function označuje metodu jako vstupní bod funkce. Název musí být v rámci projektu jedinečný, musí začínat písmenem a obsahovat pouze písmena, číslice _a -až 127 znaků. Šablony projektů často vytvářejí metodu s názvem Run, ale název metody může být libovolný platný název metody jazyka C#. Metoda musí být veřejným členem veřejné třídy. Obecně by to měla být instanční metoda, aby služby mohly být předány prostřednictvím injekce závislostí.

Parametry funkce

Tady jsou některé parametry, které můžete zahrnout jako součást podpisu metody funkce:

  • Vazby, které jsou označené jako takové dekorací parametrů jako atributy. Funkce musí obsahovat přesně jeden parametr triggeru.
  • Objekt kontextu spuštění, který poskytuje informace o aktuálním vyvolání.
  • Příznak pro zrušení, který se používá k plynulému vypnutí.

Kontext spuštění

V izolovaném modelu pracovního procesu předá objekt FunctionContext vašim metodám funkce. Tento objekt umožňuje získat ILogger instanci pro zápis do protokolů voláním GetLogger metody a zadáním categoryName řetězce. Tento kontext můžete použít k získání ILogger bez nutnosti použití vkládání závislostí. Další informace naleznete v tématu Protokoly.

Tokeny zrušení

Funkce může přijmout parametr cancellationToken , který umožňuje operačnímu systému upozornit váš kód, když se funkce chystá ukončit. Pomocí tohoto oznámení můžete zajistit, aby se funkce neočekávaně neukončila způsobem, který ponechá data v nekonzistentním stavu.

Funkce .NET, které běží v izolovaném pracovním procesu, podporují tokeny zrušení. Následující příklad vyvolá výjimku při přijetí požadavku na zrušení:

[Function(nameof(ThrowOnCancellation))]
public async Task ThrowOnCancellation(
    [EventHubTrigger("sample-workitem-1", Connection = "EventHubConnection")] string[] messages,
    FunctionContext context,
    CancellationToken cancellationToken)
{
    _logger.LogInformation("C# EventHub {functionName} trigger function processing a request.", nameof(ThrowOnCancellation));

    foreach (var message in messages)
    {
        cancellationToken.ThrowIfCancellationRequested();
        await Task.Delay(6000); // task delay to simulate message processing
        _logger.LogInformation("Message '{msg}' was processed.", message);
    }
}

Následující příklad provádí akce vyčištění při přijetí žádosti o zrušení:

[Function(nameof(HandleCancellationCleanup))]
public async Task HandleCancellationCleanup(
    [EventHubTrigger("sample-workitem-2", Connection = "EventHubConnection")] string[] messages,
    FunctionContext context,
    CancellationToken cancellationToken)
{
    _logger.LogInformation("C# EventHub {functionName} trigger function processing a request.", nameof(HandleCancellationCleanup));

    foreach (var message in messages)
    {
        if (cancellationToken.IsCancellationRequested)
        {
            _logger.LogInformation("A cancellation token was received, taking precautionary actions.");
            // Take precautions like noting how far along you are with processing the batch
            _logger.LogInformation("Precautionary activities complete.");
            break;
        }

        await Task.Delay(6000); // task delay to simulate message processing
        _logger.LogInformation("Message '{msg}' was processed.", message);
    }
}

Scénáře, které vedou ke zrušení

Token zrušení se signalizuje, když je vyvolání funkce zrušeno. Zrušení může vést k několika důvodům a tyto důvody se liší v závislosti na použitém typu triggeru. Mezi běžné důvody patří:

  • Odpojení klienta: Klient, který vyvolá vaši funkci, se odpojí. Tento důvod je nejpravděpodobnější pro funkce triggeru HTTP.
  • Restartování aplikace funkcí: Vy nebo platforma restartujete (nebo zastavíte) aplikaci funkcí přibližně ve stejnou dobu, kdy je vyžadováno vyvolání. K restartování může dojít kvůli přesunům instancí pracovního procesu, aktualizacím instance pracovního procesu nebo škálování.

Aspekty zrušení

  • Vyvolání během události restartování se může opakovat v závislosti na tom, jak se aktivovaly. Další informace najdete v dokumentaci k opakovaným pokusům.

  • Hostitel odešle vyvolání pracovnímu procesu , i když je token zrušení zrušen před tím, než hostitel dokáže odeslat žádost o vyvolání pracovnímu procesu.

  • Pokud nechcete, aby se pracovníkovi odesílala předem zrušená volání, přidejte do souboru host.json vlastnost SendCanceledInvocationsToWorker, která toto chování zakáže.

    Tento příklad ukazuje host.json soubor, který používá tuto vlastnost:

    {
    "version": "2.0",
    "SendCanceledInvocationsToWorker": "false"
}

  • Nastavení SendCanceledInvocationsToWorker na false může vést k výjimce s následujícím záznamem: FunctionInvocationCanceled

    Bylo požadováno zrušení. Žádost o vyvolání s ID {invocationId} je zrušená a nebude odeslána pracovníkovi.

    K této výjimce dochází, když je storno token zneplatněn (v důsledku jedné z událostí popsaných výše) před tím, než host odešle příchozí žádost o vyvolání pracovníkovi. Tuto výjimku lze bezpečně ignorovat a očekává se, pokud SendCanceledInvocationsToWorker je false.

Vazby

Definujte vazby pomocí atributů pro metody, parametry a návratové typy. Vazby mohou poskytovat data jako řetězce, pole a serializovatelné typy, jako jsou jednoduché objekty tříd (POCOs). U některých rozšíření vazeb můžete také vytvořit vazbu na typy specifické pro službu, které jsou definovány v SDK služby.

Pro informace o HTTP triggeru viz část HTTP trigger.

Kompletní sadu referenčních příkladů, které používají triggery a vazby s funkcemi izolovaného pracovního procesu, najdete v referenční ukázce rozšíření vazeb.

Vstupní vazby

Funkce může mít nulové nebo více vstupních vazeb, které funkci předávají data. Podobně jako triggery definujete vstupní vazby použitím atributu vazby na vstupní parametr. Při spuštění funkce se modul runtime pokusí získat data zadaná v vazbě. Požadovaná data často závisí na informacích poskytovaných triggerem prostřednictvím parametrů vazby.

Výstupní vazby

Chcete-li zapisovat do výstupní vazby, musíte použít atribut výstupní vazby pro metodu funkce. Tento atribut definuje, jak zapisovat do vázané služby. Návratová hodnota metody je zapsána do výstupní vazby. Následující příklad například zapíše řetězcovou hodnotu do fronty zpráv pojmenované output-queue pomocí výstupní vazby:

[Function(nameof(QueueInputOutputFunction))]
[QueueOutput("output-queue")]
public string[] QueueInputOutputFunction([QueueTrigger("input-queue")] Album myQueueItem, FunctionContext context)
{
    // Use a string array to return more than one message.
    string[] messages = {
        $"Album name = {myQueueItem.Name}",
        $"Album songs = {myQueueItem.Songs}"};

    _logger.LogInformation("{msg1},{msg2}", messages[0], messages[1]);

    // Queue Output messages
    return messages;
}

Více výstupních vazeb

Data zapsaná do výstupní vazby jsou vždy návratovou hodnotou funkce. Pokud potřebujete zapisovat do více než jedné výstupní vazby, musíte vytvořit vlastní návratový typ. Tento návratový typ musí mít atribut výstupní vazby použitý na jednu nebo více vlastností třídy. Následující příklad je funkce aktivovaná protokolem HTTP, která používá ASP.NET Core integraci a zapisuje jak do odpovědi HTTP, tak do výstupní vazby fronty.

public class MultipleOutputBindings
{
    private readonly ILogger<MultipleOutputBindings> _logger;

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

    [Function("MultipleOutputBindings")]
    public MyOutputType Run([HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req)
    {
        _logger.LogInformation("C# HTTP trigger function processed a request.");
        var myObject = new MyOutputType
        {
            Result = new OkObjectResult("C# HTTP trigger function processed a request."),
            MessageText = "some output"
        };
        return myObject;
    }

    public class MyOutputType
    {
        [HttpResult]
        public IActionResult Result { get; set; }

        [QueueOutput("myQueue")]
        public string MessageText { get; set; }
    }
}

Pokud používáte vlastní návratové typy pro více výstupních vazeb s integrací ASP.NET Core, musíte přidat [HttpResult] atribut do vlastnosti, která poskytuje výsledek. Atribut HttpResult je k dispozici při použití sady SDK 1.17.3-preview2 nebo novější společně s verzí 3.2.0 nebo novější rozšíření HTTP a verzí 1.3.0 nebo novější rozšíření ASP.NET Core.

Typů SDK

U některých typů vazeb specifických pro službu můžete data vazby poskytnout pomocí typů ze sad SDK a architektur služby. Tyto typy nabízejí možnosti nad rámec toho, co serializovaný řetězec nebo prostý objekt CLR (POCO) může poskytnout. Pokud chcete použít novější typy, aktualizujte projekt tak, aby používal novější verze základních závislostí.

Závislost Požadavek na verzi
Microsoft.Azure.Functions.Worker 1.18.0 nebo novější
Microsoft.Azure.Functions.Worker.Sdk 1.13.0 nebo novější

Při místním testování typů sad SDK na vašem počítači musíte také použít Nástroje Azure Functions Core Tools verze 4.0.5000 nebo novější. Aktuální verzi můžete zkontrolovat pomocí func --version příkazu.

Každé vazební rozšíření má také požadovanou minimální verzi, která je popsána v odkazujících článcích o rozšíření. Vazební rozšíření v současné době podporují typy SDK:

Extension Types Úroveň podpory
Azure Blob Storage BlobClient
BlobContainerClient
BlockBlobClient
PageBlobClient
AppendBlobClient		 Aktivační událost: GA
Vstup: GA
Azure Cosmos DB CosmosClient
Database
Container		 Vstup: GA
Azure Event Grid CloudEvent
EventGridEvent		 Aktivační událost: GA
Azure Event Hubs EventData
EventHubProducerClient		 Aktivační událost: GA
Azure Queue Storage QueueClient
QueueMessage		 Aktivační událost: GA
Azure Service Bus ServiceBusClient
ServiceBusReceiver
ServiceBusSender
ServiceBusMessage		 Aktivační událost: GA
Azure Table Storage TableClient
TableEntity		 Vstup: GA

Úvahy o typech SDK:

  • Pokud používáte vazbové výrazy, které spoléhají na data triggeru , nelze použít typy sad SDK pro samotný trigger.
  • Ve výstupních scénářích, ve kterých můžete použít typ sady SDK, můžete vytvářet klienty sady SDK a pracovat s klienty sady SDK přímo místo použití výstupní vazby.
  • Trigger služby Azure Cosmos DB používá kanál změn služby Azure Cosmos DB a zveřejňuje položky kanálu změn jako serializovatelné typy JSON. V důsledku toho nejsou typy SDK podporované pro tento spouštěč.

HTTP spouštěč

Spouštěče HTTP umožňují, aby byla funkce vyvolána požadavkem HTTP. Můžete použít dva různé přístupy:

  • Model integrace ASP.NET Core, který používá koncepty známé pro vývojáře ASP.NET Core
  • Integrovaný model, který nevyžaduje další závislosti a používá vlastní typy pro požadavky a odpovědi HTTP. Tento přístup se udržuje kvůli zpětné kompatibilitě s předchozími izolovanými pracovními aplikacemi .NET.

integrace ASP.NET Core

Tato část ukazuje, jak pracovat s podkladovými objekty požadavků HTTP a odpovědí pomocí typů z ASP.NET Core, včetně HttpRequest, HttpResponse a IActionResult. Tento model není k dispozici pro aplikace cílené na rozhraní .NET Framework, které by místo toho měly používat integrovaný model.

Poznámka:

Tento model nezpřístupňuje všechny funkce ASP.NET Core. Konkrétně neposkytuje přístup k ASP.NET základnímu kanálu middlewaru a možnostem směrování. integrace ASP.NET Core vyžaduje použití aktualizovaných balíčků.

Povolení integrace ASP.NET Core pro PROTOKOL HTTP:

  1. Přidejte do projektu odkaz na balíček Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore verze 1.0.0 nebo novější.

  2. Aktualizujte projekt tak, aby používal tyto konkrétní verze balíčků:

  3. Ve vašem Program.cs souboru aktualizujte konfiguraci tvůrce hostitelů pro zavolání ConfigureFunctionsWebApplication(). Tato metoda nahradí ConfigureFunctionsWorkerDefaults() , pokud byste tuto metodu použili jinak. Následující příklad ukazuje minimální nastavení bez dalších přizpůsobení:

    Poznámka:

    Aplikace musí odkazovat na verzi 2.0.0 nebo novější microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore, aby používala integraci ASP.NET Core s IHostApplicationBuilder.

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();    

builder.Build().Run();

  4. Aktualizujte všechny existující funkce aktivované protokolem HTTP tak, aby používaly typy ASP.NET Core. Tento příklad ukazuje standard HttpRequest a IActionResult používá se pro jednoduchou funkci "hello, world":

    [Function("HttpFunction")]
public IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req)
{
    return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
}

Serializace JSON s integrací ASP.NET Core

ASP.NET Core má svou vlastní vrstvu serializace a není ovlivněna přizpůsobením obecné konfigurace serializace. Chcete-li přizpůsobit chování serializace používané pro triggery HTTP, musíte zahrnout .AddMvc() volání jako součást registrace služby. IMvcBuilder Vrácený kód lze použít ke změně nastavení serializace JSON ASP.NET Core.

Při používání ASP.NET integrace můžete i nadále používat HttpRequestDataHttpResponseData , i když u většiny aplikací je lepší místo toho používat HttpRequest a IActionResult. Použití HttpRequestData/HttpResponseData nevyvolá vrstvu serializace ASP.NET Core a místo toho spoléhá na obecnou konfiguraci serializace pracovních procesů pro aplikaci. Pokud je ale povolená integrace ASP.NET Core, možná budete muset přidat konfiguraci. Výchozí chování z ASP.NET Core je zakázat synchronní vstupně-výstupní operace. Pokud chcete použít vlastní serializátor, který nepodporuje asynchronní vstupně-výstupní operace, například NewtonsoftJsonObjectSerializermusíte pro aplikaci povolit synchronní vstupně-výstupní operace konfigurací KestrelServerOptions.

Následující příklad ukazuje, jak nakonfigurovat JSON.NET (Newtonsoft.Json) a balíček NuGet Microsoft.AspNetCore.Mvc.NewtonsoftJson pro serializaci pomocí tohoto přístupu:

using Microsoft.AspNetCore.Server.Kestrel.Core;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Services.AddMvc().AddNewtonsoftJson();

// Only needed if using HttpRequestData/HttpResponseData and a serializer that doesn't support asynchronous IO
// builder.Services.Configure<KestrelServerOptions>(options => options.AllowSynchronousIO = true);

builder.Build().Run();

Integrovaný model HTTP

V integrovaném modelu systém přeloží příchozí zprávu požadavku HTTP do objektu HttpRequestData , který předává funkci. Tento objekt poskytuje data z požadavku, včetně Headers, Cookies, Identities, URLa volitelně zprávy Body. Tento objekt představuje požadavek HTTP, ale není přímo připojený k podkladovému naslouchacímu procesu HTTP nebo přijaté zprávě.

Podobně funkce vrátí objekt HttpResponseData , který poskytuje data použitá k vytvoření odpovědi HTTP, včetně zprávy StatusCode, Headersa volitelně zprávy Body.

Následující příklad ukazuje použití HttpRequestData a HttpResponseData:

[Function(nameof(HttpFunction))]
public static HttpResponseData Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequestData req,
    FunctionContext executionContext)
{
    var logger = executionContext.GetLogger(nameof(HttpFunction));
    logger.LogInformation("message logged");

    var response = req.CreateResponse(HttpStatusCode.OK);
    response.Headers.Add("Content-Type", "text/plain; charset=utf-8");
    response.WriteString("Welcome to .NET isolated worker !!");

    return response;
}

Protokolování

Do protokolů můžete zapisovat pomocí instance ILogger<T> nebo ILogger. Logger můžete získat injektováním závislostíILogger<T> nebo ILoggerFactory:

public class MyFunction {
    
    private readonly ILogger<MyFunction> _logger;
    
    public MyFunction(ILogger<MyFunction> logger) {
        _logger = logger;
    }
    
    [Function(nameof(MyFunction))]
    public void Run([BlobTrigger("samples-workitems/{name}", Connection = "")] string myBlob, string name)
    {
        _logger.LogInformation($"C# Blob trigger function Processed blob\n Name: {name} \n Data: {myBlob}");
    }

}

Protokolovací objekt můžete získat také z objektu FunctionContext předaného do vaší funkce. Zavolejte metodu GetLogger<T> nebo GetLogger a zadejte řetězcovou hodnotu jako název kategorie, do které se zapisují protokoly. Kategorie je obvykle název konkrétní funkce, ze které se protokoly zapisují. Další informace o kategoriích najdete v článku monitorování.

Použijte metody ILogger<T> a ILogger ke zápisu různých úrovní protokolu, například LogWarning nebo LogError. Další informace o úrovních protokolů najdete v článku monitorování. Úrovně protokolů pro komponenty přidané do kódu můžete přizpůsobit registrací filtrů:

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

// Registers IHttpClientFactory.
// By default this sends a lot of Information-level logs.
builder.Services.AddHttpClient();

// Disable IHttpClientFactory Informational logs.
// Note -- you can also remove the handler that does the logging: https://github.com/aspnet/HttpClientFactory/issues/196#issuecomment-432755765 
builder.Logging.AddFilter("System.Net.Http.HttpClient", LogLevel.Warning);
    
builder.Build().Run();

V rámci konfigurace vaší aplikace v Program.cs můžete také definovat, jak se chyby zobrazují v protokolech. Výchozí chování závisí na typu tvůrce, který používáte.

Při použití IHostApplicationBuilder výjimky vyvolané vaším kódem procházejí systémem beze změn. Nepotřebujete žádnou jinou konfiguraci.

Application Insights

Aplikaci izolovaného procesu můžete nakonfigurovat tak, aby odesílala protokoly přímo do Application Insights. Tato konfigurace nahrazuje výchozí chování předávání protokolů prostřednictvím hostitele. Pokud nepoužíváte Aspire, nakonfigurujte přímou integraci Application Insights, abyste měli kontrolu nad tím, jak jsou tyto protokoly zaznamenávány.

Integrace Application Insights není ve výchozím nastavení ve všech prostředích nastavení povolená. Některé šablony vytvářejí projekty Functions s potřebnými balíčky a zakomentovaným spouštěcím kódem. Pokud chcete použít integraci Application Insights, odkomentujte tyto řádky v Program.cs a v souboru projektu .csproj. Pokyny ve zbývající části této části také popisují, jak povolit integraci.

Pokud je projekt součástí orchestrace Aspire, používá k monitorování metodu OpenTelemetry. Nepovolujte přímou integraci Application Insights v projektech Aspire. Místo toho nakonfigurujte exportér OpenTelemetry služby Azure Monitor jako součást výchozího projektu služby. Pokud projekt Functions používá integraci Application Insights v kontextu Aspire, dojde při spuštění aplikace k chybám.

Instalace balíčků

Pokud chcete zapisovat protokoly přímo do Application Insights z kódu, přidejte do projektu odkazy na tyto balíčky:

Spuštěním následujících příkazů přidejte tyto odkazy do projektu:

dotnet add package Microsoft.ApplicationInsights.WorkerService
dotnet add package Microsoft.Azure.Functions.Worker.ApplicationInsights

Konfigurace spuštění

Po instalaci balíčků zavolejte AddApplicationInsightsTelemetryWorkerService() a ConfigureFunctionsApplicationInsights() během konfigurace služby ve vašem souboru Program.cs, jak je znázorněno v následujícím příkladu.

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
    
var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Build().Run();

Volání ConfigureFunctionsApplicationInsights(), které přidá ITelemetryModule, jež naslouchá funkci definované v Functions pro ActivitySource. Tento modul vytvoří telemetrii závislostí potřebnou k podpoře distribuovaného trasování. Další informace o AddApplicationInsightsTelemetryWorkerService() tom, jak ho používat, najdete v tématu Application Insights pro aplikace pracovních služeb.

Správa úrovní protokolů

Důležité

Host Functions a izolovaný pracovní proces mají samostatnou konfiguraci pro úrovně protokolu. Jakákoli konfigurace Application Insights v host.json nemá vliv na protokolování od pracovního procesu a podobně konfigurace v kódu pracovního procesu nemá vliv na protokolování z hostitele. Pokud váš scénář vyžaduje přizpůsobení v obou vrstvách, použijte změny na obou místech.

Zbytek vaší aplikace pokračuje v práci s ILogger a ILogger<T>. Sada Application Insights SDK ale ve výchozím nastavení přidává filtr protokolování, který protokolovacímu nástroji dává pokyn, aby zaznamenával pouze upozornění a vážnější protokoly. Úrovně protokolů můžete v izolovaném pracovním procesu nakonfigurovat jedním z těchto způsobů:

Metoda konfigurace Výhody
V kódu Podporuje jasnější oddělení mezi konfiguracemi na straně hostitele a na straně pracovního procesu.
Použití appsettings.json Užitečné, když chcete nastavit různé úrovně protokolů pro různé kategorie, aniž byste museli upravovat kód.

Pokud chcete zakázat výchozí chování a zachytit všechny úrovně protokolů, odeberte pravidlo filtru jako součást konfigurace služby:

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

var builder = FunctionsApplication.CreateBuilder(args);

builder.Services
    .AddApplicationInsightsTelemetryWorkerService()
    .ConfigureFunctionsApplicationInsights();

builder.Logging.Services.Configure<LoggerFilterOptions>(options =>
    {
        LoggerFilterRule defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName
            == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
        if (defaultRule is not null)
        {
            options.Rules.Remove(defaultRule);
        }
    });

builder.Build().Run();

Další informace o konfiguraci protokolování naleznete v tématu Protokolování v aplikacích .NET a Application Insights pro pracovní služby.

Optimalizace výkonu

Tato část popisuje možnosti, které umožňují zvýšit výkon při studeném startu.

Obecně platí, že vaše aplikace by měla používat nejnovější verze základních závislostí. Minimálně aktualizujte projekt následujícím způsobem:

  1. Upgradujte Microsoft.Azure.Functions.Worker na verzi 1.19.0 nebo novější.
  2. Upgradujte Microsoft.Azure.Functions.Worker.Sdk na verzi 1.16.4 nebo novější.
  3. Přidejte odkaz na Microsoft.AspNetCore.App, pokud vaše aplikace necílí na .NET Framework.

Následující fragment kódu ukazuje tuto konfiguraci v kontextu souboru projektu:

  <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.16.4" />
  </ItemGroup>

Zástupné symboly

Zástupné symboly jsou funkce platformy, která zlepšuje studený start pro aplikace, které cílí na .NET 6 nebo novější. Pokud chcete tuto optimalizaci použít, musíte zástupné symboly explicitně povolit pomocí následujících kroků:

  1. Aktualizujte konfiguraci projektu tak, aby používala nejnovější verze závislostí, jak je podrobně popsáno v předchozí části.

  2. Nastavte WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED nastavení aplikace na 1. Použijte tento příkaz az functionapp config appsettings set :

    az functionapp config appsettings set -g <groupName> -n <appName> --settings 'WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED=1'

    V tomto příkladu nahraďte <groupName> názvem skupiny prostředků a nahraďte <appName> názvem vaší aplikace funkcí.

  3. Ujistěte se, že netFrameworkVersion vlastnost aplikace funkcí odpovídá cílové rozhraní vašeho projektu, což musí být .NET 6 nebo novější. Použijte tento příkaz az functionapp config set :

    az functionapp config set -g <groupName> -n <appName> --net-framework-version <framework>

    V tomto příkladu nahraďte <framework> také odpovídajícím řetězcem verze, například v8.0podle vaší cílové verze .NET.

  4. Ujistěte se, že je vaše aplikace funkcí nakonfigurovaná tak, aby používala 64bitový proces. Použijte tento příkaz az functionapp config set :

    az functionapp config set -g <groupName> -n <appName> --use-32bit-worker-process false

Důležité

Při nastavování WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED na 1 hodnotu musíte správně nastavit všechny ostatní konfigurace funkční aplikace. Jinak se aplikace funkcí nemusí spustit.

Optimalizovaný exekutor

Vykonavatel funkcí je komponenta platformy, která spouští vyvolání. Optimalizovaná verze této komponenty je ve výchozím nastavení povolená od verze 1.16.2 sady SDK. Nevyžaduje se žádná jiná konfigurace.

ReadyToRun

Aplikaci funkcí můžete zkompilovat jako binární soubory ReadyToRun. ReadyToRun je forma předběžné kompilace, která může zlepšit výkon při spouštění, čímž se pomáhá snížit účinek studených startů při běhu v plánu Consumption. ReadyToRun je k dispozici v .NET 6 a novějších verzích a vyžaduje verzi 4.0 nebo novější modulu runtime Azure Functions.

ReadyToRun vyžaduje, abyste projekt sestavili v architektuře modulu runtime hostitelské aplikace. Pokud tyto architektury nejsou zarovnané, aplikace při spuštění narazí na chybu. Vyberte z této tabulky identifikátor runtime.

Operační systém Aplikace je 32bitová 1. Identifikátor modulu runtime
Windows Pravda win-x86
Windows Nepravda win-x64
Operační systém Linux Pravda Není k dispozici (nepodporuje se)
Operační systém Linux Nepravda linux-x64

1 Pouze 64bitové aplikace mají nárok na některé další optimalizace výkonu.

Pokud chcete zkontrolovat, jestli je vaše aplikace pro Windows 32bitová nebo 64bitová, spusťte následující příkaz rozhraní příkazového řádku a nahraďte <group_name> názvem vaší skupiny prostředků a <app_name> názvem vaší aplikace. Výstup "true" označuje, že aplikace je 32bitová a "false" označuje 64bitovou verzi.

 az functionapp config show -g <group_name> -n <app_name> --query "use32BitWorkerProcess"

Aplikaci můžete změnit na 64bitovou verzi pomocí následujícího příkazu, a to pomocí stejných nahrazení:

az functionapp config set -g <group_name> -n <app_name> --use-32bit-worker-process false`

Pokud chcete projekt zkompilovat jako ReadyToRun, aktualizujte soubor projektu přidáním <PublishReadyToRun> prvků a <RuntimeIdentifier> prvků. Následující příklad ukazuje konfiguraci pro publikování do 64bitové aplikace funkcí pro Windows.

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  <PublishReadyToRun>true</PublishReadyToRun>
</PropertyGroup>

Pokud nechcete nastavit <RuntimeIdentifier> jako součást souboru projektu, můžete toto nastavení nakonfigurovat také jako součást samotného gesta publikování. Například pro 64bitovou funkční aplikaci ve Windows je příkaz .NET CLI:

dotnet publish --runtime win-x64

V sadě Visual Studio nastavte v profilu publikování možnost Cílový modul runtime na správný identifikátor modulu runtime. Pokud je nastavena výchozí hodnota Portable, ReadyToRun se nepoužívá.

Nasazení do Azure Functions

Když nasadíte projekt kódu funkce do Azure, musí se spustit buď v aplikaci funkcí, nebo v kontejneru Linuxu. Před nasazením kódu musíte vytvořit aplikaci funkcí a další požadované prostředky Azure.

Aplikaci funkcí můžete také nasadit v kontejneru Linuxu. Další informace najdete v tématu Práce s kontejnery a Azure Functions.

Vytvoření zdrojů Azure

Aplikaci funkcí a další požadované prostředky v Azure můžete vytvořit pomocí jedné z těchto metod:

Publikování aplikace

Po vytvoření aplikace funkcí a dalších požadovaných prostředků v Azure nasaďte projekt kódu do Azure pomocí jedné z těchto metod:

Další informace najdete v tématu Technologie nasazení ve službě Azure Functions.

Nasazovací balíček

Řada metod nasazení používá archiv zip. Pokud archiv zip vytvoříte sami, musí se řídit strukturou popsanou v této části. Pokud tomu tak není, může u vaší aplikace dojít k chybám při spuštění.

Datová část nasazení by se měla shodovat s výstupem dotnet publish příkazu, i když bez nadřazené složky. Archiv zip by měl být vytvořen z následujících souborů:

  • .azurefunctions/
  • extensions.json
  • functions.metadata
  • host.json
  • worker.config.json
  • Spustitelný soubor projektu (konzolová aplikace)
  • Další podpůrné soubory a adresáře jsou na stejné úrovni jako tento spustitelný soubor.

Proces sestavení tyto soubory vygeneruje a neměli byste je upravovat přímo.

Návod

Příkaz v func pack nástrojích Core Tools můžete použít k správnému vygenerování archivu zip pro nasazení. Podpora pro func pack je aktuálně ve verzi Preview.

Při přípravě archivu zip pro nasazení komprimujte pouze obsah výstupního adresáře, nikoli samotný nadřazený adresář. Když se archiv extrahuje do aktuálního pracovního adresáře, musí být soubory uvedené dříve okamžitě viditelné.

Požadavky na nasazení

Pokud chcete spouštět funkce .NET v izolovaném pracovním modelu v Azure, musíte splnit několik požadavků. Požadavky závisí na operačním systému:

Při vytváření aplikace funkcí v Azure pomocí metod v předchozí části se tato požadovaná nastavení přidají za vás. Při vytváření těchto prostředků pomocí šablon ARM nebo souborů Bicep pro automatizaci je nutné je nastavit v šabloně.

'Aspire'

Aspire je názorově zaměřený stack, který zjednodušuje vývoj distribuovaných aplikací v cloudu. Projekty izolovaného modelu pracovních procesů můžete zahrnout do orchestrací Aspire 13. Další informace najdete ve službě Azure Functions s Aspire .

Ladění

Při místním spuštění pomocí sady Visual Studio nebo Editoru Visual Studio Code můžete ladit projekt izolovaného pracovního procesu .NET jako obvykle. Existují však dva scénáře ladění, které nefungují podle očekávání.

Vzdálené ladění pomocí sady Visual Studio

Vzhledem k tomu, že aplikace izolovaného pracovního procesu běží vně prostředí Functions runtime, musíte vzdálený debugger připojit k samostatnému procesu. Další informace o ladění pomocí sady Visual Studio najdete v tématu Vzdálené ladění.

Ladění při cílení na rozhraní .NET Framework

Pokud váš izolovaný projekt cílí na .NET Framework 4.8, pro povolení ladění musíte udělat ruční kroky. Pokud používáte jinou cílovou architekturu, tyto kroky se nevyžadují.

Aplikace by měla začínat voláním FunctionsDebugger.Enable(); jako první operace. K tomu dochází v Main() metodě před inicializací HostBuilder. Soubor Program.cs by měl vypadat nějak takto:

using System;
using System.Diagnostics;
using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;
using NetFxWorker;

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

            var host = FunctionsApplication
                .CreateBuilder(args)
                .Build();

            host.Run();
        }
    }
}

Dále je třeba ručně připojit k procesu pomocí debuggeru rozhraní .NET Framework. Visual Studio to zatím neprovádí automaticky pro aplikace .NET Framework s izolovaným pracovním procesem a operaci "Spustit ladění" je třeba se vyhnout.

Ve složce projektu (nebo ve výstupní složce sestavení) spusťte příkaz:

func host start --dotnet-isolated-debug

Tím se spustí váš pracovní proces a proces se zastaví následující zprávou:

Azure Functions .NET Worker (PID: <process id>) initialized in debug mode. Waiting for debugger to attach...

Kde <process id> je ID pracovního procesu. K ručnímu připojení k procesu teď můžete použít Visual Studio. Pokyny k této operaci najdete v tématu Připojení ke spuštěném procesu.

Po připojení ladicího programu se provádění procesu obnoví a budete moct ladit.

Náhledy verzí .NET

Před obecně dostupnou verzí může být verze .NET vydána ve stavu Preview nebo Go Live . Podrobnosti o těchto státech najdete v oficiálních zásadách podpory .NET.

I když může být možné cílit na danou verzi z místního projektu Functions, aplikace funkcí hostované v Azure nemusí mít k dispozici danou verzi. Azure Functions se dají používat jenom s verzemi Preview nebo verzemi pro reálný provoz, které jsou zmíněné v této části.

Azure Functions v současné době nefunguje s žádnými verzemi .NET ve verzi Preview nebo Go-live. Seznam obecně dostupných verzí, které můžete použít, najdete v části Podporované verze .

Použití sady .NET SDK ve verzi Preview

Pokud chcete používat Azure Functions s verzí Preview .NET, musíte projekt aktualizovat pomocí těchto možností:

  1. Instalace příslušné verze sady .NET SDK ve vašem vývoji
  2. Změna nastavení TargetFramework ve .csproj souboru.

Když nasadíte do aplikace funkcí v Azure, musíte také zajistit, aby byla architektura dostupná pro danou aplikaci. Během období náhledu nemusí některé nástroje a prostředí nabízet novou verzi náhledu jako možnost. Pokud nevidíte verzi Preview, která je součástí webu Azure Portal, můžete k ruční konfiguraci verze použít rozhraní REST API, soubory Bicep nebo Azure CLI.

Pro aplikace hostované ve Windows použijte následující příkaz Azure CLI. Nahraďte <groupName> názvem skupiny prostředků a nahraďte <appName> názvem vaší aplikace funkcí. Nahraďte <framework> odpovídajícím řetězcem verze, například v8.0.

az functionapp config set -g <groupName> -n <appName> --net-framework-version <framework>

Důležité informace o používání verzí .NET Preview

Při používání funkcí s verzemi Preview .NET mějte na paměti tyto aspekty:

  • Při vytváření vašich funkcí v sadě Visual Studio musíte použít Visual Studio Insiders, které podporuje vytváření projektů Azure Functions pomocí SDKs .NET Preview.

  • Ujistěte se, že máte nejnovější nástroje a šablony Functions. Aktualizace nástrojů:

    1. Přejděte naMožnosti>, zvolte Azure Functionsv části Projekty a řešení>Další nastavení.
    2. Podle výzvy vyberte Vyhledat aktualizace a nainstalovat aktualizace.

  • Během období Preview může mít vaše vývojové prostředí novější verzi .NET Preview než hostovaná služba. To může způsobit selhání vaší funkční aplikace při nasazení do provozu. Chcete-li to vyřešit, můžete zadat verzi sady SDK, která se má použít v global.json.

    1. dotnet --list-sdks Spusťte příkaz a poznamenejte si verzi Preview, kterou aktuálně používáte při místním vývoji.
    2. dotnet new globaljson --sdk-version <SDK_VERSION> --force Spusťte příkaz, kde <SDK_VERSION> je verze, kterou používáte místně. Například způsobí, dotnet new globaljson --sdk-version dotnet-sdk-10.0.100-preview.5.25277.114 --force že systém při sestavování projektu použije sadu .NET 10 Preview 5 SDK.

Poznámka:

Vzhledem k načítání preview frameworků mohou funkční aplikace běžící ve Windows zaznamenat vyšší dobu nutnou k prvotnímu spuštění ve srovnání se staršími verzemi GA.

Další kroky

Další informace o osvědčených postupech pro Azure Functions

Migrace aplikací .NET do izolovaného pracovního modelu

Integrace s Aspire

  • Last updated on