Freigeben über

Migrieren von Verbrauchsplan-Apps zum Flex-Verbrauchsplan

In diesem Artikel erfahren Sie, wie Sie Ihre vorhandenen Funktions-Apps aus dem Verbrauchsplan in den Flex-Verbrauchsplan migrieren. Bei den meisten Apps ist diese Migration einfach, und Ihr Code muss nicht geändert werden.

Von Bedeutung

Die Unterstützung für das Hosting von Funktionsanwendungen unter Linux in einem Verbrauchsplan wird am 30. September 2028 eingestellt werden. Ab heute werden keine Funktions- und Sprachverbesserungen am Linux-Verbrauchsplan vorgenommen. Folgen Sie diesem Artikel, um Ihre Verbrauchsplan-Apps zu migrieren, um sie stattdessen im Flex-Verbrauchsplan auszuführen. Weitere Informationen zum Ende des Supports für den Linux-Verbrauchsplan finden Sie unter Azure Functions Consumption plan hosting (legacy).

Migrationsmethoden

Dieser Artikel unterstützt die Migration zu einer Linux-Funktions-App in einem Flex-Verbrauchsplan für Linux- und Windows-Apps. Funktionen bieten mehrere Möglichkeiten, die meisten Migrationsschritte zu optimieren, insbesondere für Linux-Apps.

Die folgende Tabelle zeigt, welche Migrationsmethoden für jedes Betriebssystem verfügbar sind und in diesem Artikel behandelt werden.

Migrationsmethode BESCHREIBUNG Linux Windows
Azure Skills in GitHub Copilot. Lassen Sie Copilot Ihre Migration interaktiv anleiten und automatisieren (empfohlen für Linux). ✅ ❌
CLI-Migrationsbefehl Nutze az functionapp flex-migration, um die Migration zu automatisieren. ✅ ❌
Standard CLI-Befehle Schrittweise Migration mit Azure CLI Befehlen. ➖ ✅
Azure Portal Schrittweise Migration im Azure-Portal. ✅ ✅
Infrastruktur als Code Erstellen Sie wiederholbaren Migrationscode mithilfe von ARM-Vorlagen, Bicep Dateien oder Terraform. ➖ ➖

✅ Unterstützt und empfohlen | ➖ Unterstützt, nicht empfohlen | ❌ Nicht unterstützt

Um die richtigen Anweisungen für Ihre App anzuzeigen, wählen Sie oben im Artikel Ihr Betriebssystem aus.

Was Sie erwarten dürfen

Die spezifischen Schritte zum Migrieren Ihrer Verbrauchsplan-App sind sowohl vom Betriebssystem als auch von Ihrer spezifischen Migrationsmethode abhängig:

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows Consumption-App die Registerkarten Azure CLI oder Azure portal.

Unabhängig von Ihrer Migrationsmethode sind die folgenden allgemeinen Prinzipien der Migration aufgeführt:

  • Ihr Code bleibt gleich. Sie müssen Ihre Funktionen nicht neu schreiben, wenn Sie eine unterstützte Flex-Verbrauch-Sprachversion verwenden. Dieser Leitfaden hilft Ihnen bei der Überprüfung.
  • Sie müssen eine neue App erstellen. Der Migrationsprozess erstellt eine neue Flex-Verbrauch-App zusammen mit Ihrem vorhandenen, sodass Sie vor dem Wechsel testen können.
  • Verwenden Sie dieselbe Ressourcengruppe. Ihre neue App wird in derselben Ressourcengruppe mit Zugriff auf dieselben Abhängigkeiten ausgeführt.
  • Sie steuern die Anzeigedauer. Testen Sie Ihre neue App gründlich, bevor Sie den Datenverkehr umleiten und das alte zurücksetzen.

Hinweis

Wenn Sie Azure Government verwenden, ist Flex Consumption noch nicht verfügbar. Überprüfen Sie diese Anleitung jetzt, damit Sie bereit sind, wenn sie verfügbar ist.

Vorteile der Migration zu Flex-Verbrauch

Wenn Sie migrieren, erhalten Ihre Funktionen diese Vorteile, ohne ihren Code zu ändern:

  • Schnellere Kaltstarts: Immer einsatzbereite Instanzen bedeuten, dass Ihre Funktionen schneller reagieren.
  • Bessere Skalierung: Die Skalierung pro Funktion und Parallelitätssteuerelemente bieten Ihnen mehr Kontrolle.
  • Unterstützung für virtuelle Netzwerke: Verbinden Sie Ihre Funktionen mit privaten Netzwerken, und verwenden Sie private Endpunkte.
  • Aktive Investition: Flex Consumption ist der Ort, an dem neue Features und Verbesserungen zuerst landen.

Weitere Informationen finden Sie unter Flex-Verbrauchsplanvorteile und Vergleich der Hostingpläne.

Ressourcenbasierte Bereitstellungen

In diesem Artikel wird nicht explizit gezeigt, wie "Infrastruktur als Code" (IaC) für die Migration verwendet wird. Sie können jedoch dieselben Migrationsschritte ausführen, um Ihre ARM-Vorlagen, Bicep Dateien und Terraform-Konfigurationen zu konvertieren.

Der Flex-Verbrauchsplan führt einen neuen Abschnitt functionAppConfig in der Ressourcendefinition Microsoft.Web/sites ein, der mehrere Legacy-App-Einstellungen ersetzt. Ausführliche Informationen zu diesen Änderungen finden Sie unter Flex Consumption Plan-Verabschiedungen.

Diese Ressourcen können Ihnen bei den ersten Schritten mit Flex Consumption-Ressourcenbereitstellungen helfen:

Aktualisieren Sie nach einer erfolgreichen Migration Ihre Ressourcenbereitstellungsdateien so, dass sie mit der neuen Flex-Verbrauchskonfiguration übereinstimmen.

Voraussetzungen

  • Zugriff auf das Azure-Abonnement, das eine oder mehrere Funktions-Apps enthält, die migriert werden sollen. Das Konto, das zum Ausführen der Migrationsaufgaben verwendet wird, muss über die folgenden Berechtigungen verfügen:

    • Erstellen und Verwalten von Funktions-Apps und App Service-Hostingplänen.
    • Weisen Sie verwalteten Identitäten Rollen zu.
    • Erstellen und Verwalten von Speicherkonten.
    • Erstellen und Verwalten von Application Insights-Ressourcen.
    • Greifen Sie auf alle abhängigen Ressourcen Ihrer App zu, z. B. Azure Key Vault, Azure Service Bus oder Azure Event Hubs.

    Das Zuweisen der Rollen "Besitzer" oder "Mitwirkender " in Ihrer Ressourcengruppe bietet in der Regel ausreichende Berechtigungen.

  • So migrieren Sie mit der Azure CLI oder GitHub Copilot:

    • Azure CLI, Version 2.77.0 oder höher. Erforderlich, wenn sie Azure CLI Befehle verwenden. Die Skripts werden mithilfe von Azure CLI in Azure Cloud Shell getestet.
    • Melden Sie sich bei Azure CLI an, indem Sie az login ausführen. Stellen Sie sicher, dass Sie beim Abonnement angemeldet sind, das die Funktions-Apps enthält, die Sie migrieren möchten.
    az extension add --name resource-graph
    • Das jq Tool, das zum Arbeiten mit JSON-Ausgabe verwendet wird.

  • Um die Migration mit GitHub Copilot durchzuführen, konfigurieren Sie GitHub Copilot im gewünschten Modus:

    1. Install Copilot CLI

    2. Melden Sie sich bei Azure CLI an, wenn Sie noch nicht:

      az login

      Stellen Sie sicher, dass Sie beim Abonnement angemeldet sind, das die Funktions-Apps enthält, die Sie migrieren möchten.

    3. Starten Sie die Copilot CLI:

      copilot

    4. Fügen Sie die Marketplace-Quelle hinzu (nur zum ersten Mal):

      /plugin marketplace add microsoft/azure-skills

    5. Installieren Sie das Plug-In:

      /plugin install azure@azure-skills

    6. Laden Sie nach der Installation die MCP-Server (Model Context Protocol) neu:

      /mcp reload

    7. Installation überprüfen:

      /mcp show

      Das Azure-Plug-In sollte mit einem Häkchen aufgelistet werden. Das functionapp Tool ist Teil dieses Plug-Ins.

    Tipp

    Wenn Copilot auf das falsche Abonnement ausgerichtet ist, bitten Sie ihn, eine bestimmte Abonnement-ID zu verwenden. Sie können Ihre Abonnement-ID finden, indem Sie diese ausführen az account show --query id -o tsv. Wenn Copilot eine Verbindung mit dem falschen Azure-Mandanten herstellt, bitten Sie Copilot, bei der Durchführung von Azure-Aufrufen Ihre spezifische Mandantenidentifikation zu verwenden. Sie können Ihre Mandanten-ID finden, indem Sie den Befehl az account show --query tenantId -o tsv ausführen.

Identifizieren potenzieller Apps, die migriert werden sollen

Tipp

Sie wissen bereits, welche App migriert werden soll? Sie können diesen Abschnitt überspringen und direkt zur Bewertung Ihrer vorhandenen App wechseln.

Wenn Sie über mehrere Funktions-Apps verfügen und nicht sicher sind, welche Apps migriert werden müssen, hilft Ihnen dieser Abschnitt, diese zu finden. Sie erhalten eine Liste der App-Namen, Ressourcengruppen, Speicherorte und Laufzeitstapel.

Um eine interaktive Migration zu starten, die Ihr Abonnement überprüft und Sie auffordert, auszuwählen, welche Apps migriert werden sollen, verwenden Sie diese Eingabeaufforderung:

migrate my linux function apps in azure from consumption to flex consumption

Copilot identifiziert Ihre berechtigten Linux-Verbrauchs-Apps, lässt Sie auswählen, welche migriert werden sollen, und führt Sie dann durch die Bewertung, die Erstellung, die Konfiguration und die Bereitstellung jeder App. Fahren Sie mit den Migrationsschritten fort.

Wenn Sie nur sehen möchten, welche Apps berechtigt sind, ohne die Migration zu starten, verwenden Sie stattdessen diese Eingabeaufforderung:

list my linux consumption apps eligible for flex consumption migration

Copilot gibt eine Liste berechtigter und nicht zulässiger Apps zusammen mit den Gründen für alle Inkompatibilitäten zurück. Anschließend können Sie eine bestimmte App mithilfe der Eingabeaufforderung unter Starten der Migration für Linux migrieren.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows Consumption-App die Registerkarten Azure CLI oder Azure portal.

Bewerten Sie Ihre vorhandene App

Die Azure Fähigkeiten führen diese Aufgaben automatisch für Sie aus. Wenn Sie die Azure Fähigkeiten verwenden, wechseln Sie direkt zu Start the migration.

Führen Sie vor der Migration diese schnelle Checkliste durch, um sicherzustellen, dass Ihre App bereit ist. Die meisten Apps bestehen diese Prüfungen ohne Probleme:

Bestätigen der Regionskompatibilität

Vergewissern Sie sich, dass der Flex-Verbrauchsplan derzeit in derselben Region wie die Verbrauchsplan-App unterstützt wird, die Sie migrieren möchten.

Confirmed: Wenn die az functionapp flex-migration list-Befehlsausgabe oder Copilot-Einschätzung Ihre App in der Liste eligible_apps enthält, wird der Flex-Verbrauchsplan in derselben Region unterstützt, die von Ihrer aktuellen Linux-Consumption-App verwendet wird. In diesem Fall können Sie weiterhin die Kompatibilität des Sprachstapels überprüfen.

Aktion erforderlich: Wenn die Ausgabe Ihre App in die ineligible_apps Liste einschließt, wird eine Fehlermeldung angezeigt, die The site '<name>' is not in a region supported in Flex Consumption. Please see the list of regions supported in Flex Consumption by running az functionapp list-flexconsumption-locations besagt. In diesem Fall wird der Flex-Verbrauchsplan in der Region, die von Ihrer aktuellen Linux-Verbrauchs-App verwendet wird, nicht unterstützt.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows-Consumption-App die Registerkarten Azure CLI oder Azure Portal.

Wenn Ihre Region derzeit nicht unterstützt wird und Sie ihre Funktions-App trotzdem migrieren möchten, muss Ihre App in einer anderen Region ausgeführt werden, in der der Flex-Verbrauchsplan unterstützt wird. Das Ausführen Ihrer App in einer anderen Region als andere verbundene Dienste kann jedoch zu einer zusätzlichen Latenz führen. Stellen Sie sicher, dass die neue Region die Leistungsanforderungen Ihrer Anwendung erfüllen kann, bevor Sie die Migration abschließen.

Überprüfen der Kompatibilität des Sprachstapels

Flex-Verbrauchspläne unterstützen noch nicht alle Programmiersprachen-Stacks. Diese Tabelle gibt an, welche Sprachstapel derzeit unterstützt werden:

Stapeleinstellung Stapelname Unterstützt
dotnet-isolated .NET (isoliertes Arbeitsmodell) ✅ Ja
node JavaScript/TypeScript ✅ Ja
java Java ✅ Ja
python Python ✅ Ja
powershell PowerShell ✅ Ja
dotnet .NET (In-Process-Modell) ❌ Nein
custom Benutzerdefinierte Handler ✅ Ja

Bestätigt: Wenn der az functionapp flex-migration list-Befehl oder die Copilot-Bewertung Ihre App in die eligible_apps-Liste aufgenommen hat, verwendet Ihre Linux-Consumption-App bereits einen von Flex Consumption unterstützten Sprachstack, und Sie können damit fortfahren, die Kompatibilität der Stack-Versionen zu überprüfen.

Aktion erforderlich: Wenn die Ausgabe Ihrer App in der ineligible_apps Liste mit einer Fehlermeldung enthalten ist, die besagt Runtime '<name>' not supported for function apps on the Flex Consumption plan., dass Ihre Linux-Verbrauchs-App keine unterstützte Laufzeit von Flex Consumption ausführt.

Wenn Ihre Funktions-App einen nicht unterstützten Laufzeitstapel verwendet:

Überprüfen der Stack-Versionskompatibilität

Stellen Sie vor der Migration sicher, dass die Laufzeitstapelversion Ihrer App unterstützt wird, wenn sie in einem Flex-Verbrauchsplan in der aktuellen Region ausgeführt wird.

Bestätigt: Wenn der Befehl az functionapp flex-migration list oder die Copilot-Bewertung Ihre App in der Liste eligible_apps enthält, nutzt Ihre Linux-Verbrauchs-App bereits eine unterstützte Sprachstack-Version von Flex Consumption, und Sie können weiterhin die Nutzung der Bereitstellungs-Slots überprüfen.

Aktion erforderlich: Wenn die Ausgabe Ihre App in der Liste ineligible_apps mit einer Fehlermeldung umfasst, die besagt Invalid version {0} for runtime {1} for function apps on the Flex Consumption plan. Supported versions for runtime {1} are {2}., dass Ihre Linux-Consumption-App eine von Flex Consumption nicht unterstützte Laufzeit ausführt.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows Consumption-App die Registerkarten Azure CLI oder Azure portal.

Wenn Ihre Funktions-App eine nicht unterstützte Sprachstapelversion verwendet, aktualisieren Sie zuerst Den App-Code auf eine unterstützte Version , bevor Sie zum Flex-Verbrauch-Plan migrieren.

Überprüfen der Verwendung von Bereitstellungsplätzen

Verbrauchsplan-Apps können einen Bereitstellungsplatz definieren. Weitere Informationen finden Sie unter Azure Functions Deployment Slots. Der Flex-Verbrauchsplan unterstützt derzeit jedoch keine Bereitstellungsplätze. Bevor Sie migrieren, bestimmen Sie, ob Ihre App über einen Bereitstellungsplatz verfügt. Definieren Sie in diesem Fall eine Strategie, wie Sie Ihre App ohne Bereitstellungs-Slots verwalten, wenn sie im Flex-Verbrauchsplan läuft.

Confirmed: Wenn Ihre aktuelle App Bereitstellungsplätze aktiviert hat, zeigt der Befehl az functionapp flex-migration list oder die Copilot-Bewertung Ihre Funktions-App in der eligible_apps Liste ohne Warnung an. Fahren Sie mit der Überprüfung der Verwendung von Zertifikaten fort.

Aktion erforderlich: Ihre aktuelle App verfügt über aktivierte Bereitstellungsplätze, und die Ausgabe zeigt Ihre Funktions-App in der eligible_apps Liste an, fügt jedoch eine Warnung hinzu, die besagt: The site '<name>' has slots configured. This condition doesn't block migration, but please note that slots aren't supported in Flex Consumption.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows-Verbrauchs-App die Optionen Azure CLI oder Azure-Portal.

Wenn Ihre Funktions-App derzeit Bereitstellungsplätze verwendet, können Sie diese Funktionalität im Flex-Verbrauchsplan derzeit nicht reproduzieren. Berücksichtigen Sie vor der Migration die folgenden Optionen:

  • Setzen Sie Ihre Anwendung so um, dass separate Funktions-Apps verwendet werden. Auf diese Weise können Sie Ihren Funktionscode entwickeln, testen und in einer zweiten Nichtproduktions-App bereitstellen, anstatt Steckplätze zu verwenden.
  • Migrieren Sie allen neuen Code oder sämtliche neuen Funktionen vom Bereitstellungs-Slot in den Haupt-Slot (Produktion).

Überprüfen der Verwendung von Zertifikaten

TLS-Zertifikate (Transport Layer Security), die zuvor als SSL-Zertifikate (Secure Sockets Layer) bezeichnet werden, helfen beim Sichern von Internetverbindungen. Der Flex-Verbrauchsplan unterstützt derzeit keine TLS/SSL-Zertifikate, die verwaltete Zertifikate, Bring-your-own Certificates (BYOC) oder Public Key-Zertifikate enthalten.

Bestätigt: Wenn der Befehl az functionapp flex-migration list oder die Copilot-Bewertung Ihre App in der eligible_apps-Liste enthält, verwendet Ihre Linux Consumption-App keine Zertifikate, und Sie können weiterhin Ihre Blob-Speichertrigger überprüfen.

Aktion erforderlich: Wenn die Ausgabe Ihre App in der Liste mit einer Fehlermeldung enthält, die ineligible_apps besagt The site '<name>' is using TSL/SSL certificates. TSL/SSL certificates are not supported in Flex Consumption. oder The site '<name>' has the WEBSITE_LOAD_CERTIFICATES app setting configured. Certificate loading is not supported in Flex Consumption., dass Ihre Linux-Verbrauchs-App nicht mit Flex Consumption kompatibel ist.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Um eine Windows Consumption-App zu migrieren, verwenden Sie die Tabs Azure CLI oder Azure Portal.

Wenn Ihre App derzeit auf TLS/SSL-Zertifikaten basiert, fahren Sie erst mit der Migration fort, wenn die Unterstützung für Zertifikate dem Flex-Verbrauchsplan hinzugefügt wird.

Überprüfen Sie Ihre Blob-Speichertrigger

Derzeit unterstützt der Flex-Verbrauchsplan nur ereignisbasierte Trigger für Azure Blob-Speicher, die mit einer Source-Einstellung von EventGrid definiert sind. Der Plan unterstützt keine Blob-Speichertrigger, die Containerabfragen durchführen und eine Source-Einstellung von LogsAndContainerScan verwenden. Da die Containerabfragung die Standardeinstellung ist, müssen Sie ermitteln, ob eines ihrer BLOB-Speichertrigger die Standardquelleinstellung LogsAndContainerScan verwendet. Weitere Informationen finden Sie unter Trigger für einen BLOB-Container.

Confirmed: Wenn der Befehl az functionapp flex-migration list oder die Copilot-Bewertung Ihre App in der Liste eligible_apps enthält, verwendet Ihre Linux-Consumption-App keine Blob-Speichertrigger mit EventGrid als Quelle. Sie können weiterhin abhängige Dienste in Betracht ziehen.

Aktion erforderlich: Wenn die Ausgabe Ihre App in der ineligible_apps-Liste mit der Fehlermeldung The site '<name>' has blob storage triggers that don't use Event Grid as the source: <list> Flex Consumption only supports Event Grid-based blob triggers. Please convert these triggers to use Event Grid or replace them with Event Grid triggers before migration. enthält, dass Ihre Linux-Verbrauchs-App nicht mit Flex Consumption kompatibel ist.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows-Konsum-App die Optionen Azure CLI oder Azure-Portal.

Wenn Ihre App über Blob-Speichertrigger verfügt, die nicht über eine Ereignisrasterquelle verfügen, müssen Sie zu einer Ereignisrasterquelle wechseln, bevor Sie zum Flex-Verbrauchsplan migrieren.

Die grundlegenden Schritte zum Ändern eines vorhandenen Blob-Speichertriggers in eine Ereignisrasterquelle sind:

  1. Fügen Sie die Eigenschaft source in der Blob Storage-Triggerdefinition hinzu oder aktualisieren Sie sie zu EventGrid und stellen Sie die App erneut bereit.

  2. Erstellen Sie die Endpunkt-URL in Ihrer Funktions-App, die vom Ereignisabonnement verwendet wird.

  3. Erstellen Sie ein Ereignisabonnement für Ihren Blob-Speichercontainer.

Weitere Informationen finden Sie unter Tutorial: Auslösen von Azure Functions für Blobcontainer mithilfe eines Ereignisabonnements.

Abhängige Dienste in Betracht ziehen

Tipp

Einfache HTTP-only-App? Wenn Ihre Funktionen nur HTTP-Trigger verwenden und keine Verbindung mit anderen Azure-Diensten herstellen, können Sie wahrscheinlich den größten Teil dieses Abschnitts überspringen. Denken Sie daran, alle Clients zu aktualisieren, um nach der Migration auf die URL Ihrer neuen App zu verweisen.

Da Azure Functions ein Compute-Dienst ist, sollten Sie die Auswirkungen der Migration auf Daten und Dienste sowohl vor- als auch nachgelagert Ihrer App berücksichtigen.

Strategien zum Datenschutz

Verwenden Sie die folgenden Strategien, um sowohl upstream- als auch downstream-Daten während der Migration zu schützen:

  • Idempotenz: Stellen Sie sicher, dass Ihre Funktionen dieselbe Nachricht mehrmals ohne negative Nebenwirkungen verarbeiten können. Weitere Informationen finden Sie unter Entwerfen von Azure-Funktionen für identische Eingaben.
  • Protokollierung und Überwachung: Um die Nachrichtenverarbeitung nachzuverfolgen, aktivieren Sie die detaillierte Protokollierung in beiden Apps während der Migration. Weitere Informationen finden Sie unter Monitor-Ausführungen in Azure Functions.
  • Prüfpunkt: Implementieren Sie für Streamingtrigger, z. B. den Event Hubs-Trigger, die richtigen Prüfpunktverhalten, um die Verarbeitungsposition nachzuverfolgen. Weitere Informationen finden Sie unter Azure Functions zuverlässige Ereignisverarbeitung.
  • Parallele Verarbeitung: Erwägen Sie, beide Apps während der Übernahme vorübergehend parallel auszuführen. Achten Sie darauf, die Verarbeitung von Daten aus dem Upstreamdienst sorgfältig zu überwachen und zu überprüfen. Weitere Informationen finden Sie unter benutzerdefinierte Lösungen mit mehreren Regionen zur Resilienz.
  • Schrittweise Übernahme: Bei Systemen mit hohem Volumen sollten Sie eine schrittweise Übernahme implementieren, indem Sie Teile des Datenverkehrs an die neue App umleiten. Sie können das Routing von Anforderungen vor Ihren Apps mithilfe von Diensten wie Azure API Management oder Azure Application Gateway verwalten.

Abhilfemaßnahmen nach Triggertyp

Planen Sie Abschwächungsstrategien zum Schutz von Daten spezifischer Funktionstrigger in Ihrer App.

Auslöser Risiko für Daten Strategie
Azure Blob Storage High Erstellen Sie einen separaten Container für den ereignisbasierten Trigger in der neuen App.
Nachdem die neue App ausgeführt wird, stellen Sie die Clients um, damit sie den neuen Container verwenden.
Zulassen, dass der ursprüngliche Container vollständig verarbeitet wird, bevor die alte App beendet wird.
Azure Cosmos DB High Erstellen Sie speziell für die neue App einen dedizierten Leasecontainer.
Legen Sie diesen neuen Leasecontainer als leaseCollectionName Konfiguration in Ihrer neuen App fest.
Erfordert, dass Ihre Funktionen idempotent sind, oder Sie müssen in der Lage sein, die Ergebnisse der Verarbeitung eines doppelten Änderungsfeeds handhaben zu können.
Setzen Sie die StartFromBeginning Konfiguration auf false in der neuen App, um die vollständige erneute Verarbeitung des gesamten Feeds zu vermeiden.
Azure Event Grid Mittelstufe Erstellen Sie dasselbe Ereignisabonnement in der neuen App neu.
Erfordert, dass Ihre Funktionen idempotent sind , oder Sie müssen in der Lage sein, die Ergebnisse der doppelten Ereignisverarbeitung zu verarbeiten.
Azure Event Hubs Mittelstufe Erstellen Sie eine neue Consumergruppe für die Verwendung durch die neue App. Weitere Informationen finden Sie unter Migrationsstrategien für Ereignisrastertrigger.
Azure Service Bus High Erstellen Sie ein neues Thema oder eine neue Warteschlange für die Verwendung durch die neue App.
Aktualisieren Sie Absender und Clients, um das neue Thema oder die neue Warteschlange zu verwenden.
Wenn das ursprüngliche Thema leer ist, fahren Sie die alte App herunter.
Azure Storage Warteschlange High Erstellen Sie eine neue Warteschlange für die Verwendung durch die neue App.
Aktualisieren Sie Absender und Clients, damit sie die neue Warteschlange verwenden.
Nachdem die ursprüngliche Warteschlange leer ist, beenden Sie die alte App.
HTTP Niedrig Denken Sie daran, nach der Migration Clients sowie andere Apps oder Dienste auf die neuen HTTP-Endpunkte umzustellen.
Timer Niedrig Stellen Sie während der Umstellung sicher, dass Sie den Zeitplan zwischen den beiden Apps abstimmen, um gleichzeitige Ausführungen von beiden Apps zu vermeiden.
Deaktivieren Sie den Timertrigger in der alten App, nachdem die neue App erfolgreich ausgeführt wurde.

Aufgaben vor der Migration

Bevor Sie Ihre neue Flex Consumption-App erstellen, sammeln Sie einige Informationen zu Ihrer aktuellen App. Dieser Schritt stellt sicher, dass während des Übergangs keine Einstellungen verloren gehen.

Tipp

Dieser Schritt ist hauptsächlich Kopieren-Einfügen-Arbeit. Sammeln Sie Einstellungen aus Ihrer vorhandenen App, damit Sie sie auf die neue App anwenden können.

Führen Sie diese Aufgaben vor der Migration aus:

Erfassen von App-Einstellungen

Wenn Sie beabsichtigen, die gleichen Trigger- und Bindungsquellen und andere Einstellungen aus App-Einstellungen zu verwenden, notieren Sie sich zuerst die aktuellen App-Einstellungen in Ihrer vorhandenen Verbrauchsplan-App.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows-Verbrauchs-App die Registerkarten Azure CLI oder Azure Portal.

Vorsicht

App-Einstellungen enthalten häufig Schlüssel und andere freigegebene Geheimschlüssel. Speichern Sie Anwendungseinstellungen immer sicher, ideal verschlüsselt. Um die Sicherheit zu verbessern, verwenden Sie Microsoft Entra ID Authentifizierung mit verwalteten Identitäten in der neuen Flex-Verbrauchsplan-App anstelle von freigegebenen Geheimschlüsseln.

Sammeln von Anwendungskonfigurationen

Andere App-Konfigurationen sind über die App-Einstellungen hinaus vorhanden. Erfassen Sie diese Konfigurationen aus Ihrer vorhandenen App, damit Sie sie in der neuen App ordnungsgemäß neu erstellen können.

Überprüfen Sie diese Einstellungen. Wenn eine dieser Elemente in der aktuellen App vorhanden ist, entscheiden Sie, ob sie in der neuen Flex-Verbrauchsplan-App neu erstellt werden sollen:

Konfiguration Konfiguration Kommentar
CORS-Einstellungen cors Bestimmt alle vorhandenen CORS-Einstellungen (Cross-Origin Resource Sharing), die Ihre Clients möglicherweise benötigen.
Benutzerdefinierte Domänen Wenn Ihre App derzeit eine andere Domäne verwendet als *.azurewebsites.net, müssen Sie diese benutzerdefinierte Domänenzuordnung durch eine Zuordnung zu Ihrer neuen App ersetzen.
HTTP-Version http20Enabled Bestimmt, ob HTTP 2.0 von Ihrer App benötigt wird.
Nur HTTPS httpsOnly Bestimmt, ob TSL/SSL für den Zugriff auf Ihre App erforderlich ist.
Eingehende Clientzertifikate clientCertEnabled
clientCertMode
clientCertExclusionPaths		 Legt Anforderungen für Clientanforderungen fest, die Zertifikate für die Authentifizierung verwenden.
Maximale Skalierungshöchstgrenze WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT Legt den Grenzwert für skalierte Instanzen fest Der Standardwert ist 200. Dieser Wert befindet sich in ihren App-Einstellungen, aber in einer Flex-Verbrauchsplan-App wird er stattdessen als Websiteeinstellung (maximumInstanceCount) hinzugefügt.
Minimale eingehende TLS-Version minTlsVersion Legt eine Mindestversion von TLS fest, die von Ihrer App benötigt wird.
Minimale eingehende TLS-Verschlüsselung minTlsCipherSuite Legt eine minimale TLS-Verschlüsselungsanforderung für Ihre App fest.
Bereitgestellte Azure-Files-Freigaben azureStorageAccounts Überprüft, ob in Ihrer Anwendung explizit gemountete Dateifreigaben vorhanden sind (nur Linux)
SCM-Basisauthentifizierungsdaten für die Veröffentlichung scm.allow Bestimmt, ob die scm Veröffentlichungsseite aktiviert ist. Obwohl dies aus Sicherheitsgründen nicht empfohlen wird, ist es bei einigen Veröffentlichungsmethoden erforderlich.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows Consumption-App die Tabs Azure CLI oder Azure Portal.

Identifizieren von verwalteten Identitäten und rollenbasiertem Zugriff

Dokumentieren Sie vor der Migration, ob Ihre App von der vom System zugewiesenen verwalteten Identität oder von allen vom Benutzer zugewiesenen verwalteten Identitäten abhängt. Ermitteln Sie die rollenbasierten Zugriffssteuerungsberechtigungen (RBAC), die diesen Identitäten gewährt werden. Sie müssen die vom System zugewiesene verwaltete Identität und alle Rollenzuweisungen in Ihrer neuen App neu erstellen. Sie können Ihre vom Benutzer zugewiesenen verwalteten Identitäten in Ihrer neuen App wiederverwenden.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows-Verbrauchs-App die Registerkarten Azure CLI oder Azure-Portal.

Identifizieren integrierter Authentifizierungseinstellungen

Sammeln Sie vor der Migration zu Flex Consumption Informationen zu integrierten Authentifizierungskonfigurationen. Wenn Ihre App dasselbe Clientauthentifizierungsverhalten verwenden soll, müssen Sie sie in der neuen App neu erstellen. Weitere Informationen finden Sie unter Authentication und Autorisierung in Azure Functions.

Achten Sie besonders auf Umleitungs-URIs, zulässige externe Umleitungen und Tokeneinstellungen, um einen reibungslosen Übergang für authentifizierte Benutzer sicherzustellen.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows Consumption-App die Registerkarten Azure CLI oder Azure portal.

Überprüfen von Einschränkungen für eingehenden Zugriff

Sie können einschränkungen für eingehenden Zugriff für Apps in einem Verbrauchsplan festlegen. Möglicherweise möchten Sie diese Einschränkungen in Ihrer neuen App beibehalten. Achten Sie für jede von Ihnen definierte Einschränkung darauf, diese Eigenschaften zu erfassen:

  • IP-Adressen oder CIDR-Bereiche
  • Prioritätswerte
  • Aktionstyp (Zulassen/Verweigern)
  • Namen der Regeln

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows Konsum-App die Registerkarten Azure CLI oder Azure Portal.

Wenn Sie im Flex-Verbrauchsplan betrieben werden, können Sie diese eingehenden IP-basierten Einschränkungen neu erstellen. Sie können Ihre App weiter schützen, indem Sie andere Netzwerkeinschränkungen implementieren, z. B. die Integration virtueller Netzwerke und eingehende private Endpunkte. Weitere Informationen finden Sie unter Integration des virtuellen Netzwerks.

Migration starten

Wenn Sie die Ermittlungsaufforderung im Abschnitt " Identifizieren " verwendet haben, hat die Fähigkeit ihre neue Flex Consumption-App bereits bewertet, erstellt und konfiguriert. Sie können diesen Abschnitt überspringen und mit den Migrationsschritten fortfahren.

Wenn Sie bereits wissen, welche App migriert werden soll, verwenden Sie diese Eingabeaufforderung:

migrate my app <APP_NAME> to flex consumption

Die Skill behandelt automatisch Bewertung, App-Erstellung und Konfigurationsmigration und entspricht dem az functionapp flex-migration start-Befehl und dessen Überprüfungsschritten.

Nachdem Sie die Migration erfolgreich gestartet haben, fahren Sie mit dem Abrufen des Codebereitstellungspakets fort.

Hol das Bereitstellungspaket für den Code

Um Ihre App erneut bereitzustellen, benötigen Sie entweder die Quelldateien Ihres Projekts oder das Bereitstellungspaket. Im Idealfall verwalten Sie Ihre Projektdateien in der Quellcodeverwaltung, damit Sie Funktionscode ganz einfach für Ihre neue App erneut bereitstellen können. Wenn Sie über Ihre Quellcodedateien verfügen, können Sie diesen Abschnitt überspringen und weiterhin Leistungs benchmarks erfassen (optional).

Wenn Sie keinen Zugriff mehr auf Ihre Projektquelldateien haben, können Sie das aktuelle Bereitstellungspaket aus der vorhandenen Verbrauchsplan-App in Azure herunterladen. Der Speicherort hängt davon ab, ob das Bereitstellungspaket auf Linux oder Windows läuft.

Verbrauchsplan-Apps unter Linux verwalten die Bereitstellungs-Zip-Paketdatei in einem der folgenden Verzeichnisse:

  • Ein Azure Blob-Speichercontainer mit dem Namen scm-releases im Standardhostspeicherkonto (AzureWebJobsStorage). Dieser Container ist die Standardbereitstellungsquelle für eine Verbrauchsplan-App unter Linux.

  • Wenn Ihre App über eine Einstellung WEBSITE_RUN_FROM_PACKAGE verfügt, die eine URL ist, befindet sich das Paket an einem extern zugänglichen Speicherort, den Sie verwalten. Ein externes Paket sollte in einem BLOB-Speichercontainer mit eingeschränktem Zugriff gehostet werden. Weitere Informationen finden Sie unter URL des externen Pakets.

Tipp

Wenn Sie Ihr Speicherkonto nur auf verwalteten Identitätszugriff beschränken, müssen Sie möglicherweise Ihrem Azure Konto Lesezugriff auf den Speichercontainer gewähren, indem Sie es der Rolle Storage Blob Data Reader hinzufügen.

Das Bereitstellungspaket wird mithilfe des squashfs Formats komprimiert. Um zu sehen, was sich im Paket befindet, müssen Sie Tools verwenden, die dieses Format dekomprimieren können.

Führen Sie die folgenden Schritte aus, um das Bereitstellungspaket aus Ihrer aktuellen App herunterzuladen:

Die Copilot Migrationskompetenz versucht, Ihr vorhandenes Codeprojekt in Ihre neue App herunterzuladen und erneut bereitzustellen. Wenn dies nicht erfolgreich ist, werden Sie stattdessen durch das Abrufen und Bereitstellen des Codepakets als Teil des Migrationsworkflows geleitet. Sie können diesen Abschnitt überspringen und mit den Migrationsschritten fortfahren.

Der Speicherort der Projektquelldateien hängt von der WEBSITE_RUN_FROM_PACKAGE App-Einstellung wie folgt ab:

WEBSITE_RUN_FROM_PACKAGE-Wert Speicherort der Quelldatei
1 Die Dateien sind in einem ZIP-Archiv gespeichert, das sich in der Azure Files-Freigabe des Speicherkontos befindet, das durch die Einstellung WEBSITE_CONTENTAZUREFILECONNECTIONSTRING definiert ist. Die WEBSITE_CONTENTSHARE Einstellung definiert den Namen der Dateifreigabe.
Eine Endpunkt-URL Die Dateien befinden sich in einem ZIP-Paket an einem extern zugänglichen Speicherort, den Sie verwalten. Ein externes Paket sollte in einem BLOB-Speichercontainer mit eingeschränktem Zugriff gehostet werden. Weitere Informationen finden Sie unter URL des externen Pakets.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows-Verbrauchs-App die Registerkarten Azure CLI oder Azure-Portal.

Erfassen von Leistungs-Benchmarks (optional)

Wenn Sie die Leistungsverbesserung in Ihrer App basierend auf der Migration zum Flex Consumption-Plan überprüfen möchten, sollten Sie die Leistungs-Benchmarks Ihres aktuellen Plans erfassen. Anschließend können Sie sie mit den gleichen Benchmarks für Ihre App vergleichen, die in einem Flex Consumption-Plan ausgeführt wird.

Tipp

Vergleichen Sie die Leistung immer unter ähnlichen Bedingungen, z. B. Tageszeit, Wochentag und Clientbelastung. Versuchen Sie, die beiden Benchmarks so nah wie möglich zusammenzuführen.

Hier sind einige Benchmarks, die Sie für Ihre strukturierten Leistungstests berücksichtigen sollten:

Vorgeschlagene Benchmark Kommentar
Kaltstart Messen Sie die Zeit von der ersten Anforderung an die erste Antwort nach einem Leerlaufzeitraum.
Durchsatz Messen Sie die maximalen Anforderungen pro Sekunde mithilfe von Ladetests, um zu bestimmen, wie die App gleichzeitige Anforderungen verarbeitet.
Latenz Verfolgen Sie die Reaktionszeiten von P50, P95 und P99 unter verschiedenen Lastbedingungen. Sie können diese Metriken in Application Insights überwachen.

Verwenden Sie diese Kusto-Abfrage, um die vorgeschlagenen Wartezeiten in Application Insights zu überprüfen:

requests
| where timestamp > ago(1d)
| summarize percentiles(duration, 50, 95, 99) by bin(timestamp, 1h)
| render timechart

Schritte bei der Migration

Führen Sie die folgenden Hauptschritte aus, um Ihre Funktionen von einer Verbrauchsplan-App zu einer Flex-Verbrauchsplan-App zu migrieren:

Flex Consumption-App prüfen, die erstellt und konfiguriert wurde

Überprüfen Sie nach dem Ausführen des Befehls az functionapp flex-migration start, ob Ihre neue Flex Consumption-App erfolgreich erstellt und ordnungsgemäß konfiguriert wurde. Hier sind einige Schritte zum Überprüfen der Migrationsergebnisse:

Die Copilot Migrationsfunktion überprüft die neue Anwendung automatisch im Rahmen der Migration. Wenn Sie die Migration mit einer Copilot-Prompt in Start the migration for Linux gestartet haben, hat die Fähigkeit bereits überprüft, ob die App erstellt und ordnungsgemäß konfiguriert wurde. Sie können diesen Abschnitt überspringen und weiterhin die integrierte Authentifizierung konfigurieren.

Migrationzusammenfassung überprüfen

Der Befehl für die automatische Migration überträgt die meisten Konfigurationen. Überprüfen Sie jedoch manuell, ob diese Elemente migriert werden. Möglicherweise müssen Sie sie manuell konfigurieren:

  • Zertifikate: TLS/SSL-Zertifikate werden in Flex Consumption noch nicht unterstützt.
  • Bereitstellungsplätze: Werden im flexiblen Verbrauch nicht unterstützt.
  • Integrierte Authentifizierungseinstellungen: Sie müssen diese Einstellungen manuell neu konfigurieren.
  • CORS-Einstellungen: Je nach Konfiguration müssen Sie diese Einstellungen möglicherweise manuell überprüfen.

Wenn wichtige Einstellungen fehlen oder falsch sind, konfigurieren Sie diese manuell, indem Sie die im Windows Migrationsprozess beschriebenen Schritte Abschnitte dieses Artikels ausführen.

Endgültige Überprüfung des Plans

Bevor Sie mit dem Migrationsprozess fortfahren, nehmen Sie sich einen Moment Zeit, um diese letzten vorbereitenden Schritte auszuführen:

  • Überprüfen Sie alle gesammelten Informationen: Durchlaufen Sie alle Notizen, Konfigurationsdetails und Anwendungseinstellungen, die Sie in den vorherigen Bewertungs- und Vormigrationsabschnitten dokumentiert haben. Wenn etwas unklar ist, führen Sie die Azure CLI Befehle erneut aus, oder rufen Sie die Informationen aus dem Portal ab.

  • Definieren Sie Ihren Migrationsplan: Erstellen Sie basierend auf Ihren Ergebnissen eine Checkliste für Ihre Migration, die Folgendes hervorhebung:

    • Alle Einstellungen, die besondere Aufmerksamkeit erfordern
    • Trigger und Bindungen oder andere Abhängigkeiten, die während der Migration möglicherweise betroffen sind
    • Teststrategie für die Überprüfung nach der Migration
    • Rollbackplan, wenn unerwartete Probleme auftreten

  • Planung von Ausfallzeiten: Überlegen Sie, wann Die ursprüngliche Funktions-App beendet werden soll, um Datenverluste und doppelte Verarbeitung von Ereignissen zu vermeiden und wie sich diese Migration auf Ihre Benutzer oder nachgeschalteten Systeme auswirken kann. In einigen Fällen müssen Sie möglicherweise bestimmte Funktionen deaktivieren , bevor Sie die gesamte App beenden.

Eine sorgfältige abschließende Überprüfung trägt dazu bei, einen reibungsloseren Migrationsprozess sicherzustellen und das Risiko zu minimieren, wichtige Konfigurationen zu übersehen.

Erstellen einer App im Flex-Verbrauchsplan

Sie können eine Funktions-App im Flex Consumption-Plan zusammen mit anderen erforderlichen Azure Ressourcen auf verschiedene Weise erstellen:

Erstellungsoption Referenzartikel
Azure CLI Erstellen einer Flex-Verbrauch-App
Azure Portal Erstellen einer Funktions-App im Azure-Portal
Infrastruktur als Code ARM-Vorlage
azd
Bicep
Terraform
Visual Studio Code Visual Studio Code-Bereitstellung
Visual Studio Visual Studio-Bereitstellung

Tipp

Verwenden Sie nach Möglichkeit Microsoft Entra ID für die Authentifizierung anstelle von Verbindungszeichenfolgen, die gemeinsam genutzte Schlüssel enthalten. Die Verwendung verwalteter Identitäten ist eine bewährte Methode, die die Sicherheit verbessert, da sie die Notwendigkeit, freigegebene Geheimnisse direkt in den Anwendungseinstellungen zu speichern, eliminiert. Wenn Ihre ursprüngliche App Verbindungszeichenfolgen verwendet hat, unterstützt der Flex-Verbrauchsplan verwaltete Identitäten. Die meisten dieser Links zeigen Ihnen, wie verwaltete Identitäten in Ihrer Funktions-App aktiviert werden.

Anwenden von migrierten App-Einstellungen in der neuen App

Konfigurieren Sie vor der Bereitstellung des Codes die neue App mit den App-Einstellungen des relevanten Flex-Verbrauchsplans aus Ihrer originalen Funktions-App.

Von Bedeutung

Nicht alle Verbrauchsplan-App-Einstellungen werden unterstützt, wenn sie in einem Flex-Verbrauchsplan ausgeführt werden. Weitere Informationen finden Sie unter Veraltete Funktionen beim Flex-Verbrauchstarif.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows Consumption-App die Azure CLI oder Azure Portal Registerkarten.

Anwenden anderer App-Konfigurationen

Identifizieren Sie die Liste der weiteren App-Einstellungen Ihrer alten App, die Sie während der Vormigration gesammelt haben, und setzen Sie diese in der neuen App.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows Consumption-App die Registerkarten Azure CLI oder Azure-Portal.

Konfigurieren von Skalierungs- und Parallelitätseinstellungen

Der Flex-Verbrauchsplan verwendet die Skalierung pro Funktion. Jede Funktion in Ihrer App wird unabhängig von ihrer Arbeitsauslastung skaliert. Die Skalierung bezieht sich strenger auf Parallelitätseinstellungen. Diese Einstellungen helfen Ihnen, Skalierungsentscheidungen basierend auf den aktuellen gleichzeitigen Ausführungen zu treffen. Weitere Informationen finden Sie sowohl unter „Skalierung pro Funktion“ als auch „Parallelität“ im Artikel zum Flex-Verbrauchsplan.

Wenn Ihre neue App wie Ihre ursprüngliche App skaliert werden soll, sollten Sie die Parallelitätseinstellungen berücksichtigen. Das Festlegen höherer Parallelitätswerte kann dazu führen, dass weniger Instanzen erstellt werden, um dieselbe Last zu verarbeiten.

Wenn Sie einen benutzerdefinierten Skalierungsgrenzwert in Ihrer ursprünglichen App festlegen, können Sie sie auf Ihre neue App anwenden. Fahren Sie andernfalls mit dem nächsten Abschnitt fort.

Die standardmäßige maximale Instanzanzahl beträgt 100. Legen Sie ihn auf einen Wert zwischen 1 und 1.000 fest.

Hinweis

Das Reduzieren der maximalen Anzahl von Instanzen unter 40 für HTTP-Funktions-Apps kann häufige Anforderungsfehler und längere Drosselungsfenster verursachen, wenn der Datenverkehr die Kapazität überschreitet. Diese Einstellung ist nur für fortgeschrittene Szenarien vorgesehen, in denen eine begrenzte Skalierung akzeptabel ist und vollständig getestet wurde.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows-Consumption-App die Registerkarten Azure CLI oder Azure Portal.

Konfigurieren von benutzerdefinierten Domänen und CORS-Zugriff

Wenn Ihre ursprüngliche App über gebundene benutzerdefinierte Domänen oder CORS-Einstellungen verfügt, erstellen Sie sie in Ihrer neuen App neu. Weitere Informationen zu benutzerdefinierten Domänen finden Sie unter Setup einer vorhandenen benutzerdefinierten Domäne in Azure App Service.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows-Verbrauchs-App die Optionen Azure CLI oder Azure-Portal.

Konfigurieren verwalteter Identitäten und Zuweisen von Rollen

Wie Sie verwaltete Identitäten in Ihrer neuen App konfigurieren, hängt von der Art der verwalteten Identität ab:

Typ der verwalteten Identität Identität erstellen Rollenzuweisungen
Benutzerseitig zugewiesen Wahlfrei Sie können weiterhin dieselben vom Benutzer zugewiesenen verwalteten Identitäten mit der neuen App verwenden. Sie müssen diese Identitäten ihrer Flex Consumption-App neu zuweisen und überprüfen, ob sie weiterhin über die richtigen Rollenzuweisungen in Remotediensten verfügen. Wenn Sie neue Identitäten für die neue App erstellen möchten, müssen Sie die gleichen Rollen wie die vorhandenen Identitäten zuweisen.
Systemseitig zugewiesen Ja Da jede Funktions-App über eine eigene vom System zugewiesene verwaltete Identität verfügt, müssen Sie die vom System zugewiesene verwaltete Identität in der neuen App aktivieren und die gleichen Rollen neu zuweisen wie in der ursprünglichen App.

Das ordnungsgemäße Neustellen der Rollenzuweisungen ist der Schlüssel, um sicherzustellen, dass Ihre Funktions-App nach der Migration über denselben Zugriff auf Azure Ressourcen verfügt.

Tipp

Wenn Ihre ursprüngliche App Verbindungszeichenfolgen oder andere freigegebene Schlüssel für die Authentifizierung verwendet hat, ist dies eine großartige Möglichkeit, die Sicherheit Ihrer App zu verbessern, indem Sie zu Microsoft Entra ID Authentifizierung mit verwalteten Identitäten wechseln. Weitere Informationen finden Sie unter Tutorial: Erstellen einer Funktions-App, die eine Verbindung mit Azure Diensten mithilfe von Identitäten herstellt.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows-Verbrauchs-App die Optionen Azure CLI oder Azure-Portal.

Konfigurieren von Netzwerkzugriffseinschränkungen

Wenn Ihre ursprüngliche App IP-basierte Einschränkungen für eingehenden Zugriff aufweist, erstellen Sie eine der gleichen Eingehenden Zugriffsregeln neu, die Sie in Ihrer neuen App beibehalten möchten.

Tipp

Der Flex-Verbrauchsplan unterstützt die Integration des virtuellen Netzwerks vollständig. Aufgrund dieser Unterstützung können Sie nach der Migration auch private eingehende Endpunkte verwenden. Weitere Informationen finden Sie unter Private Endpunkte.

Die GitHub Copilot Migrationskompetenz wird derzeit nur bei der Migration von Linux-Apps unterstützt. Verwenden Sie zum Migrieren einer Windows-Verbrauchs-App die Optionen Azure CLI oder Azure-Portal.

Überwachung aktivieren

Bevor Sie Ihre neue App im Flex-Verbrauchsplan starten, stellen Sie sicher, dass Application Insights aktiviert ist. Wenn Sie Application Insights konfigurieren, können Sie probleme beheben, die während der Codebereitstellung und beim Start auftreten.

Implementieren Sie eine umfassende Überwachungsstrategie, die App-Metriken, Protokolle und Kosten abdeckt. Mithilfe dieser Strategie können Sie den Erfolg Ihrer Migration überprüfen, probleme schnell identifizieren und die Leistung und Kosten Ihrer neuen App optimieren.

Wenn Sie beabsichtigen, diese neue App mit Ihrer aktuellen App zu vergleichen, stellen Sie sicher, dass Ihr Schema auch die erforderlichen Benchmarks für den Vergleich erfasst. Weitere Informationen finden Sie unter Konfigurieren der Überwachung.

Konfigurieren der integrierten Authentifizierung

Wenn Ihre ursprüngliche App die integrierte Clientauthentifizierung verwendet hat (manchmal als Easy Auth bezeichnet), erstellen Sie sie in Ihrer neuen App neu. Wenn Sie beabsichtigen, dieselbe Clientregistrierung wiederzuverwenden, müssen Sie die authentifizierten Endpunkte der neuen App im Authentifizierungsanbieter festlegen.

Die Copilot Migrationskompetenz für Linux automatisiert keine integrierte Authentifizierungskonfiguration. Verwenden Sie die Registerkarten Azure CLI oder Azure Portal, um Ihre Authentifizierungseinstellungen manuell neu zu erstellen.

App-Code in der neuen Flex Consumption-Ressource bereitstellen.

Nachdem Sie Ihre neue Flex-Verbrauchsplan-App basierend auf den Einstellungen aus der ursprünglichen App konfiguriert haben, stellen Sie Ihren Code in Azure für die neuen App-Ressourcen bereit.

Vorsicht

Nach einer erfolgreichen Bereitstellung beginnen Trigger in Ihrer neuen App sofort mit der Verarbeitung von Daten aus verbundenen Diensten. Um duplizierte Daten zu minimieren und Datenverlust beim Starten der neuen App und Herunterfahren der ursprünglichen App zu verhindern, überprüfen Sie die Strategien, die Sie in Entschärfungen durch Triggertyp definiert haben.

Funktionen bieten verschiedene Möglichkeiten, Ihren Code entweder aus dem Codeprojekt oder als einsatzbereites Bereitstellungspaket bereitzustellen.

Tipp

Wenn Sie Ihren Projektcode in einem Quellcode-Repository verwalten, ist jetzt die perfekte Zeit zum Konfigurieren einer kontinuierlichen Bereitstellungspipeline. Mit der kontinuierlichen Bereitstellung können Sie Anwendungsupdates basierend auf Änderungen in einem verbundenen Repository automatisch bereitstellen.

Aktualisieren Sie Ihre vorhandenen Bereitstellungsworkflows, um Ihren Quellcode für Ihre neue App bereitzustellen:

Sie können auch einen neuen fortlaufenden Bereitstellungsworkflow für Ihre neue App erstellen. Weitere Informationen finden Sie unter Continuous deployment for Azure Functions.

Aufgaben nach der Migration

🎉 Herzlichen glückwunsch! Ihre App wird jetzt auf Flex Consumption ausgeführt. Um Ihren neuen Plan optimal zu verwenden, sollten Sie die folgenden optionalen Nachverfolgungsaufgaben in Betracht ziehen:

Überprüfen der grundlegenden Funktionalität

  1. Überprüfen Sie, ob die neue App in einem Flex-Verbrauchsplan ausgeführt wird:

    Die Copilot Migrationskompetenz für Linux überprüft Ihre neue App nach der Bereitstellung automatisch, einschließlich der Überprüfung, dass die App erreichbar ist und im Flex-Verbrauchsplan ausgeführt wird. Wenn Sie erneut validieren müssen, verwenden Sie diese Aufforderung:

    verify my flex consumption app <APP_NAME> is running correctly

  2. Verwenden Sie einen HTTP-Client, um mindestens einen HTTP-Triggerendpunkt in Ihrer neuen App aufzurufen, um sicherzustellen, dass er erwartungsgemäß reagiert.

Erfassen von Leistungs-Benchmarks

Führen Sie bei der Ausführung Ihrer neuen App die gleichen Leistungsvergleiche aus, die Sie aus Ihrer ursprünglichen App gesammelt haben, z. B.:

Vorgeschlagene Benchmark Kommentar
Kaltstart Messen Sie die Zeit von der ersten Anforderung an die erste Antwort nach einem Leerlaufzeitraum.
Durchsatz Messen Sie die maximalen Anforderungen pro Sekunde mithilfe von Ladetests, um zu bestimmen, wie die App gleichzeitige Anforderungen verarbeitet.
Latenz Verfolgen Sie die Reaktionszeiten von P50, P95 und P99 unter verschiedenen Lastbedingungen. Sie können diese Metriken in Application Insights überwachen.

Verwenden Sie diese Kusto-Abfrage, um die vorgeschlagenen Wartezeiten in Application Insights zu überprüfen:

requests
| where timestamp > ago(1d)
| summarize percentiles(duration, 50, 95, 99) by bin(timestamp, 1h)
| render timechart

Hinweis

Die Metriken des Flex Consumption Plans unterscheiden sich von denen des Consumption Plans. Beachten Sie beim Vergleichen der Leistung vor und nach der Migration, dass Sie unterschiedliche Metriken verwenden müssen, um ähnliche Leistungsmerkmale nachzuverfolgen. Weitere Informationen finden Sie unter Konfigurieren der Überwachung.

Erstellen benutzerdefinierter Dashboards

Mithilfe von Azure Monitor Metriken und Application Insights können Sie Dashboards im Azure Portal erstellen die Diagramme aus Plattformmetriken und Laufzeitprotokollen und Analysen anzeigen.

Erwägen Sie das Einrichten von Dashboards und Benachrichtigungen für Ihre wichtigsten Metriken im Azure-Portal. Weitere Informationen finden Sie unter Monitor your app in Azure.

Planeinstellungen verfeinern

Tatsächliche Leistungsverbesserungen und Kostenauswirkungen der Migration können je nach App-spezifischen Workloads und Konfiguration variieren. Der Flex-Verbrauchsplan bietet mehrere Einstellungen, die Sie anpassen können, um die Leistung Ihrer App zu verfeinern. Möglicherweise möchten Sie Anpassungen vornehmen, um das Verhalten der ursprünglichen App genauer abzugleichen oder Kosten im Vergleich zur Leistung auszugleichen. Weitere Informationen finden Sie unter Optimieren Ihrer App im Flex-Verbrauch-Artikel.

Aktualisieren der Ressourcenbereitstellungsdateien

Wenn Sie Ihre Funktions-App-Infrastruktur mithilfe von Bicep oder Terraform verwalten, aktualisieren Sie Ihre Bereitstellungsdateien so, dass sie jetzt auf den Flex-Verbrauchsplan abzielen. In diesem Abschnitt werden die wichtigsten Unterschiede zwischen Verbrauchs- und Flex-Verbrauchsplanressourcendefinitionen gezeigt.

Von Bedeutung

Sie können eine vorhandene Verbrauchsplan-App nicht direkt zu einem Flex-Verbrauchsmodell konvertieren. Sie müssen neue Ressourcen mit einem neuen Namen erstellen oder die vorhandenen Ressourcen löschen, bevor Sie die Flex-Verbrauchsentsprechungen bereitstellen.

Wichtige Unterschiede

Berücksichtigen Sie bei der Migration Ihrer Ressourcenbereitstellungen von "Verbrauch" zu "Flex-Verbrauch" die folgenden wichtigen Änderungen:

Aspekt Verbrauchsplan Flex-Verbrauchsplan
SKU für Hostingplan Y1 (Dynamisch) FC1 (FlexConsumption)
Plan erforderlich Optional (automatisch erstellt) Erforderlich (muss explizit sein)
Betriebssystem Windows oder Linux Nur Linux
Konfiguration App-Einstellungen functionAppConfig-Abschnitt
Speicherinhaltsfreigabe WEBSITE_CONTENTSHARE-Einstellung deployment.storage in functionAppConfig

Die folgenden Beispiele veranschaulichen die wichtigsten Unterschiede zwischen Ressourcendefinitionen des Verbrauchs- und Flex-Verbrauchsplans. Sie verwenden die vom System zugewiesene verwaltete Identität, sind aber nicht vollständig. Sie enthalten nicht alle erforderlichen Ressourcen wie Speicherkonten, Application Insights oder alle erforderlichen Rollenzuweisungen. Vollständige, produktionsfertige Beispiele finden Sie in den Flex Consumption IaC-Beispielen.

Verbrauchsplan (zuvor):

// Consumption plan (optional - auto-created if omitted)
resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  sku: {
    name: 'Y1'
    tier: 'Dynamic'
  }
  properties: {
    reserved: true // Linux
  }
}

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp,linux'
  properties: {
    serverFarmId: hostingPlan.id
    siteConfig: {
      linuxFxVersion: 'DOTNET-ISOLATED|8.0'
      appSettings: [
        { name: 'FUNCTIONS_EXTENSION_VERSION', value: '~4' }
        { name: 'FUNCTIONS_WORKER_RUNTIME', value: 'dotnet-isolated' }
        { name: 'AzureWebJobsStorage__accountName', value: storageAccount.name }
        { name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING__accountName', value: storageAccount.name }
        { name: 'WEBSITE_CONTENTSHARE', value: functionAppName }
        { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING', value: appInsights.properties.ConnectionString }
        { name: 'APPLICATIONINSIGHTS_AUTHENTICATION_STRING', value: 'Authorization=AAD' }
      ]
    }
  }
  identity: {
    type: 'SystemAssigned'
  }
}

Flex-Verbrauchsplan (nach):

// Flex Consumption plan (required)
resource hostingPlan 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: hostingPlanName
  location: location
  sku: {
    name: 'FC1'
    tier: 'FlexConsumption'
  }
  kind: 'functionapp'
  properties: {
    reserved: true
  }
}

// Deployment storage container (required)
resource deploymentContainer 'Microsoft.Storage/storageAccounts/blobServices/containers@2023-05-01' = {
  name: '${storageAccount.name}/default/deployments'
}

resource functionApp 'Microsoft.Web/sites@2023-12-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp,linux'
  properties: {
    serverFarmId: hostingPlan.id
    functionAppConfig: {
      deployment: {
        storage: {
          type: 'blobContainer'
          value: '${storageAccount.properties.primaryEndpoints.blob}deployments'
          authentication: {
            type: 'SystemAssignedIdentity'
          }
        }
      }
      scaleAndConcurrency: {
        maximumInstanceCount: 100
        instanceMemoryMB: 2048
      }
      runtime: {
        name: 'dotnet-isolated'
        version: '8.0'
      }
    }
    siteConfig: {
      appSettings: [
        { name: 'AzureWebJobsStorage__accountName', value: storageAccount.name }
        { name: 'APPLICATIONINSIGHTS_CONNECTION_STRING', value: appInsights.properties.ConnectionString }
        { name: 'APPLICATIONINSIGHTS_AUTHENTICATION_STRING', value: 'Authorization=AAD' }
      ]
    }
  }
  identity: {
    type: 'SystemAssigned'
  }
}

Hinweis

Wenn Sie APPLICATIONINSIGHTS_AUTHENTICATION_STRING mit Authorization=AAD verwenden, müssen Sie auch die Rolle Monitoring Metrics Publisher der verwalteten Identität der Funktions-App in der Application Insights-Ressource zuweisen.

Vollständige Bicep-Beispiele finden Sie in den Flex Consumption Bicep-Beispielen.

Abstimmung von Ressourcenbereitstellungen nach der Migration

Wenn Sie die Infrastruktur als Code verwenden, um Ihre Azure Ressourcenbereitstellungen zu verwalten, aktualisieren Sie Ihre Bereitstellungsdateien nach der Migration zu Flex-Verbrauch, um Konfigurationsabweichungen zu verhindern. Hier ist ein empfohlener Ansatz:

  1. Vermischen Sie keine manuellen und ressourcenbasierten Bereitstellungen: Wenn Sie die Azure CLI oder das Portal zum Erstellen Ihrer Flex Consumption-App während der Migration verwendet haben, aktualisieren Sie Ihre Ressourcendateien vor der nächsten Bereitstellung. Andernfalls könnte Ihr Deployment versuchen, die alten Ressourcen des Consumption Plans neu zu erstellen.

  2. Ressourcennamen aktualisieren oder Lebenszyklusverwaltung verwenden: Da Sie eine Consumption-App nicht in Flex Consumption umwandeln können, haben Sie zwei Optionen:

    • Neue Ressourcennamen: Aktualisieren Sie Ihren Bereitstellungscode, um neue Namen für den Hostingplan und die Funktions-App zu verwenden. Dieser Ansatz behält Ihre alten Ressourcen intakt, bis Sie sicher sind, dass die Migration erfolgreich war.
    • Importieren Sie vorhandene Ressourcen: Wenn Sie die gleichen Namen behalten möchten, löschen Sie zuerst die alten Ressourcen, und lassen Sie Ihre Bereitstellung die neuen Flex Consumption-Ressourcen erstellen. Alternativ können Sie die manuell erstellten Ressourcen mithilfe von terraform import in Ihren Terraform-Zustand importieren oder vorhandene Ressourcen in Bicep referenzieren.

  3. Überprüfen Sie die Statusausrichtung: Führen Sie nach dem Aktualisieren der Bereitstellungsdateien einen Plan- oder Vorschauvorgang (terraform plan oder az deployment group what-if) aus, um zu bestätigen, dass keine unerwarteten Änderungen auftreten.

  4. Aktualisieren Sie CI/CD-Pipelines: Wenn Ihre Bereitstellungspipelinen auf die alte Konfiguration des Verbrauchsplans verweisen, aktualisieren Sie sie, um die neuen Flex Consumption-Ressourcendefinitionen und Bereitstellungsmethoden zu verwenden.

Tipp

Um Unterbrechungen zu minimieren, sollten Sie sowohl die alte Konsum-App als auch die neue Flex-Verbrauch-App während eines Übergangszeitraums parallel ausführen. Aktualisieren Sie Ihre Bereitstellung, um die neue Flex Consumption-App zu verwalten, zu überprüfen, ob sie ordnungsgemäß funktioniert, und entfernen Sie dann die alten Ressourcen der Verbrauchs-App aus Azure und Ihren Bereitstellungsdateien.

Entfernen der ursprünglichen App (optional)

Tipp

Keine Eile hier. Bewahren Sie Ihre ursprüngliche App einige Tage oder Wochen auf, während Sie überprüfen, ob alles funktioniert. Der Verbrauchsplan berechnet nur die tatsächliche Nutzung, wodurch das Beibehalten der alten App (mit deaktivierten Triggern) weniger kostet.

Wenn Sie sicher sind, dass die neue App ordnungsgemäß funktioniert, können Sie das Original bereinigen. Dieser Schritt ist optional – einige Teams behalten die alte App als Referenz- oder Rollbackoption bei.

Von Bedeutung

Diese Aktion löscht Ihre ursprüngliche Funktions-App. Der Verbrauchsplan bleibt erhalten, wenn andere Apps ihn verwenden. Bevor Sie fortfahren, stellen Sie sicher, dass Sie:

  • Alle Funktionen wurden erfolgreich zur neuen Flex Consumption-App migriert.
  • Überprüfen Sie, ob kein Datenverkehr an die ursprüngliche App weitergeleitet wird.
  • Sichern Sie alle relevanten Protokolle, Konfigurationen oder Daten, die möglicherweise zur Referenz erforderlich sind.

Die Copilot Migrationskompetenz für Linux kann die ursprüngliche App entfernen, wenn Sie bereit sind. Copilot bittet immer um Ihre explizite Bestätigung, bevor etwas gelöscht wird. Verwenden Sie diese Eingabeaufforderung:

delete my original consumption app <ORIGINAL_APP_NAME>

Problembehandlung und Wiederherstellungsstrategien

Die meisten Migrationen werden ohne Probleme abgeschlossen. Wenn etwas nicht wie erwartet funktioniert, probieren Sie die folgenden Lösungen für häufige Probleme aus:

Thema Lösung
Leistungsprobleme beim Kaltstart • Überprüfen der Parallelitätseinstellungen
• Überprüfen auf fehlende Abhängigkeiten
Fehlende Bindungen • Überprüfen von Erweiterungspaketen
• Aktualisieren von Bindungskonfigurationen
Berechtigungsfehler • Überprüfen von Identitätszuweisungen und Rollenberechtigungen
Probleme mit der Netzwerkkonnektivität • Überprüfen von Zugriffsbeschränkungen und Netzwerkeinstellungen
Fehlende Anwendungserkenntnisse • Erneutes Erstellen der Application Insights-Verbindung
Die App kann nicht gestartet werden. Allgemeine Schritte zur Problembehandlung
Trigger verarbeiten keine Ereignisse Allgemeine Schritte zur Problembehandlung

Wenn Bei der Migration einer Produktions-App Probleme auftreten, sollten Sie bei der Problembehandlung das Rollback der Migration auf die ursprüngliche App in Betracht ziehen.

Allgemeine Schritte zur Problembehandlung

Führen Sie diese Schritte in Fällen aus, in denen die neue App nicht startet oder Funktionstrigger keine Ereignisse verarbeiten:

  1. Wählen Sie auf ihrer neuen App-Seite im portal AzureDiagnose und Lösen von Problemen im linken Bereich der App-Seite aus. Wählen Sie Verfügbarkeit und Leistung aus und überprüfen Sie den Detektor für Ausfall oder Berichtsfehler der Funktions-App. Weitere Informationen finden Sie unter Azure Functions Diagnostics overview.

  2. Wählen Sie auf der App-Seite "Monitoring>Application Insights>View Application Insights"-Daten aus, und wählen Sie dann "Fehler untersuchen"> aus, und überprüfen Sie auf Fehlerereignisse.

  3. Wählen Sie Überwachungsprotokolle> aus, und führen Sie diese Kusto-Abfrage aus, um diese Tabellen auf Fehler zu überprüfen:

    traces
    | where severityLevel == 3
    | where cloud_RoleName == "<APP_NAME>"
    | where timestamp > ago(1d)
    | project timestamp, message, operation_Name, customDimensions
    | order by timestamp desc

    Ersetzen Sie in diesen Abfragen <APP_NAME> durch den Namen Ihrer neuen App. Diese Abfragen überprüfen auf Fehler am letzten Tag (where timestamp > ago(1d)).

  4. Wählen Sie zurück auf der App-Seite"Einstellungsumgebungsvariablen>" aus, und stellen Sie sicher, dass alle wichtigen Anwendungseinstellungen ordnungsgemäß übertragen werden. Suchen Sie nach veralteten Einstellungen , die möglicherweise falsch migriert wurden, oder nach Tippfehlern oder falschen Verbindungszeichenfolgen. Überprüfen Sie die Standardmäßige Hostspeicherverbindung.

  5. Wählen Sie Einstellungen> und Identität aus und überprüfen Sie, ob die erwarteten Identitäten existieren und den richtigen Rollen zugewiesen sind.

  6. Vergewissern Sie sich in Ihrem Code, dass alle Bindungskonfigurationen korrekt sind, und achten Sie dabei besonders auf die Verbindungszeichenfolgen-Namen, Speicherwarteschlangen- und Containernamen sowie die Einstellungen für Consumergruppen bei Event Hubs-Triggern.

Rollbackschritte für kritische Produktions-Apps

Wenn Sie das Problem nicht beheben können, ziehen Sie in Betracht, zur ursprünglichen App zurückzukehren, während Sie die Problembehebung fortsetzen.

  1. Wenn die ursprüngliche App beendet wird, starten Sie sie neu:

    Bitte Copilot, die ursprüngliche App neu zu starten und die Migration rückgängig zu machen.

    restart my original consumption app <ORIGINAL_APP_NAME>

  2. Wenn Sie neue Warteschlangen, Themen oder Container erstellt haben, stellen Sie sicher, dass Clients zurück zu den ursprünglichen Ressourcen umgeleitet werden.

  3. Wenn Sie DNS oder benutzerdefinierte Domänen geändert haben, stellen Sie diese Änderungen so zurück, dass sie auf die ursprüngliche App verweisen.

Senden von Feedback

Wenn Sie Probleme mit Ihrer Migration mithilfe dieses Artikels haben oder weiteres Feedback zu diesem Leitfaden geben möchten, verwenden Sie eine der folgenden Methoden, um Hilfe zu erhalten oder Ihr Feedback zu geben:

  • Last updated on