Azure Static Web Apps verplaatsen naar een andere regio

In dit artikel wordt beschreven hoe u Azure Static Web Apps-resources verplaatst naar een andere Azure-regio.

Er zijn verschillende redenen waarom u uw bestaande Azure-resources mogelijk van de ene regio naar de andere wilt verplaatsen. U kunt het volgende doen:

• Profiteer van een nieuwe Azure-regio.
• Implementeer functies of services die alleen beschikbaar zijn in specifieke regio's.
• Voldoen aan interne beleids- en governancevereisten.
• In overeenstemming met bedrijfsfusies en overnames
• Voldoen aan vereisten voor capaciteitsplanning.

Vereisten

Bekijk de volgende vereisten voordat u zich voorbereidt op de verplaatsing.

• Controleer of Azure Static Web Apps beschikbaar is in de doelregio.

• Zorg ervoor dat u gemachtigd bent om resources voor statische web-apps te maken in de doelregio.

• Ontdek of er beperkingen voor azure Policy-regio's zijn toegepast op uw organisatie.

• Als u geïntegreerde API-ondersteuning gebruikt die wordt geleverd door Azure Functions:

  • Bepaal de beschikbaarheid van Azure Functions in de doelregio.
  • Bepalen of functie-API-sleutels worden gebruikt. Gebruikt u bijvoorbeeld Key Vault of implementeert u deze als onderdeel van uw toepassingsconfiguratiebestanden?
  • Bepaal het implementatiemodel voor API-ondersteuning in de doelregio: Bring Your own functions. Inzicht in de verschillen tussen de twee modellen.

• Zorg ervoor dat het Standaardhostingabonnement wordt gebruikt voor het hosten van de statische web-app. Zie Azure Static Web Apps-hostingabonnementen voor meer informatie over hostingplannen.

• Bepaal de toegestane downtime voor verplaatsing.

• Afhankelijk van uw Azure Static Web App-implementatie moeten de volgende afhankelijke resources mogelijk worden geïmplementeerd en geconfigureerd in de doelregio voordat ze worden verplaatst:

  • Azure Functions.
  • Azure Virtual Network
  • Azure Front Door
  • Netwerkbeveiligingsgroep
  • Azure Private Link-service
  • Azure Key Vault
  • Azure Storage-account
  • Azure Application Gateway

Uitvaltijd

De verplaatsing van een Statische Azure-website introduceert downtime voor uw toepassing. De downtime wordt beïnvloed door welk patroon voor hoge beschikbaarheid u hebt geïmplementeerd voor uw Statische Azure-website. Algemene patronen zijn:

• Koude stand-by: er wordt regelmatig een back-up van workloadgegevens gemaakt op basis van de vereisten. In het geval van een noodgeval wordt de workload opnieuw geïmplementeerd in een nieuwe Azure-regio en worden gegevens hersteld.
• Warme stand-by: de workload wordt geïmplementeerd in de BCDR-regio (bedrijfscontinuïteit en herstel na noodgevallen) en gegevens worden asynchroon of synchroon gerepliceerd. In het geval van een noodgeval wordt de implementatie in de dr-regio (disaster recovery) omhoog en uitgeschaald.
• Meerdere regio's: de workload wordt geïmplementeerd in beide regio's en gegevens worden synchroon gerepliceerd. Beide regio's hebben een beschrijfbare kopie van de gegevens. De implementatie kan actief/passief of actief/actief zijn.

Voorbereiden

Implementaties met privé-eindpunten

Als uw statische web-apps zijn geïmplementeerd met privé-eindpunten, moet u het volgende doen:

• Werk de hostnaam voor het verbindingseindpunt bij.
• Werk de hostnaam bij in de privézone van DNS of aangepaste DNS-server (alleen van toepassing op Private Link).

Zie Privé-eindpunt configureren in Azure Static Web Apps voor meer informatie.

Alle andere implementaties

Voor alle andere implementatietypen moet u het volgende doen:

• Haal, indien van toepassing, de nieuwe functie-API-sleutels op uit Azure Functions in de nieuwe regio.

• Als de Azure-functie afhankelijk is van een database, controleert u of de DATABASE_CONNECTION_STRING database is bijgewerkt. Deze database valt mogelijk niet binnen het bereik van regionale migratie.

• Werk het aangepaste domein bij zodat deze verwijst naar de nieuwe hostnaam van de statische web-app.

• Als u Key Vault gebruikt, richt u een nieuwe Key Vault in de doelregio in. Werk indien van toepassing de functie-API-sleutels bij in Key Vault. Andere gevoelige gegevens die niet moeten worden opgeslagen in code of configuratiebestanden, moeten worden opgeslagen in deze Key Vault

De sjabloon exporteren

Als u de Resource Manager-sjabloon wilt exporteren die instellingen bevat die uw statische web-app beschrijven:

1. Meld u aan bij het Azure-portaal.

2. Ga naar uw statische web-app.

3. Selecteer in het linkermenu onder Automation de optie Sjabloon Exporteren.

   Het kan even duren voordat de sjabloon wordt gegenereerd.

4. Selecteer Downloaden.

5. Zoek het gedownloade .zip bestand en open het in een map van uw keuze.

   Dit bestand bevat de .json bestanden die de sjabloon en scripts bevatten om de sjabloon te implementeren.

6. Breng de benodigde wijzigingen aan in de sjabloon, zoals het bijwerken van de locatie met de doelregio.

Verhuizen

Gebruik de volgende stappen om uw statische web-app naar een andere regio te verplaatsen.

1. Als u een privé-eindpunt verplaatst, volgt u de richtlijnen in De Azure Private Link-service verplaatsen naar een andere regio.

2. Als u een bestaande Azure Functions hebt verstrekt aan uw statische web-app, volgt u de herlocatieprocedure voor Azure Functions.

3. Implementeer de statische web-app opnieuw met behulp van de sjabloon die u in de vorige sectie hebt geëxporteerd en geconfigureerd.

   Belangrijk

   Als u geen aangepast domein gebruikt, verandert de URL van uw toepassing in de doelregio. Zorg er in dit scenario voor dat gebruikers op de hoogte zijn van de URL-wijziging.

4. Als u een geïntegreerde API gebruikt, maakt u een nieuwe geïntegreerde API die wordt ondersteund door Azure Functions.

5. Configureer uw opslagplaats (GitHub of Azure DevOps) opnieuw om te implementeren in de zojuist geïmplementeerde statische web-app in de doelregio. Start de implementatie van de toepassing met behulp van GitHub Actions of Azure Pipelines.

6. Zorg ervoor dat u met een koude stand-by-implementatie clients informeert over de nieuwe URL. Als u een aangepast DNS-domein gebruikt, wijzigt u de DNS-vermelding zodat deze verwijst naar de doelregio. Met een warme stand-by-implementatie verwerkt een load balancer, zoals Front Door of Traffic Manager, de migratie van de statische web-app in de bronregio naar de doelregio.