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.
👉 Link to repository on Github
Usage
Prerequisites
- 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.
Admin Account
Check 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:
ADMIN_USERNAMEADMIN_PASSWORD
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.
