Camunda 7 in Cloud
With Camunda 8 as cloud-native solution for workflow orchestration, most projects rely the developed predecessor Camunda 7. While migrating from Camunda 7 to 8 is a consideration of its own, your project might face another challenge: migrating to cloud in first place. As part of my studies as Google Cloud Developer, I started a repository on Github providing:
- Camunda Run 7.17
- Community history plugin by datakurre
- Option to set admin password and admin username
While the documentation covers deploying Google Cloud Run, the docker image is universal and can be deployed anywhere. The Github project is ongoing. Check issues panel for further featured or raise requests.
- Google Cloud account and have access to a Google Cloud Project: https://console.cloud.google.com/
- Checkout this repository
- gcloud CLI installed in your local workspace: https://cloud.google.com/sdk/docs/install
I use VS Code (as it is the only option to almost conveniently cloud-develop on popular legacy OS from same vendor). There is a Google extension available, but I do prefer command line of wizards.
Deploy Camunda 7 in Google Cloud Run
In order to deploy this Camunda 7 git project you need the following command:
gcloud run deploy --source .
In case gcloud is not connected to your local workspace, yet, it will prompt you the commands to do so.
Configure Camunda 7 environment
When configuring the cloud run environment the following setting are sufficient for demo purposes:
- 1 GB of memory
- 2 CPU
Maximum number of instances
As long as you run on the internal H2 database, make sure your maximum number of instances is equal to 1. Otherwise Cloud Run will start several independent instances with each their own individual database. Like that, you process model would randomly end up in one instance, while your external task worker tries to acquire a topic from another instance unaware of the process.
Minimum Number of instances
For cost efficiency, I would allow a minimum of 0, so the instance is automatically shutdown in idle time. As long as you do not have jobs (cleanup jobs, timer events etc.), this setting should save you some budget without messing with the automation experience. If you do have jobs in Camunda scheduled, they might not trigger due to optimized downtimes of the container.
configuration/default.yml for configuration, esspecially setting up admin password. By default admin user/password is
demo/demo but you may override the properties by providing environment variables:
Security Advise: Provide the password and username as secret. GCP has a secret store, which will make secrets available as environment variable in Cloud Run.
Newest job offers
Teamlead (f/m/d) Workplace Tech Support & Infrastructure
Tech Operations Lead
IT Security Operations Manager
Cloud Engineer (Azure)
Create Your Own Career
On our career website "Create Your Own Career" you can discover the wide range of entry and career opportunities at Bertelsmann and be inspired by our employee stories!Find more interesting jobs