Share via

Dapr-Komponenten in Azure-Container-Apps

  • Artikel

Dapr verwendet ein modulares Design, bei dem Funktionalität als Komponente bereitgestellt wird. Die Verwendung von Dapr-Komponenten ist optional und wird ausschließlich von den Anforderungen Ihrer Anwendung bestimmt.

Dapr-Komponenten in Container-Apps sind Ressourcen auf Umgebungsebene, die Folgendes können:

  • Ein austauschbares („pluggable“) Abstraktionsmodell bereitstellen, um eine Verbindung mit externen Unterstützungsdiensten herzustellen.
  • Von Container-Apps gemeinsam genutzt oder auf bestimmte Container-Apps begrenzt werden.
  • Dapr-Geheimnisse verwenden, um Konfigurationsmetadaten sicher abzurufen.

In diesem Handbuch erfahren Sie, wie Sie Dapr-Komponenten für Ihre Azure-Container-Apps-Dienste konfigurieren.

Komponentenschema

Im Open-Source-Projekt Dapr entsprechen alle Komponenten dem folgendenBasisschema.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: [COMPONENT-NAME]
  namespace: [COMPONENT-NAMESPACE]
spec:
  type: [COMPONENT-TYPE]
  version: v1
  initTimeout: [TIMEOUT-DURATION]
  ignoreErrors: [BOOLEAN]
  metadata:
    - name: [METADATA-NAME]
      value: [METADATA-VALUE]

In Container Apps wurde das obige Schema leicht vereinfacht, um Dapr-Komponenten zu unterstützen und unnötige Felder zu entfernen, einschließlich apiVersion, kind und redundanter Metadaten und Eigenschaften von Spezifikationen.

componentType: [COMPONENT-TYPE]
version: v1
initTimeout: [TIMEOUT-DURATION]
ignoreErrors: [BOOLEAN]
metadata:
  - name: [METADATA-NAME]
    value: [METADATA-VALUE]

Komponentenbereiche

Standardmäßig laden alle Dapr-fähigen Container-Apps innerhalb derselben Umgebung den vollständigen Satz an bereitgestellten Komponenten. Um sicherzustellen, dass nur die entsprechenden Container-Apps Komponenten zur Laufzeit laden, sollten Anwendungsbereiche verwendet werden. Im folgenden Beispiel wird die Komponente nur von den beiden Dapr-fähigen Container-Apps mit den Dapr-Anwendungs-IDs APP-ID-1 und APP-ID-2 geladen:

componentType: [COMPONENT-TYPE]
version: v1
initTimeout: [TIMEOUT-DURATION]
ignoreErrors: [BOOLEAN]
metadata:
  - name: [METADATA-NAME]
    value: [METADATA-VALUE]
scopes:
  - [APP-ID-1]
  - [APP-ID-2]

Hinweis

Dapr-Komponentenbereiche entsprechen der Dapr-Anwendungs-ID einer Container-App, nicht dem Container-App-Namen.

Herstellen einer Verbindung mit externen Diensten über Dapr

Es gibt ein paar Ansätze, die in Container-Apps unterstützt werden, um sichere Verbindungen mit externen Diensten für Dapr-Komponenten herzustellen.

  1. Verwenden einer verwalteten Identität
  2. Verwenden eines Dapr-Verweises auf Komponenten des Geheimspeichers durch Erstellen einer der folgenden Komponenten:

Verwenden einer verwalteten Identität

Für in Azure gehostete Dienste kann Dapr die verwaltete Identität der Container-Apps mit Gültigkeitsbereich verwenden, um sich beim Back-End-Dienstanbieter zu authentifizieren. Wenn Sie eine verwaltete Identität verwenden, müssen Sie keine Geheimnisinformationen in ein Komponentenmanifest einschließen. Die Verwendung verwalteter Identitäten wird bevorzugt, da die Speicherung vertraulicher Eingaben in Komponenten dadurch vermieden wird und keine Verwaltung eines Geheimnisspeichers erforderlich ist.

Hinweis

Das Metadatenfeld azureClientId (die Client-ID der verwalteten Identität) ist für jede Komponente erforderlich, die sich mit einer benutzerseitig zugewiesenen verwalteten Identität authentifiziert.

Verwenden eines Dapr-Geheimnisspeicher-Komponentenverweises

Wenn Sie Dapr-Komponenten für nicht Zugangs-aktivierte Dienste erstellen, erfordern bestimmte Metadatenfelder vertrauliche Eingabewerte. Der empfohlene Ansatz zum Abrufen dieser Geheimnisse besteht darin, auf eine vorhandene Dapr-Geheimnisspeicherkomponente zu verweisen, die sicher auf Geheimnisinformationen zugreift.

So richten Sie einen Verweis ein:

  1. Erstellen Sie eine Dapr-Geheimnisspeicherkomponente mithilfe des Azure-Container-Apps-Schemas. Der Komponententyp für alle unterstützten Dapr-Geheimspeicher beginnt mit secretstores..
  2. Erstellen Sie (nach Bedarf) zusätzliche Komponenten, die auf die Dapr-Geheimnisspeicherkomponente, die Sie erstellt haben, verweisen, um die Eingabe vertraulicher Metadaten abzurufen.

Erstellen einer Dapr-Komponente für den geheimen Speicher

Beim Erstellen einer Geheimnisspeicherkomponente in Azure-Container-Apps können Sie vertrauliche Informationen im Abschnitt der Metadaten auf eine der folgenden Weisen bereitstellen:

Azure Key Vault-Geheimnisspeicher

Die folgende Komponente zeigt die einfachste Konfiguration des geheimen Speichers mit einem geheimen Azure Key Vault-Speicher. In diesem Beispiel werden Herausgeber- und Abonnentenanwendungen so konfiguriert, dass sie sowohl eine systemseitig als auch eine benutzerseitig zugewiesene verwaltete Identität mit entsprechenden Berechtigungen für die Azure Key Vault-Instanz haben.

componentType: secretstores.azure.keyvault
version: v1
metadata:
  - name: vaultName
    value: [your_keyvault_name]
  - name: azureEnvironment
    value: "AZUREPUBLICCLOUD"
  - name: azureClientId # Only required for authenticating user-assigned managed identity
    value: [your_managed_identity_client_id]
scopes:
  - publisher-app
  - subscriber-app
Plattformseitig verwaltete Kubernetes-Geheimnisse

Kubernetes-Geheimnisse, lokale Umgebungsvariablen und lokale Dapr-Dateigeheimnisspeicher werden in den Azure-Container Apps nicht unterstützt. Als Alternative zum standardmäßigen Kubernetes-Geheimnisspeicher von Dapr bietet Azure Container Apps einen plattformseitig verwalteten Ansatz zum Erstellen und Nutzen von Kubernetes-Geheimnissen.

Diese Komponentenkonfiguration definiert den vertraulichen Wert als Geheimnisparameter, auf den im Metadatenabschnitt verwiesen werden kann. Dieser Ansatz kann verwendet werden, um eine Verbindung mit Nicht-Azure-Diensten herzustellen, oder um in Entwicklungs-/Testszenarien Komponenten schnell über die CLI bereitzustellen, ohne einen Geheimnisspeicher oder eine verwaltete Identität einrichten zu müssen.

componentType: secretstores.azure.keyvault
version: v1
metadata:
  - name: vaultName
    value: [your_keyvault_name]
  - name: azureEnvironment
    value: "AZUREPUBLICCLOUD"
  - name: azureTenantId
    value: "[your_tenant_id]"
  - name: azureClientId 
    value: "[your_client_id]"
  - name: azureClientSecret
    secretRef: azClientSecret
secrets:
  - name: azClientSecret
    value: "[your_client_secret]"
scopes:
  - publisher-app
  - subscriber-app

Verweisen auf Dapr-Geheimnisspeicherkomponenten

Nachdem Sie einen Dapr-Geheimnisspeicher mit einem der oben genannten Ansätze erstellt haben, können Sie aus anderen Dapr-Komponenten in derselben Umgebung auf diesen Geheimnisspeicher verweisen. Im folgenden Beispiel wird das secretStoreComponent-Feld mit dem Namen des in den vorigen Beispielen angegebenen Geheimnisspeichers ausgefüllt, in dem die sb-root-connectionstring gespeichert ist.

componentType: pubsub.azure.servicebus.queue
version: v1
secretStoreComponent: "my-secret-store"
metadata:
  - name: connectionString
    secretRef: sb-root-connectionstring
scopes:
  - publisher-app
  - subscriber-app

Komponentenbeispiele

Um eine Dapr-Komponente über die Container Apps CLI zu erstellen, können Sie ein YAML-Manifest für Container-Apps verwenden. Beim Konfigurieren mehrerer Komponenten müssen Sie für jede Komponente eine separate YAML-Datei erstellen und anwenden.

az containerapp env dapr-component set --name ENVIRONMENT_NAME --resource-group RESOURCE_GROUP_NAME --dapr-component-name pubsub --yaml "./pubsub.yaml"

# pubsub.yaml for Azure Service Bus component
componentType: pubsub.azure.servicebus.queue
version: v1
secretStoreComponent: "my-secret-store"
metadata:
  - name: connectionString
    secretRef: sb-root-connectionstring
scopes:
  - publisher-app
  - subscriber-app

Nächste Schritte

Erfahren Sie, wie Sie die Resilienz der Dapr-Komponenten festlegen.