DAPR in der Cloud
DAPR verspricht Plattformagnostik und quasi keinen zusätzlichen Konfigurationsaufwand bei der Migration in remote Cluster.
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.
Azure Kubernetes Service |
Vorgehen:
Vorbereitung AKS / ACR$ 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 Nun sollte kubectl verfügbar sein: $ kubectl version Anschließend werden Azure Kubernetes Service und Azure Container registry verknüpft: $ az aks update -n dapr-poc -g dapr_poc --attach-acr daprimages Die verwendeten Images sollten in einer für das Cluster erreichbaren Container registry hinterlegt sein. |
Amazon Elastic Kubernetes Service |
Vorbereitung EKS/ ECRNeues Cluster erstellen: $ eksctl create cluster --name dapr-poc --region eu-central-1 --nodegroup-name dapr-nodes --node-type t2.small --nodes 3 Überprüfen: $ kubectl version Elastic Container registry https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html Sofern ECR und EKS dem gleichen IAM zugeordnet sind, kann das EKS auf diese zugreifen. |
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
- Message Broker / PubSub installieren (redis)
- DAPR in das Cluster einbinden
- 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:
https://azure.microsoft.com/de-de/services/kubernetes-service/#features