Azure Container Apps-Hosting von Azure Functions

  • Artikel

Azure Functions bietet integrierte Unterstützung für die Entwicklung, Bereitstellung und Verwaltung containerisierter Funktions-Apps in Azure Container Apps. Verwenden Sie Azure Container Apps, um Ihre Funktions-App-Container zu hosten, wenn Sie Ihre ereignisgesteuerten Funktionen in Azure in der gleichen Umgebung ausführen müssen wie andere Microservices, APIs, Websites, Workflows oder containergehostete Programme. Das Container Apps-Hosting ermöglicht die Ausführung Ihrer Funktionen in einer vollständig verwalteten Kubernetes-basierten Umgebung mit integrierter Unterstützung für Open-Source-Überwachung, mTLS, Dapr und KEDA (Kubernetes Event-Driven Autoscaling).

Sie können Ihren Funktionscode in jedem Sprachstapel schreiben, der von Functions unterstützt wird. Sie können dieselben Functions-Trigger und -Bindungen mit der ereignisgesteuerten Skalierung verwenden. Außerdem können Sie vorhandene Functions-Clienttools und das Azure-Portal verwenden, um Container zu erstellen, Funktions-App-Container in Container Apps bereitzustellen und Continuous Deployment zu konfigurieren.

Durch die Container Apps-Integration gelten die Netzwerk- und Einblickkonfigurationen, die auf Ebene der Container App-Umgebung definiert werden, für Ihre Funktions-App, genau wie für alle Microservices, die in einer Container Apps-Umgebung ausgeführt werden. Sie erhalten auch die anderen cloudnativen Funktionen von Container Apps, einschließlich KEDA, Dapr und Envoy. Sie können Application Insights weiterhin verwenden, um die Ausführung Ihrer Funktionen zu überwachen, und Ihre Funktions-App kann auf dieselben virtuellen Netzwerkressourcen zugreifen, die von der Umgebung bereitgestellt werden.

Eine allgemeine Übersicht über Optionen für das Containerhosting in Azure Functions finden Sie unter Linux-Containerunterstützung in Azure Functions.

Hosting und Workloadprofile

Es gibt zwei primäre Hostingpläne für Container Apps: einen serverlosen Verbrauchsplan und einen dedizierten Plan, der Workloadprofile verwendet, um Ihre Bereitstellungsressourcen besser zu steuern. Ein Workloadprofil bestimmt den Umfang von Compute- und Arbeitsspeicherressourcen, die für die in einer Umgebung bereitgestellten Container-Apps verfügbar sind. Die Konfiguration dieser Profile wird auf die unterschiedlichen Anforderungen Ihrer Anwendungen abgestimmt.

Das Workloadprofil „Verbrauch“ ist das Standardprofil, das allen Workloadprofilen vom Typ Umgebung hinzugefügt wird. Sie können Ihrer Umgebung dedizierte Workloadprofile hinzufügen, während Sie eine Umgebung erstellen oder nachdem die Umgebung erstellt wurde. Weitere Informationen zu Workloadprofilen finden Sie unter Workloadprofile in Azure Container Apps.

Das Hosten containerisierter Funktions-Apps durch Container Apps wird in allen Regionen mit Container Apps-Unterstützung unterstützt.

Wenn Ihre App keine spezifischen Hardwareanforderungen hat, können Sie Ihre Umgebung entweder im Rahmen eines Verbrauchstarifs oder im Rahmen eines dedizierten Tarifs mit dem standardmäßigen Workloadprofil „Verbrauch“ ausführen. Beim Ausführen von Funktionen in Container Apps wird Ihnen nur die Nutzung von Container Apps in Rechnung gestellt. Weitere Informationen finden Sie auf der Preisseite von Azure Container Apps.

Azure Functions in Azure Container Apps unterstützt Hosting mit GPU-Unterstützung im dedizierten Plan mit Workloadprofilen.

Informationen zum Erstellen und Bereitstellen eines Funktions-App-Containers in Container Apps unter Verwendung des Standardplans „Verbrauch“ finden Sie unter Erstellen Ihrer ersten containerisierten Funktionen in Azure Container Apps.

Informationen zum Erstellen einer Container Apps-Umgebung mit Workloadprofilen und zum Bereitstellen eines Funktions-App-Containers für eine bestimmte Workload finden Sie im Artikel Arbeiten mit Containern und Azure Functions.

Funktionen in Containern

Um das Container Apps-Hosting zu verwenden, muss Ihr Code in einer Funktions-App in einem von Ihnen erstellten und verwalteten Linux-Container ausgeführt werden. Functions verwaltet eine Reihe von sprachspezifischen Basisimages, mit denen Sie Ihre containerisierten Funktions-Apps generieren können.

Wenn Sie ein Codeprojekt mit Azure Functions Core Tools erstellen und die --docker-Option einschließen, generiert Core Tools die Dockerfile mit dem korrekten Basisimage, das Sie bei der Erstellung Ihres Containers als Ausgangspunkt verwenden können.

Wichtig

Wenn Sie eigene Container erstellen, müssen Sie das Basisimage Ihres Containers auf das neueste unterstützte Basisimage aktualisieren. Unterstützte Basisimages für Azure Functions sind sprachspezifisch und sind unter Repositorys für Azure Functions-Basisimages verfügbar.

Das Functions-Team ist bestrebt, monatliche Updates für diese Basisimages zu veröffentlichen. Regelmäßige Updates umfassen die neuesten Updates der Nebenversion und Sicherheitskorrekturen für Functions-Runtime und -Sprachen. Sie sollten Ihren Container regelmäßig aus dem neuesten Basisimage aktualisieren und die aktualisierte Version Ihres Containers erneut bereitstellen.

Wenn Sie Änderungen am Funktionscode vornehmen, müssen Sie Ihr Containerimage neu erstellen und erneut veröffentlichen. Weitere Informationen finden Sie unter Aktualisieren eines Images in der Registrierung.

Bereitstellungsoptionen

Azure Functions unterstützt derzeit die folgenden Bereitstellungsmethoden für eine containerisierte Funktions-App in Azure Container Apps:

Integration in ein virtuelles Netzwerk

Wenn Sie Ihre Funktions-Apps in einer Container Apps-Umgebung hosten, können Ihre Funktionen sowohl intern als auch extern zugängliche virtuelle Netzwerke nutzen. Weitere Informationen zu Umgebungsnetzwerken finden Sie unter Netzwerk in der Azure Container Apps-Umgebung.

Konfigurieren von Skalierungsregeln

Azure Functions in Container Apps wurde zum Konfigurieren der Skalierungsparameter und -regeln gemäß dem Ereignisziel konzipiert. Sie müssen sich keine Gedanken über die Konfiguration der KEDA-skalierten Objekte machen. Sie können die minimale und maximale Replikatanzahl weiterhin festlegen, wenn Sie Ihre Funktions-App erstellen oder ändern. Der folgende Azure CLI-Befehl legt die minimale und maximale Replikatanzahl fest, wenn eine neue Funktions-App in einer Container Apps-Umgebung aus einer Azure Container Registry-Instanz erstellt wird:

az functionapp create --name <APP_NAME> --resource-group <MY_RESOURCE_GROUP> --max-replicas 15 --min-replicas 1 --storage-account <STORAGE_NAME> --environment MyContainerappEnvironment --image <LOGIN_SERVER>/azurefunctionsimage:v1 --registry-username <USERNAME> --registry-password <SECURE_PASSWORD> --registry-server <LOGIN_SERVER>

Der folgende Befehl legt die gleiche minimale und maximale Replikatanzahl für eine vorhandene Funktions-App fest:

az functionapp config container set --name <APP_NAME> --resource-group <MY_RESOURCE_GROUP> --max-replicas 15 --min-replicas 1

Verwaltete Ressourcengruppen

Azure Functions auf Container Apps führt Ihre containerisierten Funktions-App-Ressourcen in speziell verwalteten Ressourcengruppen aus. Diese verwalteten Ressourcengruppen tragen dazu bei, die Integrität Ihrer Apps zu schützen, indem sie unbeabsichtigte oder nicht autorisierte Änderungen oder Löschungen von Ressourcen in der verwalteten Gruppe verhindern, auch durch Dienstprinzipale.

Eine verwaltete Ressourcengruppe wird bei der ersten Erstellung von Funktions-App-Ressourcen in einer Container Apps-Umgebung erstellt. Container Apps-Ressourcen, die von Ihrer containerisierten Funktions-App benötigt werden, werden in dieser verwalteten Ressourcengruppe ausgeführt. Alle anderen Funktions-Apps, die Sie in derselben Umgebung erstellen, verwenden diese vorhandene Gruppe.

Eine verwaltete Ressourcengruppe wird automatisch entfernt, nachdem alle Funktions-App-Containerressourcen aus der Umgebung entfernt wurden. Die verwaltete Ressourcengruppe ist zwar sichtbar, Änderungs- oder Entfernungsversuche führen jedoch zu einem Fehler. Wenn Sie eine verwaltete Ressourcengruppe aus einer Umgebung entfernen möchten, müssen Sie alle Funktions-App-Containerressourcen entfernen. Daraufhin wird sie automatisch entfernt.

Sollten Probleme mit diesen verwalteten Ressourcengruppen auftreten, wenden Sie sich an den Support.

Überlegungen zum Hosting von Container-Apps

Beachten Sie beim Bereitstellen Ihrer Funktions-App-Container in Container Apps die folgenden Überlegungen:

  • Während alle Trigger verwendet werden können, können nur die folgenden Trigger (von null Instanzen) dynamisch skaliert werden, wenn sie in einer Container Apps-Umgebung ausgeführt werden:
    • Azure Event Grid
    • Azure Event Hubs
    • Azure Blob Storage (ereignisbasiert)
    • Azure Queue Storage
    • Azure Service Bus
    • Durable Functions (MSSQL-Speicheranbieter)
    • HTTP
    • Kafka
    • Timer
  • Diese Einschränkungen gelten für Kafka-Trigger:
    • Der Protokollwert ssl wird nicht unterstützt, wenn das Hosting in Container Apps erfolgt. Verwenden Sie einen anderen Protokollwert.
    • Damit ein Kafka-Trigger dynamisch skaliert wird, wenn eine Verbindung mit Event Hubs besteht, muss die username-Eigenschaft in eine Anwendungseinstellung aufgelöst werden, die den tatsächlichen Wert des Benutzernamens enthält. Wenn der standardmäßige $ConnectionString-Wert verwendet wird, kann der Kafka-Trigger die App nicht dynamisch skalieren.
  • Für die integrierten Container Apps-Richtliniendefinitionen gelten derzeit nur Richtlinien auf Umgebungsebene für Azure Functions-Container.
  • Sie können verwaltete Identitäten für diese Verbindungen verwenden:
  • Sie können derzeit keine Bereitstellung einer gehosteten Funktions-App von Container Apps zwischen Ressourcengruppen oder zwischen Abonnements verschieben. Stattdessen müssen Sie die vorhandene containerisierte App-Bereitstellung in einer neuen Ressourcengruppe, einem neuen Abonnement oder einer neuen Region neu erstellen.
  • Wenn Sie Container Apps verwenden, besitzen Sie keinen direkten Zugriff auf die Kubernetes-APIs auf niedrigerer Ebene.
  • Die containerapp-Erweiterung steht in Konflikt mit der appservice-kube-Erweiterung in der Azure CLI. Wenn Sie Apps zuvor in Azure Arc veröffentlicht haben, führen Sie az extension list aus, und stellen Sie sicher, dass appservice-kube nicht installiert ist. Wenn dies doch der Fall ist, kann die Entfernung erfolgen, indem Sie az extension remove -n appservice-kube ausführen.

Nächste Schritte