Бөлісу құралы:

Перенос приложений из Функции Azure версии 3.x на версию 4.x

Внимание

По состоянию на 13 декабря 2022 г. приложения-функции, работающие в версиях 2.x и 3.x среды выполнения Функции Azure, достигли конца расширенной поддержки. Дополнительные сведения см. в разделе "Устаревшие версии".

Функции Azure версии 4.x имеет высокую обратную совместимость с версией 3.x. Большинство приложений должны безопасно перенестися на 4.x, не требуя значительных изменений кода. Дополнительные сведения о версиях среды выполнения функций см. в разделе обзор версий среды выполнения Функции Azure.

Внимание

Приложения-функции, которые по-прежнему работают под управлением среды выполнения версии 3 в Linux на плане потребления, перестанут работать после 30 сентября 2026 г. Чтобы избежать нарушения работы службы, перенесите приложение в среду выполнения версии 4.

Возможность размещения приложений-функций на Linux в плане с оплатой за потребление прекращается 30 сентября 2028 года. План потребления Linux не получает новых функций или языковых версий. Приложения, работающие на Windows в плане потребления, в настоящее время не затрагиваются. Перенесите ваши приложения на план потребления Flex до даты прекращения поддержки.

В этой статье описывается процесс безопасной миграции функционального приложения для работы на версии 4.x среды выполнения Functions. Так как инструкции по миграции проекта зависят от языка, обязательно выберите язык разработки из селектора в верхней части статьи.

Определение функциональных приложений для миграции

Используйте следующий сценарий PowerShell для создания списка приложений-функций в подписке, предназначенных для версий 2.x или 3.x:

$Subscription = '<YOUR SUBSCRIPTION ID>' 
 
Set-AzContext -Subscription $Subscription | Out-Null

$FunctionApps = Get-AzFunctionApp

$AppInfo = @{}

foreach ($App in $FunctionApps)
{
     if ($App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"] -like '*3*')
     {
          $AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
     }
}

$AppInfo

Выбор целевой версии .NET

В среде выполнения Функций версии 3.x ваше функциональное приложение на C# нацелено на .NET Core 3.1, используя встраиваемую модель или на .NET 5, используя модель изолированного рабочего процесса.

При переносе приложения-функции у вас есть возможность выбрать целевую версию .NET. Проект C# можно обновить до одной из следующих версий .NET, поддерживаемых функциями версии 4.x:

версия .NET .NET официальная политика поддержки - тип выпуска Модельпроцесса функций 1,2
.NET 10 LTS (окончание поддержки 14 ноября 2028 г.) Изолированная рабочая модель
.NET 9 STS (окончание поддержки 10 ноября 2026 г.)3 Изолированная рабочая модель
.NET 8 LTS (окончание поддержки 10 ноября 2026 г.) Изолированная рабочая модель,
Модель в процессе2
.NET Framework 4.8 См. политику Изолированная рабочая модель

1 Модель изолированного рабочего поддерживает версии с долгосрочной поддержкой (LTS) и стандартной поддержкой (STS) .NET, а также .NET Framework. Модель in-process поддерживает только выпуски LTS .NET, заканчивающиеся .NET 8. Для полного сравнения возможностей и функциональности двух моделей см. раздел Различия между функциями, работающими в процессе, и изолированными рабочими процессами .NET Функции Azure.

2 Поддержка заканчивается для текущей модели 10 ноября 2026 года. Для получения дополнительной информации см. это объявление о поддержке. Для непрерывной поддержки следует перенести приложения в изолированную рабочую модель.

3 Ранее ожидаемая дата окончания поддержки .NET 9 имелась 12 мая 2026 года. В течение периода службы .NET 9 команда .NET расширила поддержку версий STS до 24 месяцев, начиная с .NET 9. Дополнительные сведения см. в записи блога.

Совет

Рекомендуется обновить до .NET 8 в изолированной рабочей модели. .NET 8 — это полностью выпущенная версия с самым длинным окном поддержки из .NET.

Хотя вместо этого можно использовать модель в процессе, мы не рекомендуем использовать этот подход, если его можно избежать. Поддержка будет завершена для модели в процессе 10 ноября 2026 года, поэтому перед этим вам потребуется перейти к изолированной рабочей модели. При этом, миграция на версию 4.x уменьшит общие затраты усилий, а модель изолированного рабочего процесса предоставит вашему приложению дополнительные преимущества, включая возможность более легко использовать будущие версии .NET. При переходе к модели изолированного рабочего процесса .NET Upgrade Assistant также может обрабатывать многие необходимые изменения в коде.

В этом руководстве нет конкретных примеров для .NET 10 (предварительная версия) или .NET 9. Если вам нужно ориентироваться на одну из этих версий, следует адаптировать примеры .NET 8.

Подготовка к переносу

Если вы еще не сделали этого, определите список приложений, которые необходимо перенести в текущей подписке Azure с помощью Azure PowerShell.

Прежде чем перенести приложение в среду выполнения функций версии 4.x, выполните следующие задачи:

  1. Просмотрите список критических изменений между версиями 3.x и 4.x.
  2. Выполните действия, описанные в разделе "Миграция локального проекта", чтобы перенести локальный проект в версию 4.x.
  3. После переноса проекта полностью протестируйте приложение локально с помощью версии 4.x Функции Azure Core Tools.
  4. Запустите валидатор предварительного обновления на приложении, размещенном в Azure, и устраните все выявленные проблемы.
  5. Обновите функциональное приложение в Azure до новой версии. Если необходимо свести к минимуму время простоя, рассмотрите возможность использования промежуточного слота для тестирования и проверки перенесенного приложения в Azure на новой версии среды выполнения. Затем можно развернуть приложение с обновленными параметрами версии в производственном слоте. Дополнительные сведения см. в разделе «Обновление с помощью слотов».
  6. Опубликуйте перенесенный проект в обновленном приложении-функции.

При использовании Visual Studio для публикации проекта версии 4.x в существующем приложении-функции в более низкой версии вам будет предложено разрешить Visual Studio обновить приложение-функцию до версии 4.x во время развертывания. Это обновление использует тот же процесс, определенный в Обновление без слотов.

Перенос локального проекта

Инструкции по обновлению зависят от языка. Если язык не отображается, выберите его из селектора в верхней части статьи.

Выберите вкладку, соответствующую целевой версии .NET, и нужную модель процесса (внутрипроцессный или изолированный рабочий процесс).

Совет

При переходе на версию LTS или STS .NET с помощью изолированной рабочей модели .NET помощник по обновлению можно использовать для автоматического внесения многих изменений, упомянутых в следующих разделах.

файл проекта

В следующем примере представлен файл проекта .csproj, использующий .NET Core 3.1 в версии 3.x:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.13" />
  </ItemGroup>
  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

Используйте одну из следующих процедур, чтобы обновить этот XML-файл для запуска в Функциях версии 4.x:

В этих шагах предполагается, что локальный проект C#; Если приложение вместо этого использует скрипт C# (CSX-файлы ), перед продолжением следует преобразовать в модель проекта .

В XML-файле проекта CSPROJ требуются следующие изменения:

  1. Задайте значение PropertyGroup. TargetFramework изменено на net8.0.

  2. Задайте значение PropertyGroup. AzureFunctionsVersion изменено на v4.

  3. Добавьте следующий OutputType элемент в :PropertyGroup

    <OutputType>Exe</OutputType>

  4. ItemGroup в .список PackageReference замените ссылку на пакет Майкрософт.NET.Sdk.Functions следующими ссылками:

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

    Обратите внимание на ссылки на другие пакеты в пространствах имен Майкрософт.Azure.WebJobs.*. Вы замените эти пакеты на следующем шаге.

  5. Добавьте следующее новое:ItemGroup

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

После внесения этих изменений обновленный проект должен выглядеть следующим образом:

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

Изменения в пакете и пространстве имен

На основе модели, в которую выполняется миграция, может потребоваться обновить или изменить пакеты, на которые ссылается приложение. При внедрении целевых пакетов необходимо обновить пространство имен инструкций using и некоторые типы, на которые вы ссылаетесь. Вы можете увидеть влияние этих изменений пространства имен на using директивы в примерах шаблона триггера HTTP в дальнейшем в этой статье.

Если вы еще не сделали этого, обновите проект, чтобы ссылаться на последние стабильные версии:

В зависимости от триггеров и привязок, которые использует приложение, может потребоваться ссылаться на другой набор пакетов. В следующей таблице показаны замены некоторых наиболее часто используемых расширений:

Сценарий Изменения ссылок на пакеты
Триггер по таймеру Добавить
Майкрософт.Azure. Functions.Worker.Extensions.Timer
Привязки хранилища Заменить
Microsoft.Azure.WebJobs.Extensions.Storage
на
Майкрософт.Azure. Functions.Worker.Extensions.Storage.Blobs
Майкрософт.Azure.Functions.Worker.Extensions.Storage.Queues и
Майкрософт.Azure.Functions.Worker.Extensions.Tables
Привязки больших двоичных объектов Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.Storage.Blobs
Привязки очередей Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
с последней версией
Майкрософт.Azure.Functions.Worker.Extensions.Storage.Queues
Привязки таблиц Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.Tables
с последней версией
Майкрософт.Azure.Functions.Worker.Extensions.Tables
Привязки Cosmos DB Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.CosmosDB
и (или)
Microsoft.Azure.WebJobs.Extensions.DocumentDB
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.CosmosDB
Привязки для служебная шина Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.ServiceBus
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.ServiceBus
Привязки Центров событий Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.EventHubs
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.EventHubs
Привязки сетки событий Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.EventGrid
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.EventGrid
привязки Служба SignalR Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.SignalRService
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.SignalRService
Устойчивые функции Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.DurableTask
с последней версией
Майкрософт.Azure.Functions.Worker.Extensions.DurableTask
Устойчивые функции
(поставщик хранилища SQL)		 Замена ссылок на
Microsoft.DurableTask.SqlServer.AzureFunctions
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.DurableTask.SqlServer
Устойчивые функции
(поставщик хранилища Netherite)		 Замена ссылок на
Microsoft.Azure.DurableTask.Netherite.AzureFunctions
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.DurableTask.Netherite
Привязки SendGrid Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.SendGrid
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.SendGrid
Привязки Kafka Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.Kafka
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.Kafka
Привязки RabbitMQ Замена ссылок на
Microsoft.Azure.WebJobs.Extensions.RabbitMQ
с последней версией
Майкрософт.Azure. Functions.Worker.Extensions.RabbitMQ
Внедрение зависимостей
и конфигурация запуска		 Удаление ссылок на
Microsoft.Azure.Functions.Extensions
(Изолированная рабочая модель предоставляет эту функцию по умолчанию.)

Ознакомьтесь с поддерживаемыми привязками для полного списка расширений, которые следует рассмотреть, и ознакомьтесь с документацией по каждому расширению, чтобы получить полные инструкции по установке для изолированной модели процесса. Не забудьте установить последнюю стабильную версию всех целевых пакетов.

Совет

Любые изменения версий расширений в ходе этого процесса могут потребовать, чтобы вы также обновили файл host.json. Обязательно ознакомьтесь с документацией по каждому используемому расширению. Например, расширение служебная шина имеет критические изменения в структуре между версиями 4.x и 5.x. Дополнительные сведения см. в разделе привязки Служебная шина Azure для Функции Azure.

Приложение изолированной рабочей модели не должно ссылаться на пакеты в пространствах имен Майкрософт.Azure.WebJobs.* или Майкрософт.Azure.Functions.Extensions. Если у вас есть оставшиеся ссылки на них, их следует удалить.

Совет

Ваше приложение также может зависеть от типов Azure SDK, в составе триггеров и привязок или как автономной зависимости. Следует воспользоваться этой возможностью, чтобы тоже обновить их. Последние версии расширений функций совместимы с самыми новыми версиями Azure SDK для .NET. Почти все пакеты, входящие в их состав, имеют форму Azure.*.

файл Program.cs

При миграции на выполнение в изолированном рабочем процессе необходимо добавить следующий файл program.cs в проект:

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

Этот пример включает интеграцию ASP.NET Core для повышения производительности и предоставления знакомой модели программирования при использовании триггеров HTTP в приложении. Если вы не планируете использовать триггеры HTTP, можно заменить вызов на вызов ConfigureFunctionsWebApplicationConfigureFunctionsWorkerDefaults. При этом можно удалить ссылку на Майкрософт.Azure.Functions.Worker.Extensions.Http.AspNetCore из файла проекта. Однако для оптимальной производительности даже для функций с другими типами триггеров следует сохранить FrameworkReference для ASP.NET Core.

Файл Program.cs заменяет любой файл с FunctionsStartup атрибутом, который обычно является файлом Startup.cs. В местах, где ваш код FunctionsStartup будет ссылаться на IFunctionsHostBuilder.Services, можно вместо этого добавить инструкции в метод .ConfigureServices() класса HostBuilder в вашем файле Program.cs. Дополнительные сведения о работе с Program.cs см. в руководстве по запуску и настройке в изолированной рабочей модели.

Примеры Program.cs по умолчанию включают настройку Application Insights. В Program.cs необходимо также настроить фильтрацию журналов, которая должна применяться к журналам, поступающим из кода в проекте. В изолированной рабочей модели файл host.json управляет событиями, создаваемыми средой выполнения узла функций. Если правила фильтрации не настроены в Program.cs, могут возникнуть различия в уровнях журнала, присутствующих для различных категорий телеметрии.

Хотя вы можете зарегистрировать пользовательские источники конфигурации в рамках HostBuilder, они аналогично применяются только к коду в вашем проекте. Платформа также нуждается в настройке триггеров и привязок, и это необходимо предоставить с помощью настроек приложения, ссылок на Key Vault или ссылок на App Configuration.

После того как вы переместите все из любых существующих FunctionsStartup в файл Program.cs, можно удалить атрибут FunctionsStartup и класс, к которому он был применён.

файл local.settings.json

Файл local.settings.json используется только при локальном запуске. Дополнительные сведения см. в файле локальных параметров.

При переходе на версию 4.x убедитесь, что файл local.settings.json содержит по крайней мере следующие элементы:

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

Примечание.

При переходе от работы в одном процессе к работе в изолированном рабочем процессе необходимо изменить значение параметра FUNCTIONS_WORKER_RUNTIME на "dotnet-isolated".

файл host.json

Вам не нужно вносить изменения в файл host.json. Однако, если конфигурация Application Insights в этом файле относится к вашей внутренней модели проекта, возможно, вам потребуется внести другие изменения в файл Program.cs. Файл host.json управляет ведением журнала только из среды выполнения узла Функций и в изолированной рабочей модели некоторые из этих журналов приходят непосредственно из приложения, что дает вам больше контроля. Дополнительные сведения об фильтрации этих журналов см. в статье "Управление уровнями журналов в изолированной рабочей модели ".

Изменения имени класса

Некоторые классы ключей изменили имена между версиями. Эти изменения являются результатом изменений в .NET API или различий между внутрипроцессным и изолированным рабочим процессами. В следующей таблице указывается ключ .NET классов, используемых функциями, которые могут измениться при миграции:

.NET Core 3.1 .NET 5 .NET 8
FunctionName (атрибут) Function (атрибут) Function (атрибут)
ILogger ILogger ILogger, ILogger<T>
HttpRequest HttpRequestData HttpRequestData, HttpRequest (с помощью интеграции ASP.NET Core)
IActionResult HttpResponseData , (с помощью интеграции ASP.NET Core)
FunctionsStartup (атрибут) Вместо этого используется Program.cs Вместо этого используется Program.cs

В привязках также могут быть различия имен классов. Дополнительные сведения см. в справочных статьях по конкретным привязкам.

Другие изменения кода

В этом разделе рассматриваются другие изменения кода, которые следует учитывать при работе с миграцией. Эти изменения не требуются для всех приложений, но следует оценить, имеют ли какие-либо значения для ваших сценариев. Не забудьте проверить критические изменения между 3.x и 4.x для других изменений, которые могут потребоваться внести в проект.

Сериализация JSON

По умолчанию изолированная рабочая модель использует System.Text.Json для сериализации JSON. Чтобы настроить параметры сериализатора или переключиться на JSON.NET (Newtonsoft.Json), см. статью Customization JSON serialization.

Уровни логов и фильтрация в Application Insights

Можно отправлять журналы в Application Insights как из среды выполнения хоста функций, так и из кода вашего проекта. host.json позволяет настраивать правила ведения журнала хоста, но для управления журналами, поступающими из вашего кода, необходимо настроить правила фильтрации в рамках Program.cs. Дополнительные сведения об фильтрации этих журналов см. в статье "Управление уровнями журналов в изолированной рабочей модели ".

Шаблон триггера HTTP

Различия между процессом и изолированным рабочим процессом можно увидеть в триггерных функциях HTTP. Шаблон триггера HTTP для версии 3.x (в процессе) выглядит следующим образом:

using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;

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

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            string responseMessage = string.IsNullOrEmpty(name)
                ? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
                : $"Hello, {name}. This HTTP triggered function executed successfully.";

            return new OkObjectResult(responseMessage);
        }
    }
}

Шаблон триггера HTTP для перенесенной версии выглядит следующим образом:

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

Чтобы обновить проект до Функции Azure 4.x:

  1. Обновите локальную установку Функции Azure Core Tools до версии 4.x.

  2. Обновите пакет расширений Функции Azure до версии 2.x или более поздней версии. Дополнительные сведения см. в разделе Критические изменения.

  1. При необходимости перейдите к одной из версий Java, поддерживаемых в версии 4.x.

  2. Обновите файл приложения POM.xml, чтобы изменить параметр FUNCTIONS_EXTENSION_VERSION на ~4, как показано в следующем примере:

    <configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~4</value>
        </property>
    </appSettings>
</configuration>
  1. При необходимости перейдите к одной из версий Node.js, поддерживаемых в версии 4.x.
  1. Воспользуйтесь этой возможностью для обновления до PowerShell 7.2, что рекомендуется. Дополнительные сведения см. в разделах версий PowerShell.
  1. Если вы используете Python 3.6, перейдите к одной из версий поддерживаемых версий.

Запуск средства проверки перед обновлением

Функции Azure предоставляет валидатор предварительного обновления, который помогает выявлять потенциальные проблемы при миграции функционального приложения на версию 4.x. Чтобы запустить средство проверки перед обновлением:

  1. На портале Azure перейдите к приложению-функции.

  2. Откройте страницу Диагностика и решение проблем

  3. В диагностике приложения-функции начните вводить Functions 4.x Pre-Upgrade Validator и выберите его из списка.

  4. После завершения проверки просмотрите рекомендации и устраните выявленные проблемы в приложении. Если вам нужно внести изменения в приложение, обязательно проверьте изменения в среде выполнения функций версии 4.x либо локально с помощью Функции Azure Core Tools версии 4, либо используя промежуточный слот.

Обновите функциональное приложение в Azure

Перед публикацией перенесенного проекта необходимо обновить среду выполнения узла приложения-функции в Azure до версии 4.x. Версия среды выполнения, используемая узлом функций, управляется FUNCTIONS_EXTENSION_VERSION параметром приложения, но в некоторых случаях другие параметры также должны быть обновлены. Изменения кода и изменения параметров приложения требуют перезапуска приложения-функции.

Самый простой способ — обновить без слотов , а затем повторно опубликовать проект приложения. Вы также можете свести к минимуму время простоя в вашем приложении и упростить откат, обновляя с использованием слотов.

Обновление без слотов

Самый простой способ обновить до версии 4.x — это установить значение параметра приложения FUNCTIONS_EXTENSION_VERSION на ~4 в приложении-функции Azure. На сайте со слотами необходимо выполнить другую процедуру.

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

Необходимо также задать другой параметр, который отличается от Windows и Linux.

При работе с Windows также необходимо включить .NET 8.0, которая требуется в среде выполнения версии 4.x.

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

.NET 6 требуется для приложений-функций на любом языке, работающем на Windows.

В этом примере замените <APP_NAME> именем приложения-функции и <RESOURCE_GROUP_NAME> именем группы ресурсов.

Теперь вы можете повторно опубликовать проект приложения, перенесенный для запуска в версии 4.x.

Обновление с помощью слотов

Использование слотов развертывания — это хороший способ обновить приложение-функцию до среды выполнения версии 4.x из предыдущей версии. С помощью промежуточного слота можно запустить приложение в новой версии среды выполнения в промежуточном слоте и перейти в рабочую среду после проверки. Слоты также позволяют свести к минимуму время простоя во время обновления. Если необходимо свести к минимуму время простоя, выполните действия, описанные в разделе "Минимальное время простоя".

После проверки приложения в обновленном слоте вы можете перевести приложение и новые параметры версии в рабочую среду. Для этого переключения требуется установить параметр WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 в рабочем слоте. Добавление этого параметра влияет на время простоя, необходимое для обновления.

Стандартное обновление

Если для приложения-функции с поддержкой слотов допустимо время простоя, необходимое для полного перезапуска, можно обновить параметр WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS непосредственно в рабочем слоте. Так как изменение этого параметра непосредственно в рабочем слоте приводит к перезапуску, влияющему на доступность, рекомендуется выполнять это изменение в период пониженного трафика. Затем можно заменить обновленную версию из промежуточного слота.

Командлет PowerShell Update-AzFunctionAppSetting на данный момент не поддерживает слоты. Необходимо использовать Azure CLI или портал Azure.

  1. Используйте следующую команду, чтобы задать WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 в рабочем слоте:

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

    В этом примере замените <APP_NAME> именем приложения-функции и <RESOURCE_GROUP_NAME> именем группы ресурсов. Эта команда приводит к перезапуску приложения, запущенного в рабочем слоте.

  2. Используйте следующую команду, чтобы также задать WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS в промежуточном слоте:

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

  3. Используйте следующую команду, чтобы изменить FUNCTIONS_EXTENSION_VERSION и обновить промежуточный слот до новой версии среды выполнения:

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

  4. Для среды выполнения функций версии 4.x требуется .NET 6 в Windows. В Linux приложения .NET также должны обновляться до .NET 6. Используйте следующую команду, чтобы среда выполнения была запущена в .NET 6:

    При работе с Windows также необходимо включить .NET 8.0, которая требуется в среде выполнения версии 4.x.

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

    .NET 6 требуется для приложений-функций на любом языке, работающем на Windows.

    В этом примере замените <APP_NAME> именем приложения-функции и <RESOURCE_GROUP_NAME> именем группы ресурсов.

  5. Если вашему проекту кода потребовались обновления, чтобы запускаться на версии 4.x, внедрите эти обновления на промежуточный слот.

  6. Убедитесь, что приложение-функция работает правильно в обновленной промежуточной среде перед переключением.

  7. Используйте следующую команду, чтобы переключить обновленный слот подготовки на продакшн.

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

Обновление для минимального простоя

Чтобы свести к минимуму время простоя в рабочем приложении, можно переключить параметр WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS из промежуточного слота в рабочую среду. После этого можно переключить обновленную версию из предварительно созданного промежуточного слота.

  1. Используйте следующую команду, чтобы задать WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 в промежуточном слоте:

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

  2. Используйте следующие команды, чтобы переключить слот с новым параметром в рабочую среду и одновременно восстановить параметр версии в промежуточном слоте.

    az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~3 -g <RESOURCE_GROUP_NAME>  -n <APP_NAME> --slot <SLOT_NAME>

    В период между переключением и восстановлением версии этапа выполнения в промежуточном слоте могут появляться ошибки. Эта ошибка может произойти, если WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 существует только в промежуточной среде во время переключения, что приводит к удалению параметра FUNCTIONS_EXTENSION_VERSION в этой среде. Без параметра версии слот находится в плохом состоянии. Обновление версии в промежуточном слоте сразу после переключения должно привести слот в исправное состояние. При необходимости можно откатить изменения. Однако любая отмена обмена также требует непосредственного удаления WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 из рабочего окружения до повторного обмена, чтобы предотвратить такие же ошибки в рабочей среде, как и в промежуточной. Это изменение в рабочем параметре приведет к перезапуску.

  3. Используйте следующую команду, чтобы вновь установить WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 в промежуточном слоте.

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

    На этом этапе в обоих слотах установлено WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0.

  4. Используйте следующую команду, чтобы изменить FUNCTIONS_EXTENSION_VERSION и обновить промежуточный слот до новой версии среды выполнения:

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

  5. Для среды выполнения функций версии 4.x требуется .NET 6 в Windows. В Linux приложения .NET также должны обновляться до .NET 6. Используйте следующую команду, чтобы среда выполнения была запущена в .NET 6:

    При работе с Windows также необходимо включить .NET 8.0, которая требуется в среде выполнения версии 4.x.

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

    .NET 6 требуется для приложений-функций на любом языке, работающем на Windows.

    В этом примере замените <APP_NAME> именем приложения-функции и <RESOURCE_GROUP_NAME> именем группы ресурсов.

  6. Если вашему проекту кода потребовались обновления, чтобы запускаться на версии 4.x, внедрите эти обновления на промежуточный слот.

  7. Убедитесь, что приложение-функция работает правильно в обновленной промежуточной среде перед переключением.

  8. Используйте следующую команду, чтобы заменить обновленный и предварительно подготовленный слот промежуточной среды на производственную среду.

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

Важные изменения между версиями 3.x и 4.x

Ниже приведены ключевые критические изменения, которые следует учесть перед обновлением приложения 3.x до версии 4.x, включая критические изменения, относящиеся к языку. Полный список см. на странице GitHub для Функции Azure с задачами, помеченными Breaking Change: Approved.

Если вы не видите свой язык программирования, выберите его в списке в верхней части страницы.

Время выполнения

  • Функции Azure Proxies — это функция в версиях 1.x через 3.x среды выполнения Функции Azure. Эта функция не поддерживается в версии 4.x. Дополнительные сведения см. в статье Serverless REST API с помощью Функции Azure.

  • Ведение журнала в служба хранилища Azure с помощью AzureWebJobsDashboard больше не поддерживается в версии 4.x. Вместо этого следует использовать Application Insights. (#1923)

  • Функции Azure версии 4.x теперь предъявляет минимальные требования к версии расширений. Обновите до последней версии затронутых расширений. Для языков, не относящихся к .NET, обновите пакет расширений до версии 2.x или более поздней. (#1987)

  • Таймауты по умолчанию и максимальные таймауты теперь применяются в версии 4.x для приложений-функций, работающих на Linux в плане потребления. (#1915)

  • Функции Azure 4.x использует Azure.Identity и Azure.Security.KeyVault.Secrets для поставщика Key Vault и не рекомендует использовать Майкрософт.Azure. KeyVault. Дополнительные сведения о настройке параметров функционального приложения см. в разделе Key Vault в Управление хранилищем ключей. (#2048)

  • Функциональные приложения, которые совместно используют учетные записи хранения, теперь не запускаются, если их идентификаторы хостов совпадают. Дополнительные сведения см. в разделе Рекомендации в отношении идентификаторов узла. (#2049)

  • Функции Azure 4.x поддерживает более новые версии .NET. Полный список версий см. в разделе Поддерживаемые языки в Функции Azure.

  • InvalidHostServicesException теперь является фатальной ошибкой. (#2045)

  • EnableEnhancedScopes включен по умолчанию. (#1954)

  • Удалите HttpClient в качестве зарегистрированной службы. (#1911)

  • Используйте загрузчик одного класса в Java 11. (#1997)

  • Остановите загрузку рабочих jars в Java 8. (#1991)

  • Node.js версии 10 и 12 не поддерживаются в Функции Azure 4.x. (#1999)

  • Сериализация выходных данных в приложениях Node.js была обновлена для устранения предыдущих несоответствий. (#2007)

  • Количество потоков по умолчанию обновлено. Функции, которые не являются потокобезопасными или имеют высокий объем памяти, могут быть затронуты. (#1962)

  • Python 3.6 не поддерживается в Функции Azure 4.x. (#1999)

  • Передача общей памяти включена по умолчанию. (#1973)

  • Количество потоков по умолчанию обновлено. Функции, которые не являются потокобезопасными или имеют высокий объем памяти, могут быть затронуты. (#1962)

Следующие шаги

Дополнительные сведения о версиях функций

  • Last updated on