Deploy to Dapr
Dapr core concept
Deployments to Dapr as similar to Kubernetes deployments. Your single services are deployed as container (pod) on a Kubernetes cluster. On plain Kubernetes deployments, the event bridge of a service is directly connected to the message broker. If you are on a Dapr infrastructure, Dapr will automatically add a sidecar container to your service instance. The whole communication from and to your service is passed through this sidecar container.
Dapr also provides some abstraction and adapters for config, state and secret stores.
To learn more about Dapr, visit the official site dapr.io.
Prepare your code
Similar to Kubernetes deployments, a http server must be provided by your service instance. The
@purista/dapr-sdk package provides an event bridge which working as HTTP server. In addition, adapters for config, state and secrets stores are available.
You can find an example in the PURISTA repository. This example also contains the usage of the Dapr config store, secret store and state store.
Kubernetes deployment file
The deployment of an application or service follows teh regular Kubernetes deployment. The only difference here is, to provide the information, required by Dapr to work properly.
Dapr requires to have a unique app-ID for a service defined in the deployment. This id match the pattern
[prefix-][convertToKebabCase(service-name)]-v[convertToKebabCase(service version)]. If the app-ID does not follow this pattern, PURISTA services might be not able to invoke commands or subscribe to events correctly
# file order-service-deployment.yaml
# We add the annotations below to let Dapr recognize
# and deploy the sidecar together with our service in the pod.
# The client service will use this name to locate
# the Order service through the Dapr sidecar.
# The port that your application is listening on
- name: purista-order-service
Dapr provides some additional functionality, like the concept of actors or bulk messageing. Currently these functionalities are not supported by the
It is also not possible to deploy multiple services or service versions in one container (pod). Each service/service-version must be deployed independently.