To better understand how Dapr works it can be helpful to look into the Dapr executables, how they work and the defaults they use.
- dapr | Dapr CLI tool. Used to initialize and manually start Dapr etc.
- daprd | Dapr main process. The Dapr ‘daemon’
Run the Dapr daemon
If we start Dapr using the CLI like this:
dapr run --dapr-grpc-port 4001 --dapr-http-port 3500 --app-id mysuperapp
The CLI will start a daprd process with several configuration parameters and default values. This example is from Linux (WSL) but it is identical on Windows.
| Parameter | Value | Comment |
|---|---|---|
--config |
/home/myuser/.dapr/config.yaml | |
--app-protocol |
http | |
--log-level |
info | |
--app-max-concurrency |
1 | |
--placement-host-address |
localhost:50005 | |
--components-path |
/home/myuser/.dapr/components | |
--dapr-http-max-request-size |
-1 | |
--dapr-http-read-buffer-size |
-1 | |
--app-id |
mysuperapp | |
--app-port |
0 | |
--dapr-http-port |
3500 | |
--dapr-grpc-port |
4001 | |
--profile-port |
-1 | |
--metrics-port |
36089 | |
--dapr-internal-grpc-port |
46647 |
Ok from this we see that the main Dapr folder is /home/myuser/.dapr. Here we find a bin folder with:
- daprd | Dapr main process. Dapr ‘daemon’
- dashboard | Dapr dashboard webserver
- web | Dapr dashboard website
Also we will find .dapr/config.yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: daprConfig
spec:
tracing:
samplingRate: "1"
zipkin:
endpointAddress: http://localhost:9411/api/v2/spans
The configuration only have one single thing which is the URL to the metrics endpoint. Zipkin is the defult metrics server. Let´s look at the containers Dapr installed:
Components
Then we have the --components-path which specifies the folder with all the Dap component configuration. This is the folder you will typically replaced with your custom configuration. If we look at the ‘defaults’ we find only two files
statestore.yaml
The default statestore component use Redis. This is convenient as no setup is needed. The Redis container is automatically deployed at initialization.
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
spec:
type: state.redis
version: v1
metadata:
- name: redisHost
value: localhost:6379
- name: redisPassword
value: ""
- name: actorStateStore
value: "true"
pubsub.yaml
Redis is also the default when it comes to pubsub.
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: pubsub
spec:
type: pubsub.redis
version: v1
metadata:
- name: redisHost
value: localhost:6379
- name: redisPassword
value: ""
Final thoughts
Ok, there we have it. Dapr is pretty simple when we look a the basic components and setup. One process, one ‘cli’ tool, three containers and three default configuration files.
In ‘real world’ scenarios we would typically use the sidecar pattern with Docker, Kubernetes or Azure Container Apps and we just inject a different --components-path with the components needed.