Etcd

Detailed information on the Etcd state store component

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.

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Component
  3. metadata:
  4.   name: <NAME>
  5. spec:
  6.   type: state.etcd
  7.   # Supports v1 and v2. Users should always use v2 by default. There is no
  8.   # migration path from v1 to v2, see `versioning` below.
  9.   version: v2
  10.   metadata:
  11.   - name: endpoints
  12.     value: <CONNECTION STRING> # Required. Example: 192.168.0.1:2379,192.168.0.2:2379,192.168.0.3:2379
  13.   - name: keyPrefixPath
  14.     value: <KEY PREFIX STRING> # Optional. default: "". Example: "dapr"
  15.   - name: tlsEnable
  16.     value: <ENABLE TLS> # Optional. Example: "false"
  17.   - name: ca
  18.     value: <CA> # Optional. Required if tlsEnable is `true`.
  19.   - name: cert
  20.     value: <CERT> # Optional. Required if tlsEnable is `true`.
  21.   - name: key
  22.     value: <KEY> # Optional. Required if tlsEnable is `true`.
  23.   # Uncomment this if you wish to use Etcd as a state store for actors (optional)
  24.   #- name: actorStateStore
  25.   #  value: "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

FieldRequiredDetailsExample
endpointsYConnection string to the Etcd cluster“192.168.0.1:2379,192.168.0.2:2379,192.168.0.3:2379”
keyPrefixPathNKey prefix path in Etcd. Default is no prefix.“dapr”
tlsEnableNWhether to enable TLS for connecting to Etcd.“false”
caNCA certificate for connecting to Etcd, PEM-encoded. Can be secretKeyRef to use a secret reference.“——-BEGIN CERTIFICATE——-\nMIIC9TCCA…”
certNTLS certificate for connecting to Etcd, PEM-encoded. Can be secretKeyRef to use a secret reference.“——-BEGIN CERTIFICATE——-\nMIIDUTCC…”
keyNTLS key for connecting to Etcd, PEM-encoded. Can be secretKeyRef to use a secret reference.“——-BEGIN PRIVATE KEY——-\nMIIEpAIB…”
actorStateStoreNConsider this state store for actors. Defaults to “false”“true”, “false”

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:

  1. version: '2'
  2. services:
  3.   etcd:
  4.     image: gcr.io/etcd-development/etcd:v3.4.20
  5.     ports:
  6.       - "2379:2379"
  7.     command: etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379
  2. Save the `docker-compose.yml` file and run the following command to start the Etcd server:

docker-compose up -d

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

Last modified October 11, 2024: Fixed typo (#4389) (fe17926)