Delen via

Uw functie-app verplaatsen naar een andere Azure-regio

  • Artikel

In dit artikel wordt beschreven hoe u een door Azure Functions gehoste functie-app 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.

De Azure-resources die als host fungeren voor uw functie-app zijn regiospecifiek en kunnen niet worden verplaatst tussen regio's. In plaats daarvan moet u een kopie maken van uw bestaande functie-app-resources in de doelregio en vervolgens uw functiecode opnieuw implementeren naar de nieuwe app.

U kunt dezelfde resources verplaatsen naar een andere resourcegroep of een ander abonnement, zolang ze in dezelfde regio blijven. Zie App Service-resources verplaatsen naar een nieuwe resourcegroep of een nieuw abonnement voor meer informatie.

Vereisten

  • Zorg ervoor dat de doelregio Ondersteuning biedt voor Azure Functions en alle gerelateerde services waarvan u de resources wilt verplaatsen.
  • Zorg ervoor dat u over bevoegdheden beschikt om de resources te maken die nodig zijn in de nieuwe regio.

Voorbereiden

Identificeer alle resources van de functie-app die worden gebruikt in de bronregio, waaronder mogelijk:

Wanneer u zich voorbereidt om uw app naar een nieuwe regio te verplaatsen, zijn er enkele onderdelen van de architectuur waarvoor speciale overweging en planning is vereist.

Naam van de functie-app

Namen van functie-apps moeten wereldwijd uniek zijn in alle Azure-apps. Dit betekent dat uw nieuwe functie-app niet dezelfde naam en URL kan hebben als de oorspronkelijke app. Dit geldt zelfs wanneer u een aangepaste DNS gebruikt, omdat de onderliggende <APP_NAME>.azurewebsites.net waarde nog steeds uniek moet zijn. Mogelijk moet u clients bijwerken die verbinding maken met HTTP-eindpunten in uw functie-app. Deze clients moeten de nieuwe URL gebruiken bij het indienen van aanvragen.

Broncode

In het ideale gevallen onderhoudt u uw broncode in een codeopslagplaats van een bepaald type, of in een containeropslagplaats als deze wordt uitgevoerd in een Linux-container. Als u continue implementatie gebruikt, wilt u de verbinding tussen de opslagplaats of containerimplementatie overschakelen naar het adres van de nieuwe functie-app. Als u om een of andere reden de broncode niet meer hebt, kunt u het pakket dat momenteel wordt uitgevoerd , downloaden vanuit de oorspronkelijke functie-app. U wordt aangeraden uw bronbestanden op te slaan in een codeopslagplaats en continue implementatie te gebruiken voor updates.

Standaardopslagaccount

Voor de Functions-host is een Azure Storage-account vereist. Zie Vereisten voor opslagaccounts voor meer informatie. Voor de beste prestaties moet uw functie-app een opslagaccount in dezelfde regio gebruiken. Wanneer u een nieuwe app maakt met een nieuw opslagaccount in uw nieuwe regio, krijgt uw app een nieuwe set functietoegangssleutels en wordt de status van triggers (zoals timertriggers) opnieuw ingesteld.

Permanente lokale opslag

Uitvoeringen van functies zijn bedoeld om staatloos te zijn. We voorkomen echter niet dat u gegevens naar het lokale bestandssysteem schrijft. Het is mogelijk om gegevens op te slaan die zijn gegenereerd en gebruikt door uw toepassing op het %HOME%\site virtuele station, maar deze gegevens mogen niet statusgerelateerd zijn. Als uw scenario vereist dat u de status tussen functie-uitvoeringen onderhoudt, kunt u overwegen om in plaats daarvan Durable Functions te gebruiken.

Als uw toepassing gegevens ophoudt in het gedeelde opslagpad van de app, moet u plannen hoe u die status gaat beheren tijdens het verplaatsen van resources. Houd er rekening mee dat voor toegewezen apps (App Service)-plannen de share deel uitmaakt van de site. Voor verbruiks- en Premium-abonnementen is de share standaard een Azure Files-share in het standaardopslagaccount. Apps die worden uitgevoerd op Linux, maken mogelijk gebruik van een expliciet gekoppelde share voor permanente opslag.

Verbonden services

Uw functies kunnen verbinding maken met Azure Services en andere resources met behulp van een service-SDK of triggers en bindingen. Elke verbonden service kan negatief worden beïnvloed wanneer de app naar een nieuwe regio wordt verplaatst. Als latentie of het hele probleem zich voordeed, kunt u ook een verbonden service naar de nieuwe regio verplaatsen. Zie de documentatie voor de respectieve services voor meer informatie over het verplaatsen van deze resources tussen regio's. Wanneer u een app met verbonden services verplaatst, kunt u overwegen om tijdens de verplaatsing een strategie voor herstel na noodgevallen en bedrijfscontinuïteit tussen regio's te overwegen.

Voor wijzigingen in verbonden services moet u mogelijk de waarden bijwerken die zijn opgeslagen in uw toepassingsinstellingen, die worden gebruikt om verbinding te maken met deze services.

Configuratie

  • U kunt een momentopname van de bestaande app-instellingen en verbindingsreeks s vanuit Azure Portal vastleggen. Vouw Omgevingsvariabelen instellingen>uit, selecteer Geavanceerd bewerken onder App-instellingen of Verbindingsreeksen en sla de JSON-uitvoer op die de bestaande instellingen of verbindingen bevat. U moet deze instellingen opnieuw maken in de nieuwe regio, maar de waarden zelf worden waarschijnlijk gewijzigd als gevolg van latere regiowijzigingen in de verbonden services.

  • Bestaande Key Vault-verwijzingen kunnen niet worden geëxporteerd over een geografische grens van Azure. U moet alle vereiste verwijzingen in de nieuwe regio opnieuw maken.

  • Uw app-configuratie kan worden beheerd door Azure-app Configuratie of vanuit een andere centrale (downstream) databaseafhankelijkheid. Bekijk een App Configuration-archief of vergelijkbare winkels voor omgevings- en regiospecifieke instellingen waarvoor mogelijk wijzigingen zijn vereist.

Aangepaste domeinen

Als uw functie-app gebruikmaakt van een aangepast domein, bindt u deze vooraf aan de doel-app. Controleer en schakel het domein in de doel-app in. Na de verplaatsing moet u de domeinnaam opnieuw toewijzen.

Virtuele netwerken

Met Azure Functions kunt u uw apps integreren met virtuele netwerkbronnen en ze zelfs uitvoeren in een virtueel netwerk. Zie Azure Functions-netwerkopties voor meer informatie. Wanneer u overstapt naar een nieuwe regio, moet u eerst alle vereiste virtuele netwerk- en subnetbronnen verplaatsen of opnieuw maken voordat u uw app implementeert. Dit omvat het verplaatsen of opnieuw maken van privé-eindpunten en service-eindpunten.

Identiteiten

  • U moet alle door het systeem toegewezen beheerde identiteiten opnieuw maken, samen met uw app in de nieuwe doelregio. Normaal gesproken wordt een automatisch gemaakte Microsoft Entra ID-app, die door EasyAuth wordt gebruikt, standaard ingesteld op de naam van de app-resource.

  • Door de gebruiker toegewezen beheerde identiteiten kunnen ook niet worden verplaatst tussen regio's. Als u door de gebruiker toegewezen beheerde identiteiten in dezelfde resourcegroep met uw app wilt behouden, moet u deze opnieuw maken in de nieuwe regio. Zie Beheerde identiteiten voor Azure-resources verplaatsen naar een andere regio voor meer informatie.

  • Verdeel de beheerde identiteiten dezelfde machtigingen in uw verplaatste services als de oorspronkelijke identiteiten die ze vervangen, inclusief groepslidmaatschappen.

Certificaten

App Service-certificaatresources kunnen worden verplaatst naar een nieuwe resourcegroep of een nieuw abonnement, maar niet tussen regio's. Certificaten die kunnen worden geëxporteerd, kunnen ook worden geïmporteerd in de app of in Key Vault in de nieuwe regio. Dit export- en importproces is gelijk aan een verplaatsing tussen regio's.

Er zijn verschillende soorten certificaten waarmee rekening moet worden gehouden bij het plannen van uw serviceverplaatsing:

Type certificaat Exporteerbaar Opmerkingen
App Service beheerd Nee Maak deze certificaten opnieuw in de nieuwe regio.
Azure Key Vault beheerd Ja Deze certificaten kunnen worden geëxporteerd uit Key Vault en vervolgens worden geïmporteerd in Key Vault in de nieuwe regio.
Persoonlijke sleutel (zelfbeheerd) Ja Certificaten die u buiten Azure hebt verkregen, kunnen worden geëxporteerd uit App Service en vervolgens worden geïmporteerd in de nieuwe app of in Key Vault in de nieuwe regio.
Openbare sleutel Nee Uw app heeft mogelijk certificaten met alleen een openbare sleutel en geen geheim, die worden gebruikt voor toegang tot andere beveiligde eindpunten. Haal de vereiste openbare-sleutelcertificaatbestanden op en importeer deze in de app in de nieuwe regio.

Access keys

Functions gebruikt toegangssleutels om http-eindpunten in uw functie-app moeilijker te openen. Deze sleutels worden versleuteld onderhouden in het standaardopslagaccount. Wanneer u een nieuwe app in de nieuwe regio maakt, wordt er een nieuwe set sleutels gemaakt. U moet bestaande clients bijwerken die toegangssleutels gebruiken om de nieuwe sleutels in de nieuwe regio te kunnen gebruiken. Hoewel u de nieuwe sleutels moet gebruiken, kunt u de oude sleutels opnieuw maken in de nieuwe app. Zie Werken met toegangssleutels in Azure Functions voor meer informatie.

Uitvaltijd

Als minimale downtime een vereiste is, kunt u overwegen om uw functie-app in beide regio's uit te voeren, zoals wordt aanbevolen om een architectuur voor herstel na noodgevallen te implementeren. De specifieke architectuur die u implementeert, is afhankelijk van de triggertypen in uw functie-app. Zie Betrouwbaarheid in Azure Functions voor meer informatie.

Durable Functions

Met de Durable Functions-extensie kunt u indelingen definiëren, waarbij de status wordt gehandhaafd in uw functie-uitvoeringen met behulp van stateful entiteiten. In het ideale geval moet u toestaan dat actieve indelingen worden voltooid voordat u uw Durable Functions-app migreert, met name wanneer u van plan bent over te schakelen naar een nieuw opslagaccount in de nieuwe regio. Wanneer u uw Durable Functions-apps migreert, kunt u overwegen een van deze strategieën voor herstel na noodgevallen en geo-distributie te gebruiken.

Verhuizen

Als u uw functie-app opnieuw maakt in een nieuwe regio, moet u eerst de Azure-infrastructuur van een App Service-plan, functie-app-exemplaar en gerelateerde resources, zoals virtuele netwerken, identiteiten en sites, opnieuw maken. U moet ook opnieuw verbinding maken of, in de nieuwe regio, de Azure-resources opnieuw maken die vereist zijn voor de app. Deze resources bevatten mogelijk het standaard Azure Storage-account en het Application Insights-exemplaar.

Vervolgens kunt u de werkelijke broncode of container van de toepassing verpakken en opnieuw implementeren in de functie-app die wordt uitgevoerd in de nieuwe regio.

Uw Azure-infrastructuur opnieuw maken

Er zijn verschillende manieren om een functie-app en gerelateerde resources in Azure te maken in de doelregio:

  • Implementatiesjablonen: Als u uw functie-app oorspronkelijk hebt geïmplementeerd met behulp van IaC-bestanden (Infrastructure-as-Code) (Bicep, ARM-sjablonen of Terraform), kunt u deze vorige implementaties bijwerken om de nieuwe regio te bereiken en deze gebruiken om resources in de nieuwe regio opnieuw te maken. Als u deze implementatiebestanden niet meer hebt, kunt u altijd een ARM-sjabloon voor uw bestaande resourcegroep downloaden vanuit Azure Portal.
  • Azure CLI/PowerShell-scripts: als u uw functie-app oorspronkelijk hebt geïmplementeerd met behulp van Azure CLI- of Azure PowerShell-scripts, kunt u deze scripts bijwerken om in plaats daarvan de nieuwe regio te targeten en deze opnieuw uit te voeren. Als u deze scripts niet meer hebt, kunt u ook een ARM-sjabloon voor uw bestaande resourcegroep downloaden vanuit Azure Portal.
  • Azure Portal: Als u uw functie-app oorspronkelijk in de portal hebt gemaakt of u zich niet vertrouwd voelt met het gebruik van scripts of IaC-bestanden, kunt u alles opnieuw maken in de portal. Zorg ervoor dat u hetzelfde hostingabonnement, dezelfde taalruntime en dezelfde taalversie gebruikt als uw oorspronkelijke app.

Geconfigureerde resources controleren

Controleer en configureer de resources die zijn geïdentificeerd in de stap Voorbereiden hierboven in de doelregio als ze niet zijn geconfigureerd tijdens de implementatie. Als u continue implementatie met beheerde identiteitsverificatie gebruikt, moet u ervoor zorgen dat de vereiste identiteiten en roltoewijzingen bestaan in de nieuwe functie-app.

Uw broncode opnieuw implementeren

Nu u de infrastructuur hebt geïmplementeerd, kunt u de broncode opnieuw verpakken en opnieuw implementeren in de functie-app. Dit is een goed moment om uw broncode of containerinstallatiekopie naar een opslagplaats te verplaatsen en continue implementatie vanuit die opslagplaats in te schakelen.

U kunt ook elke andere publicatiemethode gebruiken die wordt ondersteund door Functions. Voor de meeste publicatie op basis van hulpprogramma's moet u basisverificatie inschakelen op het scm eindpunt. Dit wordt niet aanbevolen voor productie-apps.

Overwegingen voor herlocatie

  • Vergeet niet om uw configuratie te controleren en uw functies in de doelregio te testen.
  • Als u aangepast domein hebt geconfigureerd, moet u de domeinnaam opnieuw toewijzen.
  • Voor een functie-app die wordt uitgevoerd in een Toegewezen (App Service)-plan, bekijkt u ook het App Service-migratieplan wanneer het plan wordt gedeeld met een of meer web-apps.

Opschonen

Nadat de verplaatsing is voltooid, verwijdert u de functie-app en het hostingabonnement uit de bronregio. U betaalt voor functie-apps in Premium- of Dedicated-abonnementen, zelfs wanneer de app zelf niet wordt uitgevoerd. Als u andere services in de nieuwe regio opnieuw hebt gemaakt, moet u ook de oudere services verwijderen nadat u zeker weet dat ze niet meer nodig zijn.

Bekijk het Azure Architecture Center voor voorbeelden van functie-apps die in meerdere regio's worden uitgevoerd als onderdeel van geavanceerdere en geografisch redundante oplossingsarchitecturen.