Стратегии обновления сайта в Flex Consumption

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

План потребления Flex в настоящее время поддерживает следующие стратегии обновления:

• Повторное создание: Функции перезапускают все активные экземпляры после замены вашего кода последней версией. Такой подход может привести к краткому простою во время перезапуска экземпляров и сохранения поведения по умолчанию из других планов размещения функций Azure.
• Последовательное обновление (предварительная версия): обеспечивает развертывание без простоя путем очистки и замены экземпляров в пакетах. Исполняющиеся процессы завершаются естественным образом без принудительной остановки.

Сравнение стратегий

В этой таблице сравниваются две стратегии обновления сайта:

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

В этой таблице сравнивается процесс обновления двух стратегий:

В этой таблице сравниваются ключевые характеристики двух стратегий:

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

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

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

Настройка стратегии обновления

Вы можете задать стратегию обновления для приложения с помощью SiteUpdateStrategy параметра сайта, который является дочерним functionAppConfig. По умолчанию свойство SiteUpdateStrategy.type имеет значение Recreate. В настоящее время только шаблоны Bicep и ARM с версией 2023-12-01 API или более поздней поддерживают изменение этого свойства.

functionAppConfig: {
  ...
  siteUpdateStrategy: {
    type: 'RollingUpdate'
  }
  ...
}

"functionAppConfig": {
  ...
  "siteUpdateStrategy": {
    "type": "RollingUpdate"
  }
  ...
}

Изменения стратегии обновления сайта вступили в силу при следующем обновлении сайта. Например, изменение type с Recreate на RollingUpdate использует стратегию повторного создания для этого обновления. Все последующие обновления сайта затем используют постепенные обновления.

Мониторинг обновлений сайта

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

Мониторинг хода выполнения поэтапного обновления

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

// Rolling update completion check
let deploymentStart = datetime('2025-10-30T19:00:00Z'); // Set to your deployment start time
let checkInterval = 10s; // How often you run this query
let buffer = 30s; // Safety buffer for instance detection
//
// Get original instances (active before deployment)
let originalInstances = 
    traces
    | where timestamp between ((deploymentStart - buffer) .. deploymentStart)
    | where cloud_RoleInstance != ""
    | summarize by InstanceId = cloud_RoleInstance;
//
// Get currently active instances
let currentInstances = 
    traces
    | where timestamp >= now() - checkInterval
    | where cloud_RoleInstance != ""
    | summarize by InstanceId = cloud_RoleInstance;
//
// Check completion status
currentInstances
| join kind=leftouter (originalInstances | extend IsOriginal = true) on InstanceId
| extend IsOriginal = isnotnull(IsOriginal)
| summarize 
    OriginalStillActiveInstances = make_set_if(InstanceId, IsOriginal),
    NewInstances = make_set_if(InstanceId, not(IsOriginal)),
    OriginalStillActiveCount = countif(IsOriginal),
    NewCount = countif(not(IsOriginal)),
    TotalOriginal = toscalar(originalInstances | count)
| extend 
    RollingUpdateComplete = iff(OriginalStillActiveCount == 0, "YES", "NO"),
    PercentComplete = round(100.0 * (1.0 - todouble(OriginalStillActiveCount) / todouble(TotalOriginal)), 1)
| project RollingUpdateComplete, PercentComplete, OriginalStillActiveCount, NewCount

Как использовать этот запрос для оценки:

1. Вставьте этот запрос в панель "Журналы" ресурса Application Insights, связанного с вашим функциональным приложением.
2. Установите deploymentStart на метку времени, когда обновление вашего сайта возвращает успешный результат.
3. Периодически выполняйте запрос, чтобы оценить ход выполнения. Установите интервал опроса как минимум равным среднему времени выполнения функции и убедитесь, что переменная checkInterval в запросе соответствует этой частоте опроса.
4. Запрос возвращает приблизительные значения:
   • RollingUpdateComplete: лучше всего оценить, заменяются ли все исходные экземпляры.
   • PercentComplete: предполагаемый процент исходных экземпляров, которые заменяются
   • OriginalStillActiveCount: предполагаемое количество исходных экземпляров, которые по-прежнему выполняются
   • NewCount: число новых экземпляров, активных в настоящее время

Помните об этих ограничениях при использовании этих запросов:

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

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

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

Часто задаваемые вопросы

Я привык к слотам развертывания для обновлений без простоев. Чем отличаются поэтапные обновления?

• В отличие от слотов развертывания, последовательные обновления не требуют дополнительной инфраструктуры. Установите siteUpdateStrategy.type в "RollingUpdate" для развертывания без простоя.
• Постепенные обновления сохраняют текущие операции, а слоты развертывания завершают их во время переключений. Некоторые свойства сайта и параметры прилипания нельзя переключить и требовать непосредственного изменения рабочего слота.
• В отличие от слотов развертывания, последовательные обновления не предоставляют отдельную среду для тестирования изменений или маршрутизации процента динамического трафика. Если вам нужны эти функции, используйте план, поддерживающий слоты развертывания, такие как Elastic Premium, или управляйте отдельными приложениями Flex Consumption за диспетчером трафика.

Как откатить обновление сайта?

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

Как обрабатываются триггеры таймера?

• Триггеры таймера сохраняют свою синглтон природу. После того как таймерная функция помечается для отключения, новые функции таймера выполняются в последней версии.

Я вижу ошибки среды выполнения во время последовательного обновления... что пошло не так?

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

Дальнейшие шаги

• Дополнительные сведения о плане потребления Flex
• Узнайте больше о различиях развертываний в Flex Consumption
• Узнайте, как писать шаблоны инфраструктуры как кода