Freigeben über

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:

Sie können Ihre containerisierten Apps mithilfe von Azure Pipelines oder GitHub Actions kontinuierlich aus Quellcode bereitstellen. Das Functions-Feature für die kontinuierliche Bereitstellung wird bei der Bereitstellung in Container Apps derzeit nicht unterstützt.

Autorisierung mit verwalteter Identität

Um die beste Sicherheit zu gewährleisten, sollten Sie mithilfe der Microsoft Entra-Authentifizierung und der Autorisierung über verwaltete Identität eine Verbindung mit Remotediensten herstellen. Sie können verwaltete Identitäten für diese Verbindungen verwenden:

Bei der Ausführung in Container-Apps können Sie Microsoft Entra ID mit verwalteten Identitäten für alle Bindungserweiterungen verwenden, die verwaltete Identitäten unterstützen. Derzeit unterstützen nur diese Bindungserweiterungen die ereignisgesteuerte Skalierung bei Verwendung der Authentifizierung mit verwalteter Identität:

  • Azure Event Hubs
  • Azure Queue Storage
  • Azure Service Bus

Verwenden Sie für andere Bindungen feste Replikate bei Verwendung der Authentifizierung mit verwalteter Identität. Weitere Informationen finden Sie im Functions-Leitfaden für Entwickelnde.

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.

Ereignisgesteuerte Skalierung

Alle Functions-Trigger können in Ihrer containerisierten Funktions-App verwendet werden. Es können nur diese Trigger (ab null Instanzen) basierend auf empfangenen Ereignissen 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

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.

Anwendungsprotokollierung

Sie können Ihre in Container-Apps gehostete containerisierte Funktions-App überwachen, indem Sie Azure Monitor Application Insights auf die gleiche Weise wie mit Apps überwachen, die in Azure Functions gehostet werden. Weitere Informationen finden Sie unter Überwachen von Azure Functions.

Für Bindungen, die die ereignisgesteuerte Skalierung unterstützen, werden Skalierungsereignisse als Ereignisse der Typen FunctionsScalerInfo und FunctionsScalerError in Ihrem Log Analytics-Arbeitsbereich protokolliert. Weitere Informationen finden Sie unter Anwendungsprotokollierung in Azure Container Apps.

Überlegungen zum Hosting von Container-Apps

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

  • 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 $ConnectionString-Standardwert 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:
  • Standardmäßig überwacht eine containerisierte Funktions-App Port 80 auf eingehende Anforderungen. Wenn Ihre App einen anderen Port verwenden muss, verwenden Sie die Anwendungseinstellung WEBSITES_PORT, um diesen Standardport zu ändern.
  • Sie sind derzeit nicht in der Lage, integrierte fortlaufende Bereitstellungsfeatures beim Hosten in Container-Apps zu verwenden. Die Bereitstellung muss stattdessen aus dem Quellcode mithilfe von Azure Pipelines oder GitHub Actions stattfinden.
  • 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.