{"id":1277,"date":"2023-01-02T14:36:03","date_gmt":"2023-01-02T11:36:03","guid":{"rendered":"https:\/\/www.bandidor.info\/wp\/?p=1277"},"modified":"2023-02-03T19:48:25","modified_gmt":"2023-02-03T16:48:25","slug":"make-use-of-my-local-camunda-8-cluster","status":"publish","type":"post","link":"https:\/\/www.bandidor.info\/wp\/?p=1277","title":{"rendered":"Make use of my local Camunda 8 cluster"},"content":{"rendered":"\n

A short recap from the previous article (Camunda 8 on k0s \u2013 the zero friction Kubernetes<\/a>). I have a running Camunda 8 cluster on my local machine, and I’m able to access its components via Web UI. I even managed to create a new user in Keycloack and login to Camunda 8 Operate as this new user. Now I’ll try to make use of it, i.e. to deploy and run my first BPMN process.<\/p>\n\n\n\n

Connect Camunda Desktop Modeler to Camunda 8 Self-Hosted cluster<\/h2>\n\n\n\n

Very straightforward exercise. Go to the download page https:\/\/camunda.com\/download\/modeler\/<\/a>, grab a binary for the respective desktop platform and create the first, very simple process, which I’ll describe later. Don’t forget to select the right execution platform – Camunda Platform 8.1.<\/p>\n\n\n\n

Time to deploy!<\/strong><\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n


Well, this didn’t go as expected… Let’s verify the settings one by one.<\/p>\n\n\n\n

Target – Camunda Platform 8 Self-Manager, this was easy – Check<\/strong>!<\/p>\n\n\n\n

Cluster endpoint – a less obvious one, but in my understanding, one would interact with the zeebe cluster through the zeebe gateway, and http:\/\/zeebe.camunda-example is its URL accordingly to our Ingress configuration (see Helm chart explanation in the previous article here – Camunda 8 on k0s \u2013 the zero friction Kubernetes<\/a> ) – Check!<\/strong><\/p>\n\n\n\n

Authentication – None. After reading the documentation and studying the settings in Operate and Keycloak, I figured that the gateway endpoint doesn’t have any protection in the default setup. Let’s say – Check<\/strong>!<\/p>\n\n\n\n

I then checked the respective ingress configuration and confirmed that gRPC is configured as its back-end protocol:<\/p>\n\n\n\n

olegme@master-node:~$ kubectl get ing c8-zeebe-gateway -n c8 -o yaml\napiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n  annotations:\n    ingress.kubernetes.io\/rewrite-target: \/\n    meta.helm.sh\/release-name: c8\n    meta.helm.sh\/release-namespace: c8\n    nginx.ingress.kubernetes.io\/backend-protocol: GRPC\n    nginx.ingress.kubernetes.io\/ssl-redirect: \"false\"\n  creationTimestamp: \"2022-12-28T17:41:45Z\"\n\n...\n<\/code><\/pre>\n\n\n\n
There is also a nice CLI utility zbctl<\/code>, described here: https:\/\/docs.camunda.io\/docs\/apis-clients\/cli-client\/<\/a>. Let’s try using it from our desktop (outside of the cluster). The --insecure<\/code> option is needed to prevent the TLS handshake; it will fail as we haven’t configured any SSL-based authentication.<\/p>\n\n\n\n
olegme@master-node:~\/k0s$ zbctl --insecure --address http:\/\/zeebe.camunda-example  status\nError: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp: address tcp\/\/\/zeebe.camunda-example: unknown port\"\n<\/code><\/pre>\n\n\n\n
It doesn’t work as well. Let’s divide and conquer. Two major parts here, the gateway and the Ingress. <\/p>\n\n\n\n
Connecting to the zeebe gateway from within the cluster.<\/h3>\n\n\n\n
Actually, from the gateway POD itself.<\/p>\n\n\n\n
exec kubectl exec -i -t -n c8 c8-zeebe-gateway-86885f7fcb-ndmg5 -c zeebe-gateway  -- sh -c \"clear; (bash || ash || sh)\"<\/code><\/pre>\n\n\n\n
I’ll skip the installation of the node <\/code>package and zbctl <\/code>command, this is done in a very usual Debian-ish way. Let’s check the connection:<\/p>\n\n\n\n
root@c8-zeebe-gateway-86885f7fcb-ndmg5:\/usr\/local\/zeebe# zbctl --insecure status\nCluster size: 1\nPartitions count: 1\nReplication factor: 1\nGateway version: 8.1.5\nBrokers:\n  Broker 0 - c8-zeebe-0.c8-zeebe.c8.svc:26501\n    Version: 8.1.5\n    Partition 1 : Leader, Healthy\n\n<\/code><\/pre>\n\n\n\n
Wow, works like a charm. It even didn’t need the address; it worked with the default one – 127.0.0.1:26500<\/code>. This led me to conclude that something was wrong with my Ingress configuration. Instead of investigating the Ingress configuration, I went for a simple workaround.<\/p>\n\n\n\n
Deploy a service on an external IP<\/h3>\n\n\n\n
First of all, external IP means external in relation to my cluster. So it can be reached from my desktop.<\/p>\n\n\n\n
After taking a closer look at the definition of the c8-zeebe-gateway<\/code> service, I decided to implement an additional, standalone service which will use LoadBalancer <\/code>as its type and connect to zeebe gateway as its backend. Like this:<\/p>\n\n\n
\napiVersion: v1\nkind: Service\nmetadata:\n  name: example-load-balancer\nspec:\n  selector:\n    app: camunda-platform\n    app.kubernetes.io\/component: zeebe-gateway\n    app.kubernetes.io\/instance: c8\n    app.kubernetes.io\/managed-by: Helm\n    app.kubernetes.io\/name: zeebe-gateway\n    app.kubernetes.io\/part-of: camunda-platform\n  ports:\n  - name: http\n    port: 9600\n    protocol: TCP\n    targetPort: 9600\n  - name: gateway\n    port: 26500\n    protocol: TCP\n    targetPort: 26500\n  type: LoadBalancer\n<\/pre><\/div>\n\n\n
Here we see it deployed and available outside of the cluster on 192.168.2.242<\/code>:<\/p>\n\n\n\n
olegme@master-node:~$ kubectl get svc example-load-balancer  -n c8\nNAME                    TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                          AGE\nexample-load-balancer   LoadBalancer   10.98.193.71   192.168.2.242   9600:30625\/TCP,26500:32169\/TCP   162m\n<\/code><\/pre>\n\n\n\n
Let’s make a connectivity test from the master-node:<\/p>\n\n\n\n
olegme@master-node:~\/k0s$ zbctl --insecure --address 192.168.2.242  status\nCluster size: 1\nPartitions count: 1\nReplication factor: 1\nGateway version: 8.1.5\nBrokers:\n  Broker 0 - c8-zeebe-0.c8-zeebe.c8.svc:26501\n    Version: 8.1.5\n    Partition 1 : Leader, Healthy\n\n<\/code><\/pre>\n\n\n\n
Wow, it works! Why don’t we try then to modify the Helm chart we used to deploy our Camunda 8 cluster to replace the Ingress configuration for the zeebe gateway with a LoadBalancer-based one? Let’s move on.<\/p>\n\n\n\n
LoadBalancer with an external IP for zeebe gateway<\/h3>\n\n\n\n
Based on the file values.yaml<\/code> provided here https:\/\/github.com\/camunda\/camunda-platform-helm\/blob\/main\/charts\/camunda-platform\/<\/a> I just replaced the ingress definition with a LoadBalancer-based service definition; here is an excerpt from the configuration:<\/p>\n\n\n
\n...\nzeebe-gateway:\n  replicas: 1\n  # Service configuration for the gateway service (copied over from https:\/\/github.com\/camunda\/camunda-platform-helm\/blob\/main\/charts\/camunda-platform\/values.yaml)\n  service:\n    # Service.type defines the type of the service https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/service\/#publishing-services-service-types\n    type: LoadBalancer\n    # Service.loadBalancerIP defines public ip of the load balancer if the type is LoadBalancer\n    loadBalancerIP: ""\n    # Service.loadBalancerSourceRanges defines list of allowed source ip address ranges if the type is LoadBalancer\n    loadBalancerSourceRanges: []\n    # Service.httpPort defines the port of the http endpoint, where for example metrics are provided\n    httpPort: 9600\n    # Service.httpName defines the name of the http endpoint, where for example metrics are provided\n    httpName: "http"\n    # Service.gatewayPort defines the port of the gateway endpoint, where client commands (grpc) are sent to\n    gatewayPort: 26500\n    # Service.gatewayName defines the name of the gateway endpoint, where client commands (grpc) are sent to\n    gatewayName: "gateway"\n    # Service.internalPort defines the port of the internal api endpoint, which is used for internal communication\n    internalPort: 26502\n    # Service.internalName defines the name of the internal api endpoint, which is used for internal communication\n    internalName: "internal"\n    # Service.annotations can be used to define annotations, which will be applied to the zeebe-gateway service\n    annotations: {}\n...\n<\/pre><\/div>\n\n\n
Command line connectivity test works:<\/p>\n\n\n\n
olegme@master-node:~$ zbctl --insecure --address 192.168.2.242:26500 status\nCluster size: 1\nPartitions count: 1\nReplication factor: 1\nGateway version: 8.1.5\nBrokers:\n  Broker 0 - c8-zeebe-0.c8-zeebe.c8.svc:26501\n    Version: 8.1.5\n    Partition 1 : Leader, Healthy\n<\/code><\/pre>\n\n\n\n
And the desktop Modeler can now connect as well:<\/p>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

Here is what the success looks like:<\/p>\n\n\n
\n
\"\"<\/a>
 <\/figcaption><\/figure>\n<\/div>\n\n\n
Conclusion<\/h2>\n\n\n\n
Now we can deploy our BPMN model to Camunda 8 cluster and start a process. Note, though, that the zeebe gateway end-point is completely unprotected. How to do that in a Self-Hosted version calls for a new article, but sometime in the distant future. In my next article, I’ll review how to re-implement an existing BPMN process I implemented on Camunda 7 and see what it means for Camunda 8. Read on –  Make Use Of My Local Camunda 8 Cluster – Part II<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Deploy and run my first BPMN process on Camunda 8 Self-Hosted.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[55,39],"tags":[42,35],"class_list":["post-1277","post","type-post","status-publish","format-standard","hentry","category-camunda-8","category-kubernetes","tag-bpmn","tag-camunda"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2EszU-kB","_links":{"self":[{"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1277","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1277"}],"version-history":[{"count":14,"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1277\/revisions"}],"predecessor-version":[{"id":1339,"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=\/wp\/v2\/posts\/1277\/revisions\/1339"}],"wp:attachment":[{"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1277"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1277"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bandidor.info\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1277"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}