Dapr integration with Azure Container Apps
The Distributed Application Runtime (Dapr) is a set of incrementally adoptable APIs that simplify the authoring of distributed, microservice-based applications. For example, Dapr provides capabilities for enabling application intercommunication, whether through messaging via pub/sub or reliable and secure service-to-service calls. Once Dapr is enabled in Container Apps, it exposes its HTTP and gRPC APIs via a sidecar: a process that runs in tandem with each of your Container Apps.
Dapr APIs, also referred to as building blocks, are built on best practice industry standards, that:
- Seamlessly fit with your preferred language or framework
- Are incrementally adoptable; you can use one, several, or all of the building blocks depending on your needs
Dapr building blocks
|Service-to-service invocation||Discover services and perform reliable, direct service-to-service calls with automatic mTLS authentication and encryption.|
|State management||Provides state management capabilities for transactions and CRUD operations.|
|Pub/sub||Allows publisher and subscriber container apps to intercommunicate via an intermediary message broker.|
|Bindings||Trigger your application with incoming or outgoing events, without SDK or library dependencies.|
|Actors||Dapr actors apply the scalability and reliability that the underlying platform provides.|
|Observability||Send tracing information to an Application Insights backend.|
The following Pub/sub example demonstrates how Dapr works alongside your container app:
|1||Container Apps with Dapr enabled||Dapr is enabled at the container app level by configuring Dapr settings. Dapr settings apply across all revisions of a given container app.|
|2||Dapr sidecar||Fully managed Dapr APIs are exposed to your container app via the Dapr sidecar. These APIs are available through HTTP and gRPC protocols. By default, the sidecar runs on port 3500 in Container Apps.|
|3||Dapr component||Dapr components can be shared by multiple container apps. The Dapr sidecar uses scopes to determine which components to load for a given container app at runtime.|
You can define the Dapr configuration for a container app through the Azure CLI or using Infrastructure as Code templates like a bicep or an Azure Resource Manager (ARM) template. You can enable Dapr in your app with the following settings:
|CLI Parameter||Template field||Description|
||Enables Dapr on the container app.|
||Identifies which port your application is listening.|
||Tells Dapr which protocol your application is using. Valid options are
||The unique ID of the application. Used for service discovery, state encapsulation, and the pub/sub consumer ID.|
The following example shows how to define a Dapr configuration in a template by adding the Dapr configuration to the
properties.configuration section of your container apps resource declaration.
Since Dapr settings are considered application-scope changes, new revisions aren't created when you change Dapr setting. However, when changing Dapr settings, the container app revisions and replicas are automatically restarted.
Configure Dapr components
Once Dapr is enabled on your container app, you're able to plug in and use the Dapr APIs as needed. You can also create Dapr components, which are specific implementations of a given building block. Dapr components are environment-level resources, meaning they can be shared across Dapr-enabled container apps. Components are pluggable modules that:
- Allow you to use the individual Dapr building block APIs.
- Can be scoped to specific container apps.
- Can be easily modified to point to any one of the component implementations.
- Can reference secure configuration values using Container Apps secrets.
Based on your needs, you can "plug in" certain Dapr component types like state stores, pub/sub brokers, and more. In the examples below, you'll find the various schemas available for defining a Dapr component in Azure Container Apps. The Container Apps manifests differ sightly from the Dapr OSS manifests in order to simplify the component creation experience.
By default, all Dapr-enabled container apps within the same environment will load the full set of deployed components. By adding scopes to a component, you tell the Dapr sidecars for each respective container app which components to load at runtime. Using scopes is recommended for production workloads.
When defining a Dapr component via YAML, you'll pass your component manifest into the Azure CLI. When configuring multiple components, you'll need to create a separate YAML file and run the Azure CLI command for each component.
For example, deploy a
pubsub.yaml component using the following command:
az containerapp env dapr-component set --name ENVIRONMENT_NAME --resource-group RESOURCE_GROUP_NAME --dapr-component-name pubsub --yaml "./pubsub.yaml"
pubsub.yaml spec will be scoped to the dapr-enabled container apps with app IDs
# pubsub.yaml for Azure Service Bus component componentType: pubsub.azure.servicebus version: v1 metadata: - name: connectionString secretRef: sb-root-connectionstring secrets: - name: sb-root-connectionstring value: "value" # Application scopes scopes: - publisher-app - subscriber-app
For comparison, a Dapr OSS
pubsub.yaml file would include:
apiVersion: dapr.io/v1alpha1 kind: Component metadata: name: dapr-pubsub spec: type: pubsub.azure.servicebus version: v1 metadata: - name: connectionString secretKeyRef: name: sb-root-connectionstring key: "value" # Application scopes scopes: - publisher-app - subscriber-app
Current supported Dapr version
Azure Container Apps supports Dapr version 1.7.3.
Version upgrades are handled transparently by Azure Container Apps. You can find the current version via the Azure portal and the CLI.
Unsupported Dapr capabilities
- Dapr Secrets Management API: Use Container Apps secret mechanism as an alternative.
- Custom configuration for Dapr Observability: Instrument your environment with Application Insights to visualize distributed tracing.
- Dapr Configuration spec: Any capabilities that require use of the Dapr configuration spec.
- Advanced Dapr sidecar configurations: Container Apps allows you to specify sidecar settings including
app-id. For a list of unsupported configuration options, see the Dapr documentation.
- Declarative pub/sub subscriptions
- Actor reminders: Require a minReplicas of 1+ to ensure reminders will always be active and fire correctly.
Now that you've learned about Dapr and some of the challenges it solves, try Deploying a Dapr application to Azure Container Apps using the Azure CLI or Azure Resource Manager.
Submit and view feedback for