camunda / camunda-platform-helm Goto Github PK
View Code? Open in Web Editor NEWCamunda Platform 8 Self-Managed Helm charts
Home Page: https://docs.camunda.io/docs/self-managed/overview/
License: Apache License 2.0
Camunda Platform 8 Self-Managed Helm charts
Home Page: https://docs.camunda.io/docs/self-managed/overview/
License: Apache License 2.0
The config parameters are described in a bullet point list currently, but I personally would love to see an example file for the stupids (like me) who are not completely sure how to apply them exactly.
As you can see here I spontaneously messed it up: https://github.com/berndruecker/kafka-connect-zeebe-benchmark/pull/2/files ;-)
Add Identity Application to the single chart. Dependency of #126.
Description:
I have deployed zeebe cluster and zeebe operate separately, In the zeebe cluster, the elasticsearch is configured with the AWS ELK but facing issue with zeebe operate.
Configmap.yaml:
kind: ConfigMapmetadata:
name: {{ include "zeebe-operate.fullname" . }}
apiVersion: v1
data:
application.yml: |
# Operate configuration file
camunda.operate:
elasticsearch:
host: {{ .Values.global.elasticsearch.host }}
port: {{ .Values.global.elasticsearch.port }}
username: {{ .Values.global.elasticsearch.username }}
password: {{ .Values.global.elasticsearch.password }}
prefix: zeebe-record-operate
ERROR:
2020-06-29 05:35:10.397 ERROR 6 --- [ main] o.c.o.e.ElasticsearchConnector : Error occurred while connecting to Elasticsearch: clustername [elasticsearch], https://xx.xx.xx.x.x.x.x.ap-south-1.es.amazonaws.com:443. Will be retried...
java.io.IOException: https://xxxxx-xxxx-xxx-xx-xxx-x..ap-south-1.es.amazonaws.com: Name or service not known
at org.elasticsearch.client.RestClient$SyncResponseListener.get(RestClient.java:964) ~[elasticsearch-rest-client-6.8.7.jar!/:6.8.7]
at org.elasticsearch.client.RestClient.performRequest(RestClient.java:233) ~[elasticsearch-rest-client-6.8.7.jar!/:6.8.7]
at org.elasticsearch.client.RestHighLevelClient.internalPerformRequest(RestHighLevelClient.java:1764) ~[elasticsearch-rest-high-level-client-6.8.8.jar!/:6.8.7]
at org.elasticsearch.client.RestHighLevelClient.performRequest(RestHighLevelClient.java:1734) ~[elasticsearch-rest-high-level-client-6.8.8.jar!/:6.8.7]
at org.elasticsearch.client.RestHighLevelClient.performRequestAndParseEntity(RestHighLevelClient.java:1696) ~[elasticsearch-rest-high-level-client-6.8.8.jar!/:6.8.7]
at org.elasticsearch.client.ClusterClient.health(ClusterClient.java:146) ~[elasticsearch-rest-high-level-client-6.8.8.jar!/:6.8.7]
at org.camunda.operate.es.ElasticsearchConnector.checkHealth(ElasticsearchConnector.java:89) ~[camunda-operate-common-0.23.0.jar!/:?]
at org.camunda.operate.es.ElasticsearchConnector.createEsClient(ElasticsearchConnector.java:75) ~[camunda-operate-common-0.23.0.jar!/:?]
at org.camunda.operate.es.ElasticsearchConnector.esClient(ElasticsearchConnector.java:51) ~[camunda-operate-common-0.23.0.jar!/:?]
at org.camunda.operate.es.ElasticsearchConnector$$EnhancerBySpringCGLIB$$670b527.CGLIB$esClient$0() ~[camunda-operate-common-0.23.0.jar!/:?]
at org.camunda.operate.es.ElasticsearchConnector$$EnhancerBySpringCGLIB$$670b527$$FastClassBySpringCGLIB$$af2d84c1.invoke() ~[camunda-operate-common-0.23.0.jar!/:?]
at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244) ~[spring-core-5.2.5.RELEASE.jar!/:5.2.5.RELEASE]
at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:331) ~[spring-context-5.2.5.RELEASE.jar!/:5.2.5.RELEASE]
at org.camunda.operate.es.ElasticsearchConnector$$EnhancerBySpringCGLIB$$670b527.esClient() ~[camunda-o
Installing the latest version produces the following error:
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(Ingress.spec.rules[0].http.paths[0].backend): unknown field "serviceName" in io.k8s.api.networking.v1.IngressBackend, ValidationError(Ingress.spec.rules[0].http.paths[0].backend): unknown field "servicePort" in io.k8s.api.networking.v1.IngressBackend]
https://github.com/camunda-cloud/zeebe-controller-k8s/pull/845#issuecomment-1035954492 should be done in the charts as well to mitigate a bug in operate
CAMUNDA_OPERATE_ARCHIVER_WAITPERIODBEFOREARCHIVING for operate 1.3.x (also alphas) to 2h.
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates are awaiting their schedule. Click on a checkbox to get an update now.
camunda/camunda-tf-rosa
, github/codeql-action
)These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
camunda/console
, registry.camunda.cloud/console/console-sm
)These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.
.tool-versions
golang 1.22.6
gomplate v4.1.0
helm 3.15.3
kubectl 1.27.16
kustomize 5.4.3
yq 4.44.3
.github/actions/generate-chart-matrix/action.yml
tj-actions/changed-files v44@c65cd883420fd2eb864698a825fc4162dd94482c
.github/actions/gke-login/action.yml
google-github-actions/auth v2@f112390a2df9932162083945e46d439060d66ec2
google-github-actions/auth v2@f112390a2df9932162083945e46d439060d66ec2
google-github-actions/get-gke-credentials v2@6051de21ad50fbb1767bc93c11357a49082ad116
.github/workflows/add-to-project.yml
tibdex/github-app-token v2@3beb63f4bd073e61482598c45c71c1019b59b73a
actions/add-to-project v1.0.2@244f685bbc3b7adfa8466e08b698b5577571133e
.github/workflows/chart-public-files.yaml
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
EndBug/add-and-commit v9.1.4@a94899bca583c204427a224a7af87c02f9b325d5
.github/workflows/chart-release-chores.yml
tibdex/github-app-token v2@3beb63f4bd073e61482598c45c71c1019b59b73a
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
asdf-vm/actions v3@05e0d2ed97b598bfce82fd30daf324ae0c4570e6
actions/cache v4@0c45773b623bea8c8e75f6c82b208c3cf94ea4f9
EndBug/add-and-commit v9.1.4@a94899bca583c204427a224a7af87c02f9b325d5
.github/workflows/chart-release-pr.yml
tibdex/github-app-token v2@3beb63f4bd073e61482598c45c71c1019b59b73a
googleapis/release-please-action v4@7987652d64b4581673a76e33ad5e98e3dd56832f
.github/workflows/chart-release-snapshot.yaml
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
asdf-vm/actions v3@05e0d2ed97b598bfce82fd30daf324ae0c4570e6
sigstore/cosign-installer v3.6.0@4959ce089c160fddf62f7b42464195ba1a56d382
docker/login-action v3@9780b0c442fbb1117ed29e0efdff1e18412f7567
oras-project/setup-oras v1@ca28077386065e263c03428f4ae0c09024817c93
.github/workflows/chart-release-update-config.yml
tibdex/github-app-token v2@3beb63f4bd073e61482598c45c71c1019b59b73a
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
EndBug/add-and-commit v9.1.4@a94899bca583c204427a224a7af87c02f9b325d5
.github/workflows/chart-release.yaml
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
asdf-vm/actions v3@05e0d2ed97b598bfce82fd30daf324ae0c4570e6
actions/cache v4@0c45773b623bea8c8e75f6c82b208c3cf94ea4f9
helm/chart-releaser-action v1.6.0@a917fd15b20e8b64b94d9158ad54cd6345335584
sigstore/cosign-installer v3.6.0@4959ce089c160fddf62f7b42464195ba1a56d382
helm/chart-releaser-action v1.6.0@a917fd15b20e8b64b94d9158ad54cd6345335584
helm/chart-releaser-action v1.6.0@a917fd15b20e8b64b94d9158ad54cd6345335584
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
asdf-vm/actions v3@05e0d2ed97b598bfce82fd30daf324ae0c4570e6
nick-fields/retry v3@7152eba30c6575329ac0576536151aca5a72780e
EndBug/add-and-commit v9.1.4@a94899bca583c204427a224a7af87c02f9b325d5
.github/workflows/chart-update-readme.yaml
tibdex/github-app-token v2@3beb63f4bd073e61482598c45c71c1019b59b73a
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
.github/workflows/chart-validate-template.yaml
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
actions/setup-python v5@39cd14951b08e74b54015e9e001cdefcf80e669f
asdf-vm/actions v3@05e0d2ed97b598bfce82fd30daf324ae0c4570e6
helm/chart-testing-action v2.6.1@e6669bcd63d7cb57cb4380c33043eebe5d111992
redhat-actions/openshift-tools-installer v1@144527c7d98999f2652264c048c7a9bd103f8a82
.github/workflows/renovate-config-check.yaml
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
.github/workflows/renovate-post-upgrade.yaml
tibdex/github-app-token v2@3beb63f4bd073e61482598c45c71c1019b59b73a
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
asdf-vm/actions v3@05e0d2ed97b598bfce82fd30daf324ae0c4570e6
actions/cache v4@0c45773b623bea8c8e75f6c82b208c3cf94ea4f9
EndBug/add-and-commit v9.1.4@a94899bca583c204427a224a7af87c02f9b325d5
.github/workflows/repo-issue-labeler.yaml
github/issue-labeler v3.4@c1b0f9f52a63158c4adc09425e858e87b32e9685
.github/workflows/repo-pr-conventions.yaml
amannn/action-semantic-pull-request v5.5.3@0723387faaf9b38adef4775cd42cfd5155ed6017
.github/workflows/repo-pr-labeler.yaml
actions/labeler v5@8558fd74291d67161a8a78ce36a881fa63b766a9
.github/workflows/sec-codeql.yml
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
github/codeql-action 5c681efc3f71cd6b47b1c14583c9e86913966e9f
github/codeql-action 5c681efc3f71cd6b47b1c14583c9e86913966e9f
github/codeql-action 5c681efc3f71cd6b47b1c14583c9e86913966e9f
.github/workflows/sec-scorecard.yml
actions/checkout v4.1.7@692973e3d937129bcbf40652eb9f2f61becf3332
ossf/scorecard-action v2.4.0@62b2cac7ed8198b15735ed49ab1e5cf35480ba46
actions/upload-artifact v4.3.6@834a144ee995460fba8ed112a2fc961b36a5ec5a
github/codeql-action v3.26.2@429e1977040da7a23b6822b13c129cd1ba93dbb2
.github/workflows/test-integration-cleanup-template.yaml
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
redhat-actions/oc-login v1@5eb45e848b168b6bf6b8fe7f1561003c12e3c99d
.github/workflows/test-integration-rosa-cleanup.yml
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
camunda/camunda-tf-rosa main
slackapi/slack-github-action v1.26.0@70cd7be8e40a46e8b0eced40b0de447bdb42f68e
.github/workflows/test-integration-rosa-template.yaml
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
camunda/camunda-tf-rosa e97b03ea5c79b19a92b178952fb4a401d442ff10
tibdex/github-app-token v2@3beb63f4bd073e61482598c45c71c1019b59b73a
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
nick-fields/retry v3@7152eba30c6575329ac0576536151aca5a72780e
cloudposse/github-action-matrix-outputs-write v1@ed06cf3a6bf23b8dce36d1cf0d63123885bb8375
cloudposse/github-action-matrix-outputs-read v1@33cac12fa9282a7230a418d859b93fdbc4f27b5a
tibdex/github-app-token v2@3beb63f4bd073e61482598c45c71c1019b59b73a
camunda/camunda-tf-rosa e97b03ea5c79b19a92b178952fb4a401d442ff10
slackapi/slack-github-action v1.26.0@70cd7be8e40a46e8b0eced40b0de447bdb42f68e
.github/workflows/test-integration-template.yaml
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
hashicorp/vault-action v3.0.0@d1720f055e0635fd932a1d2a48f87a666a57906c
tibdex/github-app-token v2@3beb63f4bd073e61482598c45c71c1019b59b73a
redhat-actions/oc-login v1@5eb45e848b168b6bf6b8fe7f1561003c12e3c99d
asdf-vm/actions v3@05e0d2ed97b598bfce82fd30daf324ae0c4570e6
bobheadxi/deployments v1@648679e8e4915b27893bd7dbc35cb504dc915bc8
bobheadxi/deployments v1@648679e8e4915b27893bd7dbc35cb504dc915bc8
bobheadxi/deployments v1@648679e8e4915b27893bd7dbc35cb504dc915bc8
.github/workflows/test-regression.yaml
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
.github/workflows/test-unit-template.yml
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
actions/checkout v4@692973e3d937129bcbf40652eb9f2f61becf3332
asdf-vm/actions v3@05e0d2ed97b598bfce82fd30daf324ae0c4570e6
actions/cache v4@0c45773b623bea8c8e75f6c82b208c3cf94ea4f9
charts/camunda-platform-8.2/go.mod
go 1.21
go 1.23.0
github.com/gruntwork-io/terratest v0.47.0
github.com/stretchr/testify v1.9.0
k8s.io/api v0.28.4
charts/camunda-platform-8.3/go.mod
go 1.21.5
github.com/gruntwork-io/terratest v0.47.0
github.com/stretchr/testify v1.9.0
k8s.io/api v0.28.4
charts/camunda-platform-8.4/go.mod
go 1.22.0
github.com/gruntwork-io/terratest v0.47.0
github.com/stretchr/testify v1.9.0
k8s.io/api v0.28.4
charts/camunda-platform-alpha/go.mod
go 1.22.2
github.com/BurntSushi/toml v1.4.0
github.com/gruntwork-io/terratest v0.47.0
github.com/stretchr/testify v1.9.0
gopkg.in/yaml.v3 v3.0.1
k8s.io/api v0.28.4
charts/camunda-platform-latest/go.mod
go 1.22.2
github.com/BurntSushi/toml v1.4.0
github.com/gruntwork-io/terratest v0.47.0
github.com/stretchr/testify v1.9.0
gopkg.in/yaml.v3 v3.0.1
k8s.io/api v0.28.4
charts/camunda-platform-8.2/values-latest.yaml
camunda/connectors-bundle 0.23.2
camunda/optimize 8.2.13
camunda/identity 8.2.30
bitnami/keycloak 19.0.3
bitnami/postgresql 15.4.0
bitnami/elasticsearch-curator-archived 5.8.4
charts/camunda-platform-8.2/values.yaml
camunda/zeebe 8.2.30
camunda/zeebe 8.2.30
camunda/operate 8.2.29
camunda/tasklist 8.2.30
camunda/optimize 8.2.13
camunda/identity 8.2.30
bitnami/postgresql 15.4.0
bitnami/keycloak 19.0.3
camunda/connectors-bundle 0.23.2
bitnami/elasticsearch-curator-archived 5.8.4
charts/camunda-platform-8.3/values-latest.yaml
camunda/connectors-bundle 8.3.15
camunda/optimize 8.3.12
camunda/identity 8.3.15
bitnami/keycloak 22.0.5
bitnami/postgresql 15.5.0
bitnami/elasticsearch 8.8.2
charts/camunda-platform-8.3/values.yaml
camunda/zeebe 8.3.14
camunda/zeebe 8.3.14
camunda/operate 8.3.14
camunda/tasklist 8.3.15
camunda/optimize 8.3.12
camunda/identity 8.3.15
bitnami/postgresql 15.5.0
bitnami/postgresql 15.5.0
bitnami/keycloak 22.0.5
camunda/connectors-bundle 8.3.15
bitnami/elasticsearch 8.8.2
charts/camunda-platform-8.4/values-latest.yaml
camunda/connectors-bundle 8.4.10
camunda/optimize 8.4.7
camunda/identity 8.4.10
bitnami/keycloak 22.0.5
bitnami/postgresql 15.5.0
bitnami/elasticsearch 8.9.2
charts/camunda-platform-8.4/values.yaml
registry.camunda.cloud/console/console-sm 8.4.60
camunda/zeebe 8.4.10
camunda/zeebe 8.4.10
camunda/operate 8.4.11
camunda/tasklist 8.4.11
camunda/optimize 8.4.7
camunda/identity 8.4.10
bitnami/postgresql 15.7.0
bitnami/postgresql 15.7.0
bitnami/keycloak 22.0.5
camunda/connectors-bundle 8.4.10
bitnami/elasticsearch 8.9.2
charts/camunda-platform-alpha/openshift/values.yaml
charts/camunda-platform-alpha/values-latest.yaml
camunda/connectors-bundle 8.6.0-alpha4
camunda/optimize 8.6.0-alpha4
camunda/tasklist 8.6.0-alpha4
camunda/zeebe 8.6.0-alpha4
camunda/zeebe 8.6.0-alpha4
camunda/identity 8.6.0-alpha4
bitnami/keycloak 23.0.7
bitnami/postgresql 15.8.0
bitnami/elasticsearch 8.15.0
charts/camunda-platform-alpha/values.yaml
camunda/zeebe 8.6.0-alpha4
camunda/zeebe 8.6.0-alpha4
camunda/operate 8.6.0-alpha4
camunda/tasklist 8.6.0-alpha4
camunda/optimize 8.6.0-alpha4
camunda/identity 8.6.0-alpha4
bitnami/postgresql 15.8.0
bitnami/keycloak 23.0.7
bitnami/postgresql 15.8.0
bitnami/postgresql 14.13.0
camunda/connectors-bundle 8.6.0-alpha4
bitnami/elasticsearch 8.15.0
charts/camunda-platform-latest/values-latest.yaml
camunda/connectors-bundle 8.5.5
camunda/optimize 8.5.4
bitnami/keycloak 23.0.7
bitnami/postgresql 15.7.0
bitnami/elasticsearch 8.12.2
charts/camunda-platform-latest/values.yaml
registry.camunda.cloud/console/console-sm 8.5.88
camunda/zeebe 8.5.6
camunda/zeebe 8.5.6
camunda/operate 8.5.5
camunda/tasklist 8.5.4
camunda/optimize 8.5.4
camunda/identity 8.5.4
bitnami/postgresql 15.7.0
bitnami/keycloak 23.0.7
bitnami/postgresql 15.7.0
bitnami/postgresql 14.12.0
camunda/connectors-bundle 8.5.5
bitnami/elasticsearch 8.12.2
charts/web-modeler-postgresql-14/values.yaml
docker.io/bitnami/postgresql 16.4.0-debian-12-r2
docker.io/bitnami/os-shell 12-debian-12-r27
docker.io/bitnami/postgres-exporter 0.15.0-debian-12-r39
charts/web-modeler-postgresql/values.yaml
docker.io/bitnami/postgresql 14.13.0
docker.io/bitnami/bitnami-shell 11-debian-11-r136
docker.io/bitnami/postgres-exporter 0.15.0
charts/camunda-platform-8.2/Chart.yaml
postgresql 11.x.x
common 2.x.x
charts/camunda-platform-8.2/charts/identity/Chart.yaml
keycloak 12.3.0
charts/camunda-platform-8.3/Chart.yaml
postgresql 11.x.x
common 2.x.x
charts/camunda-platform-8.3/charts/identity/Chart.yaml
keycloak 16.1.7
postgresql 12.x.x
charts/camunda-platform-8.4/Chart.yaml
postgresql 11.x.x
common 2.x.x
charts/camunda-platform-8.4/charts/identity/Chart.yaml
keycloak 17.3.6
postgresql 12.x.x
charts/camunda-platform-alpha/Chart.yaml
keycloak 19.4.1
postgresql 14.x.x
elasticsearch 20.0.4
common 2.x.x
charts/camunda-platform-latest/Chart.yaml
keycloak 19.4.1
postgresql 12.x.x
elasticsearch 20.0.4
common 2.x.x
charts/web-modeler-postgresql-14/Chart.yaml
charts/web-modeler-postgresql/Chart.yaml
common 2.x.x
charts/camunda-platform-8.2/values-latest.yaml
camunda/web-modeler 8.2.17
elasticsearch/elasticsearch 7.17.23
charts/camunda-platform-8.2/values.yaml
camunda/web-modeler 8.2.17
elasticsearch/elasticsearch 7.17.23
charts/camunda-platform-8.3/values-latest.yaml
camunda/web-modeler 8.3.10
charts/camunda-platform-8.3/values.yaml
camunda/web-modeler 8.3.10
charts/camunda-platform-8.4/values-latest.yaml
camunda/console 8.4.60
camunda/web-modeler 8.4.8
charts/camunda-platform-8.4/values.yaml
camunda/console 8.4.60
camunda/web-modeler 8.4.8
charts/camunda-platform-alpha/values-latest.yaml
camunda/web-modeler-restapi 8.6.0-alpha4
charts/camunda-platform-alpha/values.yaml
camunda/web-modeler-restapi 8.6.0-alpha4
charts/camunda-platform-latest/values-latest.yaml
camunda/console 8.5.88
camunda/web-modeler 8.5.6
charts/camunda-platform-latest/values.yaml
camunda/console 8.5.88
camunda/web-modeler 8.5.6
Hello!
I would like to configure zeebe operate helm chart with an elasticsearch authentication. I configured url
with this schema: https://<es_user>:<es_pass>@<es_host>:<es_port>
but it does not work.
Do you have a solution to use elasticsearch auth with zeebe-operate helm chart ?
Thanks
We are using Zeebe with the elasticsearch exporter and the Operate dashboard. After upgrading from 1.0.1 to 1.3.3 operate does not show any processes from after the update and prints migrations errors.
I tried to start versions 1.1 and 1.2 for both the zeebe broker and operate dashboard to migrate the data, but it didn't help. It seems operate is unable to use any of the new data saved by the new broker version.
Zeebe or Elasticsearch do not show any errors and I found data in the index zeebe-record_process-instance_1.3.3_2022-02-03, so the data should be saved correctly in elasticsearch.
operate-logs.csv
Zeebe 1.3.3
Operate 1.3.3
Elasticsearch v7.14.1
Hi
I recently deployed zeebe-cluster-helm chart version 0.0.88 and as part of my testing noticed that the gateway service exposes an endpoint on port 9600, which seems to always return:
503 Service Unavailable
upstream connect error or disconnect/reset before headers. reset reason: connection failure
I know this endpoint is exposed by the Zeebe pods and used by Kubernetes to check when the pod is ready, but in the gateway deployment I don't think the 9600 endpoint is used and the gateway pod seems to be ready and working, despite the 503 error.
So, is the 9600 endpoint required on the gateway pod and if yes, what might be causing the 503 error?
I tested this endpoint by calling :9600/ready, perhaps for the gateway this endpoint is invalid?
I have checked the logs, which I can provide if it helps, but they simply report that a 503 Service Unavailable error was returned.
Worth mentioning... The reason I say the gateway pod is working is because when I request the Topology I get the following response:
{
"brokers": [
{
"partitions": [],
"nodeId": 0,
"host": "workflow-engine-zeebe-0.workflow-engine-zeebe.ah-playground.svc.cluster.local",
"port": 26501
}
],
"clusterSize": 1,
"partitionsCount": 1,
"replicationFactor": 1
}
So I have assumed the standalone gateway is talking to the Zeebe Cluster.
config:
Zeebe version 0.22.1
Zeebe Cluster:
clusterSize: 1
partitionCount: 1
replicationFactor: 1
ES
replicas: 1
Thanks
Andy
Sometimes on our benchmarks we also want to see metrics from elastic, for that normally the elastic-exporter is used
We configured it normally like this, in order to work with out Prometheus setup.
es:
uri: "http://elasticsearch-master-headless:9200"
serviceMonitor:
enabled: true
labels:
release: "metrics"
We should rework the Zeebe configmap, could be done similar to https://github.com/camunda-community-hub/camunda-cloud-operator/blob/main/operator/controllers/zeebe_controller.go
See related discussion #145 (comment) the gateway doesn't need this
We need to test our charts, to verify and ensure functionality and to guarantee that we not break them on adding more features or fixing bugs.
I tried to configure podSecurityContext/securityContext with zeebe-cluster-helm 1.2.10.
It fails with
Error: YAML parse error on zeebe-cluster-helm/templates/statefulset.yaml: error converting YAML to JSON: yaml: line 104: mapping values are not allowed in this context helm.go:88: [debug] error converting YAML to JSON: yaml: line 104: mapping values are not allowed in this context
The values file contains:
podSecurityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- all
The generated content is:
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- all
with a bad indentation (capabilities and allowPrivilegeEscalation) should be aligned.
I tried with {{ toYaml .Values.podSecurityContext | indent 10 | trim }}
instead of {{ toYaml .Values.podSecurityContext | indent 12 | trim }}
the generation is OK (it is more a securityContext than a podSecurityContext in fact).
Indent should be 12 for Deployment (didn't need to update it) and 10 for statefulset ...
Services like operate doesn't seem to work without the standalone gateway, If we want to make it possible to swtich bettwen embedded and standlone gateway then the broker contact point shouldn't be hard coded like it is done here https://github.com/camunda-community-hub/camunda-cloud-helm/blob/main/charts/zeebe-operate-helm/templates/configmap.yaml#L24
Possible solution in ccsm helm:
We could create a helper template and define zeebe.contactPoint
. Depending on gateway enabled or not we set the contact point to the gateway or broker.
Add curator to the single chart and make it configurable.
When trying to install the zeebe-cluster-helm
chart I am getting:
Error: admission webhook "validation.gatekeeper.sh" denied the request: [denied by autogke-no-write-mode-hostpath] hostPath volume proc used in container prometheus-node-exporter uses path /proc which is not allowed in Autopilot. Allowed path prefixes for hostPath volumes are: ["/var/log/"]. Requesting user: <XXXX> and groups: <["system:authenticated"]>
[denied by autogke-no-write-mode-hostpath] hostPath volume sys used in container prometheus-node-exporter uses path /sys which is not allowed in Autopilot. Allowed path prefixes for hostPath volumes are: ["/var/log/"]. Requesting user: <XXXXXX> and groups: <["system:authenticated"]>
[denied by autogke-no-host-port] container prometheus-node-exporter specifies a host port; disallowed in Autopilot. Requesting user: <XXXXXXX> and groups: <["system:authenticated"]>
[denied by autogke-disallow-hostnamespaces] enabling hostPID is not allowed in Autopilot. Requesting user: <XXXXX> and groups: <["system:authenticated"]>
[denied by autogke-disallow-hostnamespaces] enabling hostNetwork is not allowed in Autopilot. Requesting user: <XXXXX> and groups: <["system:authenticated"]>
Currently we have the problem that we quite often add new features or try to fix bugs but we didn't test it automatically. It already often happens that on new releases our current benchmark didn't work anymore. I would like to introduce some tests for the helm charts.
Maybe we can make use of golden files https://medium.com/@jarifibrahim/golden-files-why-you-should-use-them-47087ec994bf
It's not possible to deploy the zeebe-operate-helm
-chart to K8S-Clusters with a version < 1.19.0
due to an incompatibility with the ingress
's apiVersion
.
Is this by design because you don't want to support K8S-versions which are EOL
with this chart?
Otherwise I'd like to provide a "fix" for that by adjusting the ingress.yaml
as it is created per default by $ helm create chart
:
# [...]
{{- if .Values.ingress.enabled -}}
# [...]
{{- if and .Values.ingress.className (not (semverCompare ">=1.18-0" .Capabilities.KubeVersion.GitVersion)) }}
{{- if not (hasKey .Values.ingress.annotations "kubernetes.io/ingress.class") }}
{{- $_ := set .Values.ingress.annotations "kubernetes.io/ingress.class" .Values.ingress.className}}
{{- end }}
{{- end }}
{{- if semverCompare ">=1.19-0" .Capabilities.KubeVersion.GitVersion -}}
apiVersion: networking.k8s.io/v1
{{- else if semverCompare ">=1.14-0" .Capabilities.KubeVersion.GitVersion -}}
apiVersion: networking.k8s.io/v1beta1
{{- else -}}
apiVersion: extensions/v1beta1
{{- end }}
kind: Ingress
# [...]
spec:
{{- if and .Values.ingress.className (semverCompare ">=1.18-0" .Capabilities.KubeVersion.GitVersion) }}
ingressClassName: {{ .Values.ingress.className }}
{{- end }}
# [...]
$ k version
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.17", GitCommit:"68b4e26caf6ede7af577db4af62fb405b4dd47e6", GitTreeState:"clean", BuildDate:"2021-03-18T00:54:02Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}
$ helm upgrade --install --namespace ${K8S_NAMESPACE} camundacloud/zeebe-operate-helm .
Error: UPGRADE FAILED: unable to recognize "": no matches for kind "Ingress" in version "networking.k8s.io/v1"
Looks like imagePullSecrets support is missing from the helm chart.
I does work if you set the secrets in the ServiceAccount but it would be great if it is added for the pods as well.
Two use cases could be the following:
Description
Nodes in a Zeebe cluster use SWIM (i.e. gossip) to propagate information about other nodes. This is how topology is propagated, and how which node is subscribed to which notification event as well. Within SWIM, each node is identified by its memberId; if two nodes share the same memberId
, then problems can arise as for the other nodes they are essentially the same. As you can imagine, that has some pretty bad consequences, such as breaking topology (e.g. incomplete topologies) or missing long polling notifications.
To fix this, we simply need to ensure every gateway replica gets a different memberId
. This can be done by setting the env var ZEEBE_GATEWAY_CLUSTER_MEMBERID
to the hostname or some such. I think at the moment it is unfortunately hardcoded to be zeebe-gateway
, which could lead to the issues I've described above if someone uses more than one gateway replica.
Note that this does not affect embedded gateways.
When installing zeebe-full-helm
on k8s 1.22 the nginx ingress is crash-looping. This might be due to updates in k8s:
https://kubernetes.io/blog/2021/07/26/update-with-ingress-nginx/
Hi,
I wanted to deploy all pods related to Zeebe in a different node pools in AKS. I figured it out that I can run all the pods in one node pool except the tasklist and operate pods.
Is there anyway to set these values for Tasklist and operate pods?
I have used below values.yaml file for installing the zeebe-full-helm chart.
helm upgrade --namespace zeebe --install --wait --timeout 10m0s zb zeebe/zeebe-full-helm -f values.yaml
`
global:
zeebe: "{{ .Release.Name }}-zeebe"
zeebe-cluster-helm:
elasticsearch:
tolerations:
- key: "zeebe"
operator: "Equal"
value: "gpu"
effect: "NoSchedule"
nodeSelector:
zeebe: isolatenodepool
gateway:
tolerations:
- key: "zeebe"
operator: "Equal"
value: "gpu"
effect: "NoSchedule"
nodeSelector:
zeebe: isolatenodepool
tolerations:
cloudevents:
enabled: false
tasklist:
enabled: true
zeeqs:
enabled: false
ingress-nginx:
controller:
tolerations:
- key: "zeebe"
operator: "Equal"
value: "gpu"
effect: "NoSchedule"
nodeSelector:
zeebe: isolatenodepool
service:
ports:
http: 80
https: 443
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
zeebe-tasklist-helm:
ingress:
enabled: true
annotations:
ingress.kubernetes.io/ingress.class: nginx
ingress.kubernetes.io/rewrite-target: "/"
nginx.ingress.kubernetes.io/ssl-redirect: "false"
path: /
host: tasklist.zeebe.weud
tls:
enabled: false
secretName:
nodeSelector:
zeebe: isolatenodepool
tolerations:
zeebe-operate-helm:
ingress:
enabled: true
annotations:
ingress.kubernetes.io/ingress.class: nginx
ingress.kubernetes.io/rewrite-target: "/"
nginx.ingress.kubernetes.io/ssl-redirect: "false"
path: /
host: operate.zeebe.weud
tls:
enabled: false
secretName:
nodeSelector:
zeebe: isolatenodepool
tolerations:
I tried:
zeebe-operate-helm:
resources:
limits:
cpu: 14
memory: 54Gi
requests:
cpu: 14
memory: 32Gi
in zeebe-full-helm
to configure Operate resources similar to how it is done for zeebe-cluster-helm
. However, I saw that the deployment.yaml is having resources hard-coded. I suggest to do it similar to zeebe-cluster-helm's statefulset.yaml.
As a last chapter it would be awesome to see some kind of contribution guide/ section in the readme.
Maybe you could just link one created by @celanthe. I just found this page here. Nevertheless, Camunda Platform deals with it separately in their GitHub Repository.
Hello, I had a problem with default config for tasklist. The service did not work in default installation I had to change main object of config from zeebe to camunda.
From:
# Tasklist configuration file
zeebe.tasklist:
# Set Tasklist username and password.
# If user with <username> does not exists it will be created.
# Default: demo/demo
---TRUNC---
To:
# Tasklist configuration file
camunda.tasklist:
# Set Tasklist username and password.
# If user with <username> does not exists it will be created.
# Default: demo/demo
---TRUNC---
Add optimize chart to the single chart.
Depends on #127
I am trying to install zeebe via helm charts in a separate namespace, the same fails. I have capture the debug logs from helm command as below:
$ helm install zeebe zeebe/zeebe-full-helm -n zeebe --debug
install.go:178: [debug] Original chart version: ""
install.go:199: [debug] CHART PATH: /home/edgeprov/.cache/helm/repository/zeebe-full-helm-1.3.1.tgz
client.go:128: [debug] creating 1 resource(s)
install.go:151: [debug] CRD alertmanagerconfigs.monitoring.coreos.com is already present. Skipping.
client.go:128: [debug] creating 1 resource(s)
install.go:151: [debug] CRD alertmanagers.monitoring.coreos.com is already present. Skipping.
client.go:128: [debug] creating 1 resource(s)
install.go:151: [debug] CRD podmonitors.monitoring.coreos.com is already present. Skipping.
client.go:128: [debug] creating 1 resource(s)
install.go:151: [debug] CRD probes.monitoring.coreos.com is already present. Skipping.
client.go:128: [debug] creating 1 resource(s)
install.go:151: [debug] CRD prometheuses.monitoring.coreos.com is already present. Skipping.
client.go:128: [debug] creating 1 resource(s)
install.go:151: [debug] CRD prometheusrules.monitoring.coreos.com is already present. Skipping.
client.go:128: [debug] creating 1 resource(s)
install.go:151: [debug] CRD servicemonitors.monitoring.coreos.com is already present. Skipping.
client.go:128: [debug] creating 1 resource(s)
install.go:151: [debug] CRD thanosrulers.monitoring.coreos.com is already present. Skipping.
W0117 18:44:32.951595 1150858 warnings.go:70] policy/v1beta1 PodDisruptionBudget is deprecated in v1.21+, unavailable in v1.25+; use policy/v1 PodDisruptionBudget
client.go:299: [debug] Starting delete for "zeebe-ingress-nginx-admission" ServiceAccount
client.go:128: [debug] creating 1 resource(s)
client.go:299: [debug] Starting delete for "zeebe-ingress-nginx-admission" ClusterRole
client.go:128: [debug] creating 1 resource(s)
client.go:299: [debug] Starting delete for "zeebe-ingress-nginx-admission" ClusterRoleBinding
client.go:328: [debug] clusterrolebindings.rbac.authorization.k8s.io "zeebe-ingress-nginx-admission" not found
client.go:128: [debug] creating 1 resource(s)
client.go:299: [debug] Starting delete for "zeebe-ingress-nginx-admission" Role
client.go:328: [debug] roles.rbac.authorization.k8s.io "zeebe-ingress-nginx-admission" not found
client.go:128: [debug] creating 1 resource(s)
client.go:299: [debug] Starting delete for "zeebe-ingress-nginx-admission" RoleBinding
client.go:328: [debug] rolebindings.rbac.authorization.k8s.io "zeebe-ingress-nginx-admission" not found
client.go:128: [debug] creating 1 resource(s)
client.go:299: [debug] Starting delete for "zeebe-ingress-nginx-admission-create" Job
client.go:328: [debug] jobs.batch "zeebe-ingress-nginx-admission-create" not found
client.go:128: [debug] creating 1 resource(s)
client.go:528: [debug] Watching for changes to Job zeebe-ingress-nginx-admission-create with timeout of 5m0s
client.go:556: [debug] Add/Modify event for zeebe-ingress-nginx-admission-create: ADDED
client.go:595: [debug] zeebe-ingress-nginx-admission-create: Jobs active: 0, jobs failed: 0, jobs succeeded: 0
Error: INSTALLATION FAILED: failed pre-install: timed out waiting for the condition
helm.go:88: [debug] failed pre-install: timed out waiting for the condition
INSTALLATION FAILED
main.newInstallCmd.func2
helm.sh/helm/v3/cmd/helm/install.go:127
github.com/spf13/cobra.(*Command).execute
github.com/spf13/[email protected]/command.go:856
github.com/spf13/cobra.(*Command).ExecuteC
github.com/spf13/[email protected]/command.go:974
github.com/spf13/cobra.(*Command).Execute
github.com/spf13/[email protected]/command.go:902
main.main
helm.sh/helm/v3/cmd/helm/helm.go:87
runtime.main
runtime/proc.go:225
runtime.goexit
runtime/asm_amd64.s:1371
Verify whether we have the standardized and recommended labels set https://helm.sh/docs/chart_best_practices/labels/#standard-labels
related to #124
values.yml:
global:
image:
repository: camunda/zeebe
tag: SNAPSHOT
pullPolicy: Always
operate:
enabled: true
global:
image:
repository: camunda/operate
zeebe:
clusterSize: "3"
partitionCount: "3"
replicationFactor: "3"
....
generates this deployment for Operate:
# Source: ccsm-helm/charts/operate/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: os-benchmark-1-operate
labels:
app: camunda-cloud-self-managed
app.kubernetes.io/name: operate
helm.sh/chart: operate-0.0.9
app.kubernetes.io/instance: os-benchmark-1
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/version: 1.3.1
app.kubernetes.io/part-of: camunda-cloud-self-managed
app.kubernetes.io/component: operate
annotations:
spec:
replicas: 1
selector:
matchLabels: ...
template:
metadata:
labels: ...
spec:
containers:
- name: operate
image: "camunda/zeebe:SNAPSHOT"
...
I'd expect the global.image.repository
overwrite for Operate to work, but I'm not too familiar with Helm.
I've found the values.yml in the Zeebe benchmarks: https://github.com/camunda-cloud/zeebe/blob/main/benchmarks/setup/default/zeebe-values.yaml#L112-L116
Right now Prometheus can be deployed with a Zeebe Cluster, but in order to access grafana you need to port forward to it, this can be simplified by enabling the ingress in the prometheus chart and making sure that our Ingress Controller expose the right paths. This has proved to be challenging and time-consuming but I am sure that it can be done.
Tried to setup zeebe-cluster using the operator. Everything seems to be working fine except gateway health check.
It's always throwing out_of_service response.
{"status":"OUT_OF_SERVICE","components":{"diskSpace":{"status":"UP","details":{"total":21462233088,"free":17460678656,"threshold":10485760,"exists":true}},"gatewayClusterAwareness":{"status":"UP"},"gatewayPartitionLeaderAwareness":{"status":"UP"},"gatewayResponsive":{"status":"UP","details":{"timeOut":"PT0.5S"}},"gatewayStarted":{"status":"UP"},"livenessDiskSpace":{"status":"UP","details":{"total":21462233088,"free":17460678656,"threshold":1048576,"exists":true}},"livenessGatewayClusterAwareness":{"status":"UP","details":{"derivedFrom":"ClusterAwarenessHealthIndicator","wasEverUp":true,"maxDowntime":"PT5M","lastSeenDelegateHealthStatus":{"status":"UP"}}},"livenessGatewayPartitionLeaderAwareness":{"status":"UP","details":{"derivedFrom":"PartitionLeaderAwarenessHealthIndicator","wasEverUp":true,"maxDowntime":"PT5M","lastSeenDelegateHealthStatus":{"status":"UP"}}},"livenessGatewayResponsive":{"status":"UP","details":{"derivedFrom":"ResponsiveHealthIndicator","wasEverUp":true,"maxDowntime":"PT10M","lastSeenDelegateHealthStatus":{"status":"UP","details":{"timeOut":"PT5S"}}}},"livenessMemory":{"status":"UP","details":{"threshold":0.01}},"livenessState":{"status":"UP"},"memory":{"status":"UP","details":{"threshold":0.1}},"readinessState":{"status":"OUT_OF_SERVICE"}},"groups":["liveness","readiness","startup"]}
Please refer to this slack thread
Hi,
In camunda-community-hub/zeebe-helm@af79d0c#diff-8bc94a3006768345d17c827c0bb5840e6e4daee6de1c2b1ea672f53f162d171dL56, the url of the chart repository was changed, but that wasn't reflected in the README here, nor in other repositories (zeebe-operate, zeebe-cluster, ...).
The old URL (helm.zeebe.io) returns 404.
I wish to use the value global.zeebe
to name the Kubernetes resources zeebe
rather than zeebe-zeebe
.
In version 0.0.89 of the chart this works fine:
> helm install zeebe zeebe/zeebe-cluster --version 0.0.89 --set global.zeebe=zeebe
> kubectl get pods
NAME READY STATUS
elasticsearch-master-0 1/1 Running
elasticsearch-master-1 1/1 Running
elasticsearch-master-2 1/1 Running
zeebe-0 1/1 Running
zeebe-1 1/1 Running
zeebe-2 1/1 Running
zeebe-gateway-5f89d47657-pl8jw 1/1 Running
In the latest versions of the chart this causes the startup to fail:
> helm install zeebe zeebe/zeebe-cluster --version 0.0.99 --set global.zeebe=zeebe
> kubectl get pods
NAME READY STATUS
elasticsearch-master-0 1/1 Running
elasticsearch-master-1 1/1 Running
elasticsearch-master-2 1/1 Running
zeebe-0 0/1 CrashLoopBackOff
zeebe-1 0/1 CrashLoopBackOff
zeebe-2 0/1 CrashLoopBackOff
zeebe-gateway-5657db69c4-bzfvw 1/1 Running
> kubectl logs zeebe-0
[...]
***************************
APPLICATION FAILED TO START
***************************
Description:
Failed to bind properties under 'zeebe.broker.gateway.network.port' to int:
Property: zeebe.broker.gateway.network.port
Value: tcp://10.0.96.44:9600
Origin: "zeebe.broker.gateway.network.port" from property source "systemProperties"
Reason: failed to convert java.lang.String to int
I am using Helm 3.
Use the zeebe benchmark defaults
# JavaOpts:
# DEFAULTS
JavaOpts: >-
-XX:MaxRAMPercentage=25.0
-XX:+ExitOnOutOfMemoryError
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/usr/local/zeebe/data
-XX:ErrorFile=/usr/local/zeebe/data/zeebe_error%p.log
-Xlog:gc*:file=/usr/local/zeebe/data/gc.log:time:filecount=7,filesize=8M
Deploying the zeebe ful chart $ helm install test zeebe/zeebe-full-helm
will depeloy a ingress controller, which should forward traffic to operate (?).
But accessing the external ip doesn't work and shows a bad gateway.
Reported by an user https://camunda-cloud.slack.com/archives/C6WGNHV2A/p1643705936901069
Workaround port forward traffic to operate service directly.
k8s 1.21 says: policy/v1beta1 PodDisruptionBudget is deprecated in v1.21+, unavailable in v1.25+; use policy/v1 PodDisruptionBudget
My problem was that I wanted to setup Zeebe with operate for our benchmarks and
I saw that the throughput was significant lower when we use the zeebe-full instead of the zeebe-cluster chart. https://github.com/zeebe-io/zeebe-benchmark/issues/23
I used the same configuration for the full chart as for the cluster chart, the only difference was that I
put all properties under zeebe-cluster
.
Like:
zeebe-cluster:
image:
repository: camunda/zeebe
tag: SNAPSHOT
pullPolicy: IfNotPresent
# ZEEBE CFG
clusterSize: 3
partitionCount: 3
replicationFactor: 3
cpuThreadCount: 4
ioThreadCount: 4
... etc.
I expected that this was the way to go since the README in this repo says the same https://github.com/zeebe-io/zeebe-full-helm. Furthermore I expected that this works that way because the chart is called liked that.
Luckily I found this conversation, which shows the usage of zeebe
instead of zeebe-cluster
.
This fixes also my benchmark setup and worked now as expected:
zeebe:
image:
repository: camunda/zeebe
tag: SNAPSHOT
pullPolicy: IfNotPresent
# ZEEBE CFG
clusterSize: 3
partitionCount: 3
replicationFactor: 3
cpuThreadCount: 4
ioThreadCount: 4
... etc.
We probably should add an example configuration or something like that how to configure this or we change the name to zeebe-cluster, this would things probably more clear.
The helm chart should be able to also deploy an curator job like:
CFG Map
[zell zeebe-benchmark/ ns:zell-helm]$ cat setup/curator-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: curator-config
labels:
app: curator
data:
action_file.yml: |-
---
# Remember, leave a key empty if there is no value. None will be a string,
# not a Python "NoneType"
#
# Also remember that all examples have 'disable_action' set to True. If you
# want to use this action as a template, be sure to set this to False after
# copying it.
actions:
1:
action: delete_indices
description: "Clean up ES by deleting old indices"
options:
timeout_override:
continue_if_exception: False
disable_action: False
ignore_empty_list: True
filters:
- filtertype: age
source: name
direction: older
timestring: '%Y-%m-%d'
unit: days
unit_count: 1
field:
stats_result:
epoch:
exclude: False
config.yml: |-
---
# Remember, leave a key empty if there is no value. None will be a string,
# not a Python "NoneType"
client:
hosts:
- elasticsearch-master-headless
port: 9200
url_prefix:
use_ssl: False
certificate:
client_cert:
client_key:
ssl_no_validate: False
http_auth:
timeout: 30
master_only: False
logging:
loglevel: INFO
logfile:
logformat: default
blacklist: ['elasticsearch', 'urllib3']
Cronjob
[zell zeebe-benchmark/ ns:zell-helm]$ cat setup/curator-cronjob.yaml
# https://medium.com/@hagaibarel/running-curator-as-a-kubernetes-cronjob-19eaab9afd3b
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: curator
labels:
app: curator
spec:
schedule: "0 3 * * *" # run every 03:00 AM daily
successfulJobsHistoryLimit: 1
failedJobsHistoryLimit: 3
concurrencyPolicy: Forbid
startingDeadlineSeconds: 120
jobTemplate:
spec:
template:
spec:
containers:
- image: bobrik/curator:5.7.6
name: curator
args: ["--config", "/etc/config/config.yml", "/etc/config/action_file.yml"]
volumeMounts:
- name: config
mountPath: /etc/config
volumes:
- name: config
configMap:
name: curator-config
restartPolicy: OnFailure
Description
It's not currently possible to support non-root deployments with the Helm charts. In order to do so, we need to:
.spec.template.securityContext
so users can add runAsUser
, runAsGroup
, and fsGroup
(and set it to 1000 as recommended value)defaultMode
of the config
volume to 0777
instead of 0744
.When using the Helm charts to demo or test something, it's sometimes useful to be able to inject sidecar containers, or extra init containers. Some operators (e.g. linkerd) do this for you through annotations, others require you to do this yourself (e.g. Jaeger - they support annotations as well, but only on deployments for whatever reason).
AT:
extraAnnotations
value to allow specifying annotations for podsextraContainers
value to allow specifying sidecar containers for podsextraInitContainers
value to allow specifying additional init containers for pods (e.g. testing migration script, for example)extraVolumes
and extraVolumeMounts
to allow injecting/overwriting files during deploymentAt the moment I really only care to scope all of these for Zeebe, not sure if it makes sense to have these for other services; some of them might even have partial support already.
NOTE: see some examples here and here, and some discussion here
One helm chart to rule them all.
Create one single chart which contains all applications as sub charts.
Examples:
AT:
0 0 * * *
https://crontab.guru/every-dayi have tried the zeebe-operate helm chart and wanted to override the resource part like it is possible in zeebe-cluster-helm. But here the resource part is hardcoded written in deployment.yaml so it is not possible. Would be good to have it defined the same way like in https://github.com/zeebe-io/zeebe-cluster-helm/blob/master/zeebe-cluster/templates/statefulset.yaml
It seems that the current logging properties are out dated. I asked for feedback from the operate team. https://camunda.slack.com/archives/C9B5270DA/p1643803696900629
In the deployment guide it seems to reference only the log4j file, so we could do that. https://docs.camunda.io/docs/self-managed/operate-deployment/configuration/#logging
Originally posted by @Zelldon in #143 (comment)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.