Перенос приложений .NET из модели внутрипроцессной в изолированную рабочую модель
Внимание
Поддержка будет завершена для модели в процессе 10 ноября 2026 г. Настоятельно рекомендуется перенести приложения в изолированную рабочую модель, следуя инструкциям в этой статье.
В этой статье описывается процесс безопасного переноса приложения-функции .NET из модели внутрипроцессной в изолированную рабочую модель. Дополнительные сведения о высоких различиях между этими моделями см. в сравнении режима выполнения.
В этом руководстве предполагается, что приложение работает в среде выполнения функций версии 4.x. В противном случае следует следовать руководствам по обновлению версии узла:
- Перенос приложений из Функции Azure версии 2.x и 3.x на версию 4.x
- Перевод приложений с Функций Azure версии 1.x на версию 4.x
Эти руководства по миграции версий узла также помогают перенестися в изолированную рабочую модель при работе с ними.
Определение приложений-функций для миграции
Используйте следующий скрипт Azure PowerShell, чтобы создать список приложений-функций в подписке, которые в настоящее время используют модель внутрипроцессного процесса.
В скрипте используется подписка, которую Azure PowerShell в настоящее время настроена для использования. Вы можете изменить подписку, сначала запустив Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>' и заменив <YOUR SUBSCRIPTION ID> идентификатором подписки, которую вы хотите оценить.
$FunctionApps = Get-AzFunctionApp
$AppInfo = @{}
foreach ($App in $FunctionApps)
{
if ($App.Runtime -eq 'dotnet')
{
$AppInfo.Add($App.Name, $App.Runtime)
}
}
$AppInfo
Выбор целевой версии .NET
В среде выполнения функций версии 4.x приложение-функция .NET предназначено для .NET 6 при использовании модели в процессе.
При переносе приложения-функции у вас есть возможность выбрать целевую версию .NET. Проект C# можно обновить до одной из следующих версий .NET, поддерживаемых функциями версии 4.x:
| Версия .NET | Тип выпуска политики поддержки .NET | Модельпроцесса функций 1,2 |
|---|---|---|
| .NET 9 | Предварительная версия3 | Изолированная рабочая модель |
| .NET 8 | LTS (окончание поддержки 10 ноября 2026 г.) | Изолированная рабочая модель, Модель в процессе2 |
| .NET 6 | LTS (окончание поддержки 12 ноября 2024 г.) | Изолированная рабочая модель, Модель в процессе2 |
| .NET Framework 4.8 | См. политику | Изолированная рабочая модель |
1 Изолированная рабочая модель поддерживает долгосрочную поддержку (LTS) и стандартные версии .NET, а также платформа .NET Framework. Модель в процессе поддерживает только LTS-выпуски .NET, заканчивая .NET 8. Полное сравнение функций и функций двух моделей см. в разделе "Различия между процессом и изоляцией рабочего процесса .NET Функции Azure".
2 Поддержка заканчивается для модели в процессе 10 ноября 2026 года. Дополнительные сведения см . в этом объявлении о поддержке. Для непрерывной поддержки следует перенести приложения в изолированную рабочую модель.
3 . Дополнительные сведения о поддержке, текущих ограничениях и инструкциях по использованию предварительной версии см . в предварительной версии .NET в изолированной рабочей модели .
Совет
Рекомендуется обновить до .NET 8 в изолированной рабочей модели. Это обеспечивает быстрый путь миграции к полностью выпущенной версии с самым длинным окном поддержки из .NET.
Это руководство не содержит конкретных примеров для .NET 9 (предварительная версия) или .NET 6. Если вам нужно настроить эти версии, можно адаптировать примеры .NET 8.
Подготовка к переносу
Если вы еще не сделали этого, определите список приложений, которые необходимо перенести в текущей подписке Azure с помощью Azure PowerShell.
Прежде чем перенести приложение в изолированную рабочую модель, необходимо тщательно просмотреть содержимое этого руководства. Вы также должны ознакомиться с функциями изолированной рабочей модели и различиями между двумя моделями.
Чтобы перенести приложение, выполните следующие действия.
- Перенесите локальный проект в изолированную рабочую модель, выполнив действия, описанные в разделе "Миграция локального проекта".
- После переноса проекта полностью протестируйте приложение локально с помощью версии 4.x Функции Azure Core Tools.
- Обновите приложение-функцию в Azure до изолированной модели.
Перенос локального проекта
В этом разделе описаны различные изменения, которые необходимо внести в локальный проект, чтобы переместить его в изолированную рабочую модель. Некоторые шаги изменяются на основе целевой версии .NET. Используйте вкладки, чтобы выбрать инструкции, соответствующие требуемой версии. В этих шагах предполагается, что локальный проект C# и если приложение вместо этого использует скрипт C# (.csx файлы), перед продолжением следует преобразовать в модель проекта.
Совет
При переходе на LTS или STS-версию .NET помощник по обновлению .NET можно использовать для автоматического внесения многих изменений, упомянутых в следующих разделах.
Сначала преобразуйте файл проекта и обновите зависимости. По мере выполнения вы увидите ошибки сборки для проекта. В последующих шагах необходимо внести соответствующие изменения, чтобы удалить эти ошибки.
Файл проекта
Следующий пример — .csproj это файл проекта, использующий .NET 6 в версии 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>
Используйте одну из следующих процедур, чтобы обновить этот XML-файл для запуска в изолированной рабочей модели:
В этих шагах предполагается, что локальный проект C# и если приложение вместо этого использует скрипт C# (.csx файлы), перед продолжением следует преобразовать в модель проекта.
В XML-файле проекта требуются .csproj следующие изменения:
Задайте значение
PropertyGroup.TargetFrameworkизменено наnet8.0.Задайте значение
PropertyGroup.AzureFunctionsVersionизменено наv4.Добавьте следующий
OutputTypeэлемент в :PropertyGroup<OutputType>Exe</OutputType>ItemGroupВ .PackageReferenceсписок, замените ссылку наMicrosoft.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" />Запишите ссылки на другие пакеты в
Microsoft.Azure.WebJobs.*пространствах имен. Вы замените эти пакеты на следующем шаге.Добавьте следующее новое:
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>
Изменение целевой платформы проекта также может потребовать изменений в частях цепочки инструментов за пределами кода проекта. Например, в VS Code может потребоваться обновить azureFunctions.deploySubpath параметр расширения с помощью параметров пользователя или файла проекта .vscode/settings.json . Проверьте наличие зависимостей от версии платформы, которая может существовать вне кода проекта, как часть шагов сборки или конвейера CI/CD.
Ссылки на пакеты
При миграции в изолированную рабочую модель необходимо изменить пакеты, на которые ссылается приложение.
Если вы еще не сделали этого, обновите проект, чтобы ссылаться на последние стабильные версии:
В зависимости от триггеров и привязок, которые использует приложение, может потребоваться ссылаться на другой набор пакетов. В следующей таблице показаны замены некоторых наиболее часто используемых расширений:
| Сценарий | Изменения ссылок на пакеты |
|---|---|
| Триггер по таймеру | Добавить Microsoft.Azure.Functions.Worker.Extensions.Timer |
| Привязки хранилища | ReplaceMicrosoft.Azure.WebJobs.Extensions.Storageна Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs, Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues и Microsoft.Azure.Functions.Worker.Extensions.Tables |
| Привязки больших двоичных объектов | Замена ссылок наMicrosoft.Azure.WebJobs.Extensions.Storage.Blobsс последней версией Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs |
| Привязки очередей | Замена ссылок наMicrosoft.Azure.WebJobs.Extensions.Storage.Queuesс последней версией Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues |
| Привязки таблиц | Замена ссылок наMicrosoft.Azure.WebJobs.Extensions.Tablesс последней версией Microsoft.Azure.Functions.Worker.Extensions.Tables |
| Привязки Cosmos DB | Замена ссылок наMicrosoft.Azure.WebJobs.Extensions.CosmosDBи (или) Microsoft.Azure.WebJobs.Extensions.DocumentDBс последней версией Microsoft.Azure.Functions.Worker.Extensions.CosmosDB |
| Привязки служебной шины | Замена ссылок наMicrosoft.Azure.WebJobs.Extensions.ServiceBusс последней версией Microsoft.Azure.Functions.Worker.Extensions.ServiceBus |
| Привязки Центров событий | Замена ссылок наMicrosoft.Azure.WebJobs.Extensions.EventHubsс последней версией Microsoft.Azure.Functions.Worker.Extensions.EventHubs |
| Привязки сетки событий | Замена ссылок наMicrosoft.Azure.WebJobs.Extensions.EventGridс последней версией Microsoft.Azure.Functions.Worker.Extensions.EventGrid |
| Привязки Службы SignalR | Замена ссылок наMicrosoft.Azure.WebJobs.Extensions.SignalRServiceс последней версией Microsoft.Azure.Functions.Worker.Extensions.SignalRService |
| Устойчивые функции | Замена ссылок наMicrosoft.Azure.WebJobs.Extensions.DurableTaskс последней версией Microsoft.Azure.Functions.Worker.Extensions.DurableTask |
| Устойчивые функции (поставщик хранилища SQL) |
Замена ссылок наMicrosoft.DurableTask.SqlServer.AzureFunctionsс последней версией Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer |
| Устойчивые функции (поставщик хранилища Netherite) |
Замена ссылок наMicrosoft.Azure.DurableTask.Netherite.AzureFunctionsс последней версией Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite |
| Привязки SendGrid | Замена ссылок наMicrosoft.Azure.WebJobs.Extensions.SendGridс последней версией Microsoft.Azure.Functions.Worker.Extensions.SendGrid |
| Привязки Kafka | Замена ссылок наMicrosoft.Azure.WebJobs.Extensions.Kafkaс последней версией Microsoft.Azure.Functions.Worker.Extensions.Kafka |
| Привязки RabbitMQ | Замена ссылок наMicrosoft.Azure.WebJobs.Extensions.RabbitMQс последней версией Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ |
| Внедрение зависимостей и конфигурация запуска |
Удаление ссылок наMicrosoft.Azure.Functions.Extensions(Изолированная рабочая модель предоставляет эту функцию по умолчанию.) |
Ознакомьтесь с поддерживаемыми привязками для полного списка расширений, которые следует рассмотреть, и ознакомьтесь с документацией по каждому расширению, чтобы получить полные инструкции по установке для изолированной модели процесса. Не забудьте установить последнюю стабильную версию всех целевых пакетов.
Совет
Любые изменения версий расширений во время этого процесса могут потребовать обновления host.json файла. Обязательно ознакомьтесь с документацией по каждому используемому расширению.
Например, расширение служебная шина имеет критические изменения в структуре между версиями 4.x и 5.x. Дополнительные сведения см. в Служебная шина Azure привязках для Функции Azure.
Приложение изолированной рабочей модели не должно ссылаться на пакеты в Microsoft.Azure.WebJobs.* пространствах имен или Microsoft.Azure.Functions.Extensions. Если у вас есть оставшиеся ссылки на них, их следует удалить.
Совет
Ваше приложение также может зависеть от типов azure SDK, как часть триггеров и привязок, так и в качестве автономной зависимости. Вы должны воспользоваться этой возможностью, чтобы обновить их, а также. Последние версии расширений функций работают с последними версиями пакета SDK Azure для .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, можно заменить вызов ConfigureFunctionsWebApplication вызовом ConfigureFunctionsWorkerDefaults. При этом можно удалить ссылку Microsoft.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 или Конфигурация приложений ссылок на функции.
После перемещения всего из любого существующего FunctionsStartup Program.cs в файл можно удалить FunctionsStartup атрибут и класс, к который он был применен.
Изменения подписи функции
Некоторые ключевые типы изменяются между внутрипроцессной моделью и изолированной рабочей моделью. Многие из них относятся к атрибутам, параметрам и возвращаемым типам, составляющим сигнатуру функции. Для каждой функции необходимо внести изменения в следующее:
- Атрибут функции (который также задает имя функции)
- Получение функции
ILogger/ILogger<T> - Атрибуты и параметры триггера и привязки
В остальной части этого раздела показано, как выполнить все эти действия.
Атрибуты функций
Атрибут Function в изолированной рабочей модели заменяет FunctionName атрибут. Новый атрибут имеет ту же сигнатуру, и единственное различие в имени. Поэтому вы можете просто выполнить замену строки в проекте.
Ведение журнала
В модели внутрипроцессного процесса можно включить необязательный ILogger параметр в функцию или использовать внедрение зависимостей для получения ILogger<T>. Если приложение уже использовало внедрение зависимостей, то те же механизмы работают в изолированной рабочей модели.
Однако для любых функций, зависящих от ILogger параметра метода, необходимо внести изменения. Рекомендуется использовать внедрение зависимостей для получения ILogger<T>. Чтобы перенести механизм ведения журнала функции, выполните следующие действия.
В классе функции добавьте
private readonly ILogger<MyFunction> _logger;свойство, заменивMyFunctionимя класса функции.Создайте конструктор для класса функции, который принимает в
ILogger<T>качестве параметра:public MyFunction(ILogger<MyFunction> logger) { _logger = logger; }Замените оба экземпляра
MyFunctionв предыдущем фрагменте кода именем класса функции.Для операций ведения журнала в коде
ILoggerфункции замените ссылки на параметр_logger.ILoggerУдалите параметр из подписи функции.
Дополнительные сведения см. в разделе "Ведение журнала" в изолированной рабочей модели.
Изменения триггера и привязки
При изменении ссылок на пакет на предыдущем шаге вы внесли ошибки для триггеров и привязок, которые будут исправлены:
Удалите все
using Microsoft.Azure.WebJobs;инструкции.Добавьте инструкцию
using Microsoft.Azure.Functions.Worker;.Для каждого атрибута привязки измените имя атрибута, как указано в справочной документации, которую можно найти в индексе поддерживаемых привязок . Как правило, имена атрибутов изменяются следующим образом:
- Триггеры обычно остаются именованными так же. Например,
QueueTriggerэто имя атрибута для обеих моделей. - Входные привязки обычно требуют добавления входных привязок в их имя. Например, если в модели внутрипроцессной модели использовался атрибут входной
CosmosDBпривязки, атрибут теперь будет иметь значениеCosmosDBInput. - Выходные привязки обычно требуют добавления "Output" в их имя. Например, если в модели внутрипроцессной модели использовался атрибут выходной
Queueпривязки, теперь этот атрибут будет иметь значениеQueueOutput.
- Триггеры обычно остаются именованными так же. Например,
Обновите параметры атрибута, чтобы отразить изолированную версию рабочей модели, как указано в справочной документации привязки.
Например, в модели внутрипроцессного процесса выходная привязка большого двоичного объекта представлена атрибутом
[Blob(...)], который включаетAccessсвойство. В изолированной рабочей модели выходной атрибут большого двоичного объекта будет[BlobOutput(...)]. Привязка больше не требуетAccessсвойства, чтобы этот параметр можно было удалить. Так[Blob("sample-images-sm/{fileName}", FileAccess.Write, Connection = "MyStorageConnection")]стало бы[BlobOutput("sample-images-sm/{fileName}", Connection = "MyStorageConnection")].Перемещение выходных привязок из списка параметров функции. Если у вас есть только одна выходная привязка, это можно применить к типу возвращаемой функции. Если у вас несколько выходных данных, создайте новый класс со свойствами для каждого вывода и примените атрибуты к этим свойствам. Дополнительные сведения см. в разделе "Несколько выходных привязок".
Ознакомьтесь со справочной документацией по каждой привязке для типов, к которых можно привязаться. В некоторых случаях может потребоваться изменить тип. Для выходных привязок, если используется
IAsyncCollector<T>версия модели в процессе, ее можно заменить привязкой к массиву целевого типа:T[]Вы также можете заменить выходную привязку клиентским объектом для службы, которая она представляет, либо как тип привязки входной привязки, если она доступна, либо путем внедрения клиента самостоятельно.Если функция содержит
IBinderпараметр, удалите его. Замените функциональность клиентским объектом службы, который он представляет, либо как тип привязки для входной привязки, если он доступен, либо путем внедрения клиента самостоятельно.Обновите код функции, чтобы работать с любыми новыми типами.
файле local.settings.json
Файл local.settings.json используется только при локальном запуске. Дополнительные сведения см. в файле локальных параметров.
При переходе от выполнения процесса к выполнению в изолированном рабочем процессе необходимо изменить FUNCTIONS_WORKER_RUNTIME значение на "dotnet-isolated". Убедитесь, что файл local.settings.json содержит по крайней мере следующие элементы:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
}
}
Значение, которое у вас имеется для AzureWebJobsStorage, может отличаться. Изменить его значение в рамках миграции не нужно.
файл host.json
Изменения в файле не требуются host.json . Однако если конфигурация Application Insights в этом файле из проекта модели в процессе, может потребоваться внести дополнительные изменения в Program.cs файл. Файл host.json управляет ведением журнала только из среды выполнения узла Функций и в изолированной рабочей модели некоторые из этих журналов приходят непосредственно из приложения, что дает вам больше контроля. Дополнительные сведения об фильтрации этих журналов см. в статье "Управление уровнями журналов в изолированной рабочей модели ".
Другие изменения кода
В этом разделе рассматриваются другие изменения кода, которые следует учитывать при работе с миграцией. Эти изменения не требуются для всех приложений, но следует оценить, имеют ли они отношение к вашим сценариям.
Сериализация JSON
По умолчанию изолированная рабочая модель используется System.Text.Json для сериализации JSON. Сведения о настройке параметров сериализатора или переключении на JSON.NET (Newtonsoft.Json) см . в этих инструкциях.
Уровни журналов Application Insights и фильтрация
Журналы можно отправлять в Application Insights как из среды выполнения узла функций, так и кода в проекте. Это host.json позволяет настраивать правила для ведения журнала узлов, но управлять журналами, поступающими из кода, необходимо настроить правила фильтрации в рамках вашего кода Program.cs. Дополнительные сведения об фильтрации этих журналов см. в статье "Управление уровнями журналов в изолированной рабочей модели ".
Примеры миграций функций
Пример триггера HTTP
Триггер HTTP для модели в процессе может выглядеть следующим образом:
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"]}!");
}
}
}
Триггер 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
Обновление приложения-функции до изолированной модели включает в себя два изменения, которые должны быть завершены вместе, так как если вы завершили только одно, приложение находится в состоянии ошибки. Оба этих изменения также приводят к перезапуску процесса приложения. По этим причинам необходимо выполнить обновление с помощью промежуточного слота. Промежуточные слоты помогают свести к минимуму время простоя приложения и позволяют тестировать и проверять перенесенный код с обновленной конфигурацией в Azure. Затем можно развернуть полностью перенесенное приложение в рабочий слот с помощью операции переключения.
Внимание
Если развернутые полезные данные приложения не соответствуют настроенной среде выполнения, она будет находиться в состоянии ошибки. В процессе миграции приложение будет помещено в это состояние, в идеале только временно. Слоты развертывания помогают устранить последствия этого, так как состояние ошибки будет разрешено в промежуточной (нерабокой) среде, прежде чем изменения будут применены как одно обновление к рабочей среде. Слоты также защищаются от любых ошибок и позволяют обнаруживать любые другие проблемы перед достижением рабочей среды.
Во время процесса могут по-прежнему отображаться ошибки в журналах, поступающих из промежуточного (непроизводного) слота. Это ожидается, хотя они должны уйти, как вы идете через шаги. Перед выполнением операции переключения слотов необходимо убедиться, что эти ошибки перестают вызываться и что приложение работает должным образом.
Выполните следующие действия, чтобы использовать слоты развертывания для обновления приложения-функции до изолированной рабочей модели:
Создайте слот развертывания, если вы еще не сделали этого. Вы также можете ознакомиться с процессом замены слотов и убедиться, что вы можете обновлять существующее приложение с минимальным нарушением.
Измените конфигурацию промежуточного (непроизводящего) слота, чтобы использовать изолированную рабочую модель, установив
FUNCTIONS_WORKER_RUNTIMEдля параметра приложения значениеdotnet-isolated.FUNCTIONS_WORKER_RUNTIMEне должно быть отмечено как параметр слота.Если вы также используете другую версию .NET в рамках обновления, необходимо также изменить конфигурацию стека. Для этого ознакомьтесь с инструкциями по обновлению конфигурации стека для изолированной рабочей модели. Вы будете использовать те же инструкции для всех будущих обновлений версий .NET, которые вы делаете.
Если у вас есть автоматическая подготовка инфраструктуры, например конвейер CI/CD, убедитесь, что автоматизация также обновляется, чтобы сохранить
FUNCTIONS_WORKER_RUNTIMEиdotnet-isolatedнастроить правильную версию .NET.Опубликуйте перенесенный проект в промежуточный (непроизводственные) слот приложения-функции.
Если вы используете Visual Studio для публикации проекта изолированной рабочей модели в существующем приложении или слоте, использующем модель внутрипроцессного процесса, она также может выполнить предыдущий шаг одновременно. Если вы не выполнили предыдущий шаг, Visual Studio предложит обновить приложение-функцию во время развертывания. Visual Studio представляет эту операцию как одну операцию, но они по-прежнему являются двумя отдельными операциями. В журналах могут по-прежнему возникать ошибки из промежуточного (непроизводского) слота во время промежуточного состояния.
Убедитесь, что приложение работает должным образом в промежуточном (непроизводном) слоте.
Выполните операцию переключения слотов. Это применяет изменения, внесенные в промежуточный (непроизводственные) слот к рабочему слоту. Переключение слотов происходит как одно обновление, которое позволяет избежать промежуточного состояния ошибки в рабочей среде.
Убедитесь, что приложение работает должным образом в рабочем слоте.
После выполнения этих действий миграция завершится, а приложение выполняется в изолированной модели. Поздравляем! Повторите действия из этого руководства по мере необходимости для любых других приложений, требующих миграции.