Camunda 8 Self-Managed Local Environment
In this post I will go briefly about the options available for having a Camunda 8 environment fully functional for development locally in your machine.
 |
| Camunda Logo |
Why local?
If you do not have an Enterprise / Partner Camunda Cloud access then you may have already created 928349328403928 email accounts for 30 days free trials. If you are tired of it, then mount easily the local environment!
Manual
Yes, if you are from an older generation like me, who preferred to have virtual machines local to your machine without using Docker or Kubernetes, then this is your solution.
The Manual installation steps can be found here:
Personally, I haven't tried it at all. I am old, but I upgraded to the Kubernetes / Docker Compose life.
My views:
- If you choose this approach, do not use your local PC and do not pollute it. I would rather prefer to have a local Virtual Machine.
- I will personally avoid this way in preference for Docker-Compose or Local Kubernetes cluster
Docker Compose
This is a very common practice for developers to spin up a development environment quickly with the necessary services.
The documentation is found here:
Note: As said in the documentation, this approach is only for development!. Do not be silly and try it in production.
The GitHub is here: https://github.com/camunda/camunda-platform
Important to know:
- The docker-compose.yaml contains all the services excepting Web Modeler (it requires Enterprise License)
- If you are NOT interested in Optimize, Keycloak and Identity for development, then just use docker-compose-core.yaml
- docker-compose-web-modeler.yaml only if you have a license, you are going to need to login into registry.camunda.cloud
My views:
- It is perfect acceptable its use for development even if Camunda recommend using their HELM and KIND approach to have a local environment more close to production.
Local Kubernetes Cluster
This is the recommended approach by Camunda and the one I am also following. It consists of installing a local Kubernetes cluster with kind, minikube or your preferred for local development.
They provide very clear all the steps to configure it here:
I recommend you configure the NGINX ingress controller, so you do not have to do port-forwarding mappings every time / day you up your local environment.
Some important things to know when following the documentation:
- If using NGINX approach, create the cluster following the instructions below where you need to create the kind.config file to make sure you enable ingress-controller
- If using NGINX, you have to update the camunda-platform-kind-values.yaml. There is a small bug (maybe the fixed it when you read this) where the first ingress needs an indentation inside global
- Make sure that all the containers are Running when you finish the steps
Camunda 8 pods running in local kubernetes (KIND) - You need to have the NGINX ingress controller also up
Ingress Controllers configured
 |
| Camunda 8 Self-Managed Tasklist running locally |
Test also that operate is accessible: http://camunda.local/operate
 |
| Camunda 8 Self-Managed Operate running locally |
Is this all?
No, it is not all if you decided to use NGINX Ingress instead of Port-Forwarding. Camunda can work without TLS/SSL configured, however NGINX controllers not.
So, let's continue updating our above setup as following:
- Create the certificates using OpenSSL command, I used the same as used in the blog below from Camunda (lazy)
Shell / OpenSSLopenssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365 --nodes -addext 'subjectAltName=DNS:camunda.local'
Shell / OpenSSLopenssl req -x509 -newkey rsa:4096 -keyout key-zeebe.pem -out cert-zeebe.pem -sha256 -days 365 --nodes -addext 'subjectAltName=DNS:zeebe.camunda.local'
- Add the secrets just created to the Local Kubernetes cluster as followShell / OpenSSL
kubectl create secret tls tls-secret --cert=cert.pem --key=key.pem
Shell / OpenSSLkubectl create secret tls tls-secret-zeebe --cert=cert-zeebe.pem --key=key-zeebe.pem
- Update the yaml we used for the kind configuration before (camunda-platform-kind-values.yaml) for enabling TLS in zeebeGateway and global ingresscamunda-platform-core-kind-values.yaml
global: ingress: enabled: true className: nginx host: "camunda.local" tls: enabled: true secretName: 'tls-secret' identity: auth: # Disable the Identity authentication for local development # it will fall back to basic-auth: demo/demo as default user enabled: false # Disable identity as part of the Camunda core identity: enabled: false optimize: enabled: false # Reduce for Zeebe and Gateway the configured replicas and with that the required resources # to get it running locally zeebe: clusterSize: 1 partitionCount: 1 replicationFactor: 1 pvcSize: 10Gi zeebeGateway: ingress: enabled: true className: nginx host: "zeebe.camunda.local" tls: enabled: true secretName: 'tls-secret-zeebe' replicas: 1 connectors: enabled: true inbound: mode: disabled operate: contextPath: "/operate" tasklist: contextPath: "/tasklist" elasticsearch: master: replicaCount: 1 # Request smaller persistent volumes. persistence: size: 15Gi - Now, upgrade the Helm deployment we did before as followingShell / OpenSSL
helm upgrade --install camunda-platform camunda/camunda-platform -f camunda-platform-core-kind-values.yaml
- Test that all is good with Zeebe CLI as followingShell / OpenSSL
zbctl status --certPath cert-zeebe.pem --address zeebe.camunda.local:443
- Also, is needed that you also import in your keystore (e.g. cacerts) of your Java JDK those certificates as followingShell / OpenSSL
keytool -import -alias camunda-local-zeebe -keystore cacerts -file cert-zeebe.pem
Shell / OpenSSLkeytool -import -alias camunda-local -keystore cacerts -file cert.pem
In the next post we will do a Hello World process testing it in the above setup. Stay tuned
Comments
Post a Comment