Przenoszenie usługi Azure Container Apps do innego regionu

W tym artykule opisano sposób przenoszenia obciążenia usługi Azure Container Apps do innego regionu świadczenia usługi Azure przez ponowne utworzenie środowiska zarządzanego i aplikacji kontenera w regionie docelowym. Proces obejmuje eksportowanie konfiguracji aplikacji, ponowne wdrażanie zasobów, weryfikowanie wdrożenia i czyszczenie zasobów w regionie źródłowym.

Wymagania wstępne

Przed rozpoczęciem sprawdź, czy spełnione są następujące wymagania:

• Usługa Azure Container Apps jest dostępna w regionie docelowym.
• Region docelowy obsługuje te same funkcje, profile obciążeń i opcje sieciowe używane w regionie źródłowym.
• Masz wystarczający limit przydziału w regionie docelowym dla zasobów, które planujesz wdrożyć.
• Masz następujące uprawnienia zarówno w subskrypcjach źródłowych, jak i docelowych:
  • Właściciel lub Współautor w grupie zasobów.
  • Container Apps Contributor (zalecany). Ta rola obejmuje uprawnienia z symbolami wieloznacznymi, które przyznają dostęp do wartości wpisów tajnych w usłudze Container Apps. Aby uzyskać węższy dostęp, zobacz Uprawnienia do zarządzania sekretami.
• Obrazy kontenerów znajdują się w rejestrze dostępnym z regionu docelowego (na przykład w usłudze Azure Container Registry lub obsługiwanym rejestrze zewnętrznym).
• Zależne zasoby platformy Azure, takie jak Key Vault, konta magazynu, bazy danych, sieci wirtualne i usługi przesyłania wiadomości, są już dostępne w regionie docelowym lub mają plan ponownego wdrażania.

az acr replication create --registry <REGISTRY_NAME> --location <TARGET_REGION>

Omówienie wymagań dotyczących przestojów

Usługa Azure Container Apps nie obsługuje migracji regionów na żywo. Przestój jest głównie spowodowany propagacją DNS i zmianami routingu ruchu podczas przełączenia. Aby zminimalizować wpływ:

1. Najpierw wdróż i zweryfikuj aplikację kontenera w regionie docelowym.
2. Obniż wartości czasu wygaśnięcia DNS z wyprzedzeniem (na przykład do 60 sekund), aby zmiany routingu szybko się rozchodziły.
3. Przekieruj ruch produkcyjny do nowego punktu końcowego dopiero po zakończeniu walidacji.
4. Utrzymuj działanie źródłowej aplikacji kontenera, dopóki nie potwierdzisz, że wdrożenie docelowe działa poprawnie.

Przygotowywanie

Aby przygotować się do relokacji, wyeksportuj konfigurację źródła i przejrzyj wszystkie ustawienia specyficzne dla regionu.

Identyfikowanie zależności

Następujące zasoby zależne muszą istnieć w regionie docelowym przed przełączeniem:

• Azure Key Vault
• Konta magazynu
• Bazy danych i usługi obsługi komunikatów (takie jak Azure Service Bus, Azure Cosmos DB)
• Sieci wirtualne, podsieci i prywatne punkty końcowe
• Sieciowe grupy zabezpieczeń i trasy zdefiniowane przez użytkownika
• strefy prywatne DNS
• Obszary robocze usługi Log Analytics
• Komponenty DAPR (jeśli są używane)

Planowanie zmian tożsamości zarządzanej

Zarządzanie tożsamością zależy od typu tej tożsamości:

• Tożsamość przypisana przez system: podczas ponownego tworzenia aplikacji kontenera platforma Azure generuje nowy identyfikator podmiotu zabezpieczeń. Musisz ponownie przypisać wszystkie role RBAC, zasady dostępu usługi Key Vault i uprawnienia usługi podrzędnej do nowej tożsamości.

• Tożsamość przypisana przez użytkownika: tożsamości zarządzane przypisane przez użytkownika są zasobami regionalnymi i nie można ich przenosić między regionami. Utwórz nową tożsamość przypisaną przez użytkownika w regionie docelowym i przypisz wymagane uprawnienia przed wdrożeniem.

Eksportowanie konfiguracji źródłowej

az containerapp env show \
  --name <ENVIRONMENT_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --output json > managed-environment.json

az containerapp show \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --output json > container-app.json

Modyfikowanie szablonu środowiska zarządzanego

Przed ponownym wdrożeniem środowiska zarządzanego zaktualizuj wyeksportowaną konfigurację:

• Zaktualizuj lokalizację: ustaw location właściwość na docelowy region świadczenia usługi Azure.
• Zweryfikuj nazwy zasobów: upewnij się, że nazwa środowiska zarządzanego jest unikatowa w docelowej grupie zasobów i regionie.
• Przejrzyj konfigurację usługi Log Analytics: zaktualizuj odwołanie do obszaru roboczego usługi Log Analytics, jeśli obszar roboczy jest specyficzny dla regionu. Może być konieczne utworzenie nowego obszaru roboczego w regionie docelowym.
• Usuń właściwości tylko do odczytu: w przypadku wyeksportowania z portalu usuń właściwości, takie jak id, type, systemDatai inne pola tylko do odczytu, które powodują błędy wdrażania.

Modyfikowanie szablonu aplikacji kontenera

Po wyeksportowaniu konfiguracji aplikacji kontenera wprowadź następujące zmiany:

• Zaktualizuj odwołanie do środowiska zarządzanego: zastąp managedEnvironmentId element identyfikatorem zasobu nowego środowiska zarządzanego w regionie docelowym. Środowiska zarządzane są powiązane z regionem i nie można ich używać ponownie w różnych regionach.

• Sprawdź odwołania do obrazu kontenera: upewnij się, że odwołania do obrazu wskazują rejestr kontenerów dostępny z regionu docelowego. Jeśli włączono replikację geograficzną usługi ACR, istniejące odwołania mogą działać bez zmian.

• Przejrzyj konfigurację wejściową: po ponownym wdrożeniu aplikacja zmienia swoją w pełni kwalifikowaną nazwę domeny (FQDN). Zaplanuj aktualizowanie niestandardowych rekordów DNS i routingu ruchu podczas migracji jednorazowej.

• Skonfiguruj ponownie wpisy tajne i ustawienia aplikacji: utwórz ponownie wpisy tajne przy użyciu odwołań usługi Azure Key Vault lub konfiguracji aplikacji. Nie należy polegać na wyeksportowanych wartościach dla ustawień poufnych.

• Aktualizowanie składników Dapr: jeśli używasz Dapr, sprawdź, czy konfiguracje składników Dapr odwołują się do zasobów dostępnych w regionie docelowym (na przykład magazyny stanów, brokerzy pub/sub, magazyny tajemnic).

• Aktualizowanie diagnostyki i monitorowania: sprawdź odwołania do obszaru roboczego usługi Log Analytics i w razie potrzeby skonfiguruj ponownie ustawienia diagnostyczne.

Ponowne wdrożenie

Środowiska zarządzane usługi Azure Container Apps są powiązane z regionem. Przed ponownym wdrożeniem aplikacji kontenera utwórz środowisko zarządzane w regionie docelowym.

Wdrażanie środowiska zarządzanego

az containerapp env create \
  --name <ENVIRONMENT_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --location <TARGET_REGION> \
  --logs-workspace-id <LOG_ANALYTICS_WORKSPACE_ID> \
  --logs-workspace-key <LOG_ANALYTICS_WORKSPACE_KEY>

az containerapp env create \
  --name <ENVIRONMENT_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --location <TARGET_REGION> \
  --infrastructure-subnet-resource-id <SUBNET_ID> \
  --internal-only true \
  --logs-workspace-id <LOG_ANALYTICS_WORKSPACE_ID> \
  --logs-workspace-key <LOG_ANALYTICS_WORKSPACE_KEY>

Weryfikowanie dostępu do rejestru kontenerów

Przed wdrożeniem aplikacji kontenera upewnij się, że tożsamość używana przez aplikację kontenera (tożsamość zarządzana przypisana przez system lub przypisana przez użytkownika) ma przypisaną rolę AcrPull w docelowej usłudze Azure Container Registry.

az role assignment create \
  --assignee <IDENTITY_PRINCIPAL_ID> \
  --role AcrPull \
  --scope <ACR_RESOURCE_ID>

Wdrażanie aplikacji kontenera

az containerapp create \
  --name <APP_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <IMAGE_REFERENCE> \
  --target-port <PORT> \
  --ingress external \
  --registry-server <ACR_LOGIN_SERVER> \
  --registry-identity <IDENTITY_RESOURCE_ID>

az deployment group create \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --template-file container-app-template.json \
  --parameters container-app-parameters.json

Konfigurowanie sieci

Po wdrożeniu skonfiguruj ponownie sieć w celu dopasowania do konfiguracji źródłowej:

1. Konfigurowanie ruchu przychodzącego: skonfiguruj publiczny lub prywatny ruch przychodzący na podstawie modelu ekspozycji aplikacji.

2. Ponowna konfiguracja integracji VNet: Jeśli aplikacja kontenerowa korzysta z sieci prywatnej, skonfiguruj sieć VNet, podsieci, prywatne punkty końcowe i prywatne strefy DNS w docelowym regionie.

3. Zaktualizuj grupy zabezpieczeń sieciowych i trasy zdefiniowane przez użytkownika: w razie potrzeby ponownie utwórz grupy zabezpieczeń sieciowych i trasy zdefiniowane przez użytkownika.

4. Aktualizowanie list dozwolonych adresów IP: jeśli usługi podrzędne używają list dozwolonych opartych na adresach IP, zaktualizuj je przy użyciu nowych wychodzących adresów IP ze środowiska docelowego regionu.

5. Konfigurowanie domen niestandardowych i certyfikatów: domeny niestandardowe i certyfikaty TLS nie są przenoszone podczas relokacji. Skonfiguruj je ponownie w nowej aplikacji kontenera i zaktualizuj rekordy DNS.

Zmniejszenie ruchu

Po walidacji przekieruj ruch do wdrożenia w regionie docelowym:

1. Jeśli wcześniej obniżono czas życia DNS, zaktualizuj rekordy DNS, aby wskazywały na nową pełną nazwę domenową aplikacji kontenera.

2. Jeśli używasz usługi Azure Front Door lub Azure Traffic Manager, zaktualizuj pulę zaplecza lub punkt końcowy, aby uwzględnić aplikację kontenera w regionie docelowym i usunąć punkt końcowy regionu źródłowego.

3. Monitoruj ruch sieciowy, aby potwierdzić, że żądania trafiają do nowego środowiska wdrożeniowego.

Zweryfikować

Po przełączeniu ruchu zweryfikuj następujące elementy:

• Dostępność aplikacji i czasy odpowiedzi.
• Działanie systemu w warunkach oczekiwanego i szczytowego obciążenia.
• Łączność z usługami zależnych, takimi jak bazy danych, usługa Key Vault, magazyn i obsługa komunikatów.
• Dostęp tożsamości zarządzanej do zasobów podrzędnych.
• Funkcjonalność komponentów Dapr, jeśli są używane.
• Dzienniki i metryki przepływające do usług Azure Monitor i Log Analytics.

Sprawdź przy użyciu interfejsu wiersza polecenia:

# Confirm the container app is running
az containerapp show \
  --name <APP_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --query "{status:properties.runningStatus, fqdn:properties.configuration.ingress.fqdn}" \
  --output table

# Test the application endpoint
curl -s -o /dev/null -w "%{http_code}" https://<APP_FQDN>/health

Czyszczenie zasobów źródłowych

Po pomyślnym przeprowadzeniu walidacji i przeniesieniu ruchu:

1. Usuń aplikację kontenera źródłowego.
2. Usuń źródłowe środowisko zarządzane, jeśli nie jest już potrzebne.
3. Usuń nieużywane obrazy kontenerów, zasoby sieciowe i przypisania tożsamości, aby uniknąć niepotrzebnych opłat.
4. Zaktualizuj wszystkie pulpity monitorujące lub reguły alertów, które odwoływały się do zasobów źródłowych.

Ograniczenia

• Usługa Azure Container Apps nie obsługuje relokacji w miejscu ani w regionie na żywo.
• Należy ponownie utworzyć wpisy tajne, certyfikaty i domeny niestandardowe.
• Historia poprawek nie jest zachowywana w docelowym wdrożeniu.
• Podczas przełączenia wymagany jest przestój.
• Identyfikatory podmiotów tożsamości zarządzanej przypisywane przez system zmieniają się, więc należy ponownie utworzyć wszystkie przypisania RBAC (kontroli dostępu opartej na rolach).
• Tożsamości zarządzane przypisane przez użytkownika są regionalne i muszą zostać ponownie utworzone w regionie docelowym.
• Zmiana wychodzących adresów IP, co może mieć wpływ na listy dozwolonych usług podrzędnych.

Treści powiązane

• Automatyzowanie wdrożeń przy użyciu szablonów Bicep lub ARM
• Omówienie sieci usługi Azure Container Apps
• Konfigurowanie domen niestandardowych i certyfikatów
• Skalowanie i wydajność usługi Azure Container Apps
• Tożsamość zarządzana w usłudze Azure Container Apps