Parameters for Deployment via Modeler in Self-Managed setup

Hi guys,
I have a question regarding the deployment of models. We have set up a Camunda 8 installation self-managed on our Kubernetes-cluster using the Helm Charts. This has worked so far, we can access Operate, Tasklist, Keycloak, etc.

Now we want to deploy a process modell via the Modeler. As we understand in the SaaS-setup this is possible directly via the web-modeler. In the self-managed setup we need to provide a few parameters
grafik

But we dont really know where to find these parameters, can anyone help us out here? Do we have to create a client in Keycloak? We tried this as well, however we werent able to generate a client-secret, the tab for “credentials” simply was not there. Also we have no idea what callback-URL we have to use and what the “Audience” is. Any ideas?

You need to create an API key for the modeler to use.
The details of how to do this can be found here: Manage API clients | Camunda Platform 8

Hi Niall, yes we have seen the console, but this is only available in the SaaS-version, right? Or can we also do this in the self-managed-version. Do you know how we can access the console there?

Hello @the-villain ,

which version of the modeler do you use? In 5.2.0, you can switch from SaaS deployment to SM deployment and provide connection information like this:

Jonathan

1 Like

Hi @jonathan.lukas we are using 5.1.0 and we have exactly this view. When we are trying to deploy with no authentication we receive this error:

grafik

So we figured we need to use the OAuth-way, or is this a different error?

1 Like

Hello @the-villain ,

the error you see would mean that there is no cluster running at the provided endpoint.

You only have to use the OAuth way if your Zeebe gateway is protected.

Do you have workers or zbctl to connect to the cluster?

Jonathan

1 Like

Hi @jonathan.lukas
no we don’t have any workers connected yet, since we have no process-modell deployed. But looking at the CLI at Getting started with the CLI client | Camunda Platform 8, this looks like it also already needs credentials to connect to it?

I think that in our case it actually is protected since we are using Keycloak with an own Ingress Controller with TLS. Is there maybe some kind of configuration that we can provide so you can take a look at what we might be missing?
Maybe the values.yaml-files?

@jonathan.lukas Quick update: we might have a problem with the port now. We managed to create a client with Keycloak and now get this error:

grafik

The problem is, that we can’t expose port 26500, since we are not using the port-forwarding-solution. Is there another way of getting to the Cluster-endpoint, if the ports are not accessible from the outside?

Sorry to intercept here but how does your setup look like? Do you use k8 with helm charts or docker? Or something else? Do you use an embedded or standalone gateway?

Just to clarify with self-managed there is no authentication for the Zeebe API, which means there is no need to create a client in keycloak. You need to access the gateway directly gateway-host:port (per default the port is 26500).

Greets
Chris


Edit:

I somehow overread:

The problem is, that we can’t expose port 26500, since we are not using the port-forwarding-solution. Is there another way of getting to the Cluster-endpoint, if the ports are not accessible from the outside?

You have to make them somehow accessible either via port-forwarding or via an ingress. If this is not possible than you have to deploy an application in your cluster, which deploys your process models.

1 Like

Hi @Zelldon
The issue is, that we dont know how exactly to do this. Problem was also, that we could not configure the access to the Zeebe Gateway via te Ingress because of issues with the ports. Are there any alternatives?

For checking, here is the configuration of our ingress, maybe you see something that we need to adjust here?

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    ingress.kubernetes.io/rewrite-target: /
    meta.helm.sh/release-name: camunda8
    cert-manager.io/cluster-issuer: letsencrypt
  labels:
    app: camunda-platform
    app.kubernetes.io/instance: camunda8
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/part-of: camunda-platform
    app.kubernetes.io/version: 8.0.2
  name: camunda8-ingress
  namespace: default
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - <our host>
    secretName: ...
  rules:
  - host: <our host>
    http:
      paths:
      - backend:
          service:
            name: camunda8-keycloak
            port:
              name: http
        path: /
        pathType: ImplementationSpecific
      - backend:
          service:
            name: camunda8-identity
            port:
              number: 80
        path: /identity
        pathType: Prefix
      - backend:
          service:
            name: camunda8-operate
            port:
              number: 80
        path: /operate
        pathType: Prefix
      - backend:
          service:
            name: camunda8-optimize
            port:
              number: 80
        path: /optimize
        pathType: Prefix
      - backend:
          service:
            name: camunda8-tasklist
            port:
              number: 80
        path: /tasklist
        pathType: Prefix

I can also provide your values-files, but this is over 800 lines long. Are there any specific parameters in there that we would need to take a look at?

I am also facing the same issue. @the-villain were you able to get an answer for your problem?

1 Like

Hi @PrashanthB not completly, we have done a workaround. We presented the solution to our colleagues, if this is still open I can send you the slides that we made for this.

1 Like

Hi @the-villain ,

Far as I know, both port-forward and ingress could map a different port to externals.

If you’re using Ingress you could have a view on the following ingress annotation. This is to specify the ingress traffic protocol to GRPC.

nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
  1. Make sure your ingress controller allows GRPC traffic
  2. Add ingress annotation to specify the GRPC protocol

Hope this could help since Zeebe is using GRPC protocol.

Current I’m also struggling with establishing Oauth secured Zeebe connection externally to Zeebe cluster in Rancher.

Hi @GgJinFWu actually yes, we tried this as well, here is a part of our application.yml. Unfortunetaly it did not work :confused:

grafik