Part 3: Deploy Camunda 7 With Humanitec
As a developer with limited spare time to learn the pitfalls of Kubernetes, I am going to use the platform orchestrator Humanitec for my own use: managing small cloud projects.
Following the Humanitec tutorial, you can deploy a sample application connecting to a Postgres database. With that knowledge we can also deploy our favorite process orchestrator: Production ready Camunda 7 along with the recommended Postgres database.
Deploy Camunda 7
For deploying Camunda 7, we need to create a new application in Humanitec,
Click on Create new workload
Give the workload a name:
Click on the new workload on the right
Click on Create new container
And add a new image, for instance camunda/camunda-bpm-platform:7.19.0
Version 7.19.0 is the latest release as of writing this article. You can see all available versions on dockerhub.
After having created the container, we can now go back to the application and click on Deploy:
Then click on the Active deployment and then on the workload on the right:
Wait a while and you will see logs from your starting Camunda 7 showing up:
Now we have Camunda 7 deployed! But we do not have access to it, yet.
Add Web Access
Go back to your application, click on the draft under “Draft deployments” and then on the workload on the right:
We now can edit the workload. Click on Resource dependencies on the top left and choose DNS
Name the DNS resource as you like, for instance “camunda-dns”. Once a DNS resource has been added to the workload, the Ingress configuration is enabled:
Choose your “camunda-dns” resource at the Ingress drop down and use the default settings forwarding to port 8080, which is the default port for Camunda frontend:
Now go back to your application and click on Deploy on the draft. Click on Active Deployments again and wait for the logs. Once the deployment is complete, notice the URL that is shown next to Ingress on the left!
Copy that URL and open it in a new browser tab! You will realize, nothing is happening. No 404, but endless page loading. That is because our workload hardware resource are too limited. According to Camunda7 specs we need at least 1 cpu and 1 GB ram, but when we look in our workload we only provide a fraction of that:
Therefore, go the draft of your workload and provide more resources. 1 cpu and 2048 MB memory should be sufficient. Deploy again and wait for the the first logs showing up. Open your ingress URL again in a browser tab. You should now see a tomcat server responding. That is the tomcat server running your Camunda 7 instance! Add a /camunda behind your url and you should see the login screen:
You can login with username “demo” and password “demo”.
Voila, we got Camunda 7 engine running including frontend and ingress routing. However, this setup is for demo purposes only. It comes with demo user authentication, with demo processes and most of all with a file based H2 database, which would slow down the workflow engine after some time, if it would not get lost after each deployment.
Let’s get rid of the demo processes first by adding a new container variable camunda.bpm.run.example.enabled to false . When you click on deploy, you will have a fresh Camunda without any demo processes.
Define Postgres Resource
Since the underlying H2 database is file-based, we loose all data with each deployment. The H2 database had been created inside the container and with each deployment the old container is replaced with a new one. Therefore, we need a database outside the container in order to keep our process data.
Create resource definition for Camunda Postgres Database by choosing “Resource Management” on the left menu and click on “Add resource definition”. Choose Postgres SQL and as driver simple “postgres”:
Give your database resource an id (for instance camunda-db), a username and a password. Other fields you can leave empty.
Now for making the Postgres resource available for an applicaiton, you need to configure the matching criteria of the resource. Click on the camunda-db resource in the list of resource, go to the panel “Matching Criteria” and define a criteria. For instance, make camunda-db available, if a resource of workload has the id “camunda-db”:
Add Postgres Database To Camunda 7
Now we can add Postgres to our application. Navigate back to the application, click on the draft and then on the panel “Shared Resources”.
Click on “Add shared resource” and choose Postgres. When prompted for an id, use the id from the matching criteria that you provided earlier: camunda-db .
Now we are almost there: Postgres is added to your application. Only Camunda needs to learn to use it, by defining the following variables in the container draft:
- DB_DRIVER : defines the java driver. Luckily, Camunda aleady ships with Postgres drivers onboard
The other properties have placeholders. Placeholders have the format <resource-scope>.<resource-id>.<attribute> . Luckily, Humanitec provides auto-completion for placeholders, so you do not have to worry! As soon as you click on “add variable” and start a placeholder with $ and { Humanitec suggests available placeholders:
- DB_USERNAME : ${shared.camunda-db.username}
- DB_PASSWORD: ${shared.camunda-db.password}
- DB_URL: is a bit more tricky. In short, the jdbc url for a postgres db is jdbc:postgresql://${shared.camunda-db.host}:${shared.camunda-db.port}/${shared.camunda-db.name}
Now deploy again.
Summary
We now have an almost production ready Camunda 7 deployed. A powerful process orchestrator provisioned with your platform orchestrator. You could now experiment what happens when you deploy more Camunda containers sharing the same database.
Before you proceed, I recommend creating a custom image based on Camunda 7 providing additional configuration replacing the demo user with actual users and real passwords. Also make sure to add authentication to Camundas REST engine otherwise your engine is basically open to the entire internet. You can store your custom made Camunda 7 image in a gitlab container registry and access the registry with Humanitec.
We should also add basic authentication on the ingress route preventing arbitrary access to our application, which will be topic of another post.
