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

Diagram that shows Dapr building blocks.

Building block Description
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.

Dapr settings

The following Pub/sub example demonstrates how Dapr works alongside your container app:

Diagram demonstrating Dapr pub/sub and how it works with Container Apps.

Label Dapr settings Description
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.

Enable Dapr

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
--enable-dapr dapr.enabled Enables Dapr on the container app.
--dapr-app-port dapr.appPort Identifies which port your application is listening.
--dapr-app-protocol dapr.appProtocol Tells Dapr which protocol your application is using. Valid options are http or grpc. Default is http.
--dapr-app-id dapr.appId 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.

 dapr: {
   enabled: true
   appId: 'nodeapp'
   appProtocol: 'http'
   appPort: 3000
 }

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.

Note

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"

The pubsub.yaml spec will be scoped to the dapr-enabled container apps with app IDs publisher-app and subscriber-app.

# 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.

Limitations

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-protocol, app-port, and app-id. For a list of unsupported configuration options, see the Dapr documentation.

Known limitations

  • Declarative pub/sub subscriptions
  • Actor reminders: Require a minReplicas of 1+ to ensure reminders will always be active and fire correctly.

Next Steps

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.