Azure Container Apps verplaatsen naar een andere regio

In dit artikel wordt beschreven hoe u een Azure Container Apps-workload verplaatst naar een andere Azure-regio door de beheerde omgeving en container-apps in de doelregio opnieuw te maken. Het proces omvat het exporteren van toepassingsconfiguratie, het opnieuw implementeren van resources, het valideren van de implementatie en het opschonen van resources in de bronregio.

Prerequisites

Controleer voordat u begint of u aan de volgende vereisten voldoet:

• Azure Container Apps is beschikbaar in de doelregio.
• De doelregio ondersteunt dezelfde Container Apps-functies, workloadprofielen en netwerkopties die u in de bronregio gebruikt.
• U hebt voldoende quotum in de doelregio voor de resources die u wilt implementeren.
• U hebt de volgende machtigingen in zowel de bron- als doelabonnementen:
  • Eigenaar of Inzender voor de resourcegroep.
  • Container Apps Contributor (aanbevolen). Deze rol omvat wildcard-rechten die toegang verlenen tot geheimwaarden van Container Apps. Voor smallere toegang, zie Rechten voor het beheren van geheimen.
• Uw containerinstallatiekopieën bevinden zich in een register dat toegankelijk is vanuit de doelregio (bijvoorbeeld Azure Container Registry of een ondersteund extern register).
• Afhankelijke Azure-resource, zoals Key Vault, opslagaccounts, databases, virtuele netwerken en berichtenservices, zijn al beschikbaar in de doelregio of hebben een plan voor opnieuw implementeren.

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

Begrijp de downtimevereisten

Azure Container Apps biedt geen ondersteuning voor liveregiomigratie. Downtime wordt voornamelijk veroorzaakt door DNS-doorgifte en verkeersrouteringswijzigingen tijdens cutover. De impact minimaliseren:

1. Implementeer en valideer eerst de container-app in de doelregio.
2. Lagere DNS TTL-waarden (bijvoorbeeld tot 60 seconden), zodat routeringswijzigingen snel worden doorgegeven.
3. Stuur productieverkeer pas om naar het nieuwe eindpunt nadat de validatie is voltooid.
4. Houd de broncontainerapplicatie actief totdat u bevestigt dat de doelimplementatie gezond is.

Prepare

Ter voorbereiding op herlocatie exporteert u de bronconfiguratie en controleert u alle regiospecifieke instellingen.

Afhankelijkheden identificeren

De volgende afhankelijke resources moeten aanwezig zijn in de doelregio voordat cutover wordt uitgevoerd:

• Azure Key Vault
• Opslagrekeningen
• Databases en berichtendiensten (zoals Azure Service Bus, Azure Cosmos DB)
• Virtuele netwerken, subnetten en privé-eindpunten
• Netwerkbeveiligingsgroepen (NSG's) en door de gebruiker gedefinieerde routes (UDR's)
• Persoonlijke DNS-zones
• Log Analytics-werkruimten
• Dapr-componenten (indien gebruikt)

Plannen voor wijzigingen in beheerde identiteit

Verwerking van beheerde identiteiten is afhankelijk van het identiteitstype:

• Door het systeem toegewezen identiteit: Wanneer u de container-app opnieuw maakt, genereert Azure een nieuwe principal-id. Je moet alle RBAC-rollen, Key Vault-toegangsbeleid en machtigingen voor downstreamservices opnieuw toewijzen aan de nieuwe identiteit.

• Door de gebruiker toegewezen identiteit: door de gebruiker toegewezen beheerde identiteiten zijn regionale resources en kunnen niet worden verplaatst tussen regio's. Maak een nieuwe door de gebruiker toegewezen identiteit in de doelregio en wijs de vereiste machtigingen toe vóór de implementatie.

De bronconfiguratie exporteren

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

De sjabloon voor de beheerde omgeving wijzigen

Voordat u de beheerde omgeving opnieuw implementeert, moet u de geëxporteerde configuratie bijwerken:

• Werk de locatie bij: Stel de location eigenschap in op de Azure-doelregio.
• Resourcenamen valideren: zorg ervoor dat de naam van de beheerde omgeving uniek is binnen de doelresourcegroep en regio.
• Controleer de Log Analytics-configuratie: werk de verwijzing naar de Log Analytics-werkruimte bij als de werkruimte regiospecifiek is. Mogelijk moet u een nieuwe werkruimte maken in de doelregio.
• Alleen-lezeneigenschappen verwijderen: als u uit de portal hebt geëxporteerd, verwijdert u eigenschappen zoals id, typeen systemDataandere alleen-lezenvelden die implementatiefouten veroorzaken.

De sjabloon voor de container-app wijzigen

Nadat u de configuratie van de container-app hebt geëxporteerd, moet u de volgende wijzigingen aanbrengen:

• Werk de naslaginformatie voor de beheerde omgeving bij: vervang deze door managedEnvironmentId de resource-id van de nieuwe beheerde omgeving in de doelregio. Beheerde omgevingen zijn regiogebonden en kunnen niet opnieuw worden gebruikt in verschillende regio's.

• Controleer verwijzingen naar containerimages. Controleer of de images verwijzen naar een containerregister dat toegankelijk is vanuit de doelregio. Als u geo-replicatie van ACR hebt ingeschakeld, werken de bestaande verwijzingen mogelijk zonder wijzigingen.

• Controleer de configuratie van inkomend verkeer: na opnieuw implementeren wordt de FQDN-naam (Fully Qualified Domain Name) van de toepassing gewijzigd. Plan om aangepaste DNS-records en verkeersroutering bij te werken tijdens cutover.

• Geheimen en app-instellingen opnieuw configureren: geheimen opnieuw maken met behulp van Azure Key Vault-verwijzingen of toepassingsconfiguratie. Vertrouw niet op geëxporteerde waarden voor gevoelige instellingen.

• Dapr-onderdelen bijwerken: Als u Dapr gebruikt, controleert u of de configuraties van dapr-onderdelen verwijzen naar resources die beschikbaar zijn in de doelregio (bijvoorbeeld staatsarchieven, pub/subbrokers, geheime winkels).

• Diagnostische gegevens en bewaking bijwerken: Controleer waar nodig de referenties van de Log Analytics-werkruimte en configureer de diagnostische instellingen opnieuw.

Opnieuw implementeren

Beheerde Azure Container Apps-omgevingen zijn regiogebonden. Maak de beheerde omgeving in de doelregio voordat u container-apps opnieuw implementeert.

De beheerde omgeving implementeren

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>

Toegang tot containerregister valideren

Voordat u de container-app implementeert, controleert u of de identiteit die wordt gebruikt door de container-app (door het systeem toegewezen of door de gebruiker toegewezen beheerde identiteit) de AcrPull-rol heeft toegewezen aan het Azure Container Registry-doel.

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

De container-app implementeren

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

Netwerken configureren

Na de implementatie configureert u het netwerk opnieuw zodat deze overeenkomt met de bronconfiguratie:

1. Inkomend verkeer configureren: openbaar of privé-inkomend verkeer instellen op basis van het blootstellingsmodel van uw toepassing.

2. VNet-integratie opnieuw toepassen: als de container-app gebruikmaakt van privénetwerken, configureert u het VNet, subnetten, privé-eindpunten en privé-DNS-zones in de doelregio.

3. NSG's en UDR's bijwerken: maak indien nodig netwerkbeveiligingsgroepen en door de gebruiker gedefinieerde routes opnieuw.

4. Lijsten met toegestane IP-adressen bijwerken: als downstreamservices ip-gebaseerde acceptatielijsten gebruiken, werkt u deze bij met de nieuwe uitgaande IP-adressen uit de doelregioomgeving.

5. Aangepaste domeinen en certificaten configureren: aangepaste domeinen en TLS-certificaten worden niet overgedragen tijdens de verplaatsing. Configureer ze opnieuw in de nieuwe container-app en werk DNS-records bij.

Verkeer oversnijden

Na validatie omleidt u het verkeer naar de doelregio-implementatie.

1. Als u de DNS-TTL eerder hebt verlaagd, werkt u DNS-records bij zodat deze verwijst naar de FQDN van de nieuwe container-app.

2. Als u Azure Front Door of Azure Traffic Manager gebruikt, werkt u de back-endpool of het eindpunt bij om de container-app doelregio op te nemen en verwijdert u het eindpunt van de bronregio.

3. Controleer het verkeer om te bevestigen dat aanvragen de nieuwe implementatie bereiken.

Verifiëren

Valideer na de cutover van het verkeer de volgende items:

• Beschikbaarheid en reactietijden van toepassingen.
• Schaalgedrag onder verwachte en piekbelasting.
• Connectiviteit met afhankelijke services, zoals databases, Key Vault, opslag en berichten.
• Toegang van beheerde identiteiten tot downstreambronnen.
• Dapr-componentfunctionaliteit, indien gebruikt.
• Logboeken en metrische gegevens stromen naar Azure Monitor en Log Analytics.

Controleer met behulp van de CLI:

# 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

Bronmaterialen opschonen

Na een geslaagde validatie en de overschakeling van verkeer:

1. Verwijder de broncontainer-app.
2. Verwijder de beheerde bronomgeving als u deze niet meer nodig hebt.
3. Verwijder ongebruikte containerinstallatiekopieën, netwerkresources en identiteitstoewijzingen om onnodige kosten te voorkomen.
4. Werk alle bewakingsdashboards of waarschuwingsregels bij die verwijzen naar de bronbronnen.

Limitations

• Azure Container Apps biedt geen ondersteuning voor herlocatie van in-place of live regio's.
• U moet geheimen, certificaten en aangepaste domeinen opnieuw maken.
• De revisiegeschiedenis wordt niet bewaard in de doelimplementatie.
• Downtime is vereist tijdens de overstapfase.
• Door het systeem toegewezen principal-ID's van beheerde identiteiten veranderen, daarom moet u alle RBAC-toewijzingen opnieuw maken.
• Door de gebruiker toegewezen beheerde identiteiten zijn regionaal en moeten opnieuw worden gemaakt in de doelregio.
• Uitgaande IP-adressen veranderen, wat van invloed kan zijn op acceptatielijsten voor downstreamservices.

Verwante inhoud

• Implementaties automatiseren met Bicep- of ARM-sjablonen
• Overzicht van Azure Container Apps-netwerken
• Aangepaste domeinen en certificaten configureren
• Azure Container Apps schalen en prestaties
• Beheerde identiteit in Azure Container Apps