@djhair01 - no, run the command make helm.dependency-update in the main folder, instead ofhelm dependency update. We include a Makefile with the repo that contains a handful of useful commands, and this is one of those cases.
I am working in Mac/Linux, so Windows might have some differences in syntax, but the primary error in your first screenshot is repo camunda-platform-helm-main not found. You might need to add a ./ before the directory, like so:
Hey @nathan.loding - sorry about misinterpreting your instructions…Figured out how to run make in Windows, but getting a 401 even when I do “make helm.dependency-update”:
Hi @djhair01 - first, thanks so much for sticking with this and troubleshooting it to the end! I’ve taken a lot of notes and will be working to make some changes to our documentation to better clarify some of the things encountered here.
… It seems there are some known connectivity issues when pulling this image. That issue points to a possible DNS issue, but also mentions Cloudfront issues. It’s also possible that there is a proxy or firewall issue preventing your workstation from downloading the image.
If you try running this command, does it fail with a similar 401 Unauthorized error? This will not “fix” the Camunda Docker install, but this will attempt to pull the Elasticsearch container from Bitnami and start it, which can help us identify what might be preventing you from pulling the image.
docker run --name elasticsearch bitnami/elasticsearch:latest
Hey @nathan.loding - thanks for your patience and perseverance! The “docker run” command didn’t encounter the 401 error…Including full log for your review - it has a lot of “noise” at the beginning where I was trying to get to the right subdirectory.
I don’t have a good sense of where to go from here, so I eagerly await your guidance. Thanks.
I admit that I’m not quite sure where to look next either! We’ve narrowed the issue down, but not quite enough to really pinpoint a cause unfortunately.
The specific error is “unexpected status from GET request” and the unexpected status is “401 Unauthorized” … the URL it is trying to hit is
When I open that URL in my browser (or use curl), it returns a JWT token for me. If you try to open that URL (or try to issue a HTTP GET request from the command line, which I don’t know how to do in Windows ), what response do you get?
Update: I’m finding quite a few similar questions about 401 errors with Docker registries around the internet. One theory is that Docker has low request limits based on IP, so if you’re on a shared network that is pulling frequently from Docker, you might be rate limited.
One other suggestion to look into: perhaps you have expired/invalid cached credentials for the Docker repository on your machine? It might be worth checking the credential store to make sure Docker isn’t accidentally using bad credentials. These images should be public, you shouldn’t need a username/password.
Hi @nathan.loding - i, too, get the JWT token when i hit the ElasticSearch chart URL from a browser.
Regarding invalid docker credentials stored on my machine, i didn’t quite understand what i was looking for and what, if anything needed to change, but i did find the following in ~.docker\config.json:
Hi @djhair01 - the Elasticsearch container that is running can be removed. That was just a test to make sure your workstation could pull the image, which it can. You could spin up a separate Elasticsearch instance and configure Camunda to use it (you would need to point all Elasticsearch configuration parameters to your instance).
As for next steps, unfortunately I don’t know! This is not an issue with Camunda or with our Helm charts or container images; for some reason, your workstation is blocked from fetching the bitnami/elasticsearch charts. There is a thread in the bitnami GitHub repository that says that upgrading your Helm client to v3.13.1 may fix it.
Hi @nathan.loding - thanks for the follow-up. I read the bitnami thread and see that i am indeed running an older Helm client:
PS C:\Users\dujua.kube\camunda-platform-helm-main\charts> helm version
version.BuildInfo{Version:“v3.13.0”, GitCommit:“825e86f6a7a38cef1112bfa606e4127a706749b1”, GitTreeState:“clean”, GoVersion:“go1.20.8”}
I’ve run several permutations of the “helm upgrade” command using file names and subdirectories for the [CHART] argument, but to no avail (error message transcript is below):
Usage:
helm upgrade [RELEASE] [CHART] [flags]
My question is: what should I use for the [CHART] argument? Thanks.
TRANSCRIPT
PS C:\Users\dujua.kube\camunda-platform-helm-main\charts\camunda-platform> helm upgrade v3.13.1 Chart.yaml
Error: file ‘C:\Users\dujua.kube\camunda-platform-helm-main\charts\camunda-platform\Chart.yaml’ seems to be a YAML file, but expected a gzipped archive
PS C:\Users\dujua.kube\camunda-platform-helm-main\charts\camunda-platform> helm upgrade v3.13.1 charts
Error: Chart.yaml file is missing
PS C:\Users\dujua.kube\camunda-platform-helm-main\charts\camunda-platform> helm upgrade v3.13.1 Chart
Error: non-absolute URLs should be in form of repo_name/path_to_chart, got: Chart
PS C:\Users\dujua.kube\camunda-platform-helm-main\charts\camunda-platform> helm upgrade v3.13.1 Chart.yaml
Error: file ‘C:\Users\dujua.kube\camunda-platform-helm-main\charts\camunda-platform\Chart.yaml’ seems to be a YAML file, but expected a gzipped archive
PS C:\Users\dujua.kube\camunda-platform-helm-main\charts\camunda-platform> helm upgrade v3.13.1
Error: “helm upgrade” requires 2 arguments
Usage: helm upgrade [RELEASE] [CHART] [flags]
PS C:\Users\dujua.kube\camunda-platform-helm-main\charts\camunda-platform> helm upgrade v3.13.1 /charts
Error: repo not found
The helm upgrade command upgrades a deployed cluster with a new chart; it doesn’t upgrade the version of helm installed on your workstation. For that, you need to follow the installation instructions in Helm’s documentation.
This is where I lack some knowledge about Windows and Powershell. I think you need to have a ./ before the folder path for the local copy of the charts:
The other set of errors (“cannot re-use a name that is still in use”) means you may already have a cluster using that name. I would recommend removing anything installed (easy to do with Docker, just delete the control planes), then start the installation from the first step again. Hopefully adding a ./ before the path resolves it!
I tried doing the port forwarding and hitting URLs for Tasklist, Operate and their healthchecks but got errors. I’ve attached “Describe” and “Log” files from k9s for the pods.
Next steps to get me running? Thanks and have a great weekend.
They are unable to connect to Elasticsearch, and in the k9s screenshot Elasticsearch hasn’t started yet. Did you delete everything in Docker and start from the beginning again? If not, try that first. If you did, then this might be a case where you need to give Docker more resources.
Hi @T-san - it may be three months later, but I finally got a new blog post published that shows how to enable ingress controllers. If that’s something you’re still working on, you can read it here:
I followed the instructions and get an error:
$ sudo helm install camunda-platform camunda/camunda-platform -f camunda-values.yaml
sudo helm install camunda-platform camunda/camunda-platform -f camunda-values.yaml
Error: INSTALLATION FAILED: execution error at (camunda-platform/templates/camunda/constraints.tpl:60:52):
[camunda][error] Identity is disabled but identityKeycloak is enabled. Please ensure that if identityKeycloak is enabled, Identity must also be enabled.
I have completed the part on and part two ingress. There are a number of things that are not clear:
It would be great to have the commands to set up a demo/dev cluster all in one place and not spread across the blog with the files and information continuously changing and evolving through the blog.
The setup is anything but straightforward and easy, and the number of posts on the forum support this. Is it not possible to release a demo/dev cluster fully setup as a VM image that we can just download and run please. This may be informative to those who want to run their own clusters, but for those who wish to setup a simple demo/dev cluster it is onerous. I am wanting to support camunda as a reseller but the Saas model does not allow for a simple demo setup without getting into several thousands of dollars. By having at least a basic cluster available on the free plan would make this whole setup thing moot. But here we are messing with devops stuff that is really not necessary. For open source projects this is fine, but not for paid platforms.
I have downloaded the values.yaml file:
global:
ingress:
enabled: true
className: nginx
host: "camunda.local"
tls:
enabled: true
secretName: "tls-secret"
identity:
auth:
# Disable Identity authentication for local development
# it will fall back to basic-auth: demo/demo as default user
enabled: false
# Disable Identity for local development
identity:
enabled: false
# Disable Optimize
optimize:
enabled: false
operate:
contextPath: "/operate"
tasklist:
contextPath: "/tasklist"
# Reduce resource usage for Zeebe and Zeebe-Gateway
zeebe:
clusterSize: 1
partitionCount: 1
replicationFactor: 1
pvcSize: 10Gi
resources: {}
initResources: {}
zeebe-gateway:
replicas: 1
ingress:
enabled: true
className: nginx
host: "zeebe.camunda.local"
tls:
enabled: true
secretName: "tls-secret-zeebe"
# Enable Outbound Connectors only
connectors:
enabled: true
inbound:
mode: "disabled"
# Configure Elasticsearch to make it running for local development
elasticsearch:
resources: {}
initResources: {}
replicas: 1
minimumMasterNodes: 1
# Allow no backup for single node setups
clusterHealthCheckParams: "wait_for_status=yellow&timeout=1s"
# Request smaller persistent volumes.
volumeClaimTemplate:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "standard"
resources:
requests:
storage: 15Gi
When installing this it causes the error I described in my previous post.
I then modified the config file to enable the keycloak identity:
global:
ingress:
enabled: true
className: nginx
host: "camunda.local"
tls:
enabled: true
secretName: "tls-secret"
identity:
auth:
# Disable Identity authentication for local development
# it will fall back to basic-auth: demo/demo as default user
enabled: true
# Disable Identity for local development
identity:
enabled: true
# Disable Optimize
optimize:
enabled: false
operate:
contextPath: "/operate"
tasklist:
contextPath: "/tasklist"
# Reduce resource usage for Zeebe and Zeebe-Gateway
zeebe:
clusterSize: 1
partitionCount: 1
replicationFactor: 1
pvcSize: 10Gi
resources: {}
initResources: {}
zeebe-gateway:
replicas: 1
ingress:
enabled: true
className: nginx
host: "zeebe.camunda.local"
tls:
enabled: true
secretName: "tls-secret-zeebe"
# Enable Outbound Connectors only
connectors:
enabled: true
inbound:
mode: "disabled"
# Configure Elasticsearch to make it running for local development
elasticsearch:
resources: {}
initResources: {}
replicas: 1
minimumMasterNodes: 1
# Allow no backup for single node setups
clusterHealthCheckParams: "wait_for_status=yellow&timeout=1s"
# Request smaller persistent volumes.
volumeClaimTemplate:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "standard"
resources:
requests:
storage: 15Gi
This now starts the cluster - I think. All the services in k9s are pending, except for the keycloak:
I now have no idea of where to point an external browser to get to a login screen??? And your blog is unfortunately very silent on this matter.
So the problem I am facing is that the very starting point of having identity setup is apparently required, but you leave this as an exercise for the user!?!
@Franz - I think a point of confusion here is that blog posts aren’t the same as documentation, and they aren’t updated to reflect the latest releases. In a more recent release of the Helm charts, well after this post was published, some new values were added. If you don’t want to enable Identity, as in the blog post, you should also add this to your values.yaml:
identityKeycloak:
enabled: false
For a maintained guide that is similar to this blog post, you can reference our documentation here: Local Kubernetes cluster | Camunda 8 Docs … our documentation is much more in the style of having the commands “in one place” (or at least not spread out so much). The intention of the blog post was to educate, not provide a copy/paste environment.
Setting up any service in Kubernetes is often complicated. There will always be questions. We do offer an out-of-the-box fully configured Docker Compose configuration for development and testing, that you can then further customize as needed. Again, the intention of the blog post was to introduce Kubernetes to those not familiar with it, not to provide a fully featured copy/paste Camunda environment, nor to say that Camunda believes this configuration is the best for a local development cluster.
), what response do you get?
