Componentes do Dapr nos Aplicativos de Contêiner do Azure
O Dapr usa um design modular em que a funcionalidade é entregue como um componente. O uso de componentes do Dapr é opcional e ditado exclusivamente pelas necessidades do seu aplicativo.
Componentes do Dapr em aplicativos de contêiner são recursos de nível de ambiente que:
- pode fornecer um modelo de abstração plugável para se conectar aos serviços externos de suporte;
- pode ser compartilhado entre aplicativos de contêiner ou com escopo para aplicativos de contêiner específicos; e
- pode usar segredos Dapr para recuperar metadados de configuração com segurança.
Neste guia, você aprenderá a configurar componentes do Dapr para seus serviços dos Aplicativos de Contêiner do Azure.
Esquema de componente
No projeto de código aberto Dapr, todos os componentes estão em conformidade com o esquema básico a seguir.
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]
Nos Aplicativos de Contêiner do Azure, o esquema acima é ligeiramente simplificado para dar suporte a componentes do Dapr e remover campos desnecessários, incluindo apiVersion, kind e propriedades redundantes de metadados e especificações.
componentType: [COMPONENT-TYPE]
version: v1
initTimeout: [TIMEOUT-DURATION]
ignoreErrors: [BOOLEAN]
metadata:
- name: [METADATA-NAME]
value: [METADATA-VALUE]
Escopos do componente
Por padrão, todos os aplicativos de contêiner habilitados para Dapr no mesmo ambiente carregam o conjunto completo de componentes implantados. Para garantir que apenas os aplicativos de contêiner apropriados carreguem componentes em runtime, os escopos do aplicativo devem ser usados. No exemplo a seguir, o componente só será carregado pelos dois aplicativos de contêiner habilitados para Dapr com as IDs de aplicativo do Dapr APP-ID-1 e APP-ID-2:
componentType: [COMPONENT-TYPE]
version: v1
initTimeout: [TIMEOUT-DURATION]
ignoreErrors: [BOOLEAN]
metadata:
- name: [METADATA-NAME]
value: [METADATA-VALUE]
scopes:
- [APP-ID-1]
- [APP-ID-2]
Observação
Os escopos do componente do Dapr correspondem à ID do aplicativo Dapr de um aplicativo de contêiner, não ao nome do aplicativo de contêiner.
Conexão a serviços externos via Dapr
Há algumas abordagens com suporte em aplicativos de contêiner para estabelecer com segurança conexões com serviços externos para componentes do Dapr.
- Usar a identidade gerenciada
- Usando uma referência de componente de repositório de segredos do Dapr ao criar qualquer um dos seguintes:
- Um repositório de segredos do Azure Key Vault, que usa identidade gerenciada ou
- Segredos do Kubernetes gerenciados pela plataforma
Usar a identidade gerenciada
Para serviços hospedados no Azure, o Dapr pode usar a identidade gerenciada dos aplicativos de contêiner com escopo para autenticar no provedor de serviços de back-end. Ao usar a identidade gerenciada, você não precisa incluir informações secretas em um manifesto de componente. O uso da identidade gerenciada é preferencial, pois elimina o armazenamento de entradas confidenciais em componentes e não requer o gerenciamento de um repositório secreto.
Observação
O azureClientId campo de metadados (a ID do cliente da identidade gerenciada) é necessário para qualquer componente que se autentique com a identidade gerenciada atribuída pelo usuário.
Usar uma referência de componente do Repositório Secreto do Dapr
Quando você cria componentes do Dapr para serviços não habilitados para Entra ID, determinados campos de metadados exigem valores de entrada confidenciais. A abordagem recomendada para recuperar esses segredos é fazer referência a um componente existente do repositório secreto Dapr que acessa com segurança informações secretas.
Para configurar uma referência:
- Crie um componente de repositório de segredos do Dapr usando o esquema dos Aplicativos de Contêiner do Azure. O tipo de componente para todos os repositórios secretos Dapr com suporte começa com
secretstores.. - Crie componentes extras, conforme necessário, que referenciem o componente do repositório de segredos do Dapr que você criou para recuperar a entrada de metadados confidenciais.
Criar um componente do repositório de segredos do Dapr
Ao criar um componente de repositório de segredos nos Aplicativos de Contêiner do Azure, você pode fornecer informações confidenciais na seção de metadados de qualquer uma das seguintes maneiras:
- Para um repositório de segredos do Azure Key Vault, use a identidade gerenciada para estabelecer a conexão.
- Para repositórios de segredos que não são do Azure, use segredos do Kubernetes gerenciados pela plataforma que são definidos diretamente como parte do manifesto do componente.
Repositórios de segredos do Azure Key Vault
O componente a seguir mostra a configuração mais simples possível do repositório de segredos usando um repositório de segredos do Azure Key Vault. Neste exemplo, os aplicativos editores e assinantes são configurados para ter uma identidade gerenciada atribuída pelo sistema ou pelo usuário com as permissões apropriadas na instância do Azure Key Vault.
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
Segredos do Kubernetes gerenciados pela plataforma
Segredos do Kubernetes, variáveis de ambiente local e repositórios de segredos do Dapr de arquivo local não têm suporte nos Aplicativos de Contêiner do Azure. Como alternativa ao repositório de segredos padrão do Dapr no Kubernetes upstream, os Aplicativos de Contêiner do Azure fornecem uma abordagem gerenciada por plataforma para criar e aproveitar os segredos do Kubernetes.
Essa configuração de componente define o valor confidencial como um parâmetro secreto que pode ser referenciado na seção de metadados. Essa abordagem pode ser usada para se conectar a serviços não Azure ou em cenários de desenvolvimento/teste para implantar componentes rapidamente por meio da CLI sem configurar um repositório secreto ou uma identidade gerenciada.
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
Referenciando componentes do repositório secreto Dapr
Depois de criar um repositório de segredos do Dapr usando uma das abordagens anteriores, você pode referenciar esse repositório de outros componentes do Dapr no mesmo ambiente. No exemplo a seguir, o campo secretStoreComponent é preenchido com o nome do repositório de segredos especificado nos exemplos anteriores, onde sb-root-connectionstring é armazenado.
componentType: pubsub.azure.servicebus.queue
version: v1
secretStoreComponent: "my-secret-store"
metadata:
- name: connectionString
secretRef: sb-root-connectionstring
scopes:
- publisher-app
- subscriber-app
Exemplos de componente
Para criar um componente do Dapr por meio da CLI de Aplicativos de Contêiner, você pode usar um manifesto YAML de aplicativos de contêiner. Ao configurar vários componentes, você precisará criar e aplicar um arquivo YAML separado para cada componente.
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