Managing components in Dapr on Dapr Docs

Certification lifecycle

Mon, 01 Jan 0001 00:00:00 +0000

Note

Certification lifecycle only applies to built-in components and does not apply to pluggable components.

Overview

Dapr uses a modular design where functionality is delivered as a component. Each component has an interface definition. All of the components are interchangeable, so that in ideal scenarios, you can swap out one component with the same interface for another. Each component used in production maintains a certain set of technical requirements to ensure functional compatibility and robustness.

Updating components

Mon, 01 Jan 0001 00:00:00 +0000

When making an update to an existing deployed component used by an application, Dapr does not update the component automatically unless the HotReload feature gate is enabled. The Dapr sidecar needs to be restarted in order to pick up the latest version of the component. How this is done depends on the hosting environment.

Kubernetes

When running in Kubernetes, the process of updating a component involves two steps:

Apply the new component YAML to the desired namespace
Unless the HotReload feature gate is enabled, perform a rollout restart operation on your deployments to pick up the latest component

Self Hosted

Unless the HotReload feature gate is enabled, the process of updating a component involves a single step of stopping and restarting the daprd process to pick up the latest component.

How-To: Scope components to one or more applications

Mon, 01 Jan 0001 00:00:00 +0000

Dapr components are namespaced (separate from the Kubernetes namespace concept), meaning a Dapr runtime instance can only access components that have been deployed to the same namespace.

When Dapr runs, it matches it’s own configured namespace with the namespace of the components that it loads and initializes only the ones matching its namespaces. All other components in a different namespace are not loaded.

Namespaces

Namespaces can be used to limit component access to particular Dapr instances.

How-To: Reference secrets in components

Mon, 01 Jan 0001 00:00:00 +0000

Overview

Components can reference secrets for the spec.metadata section within the components definition.

In order to reference a secret, you need to set the auth.secretStore field to specify the name of the secret store that holds the secrets.

When running in Kubernetes, if the auth.secretStore is empty, the Kubernetes secret store is assumed.

Supported secret stores

Go to this link to see all the secret stores supported by Dapr, along with information on how to configure and use them.

State stores components

Mon, 01 Jan 0001 00:00:00 +0000

Dapr integrates with existing databases to provide apps with state management capabilities for CRUD operations, transactions and more. It also supports the configuration of multiple, named, state store components per application.

State stores are extensible and can be found in the components-contrib repo.

A state store in Dapr is described using a Component file:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
 name: statestore
spec:
 type: state.<DATABASE>
 version: v1
 metadata:
 - name: <KEY>
 value: <VALUE>
 - name: <KEY>
 value: <VALUE>
...

The type of database is determined by the type field, and things like connection strings and other metadata are put in the .metadata section. Even though metadata values can contain secrets in plain text, it is recommended you use a secret store.

Secret store components

Mon, 01 Jan 0001 00:00:00 +0000

Dapr integrates with secret stores to provide apps and other components with secure storage and access to secrets such as access keys and passwords. Each secret store component has a name and this name is used when accessing a secret.

As with other building block components, secret store components are extensible and can be found in the components-contrib repo.

A secret store in Dapr is described using a Component file with the following fields:

Bindings components

Mon, 01 Jan 0001 00:00:00 +0000

Dapr integrates with external resources to allow apps to both be triggered by external events and interact with the resources. Each binding component has a name and this name is used when interacting with the resource.

As with other building block components, binding components are extensible and can be found in the components-contrib repo.

A binding in Dapr is described using a Component file with the following fields:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
 name: <NAME>
 namespace: <NAMESPACE>
spec:
 type: bindings.<NAME>
 version: v1
 metadata:
 - name: <KEY>
 value: <VALUE>
 - name: <KEY>
 value: <VALUE>
...

The type of binding is determined by the type field, and things like connection strings and other metadata are put in the .metadata section.

How-To: Register a pluggable component

Mon, 01 Jan 0001 00:00:00 +0000

Component registration process

Pluggable, gRPC-based components are typically run as containers or processes that need to communicate with the Dapr runtime via Unix Domain Sockets (or UDS for short). They are automatically discovered and registered in the runtime with the following steps:

The component listens to an Unix Domain Socket placed on the shared volume.
The Dapr runtime lists all Unix Domain Socket in the shared volume.
The Dapr runtime connects with each socket and uses gRPC reflection to discover all proto services from a given building block API that the component implements.

A single component can implement multiple component interfaces at once.

Configure middleware components

Mon, 01 Jan 0001 00:00:00 +0000

Dapr allows custom processing pipelines to be defined by chaining a series of middleware components. There are two places that you can use a middleware pipeline:

Building block APIs - HTTP middleware components are executed when invoking any Dapr HTTP APIs.
Service-to-Service invocation - HTTP middleware components are applied to service-to-service invocation calls.

Configure API middleware pipelines

When launched, a Dapr sidecar constructs a middleware processing pipeline for incoming HTTP calls. By default, the pipeline consists of the tracing and CORS middlewares. Additional middlewares, configured by a Dapr Configuration, can be added to the pipeline in the order they are defined. The pipeline applies to all Dapr API endpoints, including state, pub/sub, service invocation, bindings, secrets, configuration, distributed lock, etc.