DAPR in der Cloud

Im ersten Teil sind wir darauf eingegangen, was die DAPR ist. Da eine der zentralen Problemstellungen, welche gelöst werden soll, die Plattformagnostik ist möchten wir nun darauf eingehen wie sich ein remote Deployment realisieren lässt.

Um die Migration von DAPR Projekten zu testen, wird ein lokales Minikube Cluster in eine Azure als auch in eine AWS Umgebung migriert.

$ az aks create --resource-group dapr_poc --name dapr-poc --node-count 3 --enable-addons monitoring --generate-ssh-keys

$ az aks get-credentials --resource-group dapr_poc --name dapr-poc

$ kubectl version

$ az aks update -n dapr-poc -g dapr_poc --attach-acr daprimages

$ eksctl create cluster --name dapr-poc --region eu-central-1 --nodegroup-name dapr-nodes --node-type t2.small --nodes 3

$ kubectl version

Die lokal verwendeten Images unterscheiden sich in keiner Weise von denen, die im Azure / AWS Cluster ausgeführt werden. Lediglich in den YAML Deployment Files müssen eventuell die Image Repository Pfade angepasst werden.

Deployment im Cluster

1. Message Broker / PubSub installieren (redis)
2. DAPR in das Cluster einbinden
3. Deployments

Benötigt: kubectl Zugriff auf remote Cluster, helm, DAPR-CLI

Installation REDIS

$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install redis bitnami/redis

Hint: Die Redis Pods müssen im selben Namespace sein wie die DAPR-Anwendung die diese verwenden soll! (Default: default)

Installation DAPR

Wenn die DAPR-CLI lokal installiert ist und kubectl mit dem remote Cluster verbunden ist, kann DAPR einfach per Befehl in das Cluster geladen werden.

$ dapr init -k

$ kubectl get pods --namespace dapr-system
NAME                                    READY   STATUS    RESTARTS   AGE
dapr-dashboard-6bb75f9645-9p95n         1/1     Running   1          1m
dapr-operator-5f84d9fd4-str9p           1/1     Running   1          1m
dapr-placement-server-0                 1/1     Running   1          1m
dapr-sentry-5d67bfbfdc-n8mpr            1/1     Running   2          1m
dapr-sidecar-injector-7b556f95d-rpt78   1/1     Running   1          1m

Deployment Anwendung

$ cd deploy
$ kubectl apply -f .

Hint: Die Anwendung wird im „default“ namespace deployed.

$ kubectl get pods
NAME                         READY   STATUS    RESTARTS   AGE
publisher-5f6b85c796-q5fbf   2/2     Running   0          1m
receiver-7dd5fcb8f5-6nch4    2/2     Running   0          1m
redis-master-0               1/1     Running   0          5m
redis-slave-0                1/1     Running   0          5m
redis-slave-1                1/1     Running   0          4m
trigger-7f788d4985-jrnhb     2/2     Running   0          1m

In jedem Anwendungs-Pod laufen nun zwei Container: Die Anwendung und das DAPR Sidecar.

Durch diese recht einfach umgesetzte Art kann erreicht werden, dass lokale Anwendungen einfach über Plattformen hinweg deployed werden können. Der große Vorteil durch den Einsatz von DAPR besteht darin, dass im eigentlichen Programmcode der Microservices keine Änderungen bezüglich Zugriffspunkten erledigt werden müssen. Diese werden durch die DAPR Anwendung über ein Routing verfügbar gemacht.

Co-Autor: Jacob Zeising

Mehr über Softwareentwicklung erfahren

Quellen:

dapr.io

github.com/dapr

https://azure.microsoft.com/de-de/services/kubernetes-service/#features  

https://aws.amazon.com/de/eks/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc&eks-blogs.sort-by=item.additionalFields.createdDate&eks-blogs.sort-order=desc