Partager via

Migrer des applications .NET du modèle In-process vers le modèle de travail isolé

  • Article

Important

Le support prendra fin pour le modèle en cours le 10 novembre 2026.. Nous vous recommandons fortement de migrer vos applications vers le modèle de travailleur isolé en suivant les instructions de cet article.

Cet article vous guide tout au long du processus de migration sécurisée de votre application de fonction .NET du modèle In-process vers le modèle de travail isolé. Pour en savoir plus sur les différences de haut niveau entre ces modèles, consultez la comparaison des modes d’exécution.

Ce guide suppose que votre application s’exécute sur la version 4.x du runtime Functions. Si ce n’est pas le cas, suivez plutôt les guides pour mettre à niveau la version de votre hôte :

Ces guides de migration de la version de l’hôte vous aident également à migrer vers le modèle Worker isolé à mesure que vous les utilisez.

Identifier les applications de fonction à migrer

Utilisez le script Azure PowerShell suivant pour générer une liste d’applications de fonction dans votre abonnement qui utilisent actuellement le modèle In-process.

Le script utilise l’abonnement qu’Azure PowerShell est actuellement configuré pour utiliser. Vous pouvez modifier l’abonnement en exécutant Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' et en remplaçant <YOUR SUBSCRIPTION ID> par l’ID de l’abonnement que vous souhaitez évaluer.

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

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

$AppInfo

Choisissez votre version cible de .NET

Sur la version 4.x du runtime Functions, votre application de fonction .NET cible .NET 6 lors de l’utilisation du modèle In-process.

Lorsque vous migrez votre application de fonction, vous avez la possibilité de choisir la version cible de .NET. Vous pouvez mettre à jour votre projet C# vers l’une des versions suivantes de .NET, qui sont prises en charge par Functions version 4.x :

Version de .NET Type de version de la politique de prise en charge officielle .NET Modèle de processus Functions1,2
.NET 9 Préversion3 Modèle de worker isolé
.NET 8 LTS (fin du support le 10 novembre 2026) Modèle de worker isolé,
Modèle In-process2
.NET 6 LTS (fin de la prise en charge le 12 novembre 2024) Modèle de worker isolé,
Modèle In-process2
.NET Framework 4.8 Consulter la stratégie Modèle de worker isolé

1 Le modèle de worker isolé prend en charge les versions LTS (Long Term Support) et STS (Standard Term Support) de .NET, ainsi que .NET Framework. Le modèle In-process ne prend en charge que les versions LTS de .NET, jusqu’à .NET 8. Pour une comparaison complète des caractéristiques et des fonctionnalités entre les deux modèles, consultez Différences entre les processus .NET in-process et les processus de travail isolés Azure Functions.

2 Le support du modèle In-process prendra fin le 10 novembre 2026. Pour plus d’informations, lisez cette annonce relative à la prise en charge. Pour continuer à bénéficier d’une prise en charge complète, vous devez migrer vos applications vers le modèle Worker isolé.

3 Pour plus d’informations sur le support, les restrictions actuelles et les instructions d’utilisation de la préversion, consultez les Préversions de .NET dans le modèle de Worker isolé.

Conseil

Nous vous recommandons de mettre à niveau vers .NET 8 sur le modèle Worker isolé. Cela fournit un chemin de migration rapide à la version entièrement publiée avec la fenêtre de support la plus longue de .NET.

Ce guide ne présente pas d’exemples spécifiques pour .NET 9 (préversion) ou .NET 6. Si vous devez cibler ces versions, vous pouvez adapter les exemples de .NET 8.

Préparation de la migration

Si ce n’est pas déjà fait, identifiez la liste des applications qui doivent être migrées dans votre abonnement Azure actuel à l’aide d’Azure PowerShell.

Avant de migrer une application vers le modèle Worker isolé, vous devez examiner attentivement le contenu de ce guide. Vous devez également vous familiariser avec les fonctionnalités du modèle Worker isolé et avec les différences entre les deux modèles.

Pour migrer l’application, vous allez :

  1. Migrez votre projet local vers le modèle Worker isolé en suivant les étapes décrites dans Migrer votre projet local.
  2. Après avoir migré votre projet, testez entièrement l’application localement à l’aide de la version 4.x d’Azure Functions Core Tools.
  3. Mettre à jour votre application de fonction dans Azure vers le modèle isolé.

Migrer votre projet local

La section décrit les différentes modifications que vous devez apporter à votre projet local pour le déplacer vers le modèle de travail isolé. Certaines des étapes changent en fonction de votre version cible de .NET. Utilisez les onglets pour sélectionner les instructions qui correspondent à la version souhaitée. Ces étapes supposent un projet C# local, et si votre application utilise plutôt un script C# (fichiers .csx), vous devez convertir en modèle de projet avant de continuer.

Conseil

Si vous passez à une version LTS ou STS de .NET, vous pouvez utiliser l’Assistant Mise à niveau .NET utilisé pour apporter automatiquement bon nombre des modifications mentionnées dans les sections suivantes.

Tout d’abord, convertissez le fichier projet et mettez à jour vos dépendances. Ainsi, vous verrez des erreurs de génération pour le projet. Dans les étapes suivantes, vous allez apporter les modifications correspondantes pour supprimer ces erreurs.

Fichier projet

L’exemple qui suit est un fichier projet .csproj qui utilise .NET 6 sur la version 4.x :

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.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>

Appliquez l’une des procédures suivantes pour mettre à jour ce fichier XML afin qu’il s’exécute dans le modèle de travail isolé :

Ces étapes supposent un projet C# local, et si votre application utilise plutôt un script C# (fichiers .csx), vous devez convertir en modèle de projet avant de continuer.

Les modifications suivantes sont requises dans le fichier projet XML .csproj :

  1. Définissez la valeur de PropertyGroup.TargetFramework en net8.0.

  2. Définissez la valeur de PropertyGroup.AzureFunctionsVersion en v4.

  3. Ajoutez l’élément OutputType suivant au PropertyGroup :

    <OutputType>Exe</OutputType>

  4. Dans la liste ItemGroup.PackageReference, remplacez la référence de package par Microsoft.NET.Sdk.Functions avec les références suivantes :

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

    Notez toute référence à d’autres packages dans les espaces de noms Microsoft.Azure.WebJobs.*. Vous remplacerez ces packages dans une étape ultérieure.

  5. Ajoutez le nouveau ItemGroup suivant :

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

Une fois ces modifications effectuées, votre projet mis à jour doit ressembler à l’exemple suivant :

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

La modification de l’infrastructure cible de votre projet peut également nécessiter la modification de certaines parties de votre chaîne d’outils, en dehors du code du projet. Par exemple, dans VS Code, vous devrez peut-être mettre à jour le paramètre d’extension azureFunctions.deploySubpath par le biais des paramètres utilisateur ou le fichier .vscode/settings.json de votre projet. Recherchez les dépendances sur la version de l’infrastructure qui peuvent exister en dehors du code de votre projet, dans le cadre des étapes de génération ou d’un pipeline CI/CD.

Références de package

Lors de la migration vers le modèle de travail isolé, vous devez modifier les packages référencés par votre application.

Si ce n’est déjà fait, mettez à jour votre projet pour référencer les dernières versions stables de :

En fonction des déclencheurs et des liaisons que votre application utilise, elle pourrait avoir besoin de référencer un ensemble de packages différent. Le tableau suivant présente des remplacements à certaines des extensions les plus couramment utilisées :

Scénario Modifications apportées aux références de package
Déclencheur de minuteur Ajouter
Microsoft.Azure.Functions.Worker.Extensions.Timer
Liaisons de stockage Replace
Microsoft.Azure.WebJobs.Extensions.Storage
par
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs,
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues et
Microsoft.Azure.Functions.Worker.Extensions.Tables
liaisons SSL Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Liaisons de la file d’attente Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Liaisons de tableau Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.Tables
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.Tables
Liaisons Cosmos DB Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.CosmosDB
et/ou
Microsoft.Azure.WebJobs.Extensions.DocumentDB
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.CosmosDB
Liaisons Service Bus Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.ServiceBus
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.ServiceBus
Liaisons Event Hubs Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.EventHubs
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.EventHubs
Liaisons Event Grid Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.EventGrid
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.EventGrid
Liaisons SignalR Service Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.SignalRService
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.SignalRService
Fonctions durables Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.DurableTask
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask
Fonctions durables
(Fournisseur de stockage SQL)		 Remplacez les références à
Microsoft.DurableTask.SqlServer.AzureFunctions
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer
Fonctions durables
(Fournisseur de stockage Netherite)		 Remplacez les références à
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite
Liaisons SendGrid Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.SendGrid
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.SendGrid
Liaisons Kafka Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.Kafka
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.Kafka
Liaisons RabbitMQ Remplacez les références à
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
par la version la plus récente de
Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ
Injection de dépendances
et la configuration de démarrage		 Supprimez les références à
Microsoft.Azure.Functions.Extensions
(Le modèle Worker isolé fournit cette fonctionnalité par défaut.)

Consultez les Liaisons prises en charge pour la liste complète des extensions à prendre en compte, et référez-vous à la documentation de chaque extension pour obtenir des instructions d’installation complètes du modèle de processus isolé. Veillez à installer la dernière version stable de tous les packages que vous ciblez.

Conseil

Toutes les modifications apportées aux versions d’extension pendant ce processus peuvent aussi vous obliger à mettre à jour votre fichier host.json. Veillez à lire la documentation de chaque extension que vous utilisez. Par exemple, l’extension Service Bus a des changements cassants dans la structure entre les versions 4.x et 5.x. Pour plus d’informations, consultez la section Liaisons Azure Service Bus pour Azure Functions.

Votre application de modèle Worker isolé ne doit pas référencer de packages dans l’espace de noms Microsoft.Azure.WebJobs.* ni Microsoft.Azure.Functions.Extensions. S’il reste des références à ces derniers, elles doivent être supprimées.

Conseil

Votre application peut également dépendre des types de kits de développement logiciel (SDK) Azure, soit dans le cadre de vos déclencheurs et liaisons, soit en tant que dépendance autonome. Vous devez également en profiter pour les mettre à jour. Les dernières versions des extensions Functions fonctionnent avec les dernières versions du kit de développement logiciel (SDK) Azure pour .NET, presque tous les packages dont la forme est Azure.*.

Fichier Program.cs

Lors de la migration pour une exécution dans un processus Worker isolé, vous devez ajouter un fichier Program.cs à votre projet avec le contenu suivant :

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

Cet exemple inclut l'intégration d'ASP.NET Core pour améliorer les performances et fournir un modèle de programmation familier lorsque votre application utilise des déclencheurs HTTP. Si vous n’avez pas l’intention d’utiliser des déclencheurs HTTP, vous pouvez remplacer l’appel à ConfigureFunctionsWebApplication par un appel à ConfigureFunctionsWorkerDefaults. Dans ce cas, vous pouvez supprimer la référence à Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore de votre fichier projet. Toutefois, pour des performances optimales, même pour les fonctions avec d’autres types de déclencheurs, vous devez conserver ASP.NET Core comme FrameworkReference.

Le fichier Program.cs remplace n’importe quel fichier qui a l’attribut FunctionsStartup, qui est généralement un fichier Startup.cs. Dans les endroits où votre code FunctionsStartup référence IFunctionsHostBuilder.Services, vous pouvez à la place ajouter des instructions dans la méthode .ConfigureServices() de HostBuilder dans votre Program.cs. Pour en savoir plus sur l’utilisation de Program.cs, consultez Démarrage et configuration dans le guide de modèle Worker isolé.

Les exemples Program.cs par défaut ci-dessus incluent la configuration de l’intégration d’Application Insights pour le modèle Worker isolé. Dans votre Program.cs, vous devez également configurer tout filtrage des journaux qui doit s’appliquer aux journaux provenant du code dans votre projet. Dans le modèle Worker isolé, le fichier host.json contrôle uniquement les événements émis par le runtime hôte Functions. Si vous ne configurez pas de règles de filtrage dans Program.cs, vous constaterez peut-être des différences dans les niveaux de journalisation présents pour les différentes catégories de votre télémétrie.

Bien que vous puissiez enregistrer des sources de configuration personnalisées dans le cadre du HostBuilder, notez que celles-ci s’appliquent également uniquement au code de votre projet. La configuration des déclencheurs et des liaisons est également requise par la plateforme, et elle doit être fournie via les paramètres d’application, les références Key Vault ou les fonctionnalités de références App Configuration.

Une fois que vous avez déplacé tous les éléments FunctionsStartup existants vers le fichier Program.cs, vous pouvez supprimer l’attribut FunctionsStartup et la classe à laquelle elle a été appliquée.

Modifications de signature de fonction

Certains types clés changent entre le modèle In-process et le modèle Worker isolé. La plupart d’entre eux concernent les attributs, les paramètres et les types de retour qui composent la signature de fonction. Pour chacune de vos fonctions, vous devez apporter des modifications à :

  • Attribut de fonction (qui définit également le nom de la fonction)
  • Comment la fonction obtient un ILogger/ILogger<T>
  • Attributs et paramètres de déclencheur et de liaison

Le reste de cette section vous guide dans chacune de ces étapes.

Attributs de fonction

L’attribut Function du modèle Worker isolé remplace l’attribut FunctionName. Le nouvel attribut a la même signature et la seule différence est dans le nom. Vous pouvez donc simplement effectuer un remplacement de chaîne dans votre projet.

Logging

Dans le modèle in-process, vous pouvez inclure un paramètre ILogger facultatif à votre fonction, ou vous pouvez utiliser l’injection de dépendances pour obtenir un ILogger<T>. Si votre application utilisait déjà l’injection de dépendances, les mêmes mécanismes fonctionnent dans le modèle Worker isolé.

Cependant, pour les fonctions qui s’appuyaient sur le paramètre de méthode ILogger, vous devez apporter une modification. Il est recommandé d’utiliser l’injection de dépendances pour obtenir un ILogger<T>. Procédez comme suit pour migrer le mécanisme de journalisation de la fonction :

  1. Dans votre classe de fonction, ajoutez une propriété private readonly ILogger<MyFunction> _logger;, en remplaçant MyFunction par le nom de votre classe de fonction.

  2. Créez un constructeur pour votre classe de fonction qui prend ILogger<T> en tant que paramètre :

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

    Remplacez les deux instances de MyFunction dans l’extrait de code précédent par le nom de votre classe de fonction.

  3. Pour les opérations de journalisation dans votre code de fonction, remplacez les références au paramètre ILogger par _logger.

  4. Supprimez le paramètre ILogger de la signature de votre fonction.

Pour plus d’informations, consultez Journalisation dans le modèle Worker isolé.

Changements de déclencheur et de liaison

Lorsque vous avez modifié vos références de package à l’étape précédente, vous avez introduit des erreurs pour vos déclencheurs et liaisons que vous allez maintenant corriger :

  1. Supprimez les instructions using Microsoft.Azure.WebJobs;.

  2. Ajoutez une instruction using Microsoft.Azure.Functions.Worker;.

  3. Pour chaque attribut de liaison, modifiez le nom de l’attribut tel que spécifié dans sa documentation de référence, que vous trouverez dans l’index des Liaison prises en charge. En général, les noms d’attributs changent comme suit :

    • Les déclencheurs restent généralement nommés de la même façon. Par exemple, QueueTrigger est le nom de l’attribut pour les deux modèles.
    • Il est généralement nécessaire que « Input » soit ajouté au nom des liaisons d’entrée. Par exemple, si vous utilisiez l’attribut de liaison d’entrée CosmosDB dans le modèle in-process, cet attribut serait maintenant CosmosDBInput.
    • Il est généralement nécessaire que « Output » soit ajouté au nom des liaisons de sortie. Par exemple, si vous utilisiez l’attribut de liaison de sortie Queue dans le modèle in-process, cet attribut serait maintenant QueueOutput.

  4. Mettez à jour les paramètres d’attribut pour refléter la version du modèle Worker isolé, comme spécifié dans la documentation de référence de la liaison.

    Par exemple, dans le modèle in-process, une liaison de sortie d’objet blob est représentée par un attribut [Blob(...)] qui inclut une propriété Access. Dans le modèle Worker isolé, l’attribut de sortie d’objet blob serait [BlobOutput(...)]. La liaison n’exige plus la propriété Access, de sorte qu’il peut être supprimé. Donc [Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")] deviendrait [BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].

  5. Déplacez les liaisons de sortie hors de la liste des paramètres de fonction. Si vous n’avez qu’une seule liaison de sortie, vous pouvez l’appliquer au type de retour de la fonction. Si vous avez plusieurs sorties, créez une classe avec des propriétés pour chaque sortie et appliquez les attributs à ces propriétés. Pour plus d’informations, consultez Plusieurs liaisons de sortie.

  6. Consultez la documentation de référence de chaque liaison pour connaître les types auquel elle peut se lier. Dans certains cas, vous devrez peut-être modifier le type. Pour les liaisons de sortie, si la version du modèle in-process a utilisé un IAsyncCollector<T>, vous pouvez la remplacer par la liaison à un tableau du type de cible : T[]. Vous pouvez également envisager de remplacer la liaison de sortie par un objet client pour le service qu’il représente, soit comme type de liaison pour une liaison d’entrée si disponible, soit en injectant un client vous-même.

  7. Si votre fonction inclut un paramètre IBinder, supprimez-le. Remplacez la fonctionnalité par un objet client pour le service qu’elle représente, soit comme type de liaison pour une liaison d’entrée si disponible, soit en injectant un client vous-même.

  8. Mettez à jour le code de fonction pour qu’il fonctionne avec les nouveaux types.

Fichier local.settings.json

Le fichier local.settings.json est uniquement utilisé lors de l’exécution locale. Pour en savoir plus, consultez Fichier de paramètres locaux.

Lors de la migration d’un processus d’exécution In-process vers un processus d’exécution Worker isolé, vous devez passer la valeur FUNCTIONS_WORKER_RUNTIME à « dotnet-isolated ». Assurez-vous que votre fichier local.settings.json comporte au moins les éléments suivants :

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

La valeur que vous avez pour « AzureWebJobsStorage » peut être différente. Vous n’avez pas besoin de modifier sa valeur dans le cadre de la migration.

Fichier host.json

Aucune modification n'est requise à votre dossier host.json. Toutefois, si votre configuration Application Insights dans ce fichier provient de votre projet de modèle in-process, vous souhaiterez peut-être apporter des modifications supplémentaires à votre fichier Program.cs. Le fichier host.json contrôle uniquement la journalisation à partir du runtime de l’hôte Functions, et dans le modèle Worker isolé, certains de ces journaux proviennent directement de votre application, vous donnant plus de contrôle. Voir Gestion des niveaux de journaux dans le modèle de travailleur isolé pour plus de détails sur la façon de filtrer ces journaux.

Autres changements de code

Cette section met en évidence d’autres modifications de code à prendre en compte lors de la migration. Ces modifications ne sont pas nécessaires à toutes les applications, mais vous devez évaluer si certaines sont pertinentes pour vos scénarios.

Sérialisation JSON

Par défaut, le modèle Worker isolé utilise System.Text.Json pour la sérialisation JSON. Pour personnaliser les options de sérialiseur ou passer à JSON.NET (Newtonsoft.Json), consultez ces instructions.

Niveaux de journalisation et filtrage Application Insights

Les journaux peuvent être envoyés à Application Insights à partir du runtime de l’hôte Functions et du code de votre projet. Le host.json vous permet de configurer des règles pour la journalisation de l’hôte, mais pour contrôler les journaux provenant de votre code, vous devrez configurer des règles de filtrage dans le cadre de votre Program.cs. Voir Gestion des niveaux de journaux dans le modèle de travailleur isolé pour plus de détails sur la façon de filtrer ces journaux.

Exemples de migrations de fonction

Exemple de déclencheur HTTP

Un déclencheur HTTP pour le modèle in-process peut ressembler à l’exemple suivant :

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

Voici un exemple de déclencheur HTTP pour la version migrée :

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

Mettre à jour votre application de fonction dans Azure

La mise à jour de votre application de fonction vers le modèle isolé implique deux modifications qui doivent être effectuées ensemble, car si vous n’en faites qu’une seule, l’application est dans un état d’erreur. Ces deux modifications entraînent également le redémarrage du processus de l’application. Pour ces raisons, vous devez effectuer la mise à jour en utilisant un emplacement de préproduction. Les emplacements de préproduction permettent de réduire le temps d’arrêt de votre application, et de tester et vérifier votre code migré avec votre configuration mise à jour dans Azure. Vous pouvez ensuite déployer votre application migrée sur l’emplacement de production au moyen d’une opération d’échange.

Important

Quand la charge utile déployée d’une application ne correspond pas au runtime configuré, elle est dans un état d’erreur. Pendant le processus de migration, vous allez placer l’application dans cet état, idéalement seulement de façon temporaire. Les emplacements de déploiement permettent d’atténuer l’impact de cet état, car l’état d’erreur sera résolu dans votre environnement intermédiaire (non-production) avant que les modifications ne soient appliquées sous la forme d’une seule mise à jour de votre environnement de production. Les slots permettent également de se prémunir contre les erreurs et de détecter d’autres problèmes avant la mise en production.

Pendant le processus, vous pouvez encore voir des erreurs dans les journaux provenant de votre emplacement intermédiaire (non-production). C’est normal, même si ces erreurs doivent disparaître à mesure que vous avancez dans les étapes. Avant d’effectuer l’opération de permutation des emplacements, vous devez vérifier que ces erreurs cessent de se produire et que votre application fonctionne comme prévu.

Procédez comme suit pour utiliser des emplacements de déploiement afin de mettre à jour votre application de fonction vers le modèle Worker isolé :

  1. Si vous ne l’avez pas déjà fait, créez un emplacement de déploiement. Vous pouvez également vous familiariser avec le processus de permutation des emplacements et vérifier que vous pouvez effectuer des mises à jour de l’application existante avec une interruption minimale.

  2. Changez la configuration de l’emplacement intermédiaire (non-production) pour utiliser le modèle Worker isolé en définissant le paramètre d’application FUNCTIONS_WORKER_RUNTIME sur dotnet-isolated. FUNCTIONS_WORKER_RUNTIME ne doit pas être marqué comme « paramètre d’emplacement ».

    Si vous ciblez également une autre version de .NET dans le cadre de votre mise à jour, vous devez également modifier la configuration de la pile. Pour cela, consultez les instructions pour mettre à jour la configuration de la pile pour le modèle Worker isolé. Vous utiliserez les mêmes instructions pour toutes les futures mises à jour que vous ferez de la version de .NET.

    Si vous disposez d’un approvisionnement d’infrastructure automatisé, comme un pipeline CI/CD, vérifiez que les automatisations sont également mises à jour pour conserver FUNCTIONS_WORKER_RUNTIME défini sur dotnet-isolated et pour cibler la version correcte de .NET.

  3. Publiez votre projet migré sur l’emplacement intermédiaire (non-production) de votre application de fonction.

    Si vous utilisez Visual Studio pour publier un projet de modèle Worker isolé sur une application ou un emplacement existant qui utilise le modèle in-process, il peut également effectuer l’étape précédente pour vous en même temps. Si vous n’avez pas effectué l’étape précédente, Visual Studio vous invite à mettre à jour l’application de fonction lors du déploiement. Visual Studio présente cela sous la forme d’une seule opération, mais il s’agit néanmoins toujours de deux opérations distinctes. Vous pouvez toujours voir des erreurs dans vos journaux qui proviennent de l’emplacement intermédiaire (non-production) pendant l’état intermédiaire.

  4. Vérifiez que votre application fonctionne comme attendu dans l’emplacement intermédiaire (non-production).

  5. Effectuez une opération de permutation d’emplacement. Ceci applique les modifications que vous avez apportées dans votre emplacement intermédiaire (non-production) à l’emplacement de production. Une permutation d’emplacement se produit sous la forme d’une seule mise à jour, ce qui évite d’introduire l’état d’erreur intermédiaire dans votre environnement de production.

  6. Vérifiez que votre application fonctionne comme attendu dans l’emplacement de production.

Une fois ces étapes effectuées, la migration est terminée et votre application s’exécute sur le modèle isolé. Félicitations ! Répétez les étapes de ce guide si nécessaire pour toute autre application nécessitant une migration.

Étapes suivantes

En savoir plus sur le modèle de travail isolé