The documentation you are viewing is for Dapr v1.12 which is an older version of Dapr. For up-to-date documentation, see the latest version.
Etcd
Component format
To setup an Etcd state store create a component of type state.etcd. See this guide on how to create and apply a state store configuration.
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: <NAME>
spec:
type: state.etcd
# Supports v1 and v2. Users should always use v2 by default. There is no
# migration path from v1 to v2, see `versioning` below.
version: v2
metadata:
- name: endpoints
value: <CONNECTION STRING> # Required. Example: 192.168.0.1:2379,192.168.0.2:2379,192.168.0.3:2379
- name: keyPrefixPath
value: <KEY PREFIX STRING> # Optional. default: "". Example: "dapr"
- name: tlsEnable
value: <ENABLE TLS> # Optional. Example: "false"
- name: ca
value: <CA> # Optional. Required if tlsEnable is `true`.
- name: cert
value: <CERT> # Optional. Required if tlsEnable is `true`.
- name: key
value: <KEY> # Optional. Required if tlsEnable is `true`.
Warning
The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described here.Versioning
Dapr has 2 versions of the Etcd state store component: v1 and v2. It is recommended to use v2, as v1 is deprecated.
While v1 and v2 have the same metadata fields, v1 causes data inconsistencies in apps when using Actor TTLs from Dapr v1.12.
v1 and v2 are incompatible with no data migration path for v1 to v2 on an existing active Etcd cluster and keyPrefixPath.
If you are using v1, you should continue to use v1 until you create a new Etcd cluster or use a different keyPrefixPath.
Spec metadata fields
| Field | Required | Details | Example |
|---|---|---|---|
endpoints |
Y | Connection string to the Etcd cluster | "192.168.0.1:2379,192.168.0.2:2379,192.168.0.3:2379" |
keyPrefixPath |
N | Key prefix path in Etcd. Default is no prefix. | "dapr" |
tlsEnable |
N | Whether to enable TLS for connecting to Etcd. | "false" |
ca |
N | CA certificate for connecting to Etcd, PEM-encoded. Can be secretKeyRef to use a secret reference. |
"-----BEGIN CERTIFICATE-----\nMIIC9TCCA..." |
cert |
N | TLS certificate for connecting to Etcd, PEM-encoded. Can be secretKeyRef to use a secret reference. |
"-----BEGIN CERTIFICATE-----\nMIIDUTCC..." |
key |
N | TLS key for connecting to Etcd, PEM-encoded. Can be secretKeyRef to use a secret reference. |
"-----BEGIN PRIVATE KEY-----\nMIIEpAIB..." |
Setup Etcd
You can run Etcd database locally using Docker Compose. Create a new file called docker-compose.yml and add the following contents as an example:
version: '2'
services:
etcd:
image: gcr.io/etcd-development/etcd:v3.4.20
ports:
- "2379:2379"
command: etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379```
Save the docker-compose.yml file and run the following command to start the Etcd server:
docker-compose up -d
This starts the Etcd server in the background and expose the default Etcd port of 2379. You can then interact with the server using the etcdctl command-line client on localhost:12379. For example:
etcdctl --endpoints=localhost:2379 put mykey myvalue
Use Helm to quickly create an Etcd instance in your Kubernetes cluster. This approach requires Installing Helm.
Follow the Bitnami instructions to get started with setting up Etcd in Kubernetes.
Related links
- Basic schema for a Dapr component
- Read this guide for instructions on configuring state store components
- State management building block
Feedback
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.