Freigeben über

Verschieben Ihrer Funktions-App in eine andere Azure-Region

  • Artikel

In diesem Artikel wird beschrieben, wie Sie eine von Azure Functions gehostete Funktions-App in eine andere Azure-Region verschieben.

Es gibt verschiedene Gründe, warum Sie vielleicht Ihre vorhandenen Azure-Ressourcen aus einer Region in eine andere verschieben möchten. Möglicherweise möchten Sie Folgendes ausführen:

  • Nutzen Sie die Vorteile einer neuen Azure-Region.
  • Stellen Sie Features oder Dienste bereit, die nur in bestimmten Regionen verfügbar sind.
  • Erfüllen Sie interne Richtlinien- und Governanceanforderungen.
  • Ausrichtung an Unternehmenszusammenschlüssen und -übernahmen
  • Erfüllen Sie Kapazitätsplanungsanforderungen.

Die Azure-Ressourcen, die Ihre Funktions-App hosten, sind regionsspezifisch und können nicht in Regionen verschoben werden. Sie müssen stattdessen eine Kopie der Ressourcen Ihrer bestehenden Funktionsanwendung in der Zielregion erstellen und dann den Code Ihrer Funktionen in der neuen Anwendung neu verteilen.

Sie können dieselben Ressourcen in eine andere Ressourcengruppe oder ein anderes Abonnement verschieben, solange sie in derselben Region verbleiben. Weitere Informationen finden Sie unter Verschieben von App Service-Ressourcen in eine neue Ressourcengruppe oder ein neues Abonnement.

Voraussetzungen

  • Stellen Sie sicher, dass die Zielregion Azure Functions und alle zugehörigen Dienste unterstützt, deren Ressourcen Sie verschieben möchten.
  • Stellen Sie sicher, dass Sie über Berechtigungen verfügen, um die erforderlichen Ressourcen in der neuen Region zu erstellen.

Vorbereiten

Identifizieren Sie alle Ressourcen der Funktions-App, die in der Quellregion verwendet werden, darunter die folgenden:

Bei der Vorbereitung, Ihre App in eine neue Region zu verschieben, gibt es einige Teile der Architektur, die besondere Überlegungen und Planung erfordern.

Name der Funktions-App

Namen von Funktions-Apps müssen in Azure global eindeutig sein. Dies bedeutet, dass Ihre neue Funktions-App nicht denselben Namen und dieselbe URL wie die ursprüngliche enthalten kann. Dies gilt auch bei der Verwendung eines benutzerdefinierten DNS, da die zugrunde liegende <APP_NAME>.azurewebsites.net weiterhin eindeutig sein muss. Möglicherweise müssen Sie alle Clients aktualisieren, die eine Verbindung mit HTTP-Endpunkten in Ihrer Funktions-App herstellen. Diese Clients müssen beim Senden von Anforderungen die neue URL verwenden.

Quellcode

Im Idealfall verwalten Sie Ihren Quellcode in einem Coderepository irgendeiner Art oder in einem Containerrepository, wenn er in einem Linux-Container ausgeführt wird. Wenn Sie Continuous Deployment verwenden, planen Sie, die Repository- oder Containerbereitstellungsverbindung zur neuen Funktions-App-Adresse zu wechseln. Wenn Sie aus irgendeinem Grund nicht mehr über den Quellcode verfügen, können Sie das aktuell ausgeführte Paket aus der ursprünglichen Funktions-App herunterladen. Es wird empfohlen, Ihre Quelldateien in einem Coderepository zu speichern und Continuous Deployment für Updates zu verwenden.

Standardspeicherkonto

Der Functions-Host erfordert ein Azure Storage-Konto. Weitere Informationen finden Sie unter Anforderungen an das Speicherkonto. Für eine optimale Leistung sollte Ihre Funktions-App ein Speicherkonto in derselben Region verwenden. Wenn Sie eine neue App mit einem neuen Speicherkonto in Ihrer neuen Region erstellen, erhält Ihre App neue Funktionszugriffsschlüssel, und der Zustand aller Trigger (z. B. Timertrigger) wird zurückgesetzt.

Beibehaltener des lokalen Speichers

Es ist vorgesehen, dass Funktionsausführungen zustandslos sind. Sie werden jedoch nicht daran gehindert, Sie Daten in das lokale Dateisystem schreiben. Es ist möglich, von Ihrer Anwendung generierte und verwendete Daten auf dem virtuellen Laufwerk %HOME%\site zu speichern, diese Daten sollten jedoch nicht zustandsbezogen sein. Wenn Ihr Szenario erfordert, dass Sie den Zustand zwischen Funktionsausführungen beibehalten müssen, sollten Sie stattdessen Durable Functions verwenden.

Wenn Ihre Anwendung Daten im gemeinsam genutzten Speicherpfad der App beibehält, sollten Sie auf jeden Fall planen, wie Sie diesen Status während einer Ressourcenverschiebung verwalten. Beachten Sie, dass die Freigabe für Apps des Dedicated-Plans (App Service) Teil der Website ist. Für Consumption- und Premium-Pläne ist die Freigabe standardmäßig eine Azure Files-Freigabe im Standardspeicherkonto. Apps, die unter Linux ausgeführt werden, verwenden möglicherweise eine explizit eingebundene Freigabe für dauerhaften Speicher.

Verbundene Dienste

Ihre Funktionen können eine Verbindung mit Azure Services und anderen Ressourcen herstellen, indem sie entweder ein Dienst-SDK oder Trigger und Bindungen verwenden. Jeder verbundene Dienst kann sich negativ auswirken, wenn die App zu einer neuen Region wechselt. Wenn Latenz oder während der gesamten Zeit Probleme auftreten, sollten Sie den verbundenen Dienst ebenfalls in die neue Region verschieben. Informationen dazu, wie Sie diese Ressourcen innerhalb von Regionen verschieben, finden Sie in der Dokumentation zu den jeweiligen Diensten. Wenn Sie eine App mit verbundenen Diensten verschieben, sollten Sie während der Verschiebung eine regionenübergreifende Strategie für Notfallwiederherstellung und Geschäftskontinuität in Betracht ziehen.

Änderungen an verbundenen Diensten erfordern möglicherweise, dass Sie die in Ihren Anwendungseinstellungen gespeicherten Werte aktualisieren, die zum Herstellen einer Verbindung mit diesen Diensten verwendet werden.

Konfiguration

  • Sie können eine Momentaufnahme der vorhandenen App-Einstellungen und Verbindungszeichenfolgen aus dem Azure-Portal erfassen. Erweitern Sie Einstellungen>Umgebungsvariablen, wählen Sie Erweiterte Bearbeitung entweder unter App-Einstellungen oder Verbindungszeichenfolgen aus, und speichern Sie die JSON-Ausgabe, die die vorhandenen Einstellungen oder Verbindungen enthält. Sie müssen diese Einstellungen in der neuen Region nachbilden, die Werte selbst werden sich aber wohl aufgrund der nachfolgenden Regionsänderungen in den verbundenen Diensten ändern.

  • Vorhandene Key Vault-Verweise können nicht über eine geografische Azure-Grenze exportiert werden. Sie müssen alle erforderlichen Verweise in der neuen Region neu erstellen.

  • Ihre App-Konfiguration wird möglicherweise von Azure App Configuration oder von einer anderen zentralen (nachgeschalteten) Datenbankabhängigkeit verwaltet. Überprüfen Sie alle App Configuration-Speicher oder ähnliche Speicher für umgebungs- und regionsspezifische Einstellungen, die möglicherweise Änderungen erfordern.

Benutzerdefinierte Domänen

Wenn Ihre Funktions-App eine benutzerdefinierte Domäne verwendet, binden Sie sie vorab an die Ziel-App. Überprüfen und aktivieren Sie die Domäne in der Ziel-App. Nach der Verschiebung müssen Sie den Domänennamen neu zuordnen.

Virtuelle Netzwerke

Mit Azure Functions können Sie Ihre Apps in virtuelle Netzwerkressourcen integrieren und sogar in einem virtuellen Netzwerk ausführen. Weitere Informationen finden Sie unter Netzwerkoptionen von Azure Functions. Wenn Sie zu einer neuen Region wechseln, müssen Sie zuerst alle erforderlichen virtuellen Netzwerk- und Subnetzressourcen verschieben oder neu erstellen, bevor Sie Ihre App bereitstellen. Dazu gehört das Verschieben oder erneute Erstellen privater Endpunkte und Dienstendpunkte.

Identities

  • Sie müssen alle systemseitig zugewiesenen verwalteten Identitäten zusammen mit Ihrer App in der neuen Zielregion neu erstellen. In der Regel benutzt eine automatisch erstellte Microsoft Entra ID-App, die von EasyAuth verwendet wird, standardmäßig den App-Ressourcennamen.

  • Benutzerseitig zugewiesene verwaltete Identitäten können auch nicht in Regionen verschoben werden. Um benutzerseitig zugewiesene verwaltete Identitäten in derselben Ressourcengruppe mit Ihrer App beizubehalten, müssen Sie sie in der neuen Region neu erstellen. Weitere Informationen finden Sie unter Verlagern verwalteter Identitäten für Azure-Ressourcen in eine andere Region.

  • Gewähren Sie den verwalteten Identitäten die gleichen Berechtigungen in Ihren verschobenen Diensten wie die ursprünglichen Identitäten, die sie ersetzen, einschließlich Gruppenmitgliedschaften.

Zertifikate

App Service Certificate-Ressourcen können in eine neue Ressourcengruppe oder in ein neues Abonnement, aber nicht zwischen Regionen verschoben werden. Zertifikate, die exportiert werden können, können auch in die App oder in Key Vault in der neuen Region importiert werden. Dieser Export- und Importvorgang entspricht einem Wechsel zwischen Regionen.

Es gibt verschiedene Arten von Zertifikaten, die bei der Planung Ihrer Dienstverlagerung berücksichtigt werden müssen:

Bescheinigungstyp Exportable Kommentare
Von App Service verwaltet No Erstellen Sie diese Zertifikate in der neuen Region neu.
Über Azure Key Vault verwaltet Ja Diese Zertifikate können aus Key Vault exportiert und dann in Key Vault in der neuen Region importiert werden.
Privater Schlüssel (selbstverwaltet) Ja Zertifikate, die Sie außerhalb von Azure erworben haben, können aus App Service exportiert und dann entweder in die neue App importiert oder in der neuen Region in Key Vault importiert werden.
Öffentlicher Schlüssel No Ihre App verfügt möglicherweise über Zertifikate mit nur einem öffentlichen Schlüssel und keinem Geheimnis, die für den Zugriff auf andere gesicherte Endpunkte verwendet werden. Rufen Sie die erforderlichen Zertifikatdateien für öffentliche Schlüssel ab, und importieren Sie sie in die App in der neuen Region.

Zugriffsschlüssel

Functions verwendet Zugriffsschlüssel, um den Zugriff auf HTTP-Endpunkte in Ihrer Funktions-App zu erschweren. Diese Schlüssel werden im Standardspeicherkonto verschlüsselt verwaltet. Wenn Sie eine neue App in der neuen Region erstellen, wird eine neue Gruppe von Schlüsseln erstellt. Sie müssen vorhandene Clients aktualisieren, die Zugriffsschlüssel verwenden, um die neuen Schlüssel in der neuen Region zu verwenden. Obwohl Sie die neuen Schlüssel verwenden sollten, ist es möglich, die alten Schlüssel in der neuen App neu zu erstellen. Weitere Informationen finden Sie unter Arbeiten mit Zugriffsschüsseln in Azure Functions.

Ausfallzeit

Wenn minimale Ausfallzeiten erforderlich sind, sollten Sie Ihre Funktionsanwendung in beiden Regionen ausführen, um eine Notfallwiederherstellungsarchitektur zu implementieren. Die spezifische Architektur, die Sie implementieren, hängt von den Triggertypen in Ihrer Funktions-App ab. Weitere Informationen finden Sie unter Zuverlässigkeit in Azure Functions.

Langlebige Funktionen

Mit der Erweiterung „Durable Functions“ können Sie Orchestrierungen definieren, bei denen der Zustand in Ihren Funktionsausführungen mithilfe zustandsbehafteter Entitäten verwaltet wird. Im Idealfall sollten Sie die Ausführung von Orchestrierungen vor der Migration Ihrer Durable Functions-App zulassen, insbesondere, wenn Sie in der neuen Region zu einem neuen Speicherkonto wechseln möchten. Wenn Sie Ihre Apps für Durable Functions migrieren, sollten Sie eine dieser Notfallwiederherstellungs- und Geoverteilungsstrategien verwenden.

Verschieben

Wenn Sie Ihre Funktions-App in einer neuen Region neu erstellen möchten, müssen Sie zuerst die Azure-Infrastruktur eines App Service-Plans, die Funktions-App-Instanz und verwandte Ressourcen wie virtuelle Netzwerke, Identitäten und Slots neu erstellen. Sie müssen auch eine erneute Verbindung herstellen oder die Azure-Ressourcen, die von der App benötigt werden, in der neuen Region neu erstellen. Diese Ressourcen können das standardmäßige Azure Storage-Konto und die Application Insights-Instanz enthalten.

Anschließend können Sie den tatsächlichen Anwendungsquellcode oder den tatsächlichen Container in der Funktions-App packen und erneut bereitstellen, die in der neuen Region ausgeführt wird.

Neuerstellung Ihrer Azure-Infrastruktur

Es gibt verschiedene Möglichkeiten zum Erstellen einer Funktions-App und verwandter Ressourcen in Azure in der Zielregion:

  • Bereitstellungsvorlagen: Wenn Sie Ihre Funktions-App ursprünglich mit Infrastructure-as-Code-Dateien (IaC) (Bicep, ARM-Vorlagen oder Terraform) bereitgestellt haben, können Sie diese vorherigen Bereitstellungen so aktualisieren, dass sie auf die neue Region ausgerichtet sind, und sie verwenden, um Ressourcen in der neuen Region neu zu erstellen. Wenn Sie nicht mehr über diese Bereitstellungsdateien verfügen, können Sie jederzeit eine ARM-Vorlage für Ihre vorhandene Ressourcengruppe aus dem Azure-Portal herunterladen.
  • Azure CLI-/PowerShell-Skripts: Wenn Sie Ihre Funktions-App ursprünglich mit Azure CLI- oder Azure PowerShell-Skripts bereitgestellt haben, können Sie diese Skripts so aktualisieren, dass sie stattdessen auf die neue Region ausgerichtet sind, und sie erneut ausführen. Wenn Sie nicht mehr über diese Skripts verfügen, können Sie auch eine ARM-Vorlage für Ihre vorhandene Ressourcengruppe aus dem Azure-Portal herunterladen.
  • Azure-Portal: Wenn Sie Ihre Funktions-App ursprünglich im Portal erstellt haben oder nicht mit Skripts oder IaC-Dateien vertraut sind, können Sie einfach alles im Portal neu erstellen. Stellen Sie sicher, dass Sie den gleichen Hostingplan, die gleiche Sprachruntime sowie Sprachversion wie Ihre ursprüngliche App verwenden.

Überprüfung der konfigurierten Ressourcen

Überprüfen und konfigurieren Sie die im obigen Schritt Vorbereiten identifizierten Ressourcen in der Zielregion, wenn sie nicht während der Bereitstellung konfiguriert wurden. Wenn Sie Continuous Deployment mit Authentifizierung der verwalteten Identität verwenden, stellen Sie sicher, dass die erforderlichen Identitäten und Rollenzuordnungen in der neuen Funktions-App vorhanden sind.

Erneutes Bereitstellen des Quellcodes

Nachdem Sie nun über die Infrastruktur verfügen, können Sie den Quellcode erneut in die Funktions-App packen und erneut bereitstellen. Dies ist ein guter Zeitpunkt, um den Quellcode oder das Containerimage in ein Repository zu verschieben und Continuous Deployment aus diesem Repository zu aktivieren.

Sie können auch jede andere Veröffentlichungsmethode verwenden, die von Functions unterstützt wird. Für die meisten toolbasierten Veröffentlichungen müssen Sie die Standardauthentifizierung auf dem scm-Endpunkt aktivieren, was für Produktions-Apps nicht empfohlen wird.

Überlegungen zur Verlagerung

  • Denken Sie daran, Ihre Konfiguration zu überprüfen und Ihre Funktionen in der Zielregion zu testen.
  • Wenn Sie eine benutzerdefinierte Domäne konfiguriert haben, ordnen Sie den Domänennamen neu zu.
  • Sehen Sie sich für eine Funktions-App, die in einem Dedicated-Plan (App Service) ausgeführt wird, auch den App Service Migration-Plan an, wenn der Plan für eine oder mehrere Web-Apps freigegeben wird.

Bereinigung

Löschen Sie nach Abschluss der Verschiebung die Funktionsanwendung und den Hosting-Plan aus der Quellregion. Bei Premium- oder Dedicated-Tarifen zahlen Sie für Funktionsanwendungen, auch wenn die Anwendung selbst nicht ausgeführt wird. Wenn Sie andere Dienste in der neuen Region neu erstellt haben, sollten Sie auch die älteren Dienste löschen, nachdem Sie sichergestellt haben, dass sie nicht mehr benötigt werden.

Im Azure Architecture Center finden Sie Beispiele für Funktions-Apps, die in mehreren Regionen als Teil fortgeschrittener und georedundanterer Lösungsarchitekturen ausgeführt werden.