Strategie aktualizacji witryny w rozwiązaniu Flex Consumption

Podczas hostowania swojej aplikacji za pomocą Azure Functions w planie Flex Consumption, można kontrolować sposób wdrażania aktualizacji na działające wystąpienia. Aktualizacja witryny odbywa się za każdym razem, gdy wdrażasz kod, modyfikujesz ustawienia aplikacji lub zmieniasz inne właściwości konfiguracji. Plan Flex Consumption udostępnia ustawienie konfiguracji (SiteUpdateStrategy), którego można użyć do określenia, czy podczas tych aktualizacji w aplikacji funkcji występuje przestój oraz w jaki sposób obsługiwane są uruchomienia będące w toku.

Plan Flex Consumption obecnie obsługuje następujące strategie aktualizacji:

• Odtwórz: Powoduje ponowne uruchomienie wszystkich działających instancji po zaktualizowaniu aplikacji o najnowsze zmiany. Takie podejście może spowodować krótki przestój podczas ponownego uruchamiania wystąpień i zachowuje domyślne zachowanie z innych planów hostingu Azure Functions.
• Aktualizacja stopniowa: zapewnia wdrożenia bez przestojów przez opróżnianie i zastępowanie wystąpień w partiach. Aktualnie wykonywane procesy przebiegają naturalnie bez przymusowego zakończenia.

Porównanie strategii

W tej tabeli porównaliśmy dwie strategie aktualizacji witryny:

Zachowania strategii aktualizacji

W tej tabeli porównaliśmy proces aktualizacji dwóch strategii:

W tej tabeli porównaliśmy kluczowe cechy dwóch strategii:

Zagadnienia dotyczące strategii aktualizacji stopniowej

Podczas korzystania ze strategii aktualizacji stopniowej należy pamiętać o tych bieżących zachowaniach i ograniczeniach.

• Parametry zarządzane przez platformę: platforma kontroluje parametry (takie jak liczba partii, instancje na partię, liczba cykli oraz interwały opróżniania), które określają zachowania aktualizacji stopniowej. Te parametry mogą ulec zmianie, aby zoptymalizować wydajność i niezawodność.
• Zmiana strategii nie ma żadnego efektu w regionach GA: W regionach, w których aktualizacje stopniowe są ogólnie dostępne, zmiana siteUpdateStrategy.type sama w sobie nie wyzwala aktualizacji witryny. Możesz bezpiecznie zaktualizować strategię przed upływem czasu i zastosować ją do następnego kodu lub wdrożenia konfiguracji. W regionach, w których aktualizacje stopniowe są nadal wdrażane, zmiana strategii jest traktowana jak każda inna zmiana konfiguracji i wyzwala aktualizację witryny korzystającą z poprzedniej strategii; nowa strategia ma zastosowanie od następnego wdrożenia.
• Brak monitorowania w czasie rzeczywistym: obecnie nie ma wglądu w liczbę wystąpień opróżniania, liczbę partii lub bieżące wartości procentowe postępu.
• Brak sygnału ukończenia: można jednak monitorować dzienniki wystąpień, aby oszacować, kiedy aktualizacja zostanie ukończona.
• Scenariusze z pojedynczym wystąpieniem: aplikacje działające w jednym wystąpieniu doświadczają krótkiego przestoju podobnego do ponownego uruchomienia, choć trwające działania są kontynuowane.
• Durable Functions: Ponieważ mieszanie wersji podczas aktualizacji może spowodować nieoczekiwane zachowanie w orkiestracji Durable, użyj jawnej strategii dopasowania wersji orchestracji.
• Infrastruktura jako kod: jednoczesne wdrażanie kodu i zmian konfiguracji powoduje wiele stopniowych aktualizacji, które mogą na siebie zachodzić.
• Zgodność z poprzednimi wersjami: upewnij się, że zmiany działają z poprzednią wersją w okresie przejściowym aktualizacji stopniowej.

Konfigurowanie strategii aktualizacji

Strategię aktualizacji dla aplikacji można ustawić przy użyciu SiteUpdateStrategy ustawienia witryny, które jest elementem podrzędnym functionAppConfig. Domyślnie SiteUpdateStrategy.type jest ustawiona na wartość Recreate. To ustawienie można skonfigurować przy użyciu Azure CLI 2.87.0 lub nowszego, Bicep lub szablonów usługi ARM z wersją interfejsu API 2023-12-01 lub nowszą.

az functionapp update-strategy config set \
  --name MyFunctionApp \
  --resource-group MyResourceGroup \
  --type RollingUpdate

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

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

Monitorowanie aktualizacji strony

Nie ma wbudowanego sygnału informującego o zakończeniu aktualizacji witryny. Można używać zapytań KQL w usłudze Application Insights jako metody szacowania z najwyższym możliwym przybliżeniem postępu aktualizacji ciągłych.

Monitorowanie postępu aktualizacji przebiegającej etapowo

Te zapytania KQL zapewniają w miarę dokładne oszacowanie postępu aktualizacji stopniowej przez śledzenie zmian wystąpień w logach Application Insights. Takie podejście ma znaczące ograniczenia i nie należy polegać na automatyzacji produkcji:

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

Jak użyć tego zapytania do szacowania:

1. Wklej to zapytanie w bloku Dzienniki zasobu usługi Application Insights skojarzonego z aplikacją funkcji.
2. Ustaw deploymentStart na znacznik czasu, w którym aktualizacja witryny zakończy się sukcesem.
3. Okresowo uruchamiaj zapytanie, aby oszacować postęp. Ustaw interwał sondowania na wartość co najmniej tak długo, jak średni czas wykonywania funkcji, i upewnij się, że zmienna checkInterval w zapytaniu jest zgodna z tą częstotliwością sondowania.
4. Zapytanie zwraca przybliżone wartości:

RollingUpdateComplete: Najlepsze oszacowanie, czy wszystkie oryginalne wystąpienia są zastępowanePercentComplete: Szacowany procent oryginalnych wystąpień, które są zastępowaneOriginalStillActiveCount: Szacowana liczba oryginalnych wystąpień nadal uruchomionychNewCount: Liczba aktualnie aktywnych wystąpień

Podczas korzystania z tych zapytań należy pamiętać o następujących ograniczeniach:

1. Luka czasowa: deploymentStart czas oznacza, kiedy aktualizacja witryny osiągnie sukces, ale rzeczywista aktualizacja ciągła niekoniecznie uruchomi się natychmiast. Podczas tej przerwy wszystkie zdarzenia zwiększenia skali udostępniają wystąpienia uruchamiające oryginalną wersję. Ponieważ zapytanie śledzi tylko wystąpienia aktywne w deploymentStart, nie monitoruje tych nowych instancji oryginalnej wersji, co potencjalnie powoduje fałszywe sygnały ukończenia.
2. Wykrywanie oparte na dzienniku: takie podejście opiera się na dziennikach aplikacji w celu wnioskowania stanu wystąpienia, a nie bezpośredniego wykonywania zapytań dotyczących stanu wystąpienia. Wystąpienia mogą być uruchomione, ale nie są aktywnie rejestrowane, co prowadzi do fałszywych sygnałów ukończenia, gdy oryginalne wystąpienia są nadal aktywne, ale nie emitują dzienników w checkInterval oknie.

Zalecenie dotyczące środowiska produkcyjnego: użyj aktualizacji rotacyjnych, gdy wdrożenia bez przestojów są kluczowe. Upewnij się, że w potokach wdrażania nie ma konieczności oczekiwania na ukończenie aktualizacji przed przejściem do kolejnych kroków. Użyj odtworzenia, gdy potrzebujesz szybszego i bardziej przewidywalnego czasu aktualizacji oraz możesz tolerować krótki przestój.

Często zadawane pytania

Poniżej przedstawiono kilka typowych pytań dotyczących strategii aktualizacji witryny.

Jak aktualizacje stopniowe różnią się od miejsc wdrożenia?

W przeciwieństwie do miejsc wdrożenia aktualizacje stopniowe nie wymagają dodatkowej infrastruktury. Ustaw siteUpdateStrategy.type wartość na "RollingUpdate" dla wdrożeń bez przestojów.

Aktualizacje bez przestojów zachowują bieżące wykonanie, a sloty wdrożeniowe kończą je podczas zamian. Niektórych właściwości witryny i ustawień trwałych nie można zamienić i wymagają bezpośredniej modyfikacji wolumenu produkcji.

W przeciwieństwie do miejsc wdrożenia, aktualizacje etapowe nie zapewniają oddzielnego środowiska do testowania zmian kanarkowych ani przekierowania części ruchu na żywo. Jeśli potrzebujesz tych funkcji, użyj planu obsługującego miejsca wdrożenia, takiego jak Elastic Premium, lub zarządzaj oddzielnymi aplikacjami Flex Consumption za pomocą usługi Traffic Manager.

Jak wycofać aktualizację witryny?

Obecnie nie ma funkcji wycofywania aktualizacji witryny. Jeśli konieczne jest wycofanie, zainicjuj inną aktualizację witryny przy użyciu poprzedniego stanu kodu lub konfiguracji. Pełny przewodnik znajdziesz w artykule Odzyskiwanie po nieudanym wdrożeniu planu Flex Consumption.

Jak obsługiwane są wyzwalacze czasomierza?

Wyzwalacze czasomierza utrzymują swój pojedynczy charakter. Po oznaczeniu aplikacji funkcji wyzwalanej zegarem do opróżniania nowe funkcje są uruchamiane w najnowszej wersji.

Występują błędy środowiska uruchomieniowego podczas aktualizacji stopniowej

Jeśli nie można uruchomić nowych wystąpień lub napotkać błędy środowiska uruchomieniowego, problem prawdopodobnie występuje w kodzie aplikacji, zależnościach, ustawieniach konfiguracji lub zmodyfikowanych zmiennych środowiskowych.

Aby rozwiązać ten problem, ponownie wdróż ostatnią znaną wersję w dobrej kondycji, aby przywrócić środowisko uruchomieniowe. Następnie przetestuj proponowane zmiany w środowisku deweloperskim lub testowym przed ponowną próbą. Przejrzyj dzienniki błędów, aby zidentyfikować konkretną zmianę, która spowodowała problem.

Dalsze kroki

• Dowiedz się więcej o planie Flex Consumption
• Dowiedz się więcej o różnicach wdrożeń w rozwiązaniu Flex Consumption
• Dowiedz się, jak pisać szablony infrastruktury jako kodu