Поделиться через


Перенести приложения из плана потребления в план "Flex Consumption"

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

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

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

План Flex Consumption — это рекомендуемый вариант бессерверного размещения для ваших функций. Дополнительные сведения см. в разделе о преимуществах плана потребления Flex. Подробное сравнение планов размещения см. в разделе " Параметры размещения Функций Azure".

Соображения

Прежде чем начинать миграцию, помните следующее:

  • Из-за значительных различий конфигурации и поведения между двумя планами вы не можете переместить существующее приложение плана потребления в план потребления Flex. Вместо этого вы создадите новое приложение плана потребления Flex, эквивалентное текущему приложению. Это новое приложение выполняется в той же группе ресурсов и с теми же зависимостями, что и текущее приложение.

  • Следует определить приоритеты миграции приложений, которые выполняются в плане потребления в Linux.

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

  • По возможности эта статья ориентирована на определенный стек среды выполнения языка. Выберите язык приложения в верхней части статьи.

  • В этой статье показано, как оценить текущее приложение и развернуть новое приложение плана потребления Flex с помощью портала Azure или Azure CLI. Если ваше текущее развертывание приложения определено с помощью инфраструктуры как кода (IaC), вы можете выполнить те же действия. Вы можете выполнять те же действия с учетом следующих рекомендаций по конкретным ресурсам непосредственно в шаблонах ARM или Bicep-файлах.

Предпосылки

  • Доступ к подписке Azure, содержащей одно или несколько приложений-функций для миграции. Учетная запись, используемая для выполнения команд Azure CLI, должна иметь следующие возможности:

    • Создание приложений-функций и планов размещения службы приложений и управление ими.
    • Назначьте роли управляемым удостоверениям.
    • Создание учетных записей хранения и управление ими.
    • Создание ресурсов Application Insights и управление ими.
    • Доступ ко всем зависимым ресурсам приложения, таким как Azure Key Vault, служебная шина Azure или Центры событий Azure.

    Назначение на роли владельца или участника в группе ресурсов обычно предоставляет достаточные разрешения.

  • Azure CLI версии 2.74.0 или более поздней версии. Скрипты тестируются с помощью Azure CLI в Azure Cloud Shell.

  • Расширение resource-graph , которое можно установить с помощью az extension add команды:

    az extension add --name resource-graph
    
  • Средство jq , которое используется для работы с выходными данными JSON.

Оценка существующего приложения

Перед миграцией на тарифный план Flex Consumption выполните следующие проверки, чтобы убедиться, что функциональное приложение может быть успешно перенесено.

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

Используйте эти действия, чтобы сделать список приложений-функций, которые необходимо перенести. В этом списке запишите имена, группы ресурсов, расположения и стеков среды выполнения. Затем можно повторить действия, описанные в этом руководстве для каждого приложения, которое вы решили перенести в план потребления Flex.

Способ сохранения сведений о приложении-функции зависит от того, работает ли ваше приложение в Linux или Windows.

Используйте эту az graph query команду для перечисления всех приложений-функций в подписке, работающих в плане потребления:

az graph query -q "resources | where subscriptionId == '$(az account show --query id -o tsv)' \
   | where type == 'microsoft.web/sites' | where ['kind'] == 'functionapp,linux' | where properties.sku == 'Dynamic' \
   | extend siteProperties=todynamic(properties.siteProperties.properties) | mv-expand siteProperties \
   | where siteProperties.name=='LinuxFxVersion' | project name, location, resourceGroup, stack=siteProperties.value" \
   --query data --output table

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

Вам предлагается установить расширение resource-graph, если оно еще не установлено.

Подтверждение совместимости региона

Убедитесь, что план потребления Flex в настоящее время поддерживается в том же регионе, что и приложение плана потребления, которое вы планируете перенести.

Используйте эту az functionapp list-flexconsumption-locations команду для перечисления всех регионов, где доступен план потребления Flex:

az functionapp list-flexconsumption-locations --query "sort_by(@, &name)[].{Region:name}" -o table

Эта команда создает таблицу регионов Azure, где в настоящее время поддерживается план потребления Flex.

Убедитесь, что регион, где выполняется приложение плана потребления, которое вы хотите перенести, входит в список.

Подсказка

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

Проверка совместимости языкового стека

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

Настройка стека Имя стека Поддерживается
dotnet-isolated .NET (изолированная рабочая модель) ✅ Да
node JavaScript/TypeScript ✅ Да
java Java ✅ Да
python Питон ✅ Да
powershell PowerShell ✅ Да
dotnet .NET (модель в процессе) ❌ Нет
custom Пользовательские обработчики ❌ Нет

Если приложение-функция использует неподдерживаемый стек среды выполнения:

  • Для приложений C#, которые выполняются в процессе с средой выполнения (dotnet), необходимо сначала перенести приложение в изолированный .NET. Дополнительные сведения см. в статье "Миграция приложений C# из модели в процессе в изолированную рабочую модель".

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

Проверка совместимости версий стека

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

Используйте эту az functionapp list-flexconsumption-runtimes команду, чтобы проверить поддержку плана потребления Flex для версии стека языков в определенном регионе:

az functionapp list-flexconsumption-runtimes --location <REGION> --runtime <LANGUAGE_STACK> --query '[].{version:version}' -o tsv

В этом примере замените <REGION> на ваш текущий регион и <LANGUAGE_STACK> на одно из следующих значений:

Языковой стек Ценность
C# (изолированная рабочая модель) dotnet-isolated
Java java
JavaScript node
PowerShell powershell
Питон python
Машинописный текст node

Эта команда отображает все версии указанного стека языков, поддерживаемые планом потребления Flex в вашем регионе.

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

Проверка использования слотов развертывания

Приложения плана потребления могут иметь определенный слот развертывания. Дополнительные сведения см. в разделе Функции Azure слотов развертывания. Однако тарифный план Flex Consumption в настоящее время не поддерживает слоты развертывания. Перед миграцией необходимо определить, имеет ли приложение слот развертывания. В этом случае необходимо определить стратегию, как управлять приложением без слотов развертывания при выполнении в контексте плана потребления Flex.

Используйте эту az functionapp deployment slot list команду для перечисления всех слотов развертывания, определенных в приложении-функции:

az functionapp deployment slot list --name <APP_NAME> --resource-group <RESOURCE_GROUP> --output table

В этом примере замените <RESOURCE_GROUP> на название вашей группы ресурсов, а <APP_NAME> на название приложения соответственно. Если команда возвращает запись, ваше приложение имеет включенные слоты развертывания.

Если ваше функциональное приложение использует слоты развертывания, вы сейчас не можете воспроизвести эту функциональность в плане Flex Consumption. Перед миграцией необходимо...

  • Перенос любого нового кода или компонентов из слота развертывания в основной (рабочий) слот.
  • Рассмотрите возможность перепроектирования приложения для использования отдельных приложений-функций. Таким образом, вы можете разрабатывать, тестировать и развертывать код функции во втором непроизводственном приложении вместо того чтобы использовать слоты.

Проверка использования сертификатов

Сертификаты TLS, ранее известные как сертификаты SSL, используются для защиты подключений к Интернету. Сертификаты TLS/SSL, которые включают управляемые сертификаты, сертификаты с поддержкой BYOC (bring-your-own certificates), или сертификаты открытого ключа, в настоящее время не поддерживаются планом Flex Consumption.

az webapp config ssl list Используйте команду для перечисления всех сертификатов TSL/SSL, доступных приложению-функции:

az webapp config ssl list --resource-group <RESOURCE_GROUP>  

В этом примере замените <RESOURCE_GROUP> на имя своей группы ресурсов. Если эта команда создает выходные данные, приложение, скорее всего, использует сертификаты.

Если приложение в настоящее время использует сертификаты TSL/SSL, вы не должны продолжать миграцию до тех пор, пока поддержка сертификатов не будет добавлена в план потребления Flex.

Убедитесь в правильности триггеров хранилища BLOB-объектов

В настоящее время план Flex Consumption поддерживает только триггеры, основанные на событиях, для хранилища Azure Blob, которые определены с параметром SourceEventGrid. Триггеры хранилища BLOB, которые используют опрос контейнеров и параметр SourceLogsAndContainerScan, не поддерживаются в Flex Consumption. Так как опрос контейнеров является стандартным, необходимо определить, используется ли какой-либо из триггеров хранилища BLOB-объектов с настройкой источника по умолчанию LogsAndContainerScan. Дополнительные сведения см. в разделе Триггеры для контейнера BLOB-объектов.

Используйте эту команду [az functionapp function list], чтобы определить, есть ли у приложения триггеры хранения BLOB-объектов, которые не используют Event Grid в качестве источника.

az functionapp function list  --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
  --query "[?config.bindings[0].type=='blobTrigger' && config.bindings[0].source!='EventGrid'].{Function:name,TriggerType:config.bindings[0].type,Source:config.bindings[0].source}" \
  --output table

В этом примере замените <RESOURCE_GROUP> на название вашей группы ресурсов, а <APP_NAME> на название приложения соответственно. Если команда возвращает строки, то в вашем приложении-функции есть по крайней мере один триггер, использующий опрос контейнера.

Если у вашего приложения есть триггеры хранилища BLOB-объектов, которые не имеют источника Event Grid, необходимо изменить на источник Event Grid перед переходом на план Flex Consumption.

Основные шаги по изменению существующего триггера хранилища Blob на источник Event Grid следующие:

  1. Создайте URL-адрес конечной точки в приложении-функции, используемом подпиской на события.

  2. Создайте подписку на события в контейнере хранилища BLOB-объектов.

  3. Добавьте или обновите свойство source в определении триггера хранилища BLOB-объектов на EventGrid.

Дополнительные сведения см. в учебнике Триггер большого двоичного объекта сетки событий функции Azure.

Рассмотрим зависимые службы

Так как Функции Azure — это служба вычислений, необходимо учитывать влияние миграции на данные и службы как выше, так и внизу приложения.

Стратегии защиты данных

Ниже приведены некоторые стратегии защиты как вышестоящих, так и подчиненных данных во время миграции:

  • Идемпотентность. Убедитесь, что функции могут безопасно обрабатывать одно и то же сообщение несколько раз без негативных побочных эффектов. Дополнительные сведения см. в разделе "Проектирование функций Azure" для идентичных входных данных.
  • Ведение журнала и мониторинг. Включение подробного ведения журнала в обоих приложениях во время миграции для отслеживания обработки сообщений. Дополнительные сведения см. в статье "Мониторинг выполнения" в Функциях Azure.
  • Контрольная точка: для триггеров потоковой передачи, таких как триггер Центров событий, реализуйте правильное поведение контрольных точек для отслеживания положения обработки. Дополнительные сведения см. в разделе "Функции Azure" для надежной обработки событий.
  • Параллельная обработка: рекомендуется временно запускать оба приложения параллельно во время переключение. Тщательно отслеживайте и проверяйте способ обработки данных из вышестоящей службы. Дополнительные сведения см. в паттерн активной-активной конфигурации для функций, триггеруемых не по HTTPS.
  • Постепенный переход: для систем с большим объемом рекомендуется реализовать постепенный переход, перенаправляя части трафика на новое приложение. Вы можете управлять маршрутизацией запросов из приложений с помощью таких служб, как управление API Azure или Шлюз приложений Azure.

Устранение рисков по типу триггера

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

Триггер Риск для данных Стратегия
Хранилище BLOB-объектов Azure Высоко Создайте отдельный контейнер для триггера на основе событий в новом приложении.
При запуске нового приложения переключите клиенты на использование нового контейнера.
Предоставьте исходному контейнеру полностью обрабатываться перед остановкой старого приложения.
Azure Cosmos DB Высоко Создайте выделенный контейнер аренды специально для нового приложения.
Задайте этот новый контейнер аренды leaseCollectionName в качестве конфигурации в новом приложении.
Требует, чтобы функции были идемпотентными или чтобы была возможность обрабатывать результаты обработки дубликатов канала изменений.
Задайте конфигурацию StartFromBeginning на false в новом приложении, чтобы избежать повторной обработки всего потока данных.
Сетка событий Azure Средний Создайте ту же подписку на события в новом приложении.
Требуется, чтобы функции были идемпотентными, или необходимо иметь возможность обрабатывать результаты дублирующейся обработки событий.
Центры событий Azure Средний Создайте новую группу потребителей для использования новым приложением. Дополнительные сведения см. в разделе "Стратегии миграции" для триггеров сетки событий.
Azure Service Bus Высоко Создайте раздел или очередь для использования новым приложением.
Обновите отправителей и клиентов, чтобы использовать новый раздел или очередь.
После того как исходный раздел пуст, закройте старое приложение.
Очередь службы хранилища Azure Высоко Создайте новую очередь для использования новым приложением.
Обновите отправителей и клиентов, чтобы использовать новую очередь.
После того как исходная очередь пуста, закройте старое приложение.
HTTP Низкий уровень Не забудьте переключить клиенты и другие приложения или службы для назначения новых конечных точек HTTP после миграции.
Таймер Низкий уровень Во время перехода обязательно смещайте расписание таймера между двумя приложениями, чтобы избежать одновременного выполнения обоих приложений.
Отключите триггер таймера в старом приложении после успешного запуска нового приложения.

Задачи предварительной подготовки

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

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

Сбор параметров приложения

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

Используйте эту az functionapp config appsettings list команду, чтобы вернуть объект, содержащий существующий app_settings параметр приложения в формате JSON:

app_settings=$(az functionapp config appsettings list --name `<APP_NAME>` --resource-group `<RESOURCE_GROUP>`)
echo $app_settings

В этом примере замените <RESOURCE_GROUP> на название вашей группы ресурсов, а <APP_NAME> на название приложения соответственно.

Осторожность

Параметры приложения часто содержат ключи и другие общие секреты. Всегда хранить параметры приложений безопасно, идеально зашифрованными. Следует использовать проверку подлинности через Microsoft Entra ID с управляемыми удостоверениями в новом приложении для плана потребления Flex для повышения безопасности, вместо использования общих секретов.

Сбор конфигураций приложений

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

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

Конфигурация Настройки Комментарий
Параметры CORS cors Определяет существующие настройки общего доступа к ресурсам (CORS), которые могут потребоваться вашими клиентами.
Личные домены Если ваше приложение в настоящее время использует домен, отличный от *.azurewebsites.net, необходимо заменить это сопоставление пользовательского домена на ваше новое приложение.
Версия HTTP http20Enabled Определяет, требуется ли вашему приложению HTTP 2.0.
Только HTTPS httpsOnly Определяет, требуется ли TSL/SSL для доступа к приложению.
Входящие сертификаты клиента clientCertEnabled
clientCertMode
clientCertExclusionPaths
Задает требования для клиентских запросов, использующих сертификаты для проверки подлинности.
Максимальное ограничение масштабирования WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT Устанавливает предел для инстанций горизонтального масштабирования. Максимальное значение по умолчанию — 200. Это значение находится в параметрах вашего приложения, но в приложении с планом потребления Flex оно вместо этого добавляется в качестве параметра сайта (maximumInstanceCount).
Минимальная версия tls для входящего трафика minTlsVersion Задает минимальную версию TLS, необходимую для приложения.
Минимальный входящий шифр TLS minTlsCipherSuite Задает минимальное требование шифра TLS для приложения.
Смонтированные общие папки Azure Files azureStorageAccounts Определяет, существуют ли в приложении явным образом подключенные файловые ресурсы (только для Linux).
Базовые учетные данные для аутентификации публикации в SCM scm.allow Определяет, включен ли scm сайт публикации. Хотя и не рекомендуется для обеспечения безопасности, он требуется для некоторых методов публикации.

Используйте этот скрипт для получения соответствующих конфигураций приложений существующего приложения:

# Set the app and resource group names
appName=<APP_NAME>
rgName=<RESOURCE_GROUP>

echo "Getting commonly used site settings..."
az functionapp config show --name $appName --resource-group $rgName \
    --query "{http20Enabled:http20Enabled, httpsOnly:httpsOnly, minTlsVersion:minTlsVersion, \
    minTlsCipherSuite:minTlsCipherSuite, clientCertEnabled:clientCertEnabled, \
    clientCertMode:clientCertMode, clientCertExclusionPaths:clientCertExclusionPaths}"

echo "Checking for SCM basic publishing credentials policies..."
az resource show --resource-group $rgName --name scm --namespace Microsoft.Web \
    --resource-type basicPublishingCredentialsPolicies --parent sites/$appName --query properties

echo "Checking for the maximum scale-out limit configuration..."
az functionapp config appsettings list --name $appName --resource-group $rgName \
    --query "[?name=='WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT'].value" -o tsv

echo "Checking for any file share mount configurations..."
az webapp config storage-account list --name $appName --resource-group $rgName

echo "Checking for any custom domains..."
az functionapp config hostname list --webapp-name $appName --resource-group $rgName --query "[?contains(name, 'azurewebsites.net')==\`false\`]" --output table

echo "Checking for any CORS settings..."
az functionapp cors show --name $appName --resource-group $rgName 

В этом примере замените <RESOURCE_GROUP> на название вашей группы ресурсов, а <APP_NAME> на название приложения соответственно. Если какой-либо из параметров сайта или проверок возвращают значения, отличные от NULL, отметьте их.

Определение управляемых удостоверений и ролевого доступа

Перед переносом необходимо документировать, зависит ли ваше приложение от управляемого удостоверения, назначаемого системой, или назначаемых пользователем управляемых удостоверений. Кроме того, необходимо определить разрешения управления доступом на основе ролей (RBAC), предоставленные этим удостоверениям. Необходимо восстановить системно управляемое удостоверение и все назначения ролей в новом приложении. Вы сможете повторно использовать пользовательские управляемые удостоверения в новом приложении.

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

appName=<APP_NAME>
rgName=<RESOURCE_GROUP>

echo "Checking for a system-assigned managed identity..."
systemUserId=$(az functionapp identity show --name $appName --resource-group $rgName --query "principalId" -o tsv) 

if [[ -n "$systemUserId" ]]; then
echo "System-assigned identity principal ID: $systemUserId"
echo "Checking for role assignments..."
az role assignment list --assignee $systemUserId --all
else
  echo "No system-assigned identity found."
fi

echo "Checking for user-assigned managed identities..."
userIdentities=$(az functionapp identity show --name $appName --resource-group $rgName --query 'userAssignedIdentities' -o json)
if [[ "$userIdentities" != "{}" && "$userIdentities" != "null" ]]; then
  echo "$userIdentities" | jq -c 'to_entries[]' | while read -r identity; do
    echo "User-assigned identity name: $(echo "$identity" | jq -r '.key' | sed 's|.*/userAssignedIdentities/||')"
	echo "Checking for role assignments..."
    az role assignment list --assignee $(echo "$identity" | jq -r '.value.principalId') --all --output json
    echo
  done
else
  echo "No user-assigned identities found."
fi

В этом примере замените <RESOURCE_GROUP> на название вашей группы ресурсов, а <APP_NAME> на название приложения соответственно. Запишите все идентификаторы и их назначенные роли.

Определение встроенных параметров проверки подлинности

Перед переходом на Flex Consumption необходимо собрать сведения о всех встроенных конфигурациях проверки подлинности. Если вы хотите использовать одно и то же поведение проверки подлинности клиента, необходимо повторно создать их в новом приложении. Дополнительные сведения см. в статье "Проверка подлинности и авторизация" в Функциях Azure.

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

az webapp auth show Эта команда позволяет определить, настроена ли встроенная проверка подлинности в приложении-функции:

az webapp auth show --name <APP_NAME> --resource-group <RESOURCE_GROUP>

В этом примере замените <RESOURCE_GROUP> на название вашей группы ресурсов, а <APP_NAME> на название приложения соответственно. Просмотрите выходные данные, чтобы определить, включена ли проверка подлинности и какие поставщики удостоверений настроены.

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

Проверка ограничений для входящего доступа

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

  • IP-адреса или диапазоны CIDR
  • Значения приоритета
  • Тип действия (разрешить или запретить)
  • Имена правил

Эта az functionapp config access-restriction show команда возвращает список существующих ограничений доступа на основе IP-адресов:

az functionapp config access-restriction show --name <APP_NAME> --resource-group <RESOURCE_GROUP>

В этом примере замените <RESOURCE_GROUP> на название вашей группы ресурсов, а <APP_NAME> на название приложения соответственно.

При работе в плане Flex Consumption можно заново установить входящие ограничения на основе IP-адреса. Вы можете дополнительно защитить приложение, реализуя другие сетевые ограничения, такие как интеграция виртуальной сети и входящие частные конечные точки. Дополнительные сведения см. в разделе Интеграция виртуальной сети.

Получите пакет развертывания кода

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

Если у вас больше нет доступа к исходным файлам проекта, можно скачать текущий пакет развертывания из существующего приложения плана потребления в Azure. Расположение пакета развертывания зависит от того, работаете ли вы в Linux или Windows.

Приложения плана потребления в Linux поддерживают ZIP-файл развертывания в одном из следующих расположений:

  • Контейнер хранилища BLOB-объектов Azure с именем scm-releases в учетной записи хранения узла по умолчанию (AzureWebJobsStorage). Этот контейнер является источником развертывания по умолчанию для приложения плана потребления в Linux.

  • Если у вашего приложения есть WEBSITE_RUN_FROM_PACKAGE параметр, который является URL-адресом, пакет находится во внешнем доступном расположении, которое поддерживается вами. Внешний пакет должен храниться в контейнере хранилища объектов Blob с ограниченным доступом. Дополнительные сведения см. в разделе URL-адрес внешнего пакета.

Подсказка

Если ваша учетная запись хранения ограничена только доступом к управляемому удостоверению, возможно, потребуется предоставить доступ на чтение учетной записи Azure к контейнеру хранилища, добавив его в Storage Blob Data Reader роль.

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

  1. Используйте эту az functionapp config appsettings list команду, чтобы получить WEBSITE_RUN_FROM_PACKAGE параметр приложения, если он присутствует:

    az functionapp config appsettings list --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
        --query "[?name=='WEBSITE_RUN_FROM_PACKAGE'].value" -o tsv
    

    В этом примере замените <RESOURCE_GROUP> на название вашей группы ресурсов, а <APP_NAME> на название приложения соответственно. Если эта команда возвращает URL-адрес, вы можете скачать файл пакета развертывания из этого удаленного расположения и перейти к следующему разделу.

  2. WEBSITE_RUN_FROM_PACKAGE Если значение равно 1 или ничего, используйте этот скрипт для получения пакета развертывания для существующего приложения:

    appName=<APP_NAME>
    rgName=<RESOURCE_GROUP>
    
    echo "Getting the storage account connection string from app settings..."
    storageConnection=$(az functionapp config appsettings list --name $appName --resource-group $rgName \
             --query "[?name=='AzureWebJobsStorage'].value" -o tsv)
    
    echo "Getting the package name..."
    packageName=$(az storage blob list --connection-string $storageConnection --container-name scm-releases \
    --query "[0].name" -o tsv)
    
    echo "Download the package? $packageName? (Y to proceed, any other key to exit)"
    read -r answer
    if [[ "$answer" == "Y" || "$answer" == "y" ]]; then
       echo "Proceeding with download..."
       az storage blob download --connection-string $storageConnection --container-name scm-releases \
    --name $packageName --file $packageName
    else
       echo "Exiting script."
       exit 0
    fi
    

    Снова замените <RESOURCE_GROUP> на имя вашей группы ресурсов и <APP_NAME> на имя вашего приложения. Пакет .zip скачан в каталог, из которого вы выполнили команду.

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

Захват показателей производительности (необязательно)

Если вы планируете проверить повышение производительности приложения на основе миграции в план потребления Flex, необходимо (необязательно) записать тесты производительности текущего плана. Затем их можно сравнить с теми же тестами для приложения, запущенного в плане потребления Flex для сравнения.

Подсказка

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

Ниже приведены некоторые тесты для структурированного тестирования производительности.

Предложенный эталон Комментарий
Холодный запуск Измеряйте время от первого запроса к первому ответу после периода простоя.
Пропускная способность Измеряйте максимальное количество запросов в секунду с помощью средств нагрузочного тестирования , чтобы определить, как приложение обрабатывает одновременные запросы.
Задержка Отслеживайте время отклика P50, P95 и P99 в различных условиях нагрузки. Эти метрики можно отслеживать в Application Insights.

Этот запрос Kusto можно использовать для просмотра предлагаемого времени отклика задержки в Application Insights:

requests
| where timestamp > ago(1d)
| summarize percentiles(duration, 50, 95, 99) by bin(timestamp, 1h)
| render timechart

Шаги переноса

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

Шаг 1. Окончательный обзор плана

Прежде чем продолжить процесс миграции, выполните следующие последние подготовительные действия:

  • Просмотрите все собранные сведения: просмотрите все заметки, сведения о конфигурации и параметры приложения, которые вы задокументировали в предыдущих разделах оценки и предварительной подготовки. Если что-либо неясно, повторно выполните команды Azure CLI или получите информацию с портала.

  • Определите план миграции: на основе результатов создайте контрольный список для миграции, который выделяет:

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

Тщательный окончательный обзор помогает обеспечить более гладкий процесс миграции и свести к минимуму риск пропуска важных конфигураций.

Шаг 2. Создание приложения в плане потребления Flex

Существует несколько способов создать приложение-функцию в плане Flex Consumption вместе с другими необходимыми ресурсами Azure.

Параметр "Создать" Справочные статьи
Azure CLI (Интерфейс командной строки для Azure) Создание приложения Flex Consumption
Портал Azure Создание приложения-функции на портале Azure
Инфраструктура как код Шаблон ARM
azd
Бицепс
Terraform
Visual Studio Code Развертывание Visual Studio Code
Визуальная студия Развертывание Visual Studio

Подсказка

По возможности следует использовать идентификатор Microsoft Entra для проверки подлинности вместо строк подключения, содержащих общие ключи. Использование управляемых удостоверений — это рекомендация, которая повышает безопасность, устраняя необходимость хранения общих секретов непосредственно в параметрах приложения. Если ваше исходное приложение использовало строки подключения, план Flex Consumption разработан для поддержки управляемых идентификаторов. Большинство этих ссылок показывают, как включить управляемые удостоверения в вашем функциональном приложении.

Шаг 3. Применение параметров перенесенного приложения в новом приложении

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

Это важно

Не все параметры приложения плана потребления поддерживаются при выполнении в плане потребления Flex. Дополнительные сведения см. в разделе о прекращении использования плана потребления Flex.

Запустите этот скрипт, выполняющий следующие задачи:

  1. Получает параметры приложения из старого приложения, игнорируя параметры, которые не применяются в плане потребления Flex или уже существуют в новом приложении.
  2. Записывает собранные параметры локально в временный файл.
  3. Применяет параметры из файла к новому приложению.
  4. Удаляет временный файл.
sourceAppName=<SOURCE_APP_NAME>
destAppName=<DESTINATION_APP_NAME>
rgName=<RESOURCE_GROUP>

echo "Getting app settings from the old app..."
app_settings=$(az functionapp config appsettings list --name $sourceAppName --resource-group $rgName)

# Filter out settings that don't apply to Flex Consumption apps or that will already have been created
filtered_settings=$(echo "$app_settings" | jq 'map(select(
  (.name | ascii_downcase) != "website_use_placeholder_dotnetisolated" and
  (.name | ascii_downcase | startswith("azurewebjobsstorage") | not) and
  (.name | ascii_downcase) != "website_mount_enabled" and
  (.name | ascii_downcase) != "enable_oryx_build" and
  (.name | ascii_downcase) != "functions_extension_version" and
  (.name | ascii_downcase) != "functions_worker_runtime" and
  (.name | ascii_downcase) != "functions_worker_runtime_version" and
  (.name | ascii_downcase) != "functions_max_http_concurrency" and
  (.name | ascii_downcase) != "functions_worker_process_count" and
  (.name | ascii_downcase) != "functions_worker_dynamic_concurrency_enabled" and
  (.name | ascii_downcase) != "scm_do_build_during_deployment" and
  (.name | ascii_downcase) != "website_contentazurefileconnectionstring" and
  (.name | ascii_downcase) != "website_contentovervnet" and
  (.name | ascii_downcase) != "website_contentshare" and
  (.name | ascii_downcase) != "website_dns_server" and
  (.name | ascii_downcase) != "website_max_dynamic_application_scale_out" and
  (.name | ascii_downcase) != "website_node_default_version" and
  (.name | ascii_downcase) != "website_run_from_package" and
  (.name | ascii_downcase) != "website_skip_contentshare_validation" and
  (.name | ascii_downcase) != "website_vnet_route_all" and
  (.name | ascii_downcase) != "applicationinsights_connection_string"
))')

echo "Settings to migrate..."
echo "$filtered_settings"

echo "Writing settings to a local a local file (app_settings_filtered.json)..."
echo "$filtered_settings" > app_settings_filtered.json

echo "Applying settings to the new app..."
output=$(az functionapp config appsettings set --name $destAppName --resource-group $rgName --settings @app_settings_filtered.json)

echo "Deleting the temporary settings file..."
rm -rf app_settings_filtered.json  

echo "Current app settings in the new app..."
az functionapp config appsettings list --name $destAppName --resource-group $rgName 

В этом примере замените `<RESOURCE_GROUP>`, `<SOURCE_APP_NAME>` и `<DEST_APP_NAME>` на имя вашей группы ресурсов и старые и новые имена приложений соответственно. Этот сценарий предполагает, что оба приложения находятся в одной группе ресурсов.

Шаг 4. Применение других конфигураций приложений

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

В этом сценарии задайте значение для любого набора конфигурации в исходном приложении и закомментируйте все команды для любой конфигурации, не заданной (null):

appName=<APP_NAME>
rgName=<RESOURCE_GROUP>
http20Setting=<YOUR_HTTP_20_SETTING>
minTlsVersion=<YOUR_TLS_VERSION>
minTlsCipher=<YOUR_TLS_CIPHER>
httpsOnly=<YOUR_HTTPS_ONLY_SETTING>
certEnabled=<CLIENT_CERT_ENABLED>
certMode=<YOUR_CLIENT_CERT_MODE>
certExPaths=<CERT_EXCLUSION_PATHS>
scmAllowBasicAuth=<ALLOW_SCM_BASIC_AUTH>

# Apply HTTP version and minimum TLS settings
az functionapp config set --name $appName --resource-group $rgName --http20-enabled $http20Setting  
az functionapp config set --name $appName --resource-group $rgName --min-tls-version $minTlsVersion

# Apply the HTTPS-only setting
az functionapp update --name $appName --resource-group $rgName --set HttpsOnly=$httpsOnly

# Apply incoming client cert settings
az functionapp update --name $appName --resource-group $rgName --set clientCertEnabled=$certEnabled
az functionapp update --name $appName --resource-group $rgName --set clientCertMode=$certMode
az functionapp update --name $appName --resource-group $rgName --set clientCertExclusionPaths=$certExPaths

# Apply the TLS cipher suite setting
az functionapp update --name $appName --resource-group $rgName --set minTlsCipherSuite=$minTlsCipher

# Apply the allow scm basic auth configuration
az resource update --resource-group $rgName --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
	--parent sites/$appName --set properties.allow=$scmAllowBasicAuth

В этом примере замените <RESOURCE_GROUP> и <APP_NAME> на имена вашей группы ресурсов и приложения-функции соответственно. Кроме того, замените заполнители любых определений переменных для существующих параметров, которые вы хотите повторно создать в новом приложении, и закомментировать все null параметры.

Шаг 5. Настройка параметров масштабирования и параллелизма

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

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

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

Максимальное число экземпляров по умолчанию равно 100, и оно должно иметь значение 40 или выше.

Используйте эту az functionapp scale config set команду, чтобы установить максимальное значение горизонтального масштабирования.

az functionapp scale config set --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
    --maximum-instance-count <MAX_SCALE_SETTING>

В этом примере замените <RESOURCE_GROUP> и <APP_NAME> на имена вашей группы ресурсов и приложения-функции соответственно. Замените <MAX_SCALE_SETTING> заданным максимальным значением масштабирования.

Шаг 6. Настройка подключений к хранилищу

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

Используйте эту az webapp config storage-account add команду для повторного подключения каждого тома хранилища в вашем новом приложении.

az webapp config storage-account add --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
  --custom-id <MOUNT_NAME> --storage-type AzureFiles --account-name <STORAGE_ACCOUNT> \
  --share-name <STORAGE_SHARE_NAME> --access-key <ACCESS_KEY> --mount-path <MOUNT_PATH>

В этом примере сделайте эти замены на основе сведений, которые вы задокументировали во время предварительной подготовки:

Замещающее поле Описание
<APP_NAME> Имя приложения-функции.
<RESOURCE_GROUP> Имя группы ресурсов.
<STORAGE_ACCOUNT> Имя учетной записи хранения для подключения.
<ACCESS_KEY> Ключ используется для доступа к учетной записи хранилища и необходим только при использовании доступа на основе ключей.
<STORAGE_SHARE_NAME> Имя общей папки файлов Azure в учетной записи хранения.
<MOUNT_NAME> Имя, используемое для подключенного ресурса общего доступа в приложении.
<MOUNT_PATH> Путь к подключенной общей папке в приложении.

Повторите этот шаг для повторного подключения к каждой общей папке.

Шаг 7. Настройка любых пользовательских доменов и доступа CORS

Если у исходного приложения есть какие-либо связанные пользовательские домены или какие-либо определенные параметры CORS, создайте их в новом приложении. Дополнительные сведения о пользовательских доменах см. в статье "Настройка существующего личного домена в службе приложений Azure".

  1. Используйте эту az functionapp config hostname add команду для привязки заново любых настраиваемых сопоставлений домена к вашему приложению.

    az functionapp config hostname add --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
        --hostname <CUSTOM_DOMAIN>
    

    В этом примере замените <RESOURCE_GROUP> и <APP_NAME> на имена вашей группы ресурсов и приложения-функции соответственно. Замените <CUSTOM_DOMAIN> на ваше личное доменное имя.

  2. Используйте эту az functionapp cors add команду для замены всех параметров CORS:

    az functionapp cors add --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
        --allowed-origins <ALLOWED_ORIGIN_1> <ALLOWED_ORIGIN_2> <ALLOWED_ORIGIN_N>
    

    В этом примере замените <RESOURCE_GROUP> и <APP_NAME> на имена вашей группы ресурсов и приложения-функции соответственно. Замените <ALLOWED_ORIGIN_*> допустимыми источниками.

Шаг 8. Настройка управляемых удостоверений и назначение ролей

Конфигурация управляемых идентификаторов в новом приложении зависит от типа управляемого идентификатора.

Тип управляемого удостоверения Создать идентичность Назначения ролей
Назначено пользователем Необязательно Вы можете продолжать использовать те же управляемые удостоверения, назначаемые пользователем, с новым приложением. Эти идентификаторы необходимо переназначить в приложении Flex Consumption и проверить, что они по-прежнему имеют правильные назначения ролей в удаленных службах. Если вы решили создать новые аккаунты для нового приложения, необходимо присвоить им те же роли, что и существующим аккаунтам.
Назначаемое системой Да Так как каждое приложение-функция имеет собственное управляемое удостоверение, назначаемое системой, необходимо включить управляемое удостоверение, назначаемое системой, в новом приложении и переназначить те же роли, что и в исходном приложении.

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

Подсказка

Если исходное приложение использовало строки подключения или другие общие секреты для проверки подлинности, это отличная возможность улучшить безопасность приложения, переключившись на использование проверки подлинности Идентификатора Microsoft Entra с управляемыми удостоверениями. Дополнительные сведения см. в руководстве: Создание функционального приложения, которое подключается к службам Azure с помощью идентификационных данных вместо секретов.

  1. Используйте эту az functionapp identity assign команду, чтобы включить управляемое удостоверение, назначаемое системой, в новом приложении:

    az functionapp identity assign --name <APP_NAME> --resource-group <RESOURCE_GROUP>
    

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

  2. Используйте этот скрипт, чтобы получить идентификатор основного удостоверения, назначенного системой, и добавить его в необходимые роли:

    # Get the principal ID of the system identity
    principalId=$(az functionapp identity show --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
        --query principalId -o tsv)
    
    # Assign a role in a specific resource (scope) to the system identity
    az role assignment create --assignee $principalId --role "<ROLE_NAME>" --scope "<RESOURCE_ID>"
    

    В этом примере замените <RESOURCE_GROUP> и <APP_NAME> на имена вашей группы ресурсов и приложения-функции соответственно. Замените <ROLE_NAME> на имя роли и <RESOURCE_ID> на конкретный ресурс, который вы захватили из исходного приложения.

  3. Повторите предыдущие команды для каждой роли, необходимой для нового приложения.

Шаг 9. Настройка встроенной проверки подлинности

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

На основе собранных ранее сведений используйте az webapp auth update команду для повторного создания каждой встроенной регистрации проверки подлинности, необходимой для приложения.

Шаг 10. Настройка ограничений доступа к сети

Если у исходного приложения есть какие-либо ограничения на входящий доступ на основе IP-адресов, вы можете воссоздать все те же правила входящего доступа, которые вы хотите сохранить в новом приложении.

Подсказка

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

Используйте эту az functionapp config access-restriction add команду для каждого ограничения доступа к IP-адресам, который вы хотите реплицировать в новом приложении:

az functionapp config access-restriction add --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
  --rule-name <RULE_NAME> --action Deny --ip-address <IP_ADDRESS> --priority <PRIORITY>

В этом примере замените эти заполнители значениями из исходного приложения:

Замещающее поле Ценность
<APP_NAME> Имя приложения-функции.
<RESOURCE_GROUP> Ваша группа ресурсов.
<RULE_NAME> Дружественное имя для правила IP.
<Priority> Приоритет исключения.
<IP_Address> IP-адрес, который требуется исключить.

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

Шаг 11. Включение мониторинга

Прежде чем приступить к новому приложению в плане потребления Flex, убедитесь, что Application Insights включена. Настройка Application Insights помогает устранить любые проблемы, которые могут возникнуть во время развертывания кода и запуска.

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

Если вы планируете сравнить это новое приложение с текущим приложением, убедитесь, что схема также собирает необходимые тесты для сравнения. Дополнительные сведения см. в разделе "Настройка мониторинга".

Шаг 12. Развертывание кода вашего приложения в новое приложение Flex Consumption

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

Осторожность

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

Функции предоставляют несколько способов развертывания вашего кода: либо напрямую из проекта кода, либо в виде готового пакета для развертывания.

Подсказка

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

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

Вы также можете создать новый рабочий процесс непрерывного развертывания для нового приложения. Дополнительные сведения см. в статье "Непрерывное развертывание функций Azure"

Задачи после миграции

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

Проверка основных функциональных возможностей

  1. Убедитесь, что новое приложение запущено в плане потребления Flex:

    Используйте эту az functionapp show команду, чтобы просмотреть информацию о плане размещения:

    az functionapp show --name <APP_NAME> --resource-group <RESOURCE_GROUP> --query "serverFarmId"
    

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

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

Снятие эталонов производительности

Используя новое приложение, вы можете выполнять те же тесты производительности, которые вы собрали из исходного приложения, например:

Предложенный эталон Комментарий
Холодный запуск Измеряйте время от первого запроса к первому ответу после периода простоя.
Пропускная способность Измеряйте максимальное количество запросов в секунду с помощью средств нагрузочного тестирования , чтобы определить, как приложение обрабатывает одновременные запросы.
Задержка Отслеживайте время отклика P50, P95 и P99 в различных условиях нагрузки. Эти метрики можно отслеживать в Application Insights.

Этот запрос Kusto можно использовать для просмотра предлагаемого времени отклика задержки в Application Insights:

requests
| where timestamp > ago(1d)
| summarize percentiles(duration, 50, 95, 99) by bin(timestamp, 1h)
| render timechart

Замечание

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

Создание пользовательских панелей мониторинга

Метрики Azure Monitor и Application Insights позволяют создавать панели мониторинга на портале Azure , отображающие диаграммы как из метрик платформы, так и журналов среды выполнения и аналитики.

Рассмотрите возможность настройки панелей мониторинга и оповещений на ключевых метриках на портале Azure. Дополнительные сведения см. в статье "Мониторинг приложения в Azure".

Уточнение параметров плана

Фактические улучшения производительности и последствия миграции могут отличаться в зависимости от рабочих нагрузок, относящихся к приложению, и конфигурации. План потребления Flex предоставляет несколько параметров, которые можно настроить для уточнения производительности приложения. Может потребоваться внести корректировки, чтобы более точно соответствовать поведению исходного приложения или сбалансировать затраты и производительность. Дополнительные сведения см. в разделе Тонкая настройка приложения в статье "Использование Flex".

Удаление исходного приложения (необязательно)

После тщательного тестирования нового приложения-функции Flex Consumption и проверки того, что все работает должным образом, может потребоваться очистить ресурсы, чтобы избежать ненужных затрат. Несмотря на то что триггеры в исходном приложении, вероятно, уже отключены, вы можете ждать несколько дней или даже недель, прежде чем полностью удалить исходное приложение. Эта задержка, которая зависит от шаблонов использования приложения, гарантирует правильность тестирования всех сценариев, включая редкие. Только после того, как вы удовлетворены результатами миграции, следует продолжить удаление исходного приложения-функции.

Это важно

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

az functionapp delete Используйте команду для удаления исходного приложения-функции:

az functionapp delete --name <ORIGINAL_APP_NAME> --resource-group <RESOURCE_GROUP>

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

Стратегии устранения неполадок и восстановления

Несмотря на тщательное планирование, могут возникнуть проблемы с миграцией. Вот как устранить потенциальные проблемы во время миграции:

Проблема Решение
Проблемы с производительностью холодного запуска • Просмотр параметров параллелизма
• Проверка отсутствующих зависимостей
Отсутствующие привязки • Проверка пакетов расширений
• Обновление конфигураций привязки
Ошибки разрешений • Проверка назначенных задач и идентификационных данных и разрешений ролей
Проблемы, связанные с подключением к сети • Проверка ограничений доступа и параметров сети
Отсутствует аналитика приложений • Повторное создание подключения Application Insights
Не удается запустить приложение См . общие инструкции по устранению неполадок
Триггеры не обрабатывают события См . общие инструкции по устранению неполадок

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

Общие действия по устранению неполадок

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

  1. На новой странице приложения на портале Azure выберите "Диагностика и решение проблем " в левой области страницы приложения. Выберите «Доступность и производительность» и просмотрите детектор «сбоев в работе приложения-функции или ошибок отчетности». Дополнительные сведения см. в разделе "Диагностика функций Azure".

  2. На странице приложения выберите "Мониторинг>Application Insights>" View Application Insights data, а затем выберите "Исследовать>сбои" и проверьте наличие событий сбоя.

  3. Выберите Мониторинг>Журналы и выполните этот запрос Kusto, чтобы проверить эти таблицы на наличие ошибок.

    traces
        | where severityLevel == 3
        | where cloud_RoleName == "<APP_NAME>"
        | where timestamp > ago(1d)
        | project timestamp, message, operation_Name, customDimensions
        | order by timestamp desc
    

    В этих запросах замените <APP_NAME> на имя нового приложения. Эти запросы проверяют наличие ошибок за прошлый день (where timestamp > ago(1d)).

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

  5. Выберите Параметры>удостоверений и дважды проверьте наличие ожидаемых удостоверений и их назначение правильным ролям.

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

Шаги отката для критически важных рабочих приложений

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

  1. Если исходное приложение было остановлено, перезапустите его:

    Используйте эту az functionapp start команду, чтобы перезапустить исходное приложение-функцию:

    az functionapp delete --name <ORIGINAL_APP_NAME> --resource-group <RESOURCE_GROUP>
    
  2. Если вы создали новые очереди, разделы и контейнеры, убедитесь, что клиенты перенаправляются обратно в исходные ресурсы.

  3. Если вы изменили DNS или личные домены, измените эти изменения, чтобы указать на исходное приложение.

Предоставление отзывов

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