Table of Contents
In the previous article, we focused on the usage of the Dapr (Distributed Application Runtime). After a pretty huge amount of theory in the first part of the Dapr series, we have managed to set up a simple ASP.NET Core Bank app using Dapr and Redis pub/sub which was our ‘Bank’, and additionally, we have prepared a second application for simulating Payday.
Within just a few lines of code we:
- Set up Dapr, and used it
- Used Redis pub/sub + state store
- Developed two fully working and stable applications
Now it’s time to focus on finishing our application. After the pretty easy development part, we need to think of Dapr deployment and hosting.
Blog Series – Dapr And Microservices
Part 1: Introduction | Part 2: Demo | Part 3: Hosting and Deployment
TL;DR
Hosting Dapr is possible in two ways: Kubernetes or Self-hosted mode with Docker. The most recommended option is to host Dapr-based applications on Kubernetes although the self-hosted mode with Docker is fully supported.
Option 1) Kubernetes
The best option to actually host Dapr-based applications is to use Kubernetes.
Dapr-based applications can be running any of the supported versions of the Kubernetes. There are just four Kubernetes services (actually 3; 1 is optional) to run a Dapr-based application and make it pretty stable.
Those four services are:
- Dapr-operator – think of it as a management service responsible for managing components updates and Kubernetes services endpoints for Dapr (such as state stores, pub/subs etc.)
- Dapr-sidecar-injector – it is injecting Dapr into annotated deployment pods together with environment variables which make it easy to access Dapr from user applications (those variables are DAPR_HTTP_PORT and DAPR_GRPC_PORT)
- Dapr-sentry – simply put – security & stuff. It is managing mTLS between the services and acts as a certificate authority
- Dapr-placement* – this one is only required when you are using actors. You don’t need it for other scenarios. It is responsible for mapping tables creation that map actor instances to pods.
Quick Start for hosting Dapr on Kubernetes
This is a short recipe for successful deployment of Dapr-based applications to the Kubernetes clusters and is available here: https://github.com/dapr/quickstarts/tree/master/hello-kubernetes
I don’t believe there is a need to rewrite the whole quickstart here. Dapr provides a lot of great sources on how to start working with it and it is updated and reviewed by the great power of the community.
Option 2) Self-hosted mode with Docker
Of course, it is possible to host Dapr-based applications with Docker. All you need to have is Docker installed on your machine.
We are going to take a closer look at the docker-compose solution. If you understand how it works on docker-compose, it will be pretty easy to move it to the docker-cli commands.
In order to run the Dapr-based application via docker-compose, it is necessary to define the sidecar pattern in the docker-compose file.
Here is our example docker-compose.yml file:
version: '3.7'
services:
redis:
image: redis:alpine
bankapp:
image: my.docker-registry.com/bankapp:latest
depends_on:
- redis
dapr-bankapp:
image: "daprio/daprd:1.0.0"
network_mode: "service:bankapp"
ports:
“9999:80”
depends_on:
- bankapp
dapr-placement:
image: "daprio/dapr:1.0.0"Here we define 4 services:
- Redis – simple redis instance
- Bankapp – ASP.NET Core application prepared in previous article (pushed to our custom docker-registry with tag latest)
- Dapr-bankapp – which is connector between our Bankapp and Dapr (also referred to as sidecar container)
- Dapr-placement – a Dapr placement service
Now we are going to call simple 2 commands in the directory where we have our docker-compose.yml file:
First, we need to pull all of the images we have in our compose file.
docker-compose pullFinally, we are going to start all of the services defined in the compose file.
docker-compose up -dThat’s it!
Our application is ready for our requests at localhost:9999.
Dapr Deployment and Hosting Summary
It is pretty easy to host and configure Dapr. We have two great options – Kubernetes and Docker. Hosting and configuring Dapr is as easy as using it inside our applications.
When you use Dapr, you will be happy that it is so pretty easy to implement code acting with state stores, pub/subs, and many more. The DevOps team is going to be also happy because they will understand that there is not much time needed to set up your application in production environments. And finally, the Project Owner is going to be amazed by the fact that estimates have been reduced, because you don’t need to worry about making implementations that are already ready and used in production by many other clients, and those clients are satisfied!
I hope that I convinced you to use Dapr in your projects. Make sure to check out the Dapr page – it is a huge knowledge base with all the tutorials, Q&As you might be looking for.
