The documentation you are viewing is for Dapr v1.6 which is an older version of Dapr. For up-to-date documentation, see the latest version.
Azure CosmosDB binding spec
To setup Azure CosmosDB binding create a component of type
bindings.azure.cosmosdb. See this guide on how to create and apply a binding configuration.
apiVersion: dapr.io/v1alpha1 kind: Component metadata: name: <NAME> namespace: <NAMESPACE> spec: type: bindings.azure.cosmosdb version: v1 metadata: - name: url value: https://******.documents.azure.com:443/ - name: masterKey value: ***** - name: database value: db - name: collection value: collection - name: partitionKey value: message
WarningThe above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described here.
Spec metadata fields
|url||Y||Output||The CosmosDB url||
|masterKey||Y||Output||The CosmosDB account master key||
|database||Y||Output||The name of the CosmosDB database||
|collection||Y||Output||The name of the container inside the database.||
|partitionKey||Y||Output||The name of the key to extract from the payload (document to be created) that is used as the partition key. This name must match the partition key specified upon creation of the Cosmos DB container.||
For more information see Azure Cosmos DB resource model.
Azure Active Directory (AAD) authentication
The Azure Cosmos DB binding component supports authentication using all Azure Active Directory mechanisms. For further information and the relevant component metadata fields to provide depending on the choice of AAD authentication mechanism, see the docs for authenticating to Azure.
This component supports output binding with the following operations:
Best Practices for Production Use
Azure Cosmos DB shares a strict metadata request rate limit across all databases in a single Azure Cosmos DB account. New connections to Azure Cosmos DB assume a large percentage of the allowable request rate limit. (See the CosmosDB documentation)
Therefore several strategies must be applied to avoid simultaneous new connections to Azure Cosmos DB:
- Ensure sidecars of applications only load the Azure Cosmos DB component when they require it to avoid unnecessary database connections. This can be done by scoping your components to specific applications.
- Choose deployment strategies that sequentially deploy or start your applications to minimize bursts in new connections to your Azure Cosmos DB accounts.
- Avoid reusing the same Azure Cosmos DB account for unrelated databases or systems (even outside of Dapr). Distinct Azure Cosmos DB accounts have distinct rate limits.
- Increase the
initTimeoutvalue to allow the component to retry connecting to Azure Cosmos DB during side car initialization for up to 5 minutes. The default value is
5sand should be increased. When using Kubernetes, increasing this value may also require an update to your Readiness and Liveness probes.
spec: type: bindings.azure.cosmosdb version: v1 initTimeout: 5m metadata:
The output binding
create operation requires the following keys to exist in the payload of every document to be created:
id: a unique ID for the document to be created
<partitionKey>: the name of the partition key specified via the
spec.partitionKeyin the component definition. This must also match the partition key specified upon creation of the Cosmos DB container.
- Basic schema for a Dapr component
- Bindings building block
- How-To: Trigger application with input binding
- How-To: Use bindings to interface with external resources
- Bindings API reference
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.