I have a managed Camunda 8.3 installation with Zeebe cluster.
I want to use zeebe spring boot client to be able to deploy BPMN and DMN files.
when zeebectl connects to zeebe cluster we use :443
In spring boot properties how do we set up these broker gateway address?
Is this correct?
zeebe:
client:
broker.gateway-address: :443
security.plaintext: false
will this use https:// to do the process deployment.
Spring Boot application has this
@SpringBootApplication
@EnableZeebeClient
@Deployment(resources = “classpath*:/bpmn/**/*.*mn”)
public class MicroserviceApplication {
public static void main(String[] args) {
SpringApplication.run(MicroserviceApplication.class, args);
}
}
Hi @dulshand, welcome back to the forums! You can use a full URL/address with the port for the gateway address: zeebe.client.broker.gateway-address: my.domain.com:443
Even though HTTPS uses port 443 by default, port 443 can be used by other communication and HTTPS can work on different ports. The Zeebe client will use gRPC rather than HTTPS regardless of the port.
Have you tried it? Are you getting any errors?
Looks like it required plain text = false. I think it worked,
@nathan.loding I have noticed a different issue related to the same problem. I have used Spring boot version of Camunda where the engine and the client can be placed in the same spring boot application and bundle the process diagrams in it, as a result the process diagrams get deployed. Then in a Microservices environment we could deploy the spring boot application with more than one replica in clustered mode.
In the current Scenario which I was talking about in this thread we have a self managed Camunda 8.3 cluster. But I want to deploy bpmn files in CICD. I have a Spring boot microservice which has other end points related to decision processing and I am making it a Zeebeclient and I place the bpmn files in that spring boot client. Since this little spring boot application that has other REST operations, the app has more functionality than merely being zeebe client. So I would deploy it as a microservices in Elastic Kubernetes Services. In EKS, I tried to put two replicas initially. What happened was, the first instance which it created and ran successfully. The second instances however fails with error "“ApplicationContextException: Failed to start bean ‘zeebeLifecycleEventProducer’”. And it kills the second instance making it impossible for me to have more than one replica. So this is a clustering issue of Camunda client in version 8.3. In the past in Camunda 7, if one replica deployed it it knew about the delta and then did not create a new version of the deployment. Both clustered instances worked. Does anyone know how to rectify this problem?
Hi @dulshand - I’m not sure I fully understand the scenario you’ve described. Do you have a single Zeebe cluster deployed, or multiple? Or do you only have multiple instances of your Spring application deployed? Are both Spring applications connecting to the same Zeebe instance?
@nathan.loding I have one Zeebe cluster running in KIND installation on EC2 instance. Eventually we will move it to EKS. But it is currently on a miniature Kubernetes version called KIND (Camunda has documentation on this type of deployment). The BPMN files should be deployed in this Camunda cluster. We do not want to enable Web modeler in upper environments like UAT and PROD. We want to track changes via Bitbucket commits, pull requests etc. So, we expect the developers to model the diagrams and then checking the bpmn files to a bitbucket repository.
We have a different Spring boot microservice lets call it SimpleApp. It has some REST capabilities unrelated to Camunda. Since the SimpleApp is a Spring boot application, I could eneable Zeebe client in it using the dependencies and annotations which I described earlier (Zeebe spring client). In the resource folder of the SimpleApp I have sub directories like src/main/resources/bpmn//test.bpmn. The goal is to deploy test.bpmn and the likes to the Camunda cluster running on KIND. The Zeebe client in SimpleApp connects to the zeebe broker running on KIND via myapp.mydomain.com:443. When SimpleApp is deployed in EKS. When running with one replica of SimpleApp, it works fine. To improve performance of other REST APIs of SimpleApp, if I want to increase the number of replicas to 2, then what happens is, the first replica starts, and it deploys all .bpmn files. The second replica will not start because the Zeebe client fails "“ApplicationContextException: Failed to start bean ‘zeebeLifecycleEventProducer’”. It is possible that they are going into some form of a racing condition.
@dulshand - I wouldn’t deploy the diagrams on startup. That’s an unnecessary step with Camunda 8. If you do deploy Web Modeler, you can use the API to integrate into your CI/CD pipelines. Otherwise I’d look for a solution other than deploying on startup. One suggestion: add an environment variable/application config that says “deploy on startup”, but only have it enabled in one instance.
I agree that it’s probably causing issues, and it’s also likely causing additional and unneeded versions of the process to be deployed, which may make troubleshooting process instances more difficult in the future.
C8 is a fundamentally different architecture than C7, so it’s important to adapt some of those processes that used to work with C7.
@nathan.loding , I am not deploying at start up. Camunda cluster is independent and it starts up with nothing. It is running on a KIND. Please forget about what I said about C7. When I run Zeebe client it does not run within C8 cluster. Zeebe client runs as an external application which has a completely different lifecycle to C8 Cluster, operate and C8 services. What I am converting to a Zeebe client is one of my other external microservice which is totally independent. Lets call it SimpleApp which is some other application that exists.
@dulshand - then I am confused?
then what happens is, the first replica starts, and it deploys all .bpmn files
From your description, you are including your BPMN models (the raw XML documents) as resources in your Spring application, and when the application starts, it deploys those BPMN models to your cluster. I would recommend against doing that.
If you remove the models from your Spring applications (there is no need to deploy the XML with these services) and instead deploy the BPMN a different way, do you still have issues when the second pod tries to start?