From 50aec0ebd9f72cdd64d76287b3f4fd6457f1b0e7 Mon Sep 17 00:00:00 2001 From: Leo <153937047+leiicamundi@users.noreply.github.com> Date: Tue, 31 Mar 2026 18:35:53 +0200 Subject: [PATCH 1/4] fix(sm): use env script reference instead of hardcoded Helm version Replace hardcoded HELM_CHART_VERSION export with a reference snippet to 0-set-environment.sh in the operator-based infrastructure guide. --- .../helm/configure/operator-based-infrastructure.md | 11 +++++------ .../helm/configure/operator-based-infrastructure.md | 11 +++++------ 2 files changed, 10 insertions(+), 12 deletions(-) diff --git a/docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md b/docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md index 6c85b5c447a..a5d1b31f248 100644 --- a/docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md +++ b/docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md @@ -546,13 +546,14 @@ Before deploying Camunda Platform: ### Helm deployment -Deploy Camunda Platform using the infrastructure configuration files you saved from previous sections: +First, source the environment setup script to set `HELM_CHART_VERSION` and other required variables. See the [Helm chart version matrix](https://helm.camunda.io/camunda-platform/version-matrix/) to choose the appropriate chart version for your deployment: -```bash -# Set the desired Helm chart version - see https://helm.camunda.io/camunda-platform/version-matrix/ -export HELM_CHART_VERSION=13.0.0 # Replace with your desired version +```bash reference +https://github.com/camunda/camunda-deployment-references/blob/main/generic/kubernetes/operator-based/0-set-environment.sh ``` +Then, deploy Camunda Platform using the infrastructure configuration files you saved from previous sections. + For end-to-end configuration patterns (OIDC-enabled "Full Cluster" including Optimize, Web Modeler, Console, and Identity), see the Full Cluster section of our [Helm installation guide](/self-managed/deployment/helm/install/quick-install.md#full-cluster). @@ -567,7 +568,6 @@ helm install "$CAMUNDA_RELEASE_NAME" camunda/camunda-platform \ -f camunda-identity-values.yml \ -f camunda-webmodeler-values.yml \ -f camunda-keycloak-domain-values.yml \ - -f camunda-values-identity-secrets.yml \ -n "$CAMUNDA_NAMESPACE" ``` @@ -583,7 +583,6 @@ helm install "$CAMUNDA_RELEASE_NAME" camunda/camunda-platform \ -f camunda-identity-values.yml \ -f camunda-webmodeler-values.yml \ -f camunda-keycloak-no-domain-values.yml \ - -f camunda-values-identity-secrets.yml \ -n "$CAMUNDA_NAMESPACE" ``` diff --git a/versioned_docs/version-8.8/self-managed/deployment/helm/configure/operator-based-infrastructure.md b/versioned_docs/version-8.8/self-managed/deployment/helm/configure/operator-based-infrastructure.md index 00ef19d3819..b56f5f61246 100644 --- a/versioned_docs/version-8.8/self-managed/deployment/helm/configure/operator-based-infrastructure.md +++ b/versioned_docs/version-8.8/self-managed/deployment/helm/configure/operator-based-infrastructure.md @@ -557,13 +557,14 @@ Before deploying Camunda Platform: ### Helm deployment -Deploy Camunda Platform using the infrastructure configuration files you saved from previous sections: +First, source the environment setup script to set `HELM_CHART_VERSION` and other required variables. See the [Helm chart version matrix](https://helm.camunda.io/camunda-platform/version-matrix/) to choose the appropriate chart version for your deployment: -```bash -# Set the desired Helm chart version - see https://helm.camunda.io/camunda-platform/version-matrix/ -export HELM_CHART_VERSION=13.0.0 # Replace with your desired version +```bash reference +https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/operator-based/0-set-environment.sh ``` +Then, deploy Camunda Platform using the infrastructure configuration files you saved from previous sections. + For end-to-end configuration patterns (OIDC-enabled "Full Cluster" including Optimize, Web Modeler, Console, and Identity), see the Full Cluster section of our [Helm installation guide](/self-managed/deployment/helm/install/quick-install.md#full-cluster). @@ -578,7 +579,6 @@ helm install "$CAMUNDA_RELEASE_NAME" camunda/camunda-platform \ -f camunda-identity-values.yml \ -f camunda-webmodeler-values.yml \ -f camunda-keycloak-domain-values.yml \ - -f camunda-values-identity-secrets.yml \ -n "$CAMUNDA_NAMESPACE" ``` @@ -594,7 +594,6 @@ helm install "$CAMUNDA_RELEASE_NAME" camunda/camunda-platform \ -f camunda-identity-values.yml \ -f camunda-webmodeler-values.yml \ -f camunda-keycloak-no-domain-values.yml \ - -f camunda-values-identity-secrets.yml \ -n "$CAMUNDA_NAMESPACE" ``` From a973296e7ea6bc76c2bb9bf9f5fb5a0dbf540bdb Mon Sep 17 00:00:00 2001 From: Leo <153937047+leiicamundi@users.noreply.github.com> Date: Tue, 31 Mar 2026 20:28:50 +0200 Subject: [PATCH 2/4] fix broken link --- .../helm/configure/operator-based-infrastructure.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/versioned_docs/version-8.8/self-managed/deployment/helm/configure/operator-based-infrastructure.md b/versioned_docs/version-8.8/self-managed/deployment/helm/configure/operator-based-infrastructure.md index b56f5f61246..f7b247ef528 100644 --- a/versioned_docs/version-8.8/self-managed/deployment/helm/configure/operator-based-infrastructure.md +++ b/versioned_docs/version-8.8/self-managed/deployment/helm/configure/operator-based-infrastructure.md @@ -85,7 +85,7 @@ All configuration files, deployment scripts, and automation tools referenced in Quick deployment commands ```bash reference -https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/camunda-deployment-references/generic/kubernetes/operator-based/get-your-copy.sh +https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/operator-based/get-your-copy.sh ``` Then execute: @@ -557,14 +557,12 @@ Before deploying Camunda Platform: ### Helm deployment -First, source the environment setup script to set `HELM_CHART_VERSION` and other required variables. See the [Helm chart version matrix](https://helm.camunda.io/camunda-platform/version-matrix/) to choose the appropriate chart version for your deployment: +Deploy Camunda Platform using the infrastructure configuration files you saved from previous sections: ```bash reference https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/operator-based/0-set-environment.sh ``` -Then, deploy Camunda Platform using the infrastructure configuration files you saved from previous sections. - For end-to-end configuration patterns (OIDC-enabled "Full Cluster" including Optimize, Web Modeler, Console, and Identity), see the Full Cluster section of our [Helm installation guide](/self-managed/deployment/helm/install/quick-install.md#full-cluster). From 89b9b4429ac91ae0cf0d6eb358e15332649243fd Mon Sep 17 00:00:00 2001 From: Leo <153937047+leiicamundi@users.noreply.github.com> Date: Wed, 1 Apr 2026 08:59:25 +0200 Subject: [PATCH 3/4] Update docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md Co-authored-by: Christina Ausley <84338309+christinaausley@users.noreply.github.com> --- .../deployment/helm/configure/operator-based-infrastructure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md b/docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md index a5d1b31f248..104e0045028 100644 --- a/docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md +++ b/docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md @@ -552,7 +552,7 @@ First, source the environment setup script to set `HELM_CHART_VERSION` and other https://github.com/camunda/camunda-deployment-references/blob/main/generic/kubernetes/operator-based/0-set-environment.sh ``` -Then, deploy Camunda Platform using the infrastructure configuration files you saved from previous sections. +Then, deploy Camunda using the infrastructure configuration files you saved from previous sections. For end-to-end configuration patterns (OIDC-enabled "Full Cluster" including Optimize, Web Modeler, Console, and Identity), see the Full Cluster section of our [Helm installation guide](/self-managed/deployment/helm/install/quick-install.md#full-cluster). From 194716d0984e4d1fbc204ef38240978b2bb9fabf Mon Sep 17 00:00:00 2001 From: Leo <153937047+leiicamundi@users.noreply.github.com> Date: Wed, 1 Apr 2026 11:38:11 +0200 Subject: [PATCH 4/4] fix: rename Camunda Platform to Camunda --- .../secondary-storage/no-secondary-storage.md | 2 +- .../cloud-providers/amazon/amazon-eks/eks-helm.md | 6 +++--- .../cloud-providers/amazon/amazon-eks/eksctl.md | 4 ++-- .../amazon/amazon-eks/terraform-setup.md | 4 ++-- .../azure/microsoft-aks/aks-helm.md | 6 +++--- .../helm/cloud-providers/openshift/dual-region.md | 2 +- .../cloud-providers/openshift/redhat-openshift.md | 6 +++--- .../configure/operator-based-infrastructure.md | 12 ++++++------ .../deployment/helm/install/production/index.md | 2 +- .../manual/cloud-providers/amazon/aws-ec2.md | 2 +- .../setup/deploy/amazon/amazon-eks/eks-helm.md | 6 +++--- .../setup/deploy/amazon/amazon-eks/eksctl.md | 4 ++-- .../deploy/amazon/amazon-eks/terraform-setup.md | 6 +++--- .../setup/deploy/openshift/redhat-openshift.md | 6 +++--- .../helm-chart-production-guide.md | 2 +- .../setup/deploy/amazon/amazon-eks/eks-helm.md | 6 +++--- .../setup/deploy/amazon/amazon-eks/eksctl.md | 4 ++-- .../deploy/amazon/amazon-eks/terraform-setup.md | 6 +++--- .../setup/deploy/azure/microsoft-aks/aks-helm.md | 6 +++--- .../setup/deploy/openshift/dual-region.md | 2 +- .../setup/deploy/openshift/redhat-openshift.md | 14 +++++++------- .../self-managed/concepts/no-secondary-storage.md | 2 +- .../cloud-providers/amazon/amazon-eks/eks-helm.md | 6 +++--- .../cloud-providers/amazon/amazon-eks/eksctl.md | 4 ++-- .../amazon/amazon-eks/terraform-setup.md | 4 ++-- .../azure/microsoft-aks/aks-helm.md | 4 ++-- .../helm/cloud-providers/openshift/dual-region.md | 2 +- .../cloud-providers/openshift/redhat-openshift.md | 6 +++--- .../configure/operator-based-infrastructure.md | 14 +++++++------- .../deployment/helm/install/production/index.md | 2 +- .../manual/cloud-providers/amazon/aws-ec2.md | 2 +- 31 files changed, 77 insertions(+), 77 deletions(-) diff --git a/docs/self-managed/concepts/secondary-storage/no-secondary-storage.md b/docs/self-managed/concepts/secondary-storage/no-secondary-storage.md index d839d722733..05ecaade514 100644 --- a/docs/self-managed/concepts/secondary-storage/no-secondary-storage.md +++ b/docs/self-managed/concepts/secondary-storage/no-secondary-storage.md @@ -23,7 +23,7 @@ You should **only** disable/run without secondary storage in limited scenarios, - For Helm deployments, Optimize is also disabled by default when secondary storage is not configured. - For Docker or manual deployments, you must **explicitly disable Optimize** in your configuration, as it cannot function without secondary storage. -This setup provides core process execution and orchestration capabilities through Zeebe, but excludes the full Camunda platform experience, such as analytics, search, and human-task management. +This setup provides core process execution and orchestration capabilities through Zeebe, but excludes the full Camunda experience, such as analytics, search, and human-task management. ## Enable **no secondary storage** mode diff --git a/docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eks-helm.md b/docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eks-helm.md index 4125f5ee35b..b121981ac8b 100644 --- a/docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eks-helm.md +++ b/docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eks-helm.md @@ -30,7 +30,7 @@ Lastly you'll verify that the connection to your Self-Managed Camunda 8 environm - [jq](https://jqlang.github.io/jq/download/) to interact with some variables. - [GNU envsubst](https://www.man7.org/linux/man-pages/man1/envsubst.1.html) to generate manifests. - (optional) Domain name/[hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) in Route53. This allows you to expose Camunda 8 and connect via community-supported [zbctl](https://github.com/camunda-community-hub/zeebe-client-go/blob/main/cmd/zbctl/zbctl.md) or [Camunda Modeler](https://camunda.com/download/modeler/). -- A namespace to host the Camunda Platform. +- A namespace to host Camunda. For the tool versions used, check the [.tool-versions](https://github.com/camunda/camunda-deployment-references/blob/main/.tool-versions) file in the repository. It contains an up-to-date list of versions that we also use for testing. @@ -118,7 +118,7 @@ https://github.com/camunda/camunda-deployment-references/blob/main/aws/kubernete If you do not have a domain name, external access to Camunda 8 web endpoints from outside the AWS VPC will not be possible. In this case, you may skip the DNS setup and proceed directly to [deploying Camunda 8 via Helm charts](#deploy-camunda-8-via-helm-charts). -Alternatively, you can use `kubectl port-forward` to access the Camunda platform without a domain or Ingress configuration. For more information, see the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). +Alternatively, you can use `kubectl port-forward` to access Camunda without a domain or Ingress configuration. For more information, see the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). Throughout the rest of this installation guide, we will refer to configurations as **"With domain"** or **"Without domain"** depending on whether the application is exposed via a domain. ::: @@ -408,7 +408,7 @@ https://github.com/camunda/camunda-deployment-references/blob/main/generic/kuber This command: -- Installs (or upgrades) the Camunda platform using the Helm chart. +- Installs (or upgrades) Camunda using the Helm chart. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from `generated-values.yml`. diff --git a/docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eksctl.md b/docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eksctl.md index bdc2d226fc3..ebdefb50219 100644 --- a/docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eksctl.md +++ b/docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eksctl.md @@ -48,7 +48,7 @@ This guide results in the following: - An Amazon EKS Kubernetes cluster running the latest Kubernetes version with four nodes ready for Camunda 8 installation. - Installed and configured [EBS CSI driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html), which is used by the Camunda 8 Helm chart to create [persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). - A [managed Aurora PostgreSQL 17.x](https://aws.amazon.com/rds/aurora/) instance that will be used by the Camunda 8 components. -- A [managed OpenSearch domain](https://aws.amazon.com/opensearch-service/) created and configured as a secondary storage option for the Camunda platform. +- A [managed OpenSearch domain](https://aws.amazon.com/opensearch-service/) created and configured as a secondary storage option for Camunda. Note: This guide’s example provisions a managed OpenSearch domain. Depending on the components you run and your requirements, you can instead configure an RDBMS-based secondary storage backend for supported components. See [configure RDBMS in Helm](/self-managed/deployment/helm/configure/database/rdbms.md) for details. - [IAM Roles for Service Accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) (IRSA) configured and [Pod Identities](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html). - This simplifies the setup by not relying on explicit credentials, but instead allows creating a mapping between IAM roles and Kubernetes service accounts based on a trust relationship. A [blog post](https://aws.amazon.com/blogs/containers/diving-into-iam-roles-for-service-accounts/) by AWS visualizes this on a technical level. @@ -845,7 +845,7 @@ We will also use this step to verify connectivity to the database from the creat Creating an OpenSearch domain can be accomplished through various methods, such as using the AWS Management Console or the AWS CLI. This guide focuses on providing a reproducible setup using the CLI. For information on creating an OpenSearch domain using the UI, refer to the [AWS OpenSearch documentation](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/create-managed-domain.html). -The resulting OpenSearch domain is intended for use with the Camunda platform, the following components utilize OpenSearch: +The resulting OpenSearch domain is intended for use with Camunda, the following components utilize OpenSearch: - Orchestration Cluster (Zeebe, Operate, Tasklist, Identity) - Optimize diff --git a/docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/terraform-setup.md b/docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/terraform-setup.md index 606e525d832..c67f7639732 100644 --- a/docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/terraform-setup.md +++ b/docs/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/terraform-setup.md @@ -114,7 +114,7 @@ After completing this guide, you will have: - An Amazon EKS Kubernetes cluster running with four nodes ready for Camunda 8 installation. - The [EBS CSI driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html), installed and configured. This is used by the Camunda 8 Helm chart to create [persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). - (Optional) A managed [Aurora PostgreSQL](https://aws.amazon.com/rds/postgresql/) instance for Camunda. -- (Optional) A managed [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) domain created and configured for use with the Camunda platform. +- (Optional) A managed [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) domain created and configured for use with Camunda. - (Optional) [IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) configured so Kubernetes workloads can assume IAM roles without stored credentials. ## 1. Configure AWS and initialize Terraform @@ -344,7 +344,7 @@ If you choose not to use this module, you'll need to either provide a managed El Additionally, you must delete the `opensearch.tf` file within the `terraform/cluster` directory of your chosen reference as it will otherwise create the resources. ::: -The OpenSearch module creates an OpenSearch domain intended for Camunda platform. OpenSearch is a powerful alternative to Elasticsearch. For more information on using OpenSearch with Camunda, refer to the [Camunda documentation](/self-managed/deployment/helm/configure/database/using-external-opensearch.md). +The OpenSearch module creates an OpenSearch domain intended for Camunda. OpenSearch is a powerful alternative to Elasticsearch. For more information on using OpenSearch with Camunda, refer to the [Camunda documentation](/self-managed/deployment/helm/configure/database/using-external-opensearch.md). The secondary storage database (OpenSearch or Elasticsearch in this setup) is required to support the Orchestration Cluster components described in the [reference architecture](/self-managed/reference-architecture/reference-architecture.md): Zeebe (workflow data), Operate (monitoring), Tasklist (human tasks), Optimize (analytics), and Identity (user management, sessions, OIDC mappings). diff --git a/docs/self-managed/deployment/helm/cloud-providers/azure/microsoft-aks/aks-helm.md b/docs/self-managed/deployment/helm/cloud-providers/azure/microsoft-aks/aks-helm.md index 9f595f915ce..b78fab250c0 100644 --- a/docs/self-managed/deployment/helm/cloud-providers/azure/microsoft-aks/aks-helm.md +++ b/docs/self-managed/deployment/helm/cloud-providers/azure/microsoft-aks/aks-helm.md @@ -26,7 +26,7 @@ This guide provides a comprehensive walkthrough for installing the Camunda 8 Hel - [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) to interact with the cluster. - [jq](https://jqlang.github.io/jq/download/) to interact with some variables. - [GNU envsubst](https://www.man7.org/linux/man-pages/man1/envsubst.1.html) to generate manifests. -- A namespace to host the Camunda Platform; in this guide we will reference `camunda` as the target namespace. +- A namespace to host Camunda; in this guide we will reference `camunda` as the target namespace. - (optional) Custom domain name/[DNS zone](https://learn.microsoft.com/en-us/azure/dns/dns-zones-records) in Azure DNS. This allows you to expose Camunda 8 endpoints and connect via community-supported [zbctl](https://github.com/camunda-community-hub/zeebe-client-go/blob/main/cmd/zbctl/zbctl.md) or [Camunda Modeler](https://camunda.com/download/modeler/). - (optional) Permissions to install Kubernetes operators (cluster-admin or equivalent) to deploy infrastructure services such as Elasticsearch, PostgreSQL, and Keycloak. This guide installs them directly from source to provide full control over versions and configuration. For the tool versions used, check the [.tool-versions](https://github.com/camunda/camunda-deployment-references/blob/main/.tool-versions) file in the related repository. This contains an up-to-date list of versions we also use for testing. @@ -84,7 +84,7 @@ https://github.com/camunda/camunda-deployment-references/blob/main/azure/kuberne If you do not have a domain name, external access to Camunda 8 web endpoints from outside the Azure Virtual Network will not be possible. In this case, skip the DNS setup and proceed directly to [deploying Camunda 8 via Helm charts](#deploy-camunda-8-via-helm-charts). -Alternatively, you can use `kubectl port-forward` to access the Camunda platform without a domain or Ingress configuration. For more information, see the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). +Alternatively, you can use `kubectl port-forward` to access Camunda without a domain or Ingress configuration. For more information, see the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). Throughout the rest of this installation guide, we will refer to configurations as **"With domain"** or **"Without domain"** depending on whether the application is exposed via a domain. ::: @@ -314,7 +314,7 @@ https://github.com/camunda/camunda-deployment-references/blob/main/generic/kuber This script: -- Installs (or upgrades) the Camunda platform using the Helm chart. +- Installs (or upgrades) Camunda using the Helm chart. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from `generated-values.yml`. diff --git a/docs/self-managed/deployment/helm/cloud-providers/openshift/dual-region.md b/docs/self-managed/deployment/helm/cloud-providers/openshift/dual-region.md index c6b91aae958..4f3ffd276dd 100644 --- a/docs/self-managed/deployment/helm/cloud-providers/openshift/dual-region.md +++ b/docs/self-managed/deployment/helm/cloud-providers/openshift/dual-region.md @@ -566,7 +566,7 @@ https://github.com/camunda/camunda-deployment-references/blob/main/generic/opens This command: -- Installs (or upgrades) the Camunda platform using the Helm chart on each cluster. +- Installs (or upgrades) Camunda using the Helm chart on each cluster. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from the value file. diff --git a/docs/self-managed/deployment/helm/cloud-providers/openshift/redhat-openshift.md b/docs/self-managed/deployment/helm/cloud-providers/openshift/redhat-openshift.md index 3b2ec027de1..88ce8e26301 100644 --- a/docs/self-managed/deployment/helm/cloud-providers/openshift/redhat-openshift.md +++ b/docs/self-managed/deployment/helm/cloud-providers/openshift/redhat-openshift.md @@ -34,7 +34,7 @@ Additional information and a high-level overview of Kubernetes as the upstream p - [jq](https://jqlang.github.io/jq/download/) to interact with some variables. - [GNU envsubst](https://www.man7.org/linux/man-pages/man1/envsubst.1.html) to generate manifests. - [oc (version supported by your OpenShift)](https://docs.openshift.com/container-platform/4.17/cli_reference/openshift_cli/getting-started-cli.html) to interact with OpenShift. -- A namespace to host the Camunda Platform. +- A namespace to host Camunda. - Permissions to install Kubernetes operators (cluster-admin or equivalent) for deploying the infrastructure services (Elasticsearch, PostgreSQL, Keycloak). These operators can also be installed via the [OpenShift OperatorHub](https://docs.openshift.com/container-platform/latest/operators/understanding/olm-understanding-operatorhub.html), but this guide installs them directly from source for full control over versions and configuration. For the tool versions used, check the [.tool-versions](https://github.com/camunda/camunda-deployment-references/blob/main/.tool-versions) file in the repository. It contains an up-to-date list of versions that we also use for testing. @@ -297,7 +297,7 @@ If you should decide to use the Red Hat endorsed [NGINX Ingress Controller](http If you do not have a domain name or do not intend to use one for your Camunda 8 deployment, external access to Camunda 8 web endpoints from outside the OpenShift cluster will not be possible. -However, you can use `kubectl port-forward` to access the Camunda platform without a domain name or Ingress configuration. For more information, refer to the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). +However, you can use `kubectl port-forward` to access Camunda without a domain name or Ingress configuration. For more information, refer to the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Merge the no-domain overlay into your `values.yml` file: @@ -659,7 +659,7 @@ https://github.com/camunda/camunda-deployment-references/blob/main/generic/opens This command: -- Installs (or upgrades) the Camunda platform using the Helm chart. +- Installs (or upgrades) Camunda using the Helm chart. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from `generated-values.yml`. diff --git a/docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md b/docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md index 104e0045028..1e3f5cbcd26 100644 --- a/docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md +++ b/docs/self-managed/deployment/helm/configure/operator-based-infrastructure.md @@ -55,7 +55,7 @@ Before proceeding with this guide, ensure you have: - **Cluster admin privileges**: Required to install Custom Resource Definitions (CRDs) and operators - **Command-line tools**: - `kubectl` configured to access your cluster - - `helm` CLI for deploying Camunda Platform + - `helm` CLI for deploying Camunda using the Helm chart - `openssl` for generating random passwords - `envsubst` command (part of `gettext` package) for environment variable substitution @@ -139,7 +139,7 @@ Each infrastructure component should be deployed individually in the following o | 1 | **[PostgreSQL](#postgresql-deployment)** | None | Database clusters for Keycloak, Management Identity, and Web Modeler | | 2 | **[Elasticsearch](#elasticsearch-deployment)** | None | Secondary storage for orchestration cluster components | | 3 | **[Keycloak](#keycloak-deployment)** | PostgreSQL | Authentication and identity management | -| 4 | **[Camunda Platform](#camunda-deployment)** | All above | Deploy using Helm with operator-managed infrastructure | +| 4 | **[Camunda](#camunda-deployment)** | All above | Deploy using Helm with operator-managed infrastructure | :::tip Automation with GitOps While this guide demonstrates manual deployment using command-line tools, these same configurations can be automated using GitOps solutions like ArgoCD, Flux, or other Kubernetes deployment pipelines. All configuration files referenced in this guide are designed to work seamlessly with declarative deployment approaches. @@ -514,7 +514,7 @@ With all infrastructure components deployed and configured, you can now deploy C ### Configuration files summary -Before deploying Camunda Platform, ensure you have saved all required configuration files locally. The files are organized by deployment phase: +Before deploying Camunda, ensure you have saved all required configuration files locally. The files are organized by deployment phase: #### Infrastructure deployment files (Custom Resources) @@ -538,7 +538,7 @@ Before deploying Camunda Platform, ensure you have saved all required configurat ### Pre-deployment checklist -Before deploying Camunda Platform: +Before deploying Camunda, ensure you have completed the following: - [ ] All infrastructure components deployed (PostgreSQL, Elasticsearch, Keycloak) - [ ] Configuration files saved locally from previous sections @@ -559,7 +559,7 @@ For end-to-end configuration patterns (OIDC-enabled "Full Cluster" including Opt -Deploy Camunda Platform with external domain configuration: +Deploy Camunda with external domain configuration: ```bash helm install "$CAMUNDA_RELEASE_NAME" camunda/camunda-platform \ @@ -574,7 +574,7 @@ helm install "$CAMUNDA_RELEASE_NAME" camunda/camunda-platform \ -Deploy Camunda Platform for local development: +Deploy Camunda for local development: ```bash helm install "$CAMUNDA_RELEASE_NAME" camunda/camunda-platform \ diff --git a/docs/self-managed/deployment/helm/install/production/index.md b/docs/self-managed/deployment/helm/install/production/index.md index 1013da52513..dad5019d51f 100644 --- a/docs/self-managed/deployment/helm/install/production/index.md +++ b/docs/self-managed/deployment/helm/install/production/index.md @@ -92,7 +92,7 @@ helm install camunda camunda/camunda-platform --version $HELM_CHART_VERSION -n o ### Ingress TLS setup -In order to access the Camunda Platform through HTTPS with Ingress, TLS must be enabled. Enabling TLS requires the following: +In order to access Camunda through HTTPS with Ingress, TLS must be enabled. Enabling TLS requires the following: 1. **Domain name**: A public registered domain that has configurable DNS records. This guide will use `camunda.example.com` as the domain. 2. **TLS certificate**: A TLS certificate created for your domain. The certificate must be an X.509 certificate, issued by a trusted Certificate Authority. The certificate must include the correct domain names (Common Name or Subject Alternative Names) to secure Ingress resources. Reach out to your DNS provider if you are unsure on how to create a TLS certificate. It is not recommended to use self-signed certificates. diff --git a/docs/self-managed/deployment/manual/cloud-providers/amazon/aws-ec2.md b/docs/self-managed/deployment/manual/cloud-providers/amazon/aws-ec2.md index 397bb514493..98fce33e508 100644 --- a/docs/self-managed/deployment/manual/cloud-providers/amazon/aws-ec2.md +++ b/docs/self-managed/deployment/manual/cloud-providers/amazon/aws-ec2.md @@ -233,7 +233,7 @@ If you choose not to use this module, you must provide your own Elasticsearch or Additionally, be sure to delete the `opensearch.tf` file in your reference copy—otherwise, the resources defined in it will still be created. ::: -The OpenSearch module provisions an OpenSearch domain for use with the Camunda platform. OpenSearch is a powerful alternative to Elasticsearch. +The OpenSearch module provisions an OpenSearch domain for use with Camunda. OpenSearch is a powerful alternative to Elasticsearch. :::note Migration to OpenSearch is not supported diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md index 5826eeaf4a0..c229e482435 100644 --- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md +++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md @@ -21,7 +21,7 @@ Lastly you'll verify that the connection to your Self-Managed Camunda 8 environm - [jq (1.7+)](https://jqlang.github.io/jq/download/) to interact with some variables. - [GNU envsubst](https://www.man7.org/linux/man-pages/man1/envsubst.1.html) to generate manifests. - (optional) Domain name/[hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) in Route53. This allows you to expose Camunda 8 and connect via community-supported [zbctl](https://github.com/camunda-community-hub/zeebe-client-go/blob/main/cmd/zbctl/zbctl.md) or [Camunda Modeler](https://camunda.com/download/modeler/). -- A namespace to host the Camunda Platform, in this guide we will reference `camunda` as the target namespace. +- A namespace to host Camunda, in this guide we will reference `camunda` as the target namespace. ### Considerations @@ -92,7 +92,7 @@ https://github.com/camunda/camunda-tf-eks-module/blob/main/examples/camunda-8.6- If you do not have a domain name, external access to Camunda 8 web endpoints from outside the AWS VPC will not be possible. In this case, you may skip the DNS setup and proceed directly to [deploying Camunda 8 via Helm charts](#deploy-camunda-8-via-helm-charts). -Alternatively, you can use `kubectl port-forward` to access the Camunda platform without a domain or Ingress configuration. For more information, see the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). +Alternatively, you can use `kubectl port-forward` to access Camunda without a domain or Ingress configuration. For more information, see the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). Throughout the rest of this installation guide, we will refer to configurations as **"With domain"** or **"Without domain"** depending on whether the application is exposed via a domain. ::: @@ -438,7 +438,7 @@ https://github.com/camunda/camunda-tf-eks-module/blob/main/examples/camunda-8.6/ This command: -- Installs (or upgrades) the Camunda platform using the Helm chart. +- Installs (or upgrades) Camunda using the Helm chart. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from `generated-values.yml`. diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md index b0d08a4ee6c..c51f7669522 100644 --- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md +++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md @@ -50,7 +50,7 @@ This guide results in the following: - An Amazon EKS Kubernetes cluster running the latest Kubernetes version with four nodes ready for Camunda 8 installation. - Installed and configured [EBS CSI driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html), which is used by the Camunda 8 Helm chart to create [persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). - A [managed Aurora PostgreSQL 15.x](https://aws.amazon.com/rds/aurora/) instance that will be used by the Camunda 8 components. -- A [managed OpenSearch domain](https://aws.amazon.com/opensearch-service/) created and configured for use with the Camunda platform.. +- A [managed OpenSearch domain](https://aws.amazon.com/opensearch-service/) created and configured for use with Camunda. - [IAM Roles for Service Accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) (IRSA) configured and [Pod Identities](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html). - This simplifies the setup by not relying on explicit credentials, but instead allows creating a mapping between IAM roles and Kubernetes service accounts based on a trust relationship. A [blog post](https://aws.amazon.com/blogs/containers/diving-into-iam-roles-for-service-accounts/) by AWS visualizes this on a technical level. - This allows a Kubernetes service account to temporarily impersonate an AWS IAM role to interact with AWS services like S3, RDS, or Route53 without supplying explicit credentials. @@ -839,7 +839,7 @@ We will also use this step to verify connectivity to the database from the creat Creating an OpenSearch domain can be accomplished through various methods, such as using the AWS Management Console or the AWS CLI. This guide focuses on providing a reproducible setup using the CLI. For information on creating an OpenSearch domain using the UI, refer to the [AWS OpenSearch documentation](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/create-managed-domain.html). -The resulting OpenSearch domain is intended for use with the Camunda platform, the following components utilize OpenSearch: +The resulting OpenSearch domain is intended for use with Camunda, the following components utilize OpenSearch: - Operate - Optimize diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/terraform-setup.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/terraform-setup.md index 40f581ab01c..00651bd1939 100644 --- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/terraform-setup.md +++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/terraform-setup.md @@ -98,8 +98,8 @@ Following this tutorial and steps will result in: - An Amazon EKS Kubernetes cluster running the latest Kubernetes version with four nodes ready for Camunda 8 installation. - The [EBS CSI driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) is installed and configured, which is used by the Camunda 8 Helm chart to create [persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). -- A [managed Aurora PostgreSQL 15.x](https://aws.amazon.com/rds/postgresql/) instance to be used by the Camunda platform. -- A [managed OpenSearch domain](https://aws.amazon.com/opensearch-service/) created and configured for use with the Camunda platform. +- A [managed Aurora PostgreSQL 15.x](https://aws.amazon.com/rds/postgresql/) instance to be used by Camunda. +- A [managed OpenSearch domain](https://aws.amazon.com/opensearch-service/) created and configured for use with Camunda. - (optional) [IAM Roles for Service Accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) (IRSA) configured. - This simplifies the setup by not relying on explicit credentials, but instead allows creating a mapping between IAM roles and Kubernetes service accounts based on a trust relationship. A [blog post](https://aws.amazon.com/blogs/containers/diving-into-iam-roles-for-service-accounts/) by AWS visualizes this on a technical level. - This allows a Kubernetes service account to temporarily impersonate an AWS IAM role to interact with AWS services like S3, RDS, or Route53 without supplying explicit credentials. @@ -374,7 +374,7 @@ If you don't want to use this module, you can skip this section. However, you ma If you choose not to use this module, you'll need to either provide a managed Elasticsearch or OpenSearch service or use the internal deployment by the Camunda Helm chart in Kubernetes. ::: -The OpenSearch module creates an OpenSearch domain intended for Camunda platform. OpenSearch is a powerful alternative to Elasticsearch. For more information on using OpenSearch with Camunda, refer to the [Camunda documentation](/self-managed/setup/guides/using-existing-opensearch.md). +The OpenSearch module creates an OpenSearch domain intended for Camunda. OpenSearch is a powerful alternative to Elasticsearch. For more information on using OpenSearch with Camunda, refer to the [Camunda documentation](/self-managed/setup/guides/using-existing-opensearch.md). :::note Migration to OpenSearch is not supported diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md index ce15649ce85..47ad408d80d 100644 --- a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md +++ b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md @@ -50,7 +50,7 @@ Camunda 8 supports OpenShift versions in the Red Hat General Availability, Full - [jq (1.7+)](https://jqlang.github.io/jq/download/) to interact with some variables. - [GNU envsubst](https://www.man7.org/linux/man-pages/man1/envsubst.1.html) to generate manifests. - [oc (version supported by your OpenShift)](https://docs.openshift.com/container-platform/4.17/cli_reference/openshift_cli/getting-started-cli.html) to interact with OpenShift. -- A namespace to host the Camunda Platform, in this guide we will reference `camunda` as the target namespace. +- A namespace to host Camunda, in this guide we will reference `camunda` as the target namespace. ## Deploy Camunda 8 via Helm charts @@ -234,7 +234,7 @@ If you should decide to use the Red Hat endorsed [NGINX Ingress Controller](http If you do not have a domain name or do not intend to use one for your Camunda 8 deployment, external access to Camunda 8 web endpoints from outside the OpenShift cluster will not be possible. -However, you can use `kubectl port-forward` to access the Camunda platform without a domain name or Ingress configuration. For more information, refer to the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). +However, you can use `kubectl port-forward` to access Camunda without a domain name or Ingress configuration. For more information, refer to the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following: @@ -318,7 +318,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic This command: -- Installs (or upgrades) the Camunda platform using the Helm chart. +- Installs (or upgrades) Camunda using the Helm chart. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from `generated-values.yml`. diff --git a/versioned_docs/version-8.7/self-managed/operational-guides/production-guide/helm-chart-production-guide.md b/versioned_docs/version-8.7/self-managed/operational-guides/production-guide/helm-chart-production-guide.md index 620f5440b94..fe1b0dff964 100644 --- a/versioned_docs/version-8.7/self-managed/operational-guides/production-guide/helm-chart-production-guide.md +++ b/versioned_docs/version-8.7/self-managed/operational-guides/production-guide/helm-chart-production-guide.md @@ -80,7 +80,7 @@ helm install camunda camunda/camunda-platform --version $HELM_CHART_VERSION -n o ### Ingress TLS setup -In order to access the Camunda Platform through HTTPS with Ingress, TLS must be enabled. Enabling TLS requires the following: +In order to access Camunda through HTTPS with Ingress, TLS must be enabled. Enabling TLS requires the following: 1. **Domain name**: A public registered domain that has configurable DNS records. This guide will use `camunda.example.com` as the domain. 2. **TLS certificate**: A TLS certificate created for your domain. The certificate must be an X.509 certificate, issued by a trusted Certificate Authority. The certificate must include the correct domain names (Common Name or Subject Alternative Names) to secure Ingress resources. Reach out to your DNS provider if you are unsure on how to create a TLS certificate. It is not recommended to use self-signed certificates. diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md index ed04ba03024..ab31e836031 100644 --- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md +++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md @@ -21,7 +21,7 @@ Lastly you'll verify that the connection to your Self-Managed Camunda 8 environm - [jq](https://jqlang.github.io/jq/download/) to interact with some variables. - [GNU envsubst](https://www.man7.org/linux/man-pages/man1/envsubst.1.html) to generate manifests. - (optional) Domain name/[hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) in Route53. This allows you to expose Camunda 8 and connect via community-supported [zbctl](https://github.com/camunda-community-hub/zeebe-client-go/blob/main/cmd/zbctl/zbctl.md) or [Camunda Modeler](https://camunda.com/download/modeler/). -- A namespace to host the Camunda Platform, in this guide we will reference `camunda` as the target namespace. +- A namespace to host Camunda, in this guide we will reference `camunda` as the target namespace. For the tool versions used, check the [.tool-versions](https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/.tool-versions) file in the repository. It contains an up-to-date list of versions that we also use for testing. @@ -102,7 +102,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/kub If you do not have a domain name, external access to Camunda 8 web endpoints from outside the AWS VPC will not be possible. In this case, you may skip the DNS setup and proceed directly to [deploying Camunda 8 via Helm charts](#deploy-camunda-8-via-helm-charts). -Alternatively, you can use `kubectl port-forward` to access the Camunda platform without a domain or Ingress configuration. For more information, see the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). +Alternatively, you can use `kubectl port-forward` to access Camunda without a domain or Ingress configuration. For more information, see the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). Throughout the rest of this installation guide, we will refer to configurations as **"With domain"** or **"Without domain"** depending on whether the application is exposed via a domain. ::: @@ -394,7 +394,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic This command: -- Installs (or upgrades) the Camunda platform using the Helm chart. +- Installs (or upgrades) Camunda using the Helm chart. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from `generated-values.yml`. diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md index 8acc965c7ce..3f3c06115d9 100644 --- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md +++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md @@ -46,7 +46,7 @@ This guide results in the following: - An Amazon EKS Kubernetes cluster running the latest Kubernetes version with four nodes ready for Camunda 8 installation. - Installed and configured [EBS CSI driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html), which is used by the Camunda 8 Helm chart to create [persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). - A [managed Aurora PostgreSQL 15.x](https://aws.amazon.com/rds/aurora/) instance that will be used by the Camunda 8 components. -- A [managed OpenSearch domain](https://aws.amazon.com/opensearch-service/) created and configured for use with the Camunda platform.. +- A [managed OpenSearch domain](https://aws.amazon.com/opensearch-service/) created and configured for use with the Camunda. - [IAM Roles for Service Accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) (IRSA) configured and [Pod Identities](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html). - This simplifies the setup by not relying on explicit credentials, but instead allows creating a mapping between IAM roles and Kubernetes service accounts based on a trust relationship. A [blog post](https://aws.amazon.com/blogs/containers/diving-into-iam-roles-for-service-accounts/) by AWS visualizes this on a technical level. - This allows a Kubernetes service account to temporarily impersonate an AWS IAM role to interact with AWS services like S3, RDS, or Route53 without supplying explicit credentials. @@ -840,7 +840,7 @@ We will also use this step to verify connectivity to the database from the creat Creating an OpenSearch domain can be accomplished through various methods, such as using the AWS Management Console or the AWS CLI. This guide focuses on providing a reproducible setup using the CLI. For information on creating an OpenSearch domain using the UI, refer to the [AWS OpenSearch documentation](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/create-managed-domain.html). -The resulting OpenSearch domain is intended for use with the Camunda platform, the following components utilize OpenSearch: +The resulting OpenSearch domain is intended for use with the Camunda, the following components utilize OpenSearch: - Operate - Optimize diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/terraform-setup.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/terraform-setup.md index c6a350cd0a0..3a443eeefaf 100644 --- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/terraform-setup.md +++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/terraform-setup.md @@ -101,8 +101,8 @@ Following this tutorial and steps will result in: - An Amazon EKS Kubernetes cluster running with four nodes ready for Camunda 8 installation. - The [EBS CSI driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) is installed and configured, which is used by the Camunda 8 Helm chart to create [persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). -- A [managed Aurora PostgreSQL 15.x](https://aws.amazon.com/rds/postgresql/) instance to be used by the Camunda platform. -- A [managed OpenSearch domain](https://aws.amazon.com/opensearch-service/) created and configured for use with the Camunda platform. +- A [managed Aurora PostgreSQL 15.x](https://aws.amazon.com/rds/postgresql/) instance to be used by Camunda. +- A [managed OpenSearch domain](https://aws.amazon.com/opensearch-service/) created and configured for use with Camunda. - (optional) [IAM Roles for Service Accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) (IRSA) configured. - This simplifies the setup by not relying on explicit credentials, but instead allows creating a mapping between IAM roles and Kubernetes service accounts based on a trust relationship. A [blog post](https://aws.amazon.com/blogs/containers/diving-into-iam-roles-for-service-accounts/) by AWS visualizes this on a technical level. - This allows a Kubernetes service account to temporarily impersonate an AWS IAM role to interact with AWS services like S3, RDS, or Route53 without supplying explicit credentials. @@ -358,7 +358,7 @@ If you choose not to use this module, you'll need to either provide a managed El Additionally, you must delete the `opensearch.tf` file within your chosen reference as it will otherwise create the resources. ::: -The OpenSearch module creates an OpenSearch domain intended for Camunda platform. OpenSearch is a powerful alternative to Elasticsearch. For more information on using OpenSearch with Camunda, refer to the [Camunda documentation](/self-managed/setup/guides/using-existing-opensearch.md). +The OpenSearch module creates an OpenSearch domain intended for Camunda. OpenSearch is a powerful alternative to Elasticsearch. For more information on using OpenSearch with Camunda, refer to the [Camunda documentation](/self-managed/setup/guides/using-existing-opensearch.md). :::note Migration to OpenSearch is not supported diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/azure/microsoft-aks/aks-helm.md b/versioned_docs/version-8.7/self-managed/setup/deploy/azure/microsoft-aks/aks-helm.md index d94a698a714..d579fce4dd8 100644 --- a/versioned_docs/version-8.7/self-managed/setup/deploy/azure/microsoft-aks/aks-helm.md +++ b/versioned_docs/version-8.7/self-managed/setup/deploy/azure/microsoft-aks/aks-helm.md @@ -17,7 +17,7 @@ This guide provides a comprehensive walkthrough for installing the Camunda 8 Hel - [jq](https://jqlang.github.io/jq/download/) to interact with some variables. - [GNU envsubst](https://www.man7.org/linux/man-pages/man1/envsubst.1.html) to generate manifests. - (optional) Custom domain name/[DNS zone](https://learn.microsoft.com/en-us/azure/dns/dns-zones-records) in Azure DNS. This allows you to expose Camunda 8 endpoints and connect via community-supported [zbctl](https://github.com/camunda-community-hub/zeebe-client-go/blob/main/cmd/zbctl/zbctl.md) or [Camunda Modeler](https://camunda.com/download/modeler/). -- A namespace to host the Camunda Platform; in this guide we will reference `camunda` as the target namespace. +- A namespace to host Camunda; in this guide we will reference `camunda` as the target namespace. For the tool versions used, check the [.tool-versions](https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/.tool-versions) file in the related repository. This contains an up-to-date list of versions we also use for testing. @@ -57,7 +57,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/azure/k If you do not have a domain name, external access to Camunda 8 web endpoints from outside the Azure Virtual Network will not be possible. In this case, skip the DNS setup and proceed directly to [deploying Camunda 8 via Helm charts](#deploy-camunda-8-via-helm-charts). -Alternatively, you can use `kubectl port-forward` to access the Camunda platform without a domain or Ingress configuration. For more information, see the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). +Alternatively, you can use `kubectl port-forward` to access Camunda without a domain or Ingress configuration. For more information, see the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). Throughout the rest of this installation guide, we will refer to configurations as **"With domain"** or **"Without domain"** depending on whether the application is exposed via a domain. ::: @@ -325,7 +325,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic This script: -- Installs (or upgrades) the Camunda platform using the Helm chart. +- Installs (or upgrades) Camunda using the Helm chart. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from `generated-values.yml`. diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md index 5492c5f9f65..b507da36d31 100644 --- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md +++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md @@ -459,7 +459,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic This command: -- Installs (or upgrades) the Camunda platform using the Helm chart on each cluster. +- Installs (or upgrades) Camunda using the Helm chart on each cluster. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from the value file. diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md index ce3b41d1dc1..add0bd220b1 100644 --- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md +++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md @@ -28,7 +28,7 @@ Additional informational and high-level overview based on Kubernetes as upstream - Ensure at least **3 Elastic IPs** (one per availability zone). - Verify quotas for **VPCs, EC2 instances, and storage**. - Request increases if needed via the AWS console ([guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)), costs are only for resources used. -- A namespace to host the Camunda Platform. +- A namespace to host Camunda. For the tool versions used, check the [.tool-versions](https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/.tool-versions) file in the repository. It contains an up-to-date list of versions that Camunda also uses for testing. @@ -143,11 +143,11 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect - The second TLS secret is used on the exposed route, referenced as `camunda-platform-external-certificate`. For example, this would be the same TLS secret used for Ingress. We also configure the Zeebe Gateway Ingress to create a [Re-encrypt Route](https://docs.openshift.com/container-platform/latest/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration). - To configure a Zeebe cluster securely, it's essential to set up a secure communication configuration between pods: - - We enable gRPC ingress for the ZeebeGateway pod, which sets up a secure proxy that we'll use to communicate with the Zeebe cluster. To avoid conflicts with other services, we use a specific domain (`zeebe-$DOMAIN_NAME`) for the gRPC proxy, different from the one used by other services (`$DOMAIN_NAME`). We also note that the port used for gRPC is `443`. + To configure a Zeebe cluster securely, it's essential to set up a secure communication configuration between pods: + - We enable gRPC ingress for the ZeebeGateway pod, which sets up a secure proxy that we'll use to communicate with the Zeebe cluster. To avoid conflicts with other services, we use a specific domain (`zeebe-$DOMAIN_NAME`) for the gRPC proxy, different from the one used by other services (`$DOMAIN_NAME`). We also note that the port used for gRPC is `443`. - - We mount the **Service Certificate Secret** (`camunda-platform-internal-service-certificate`) to the Core pod and configure a secure TLS connection. - Finally, we mount the **Service Certificate Secret** (`camunda-platform-internal-service-certificate`) to the Zeebe Gateway Pod and the Zeebe Pod to configure both [broker security](/self-managed/zeebe-deployment/configuration/broker.md#zeebebrokernetworksecurity) and gateway security. + - We mount the **Service Certificate Secret** (`camunda-platform-internal-service-certificate`) to the Core pod and configure a secure TLS connection. + Finally, we mount the **Service Certificate Secret** (`camunda-platform-internal-service-certificate`) to the Zeebe Gateway Pod and the Zeebe Pod to configure both [broker security](/self-managed/zeebe-deployment/configuration/broker.md#zeebebrokernetworksecurity) and gateway security. Update your `values.yml` file with the following: @@ -218,7 +218,7 @@ If you should decide to use the Red Hat endorsed [NGINX Ingress Controller](http If you do not have a domain name or do not intend to use one for your Camunda 8 deployment, external access to Camunda 8 web endpoints from outside the OpenShift cluster will not be possible. -However, you can use `kubectl port-forward` to access the Camunda platform without a domain name or Ingress configuration. For more information, refer to the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). +However, you can use `kubectl port-forward` to access Camunda without a domain name or Ingress configuration. For more information, refer to the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following: @@ -305,7 +305,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic This command: -- Installs (or upgrades) the Camunda platform using the Helm chart. +- Installs (or upgrades) Camunda using the Helm chart. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from `generated-values.yml`. diff --git a/versioned_docs/version-8.8/self-managed/concepts/no-secondary-storage.md b/versioned_docs/version-8.8/self-managed/concepts/no-secondary-storage.md index 7bde7dd1eb4..5d115862df1 100644 --- a/versioned_docs/version-8.8/self-managed/concepts/no-secondary-storage.md +++ b/versioned_docs/version-8.8/self-managed/concepts/no-secondary-storage.md @@ -8,7 +8,7 @@ The `noSecondaryStorage` mode allows you to run Zeebe clusters with only the eng ## No secondary storage mode -In this mode, only the Zeebe process engine and primary storage components are available. This setup provides core process orchestration functionality, but does **not** include the full feature set of the Camunda platform. +In this mode, only the Zeebe process engine and primary storage components are available. This setup provides core process orchestration functionality, but does **not** include the full feature set of Camunda. For the complete Camunda 8 experience, including web applications, APIs, and advanced features, we recommend using the standard deployment with secondary storage enabled. diff --git a/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eks-helm.md index 78b6cc0a7fd..ed48e6ce460 100644 --- a/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eks-helm.md +++ b/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eks-helm.md @@ -21,7 +21,7 @@ Lastly you'll verify that the connection to your Self-Managed Camunda 8 environm - [jq](https://jqlang.github.io/jq/download/) to interact with some variables. - [GNU envsubst](https://www.man7.org/linux/man-pages/man1/envsubst.1.html) to generate manifests. - (optional) Domain name/[hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html) in Route53. This allows you to expose Camunda 8 and connect via community-supported [zbctl](https://github.com/camunda-community-hub/zeebe-client-go/blob/main/cmd/zbctl/zbctl.md) or [Camunda Modeler](https://camunda.com/download/modeler/). -- A namespace to host the Camunda Platform. +- A namespace to host Camunda. For the tool versions used, check the [.tool-versions](https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/.tool-versions) file in the repository. It contains an up-to-date list of versions that we also use for testing. @@ -112,7 +112,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/kub If you do not have a domain name, external access to Camunda 8 web endpoints from outside the AWS VPC will not be possible. In this case, you may skip the DNS setup and proceed directly to [deploying Camunda 8 via Helm charts](#deploy-camunda-8-via-helm-charts). -Alternatively, you can use `kubectl port-forward` to access the Camunda platform without a domain or Ingress configuration. For more information, see the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). +Alternatively, you can use `kubectl port-forward` to access Camunda without a domain or Ingress configuration. For more information, see the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). Throughout the rest of this installation guide, we will refer to configurations as **"With domain"** or **"Without domain"** depending on whether the application is exposed via a domain. ::: @@ -440,7 +440,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic This command: -- Installs (or upgrades) the Camunda platform using the Helm chart. +- Installs (or upgrades) Camunda using the Helm chart. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from `generated-values.yml`. diff --git a/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eksctl.md b/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eksctl.md index 519d0797cd7..dd81a3cb1db 100644 --- a/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eksctl.md +++ b/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/eksctl.md @@ -46,7 +46,7 @@ This guide results in the following: - An Amazon EKS Kubernetes cluster running the latest Kubernetes version with four nodes ready for Camunda 8 installation. - Installed and configured [EBS CSI driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html), which is used by the Camunda 8 Helm chart to create [persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). - A [managed Aurora PostgreSQL 17.x](https://aws.amazon.com/rds/aurora/) instance that will be used by the Camunda 8 components. -- A [managed OpenSearch domain](https://aws.amazon.com/opensearch-service/) created and configured for use with the Camunda platform.. +- A [managed OpenSearch domain](https://aws.amazon.com/opensearch-service/) created and configured for use with Camunda. - [IAM Roles for Service Accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) (IRSA) configured and [Pod Identities](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html). - This simplifies the setup by not relying on explicit credentials, but instead allows creating a mapping between IAM roles and Kubernetes service accounts based on a trust relationship. A [blog post](https://aws.amazon.com/blogs/containers/diving-into-iam-roles-for-service-accounts/) by AWS visualizes this on a technical level. - This allows a Kubernetes service account to temporarily impersonate an AWS IAM role to interact with AWS services like S3, RDS, or Route53 without supplying explicit credentials. @@ -842,7 +842,7 @@ We will also use this step to verify connectivity to the database from the creat Creating an OpenSearch domain can be accomplished through various methods, such as using the AWS Management Console or the AWS CLI. This guide focuses on providing a reproducible setup using the CLI. For information on creating an OpenSearch domain using the UI, refer to the [AWS OpenSearch documentation](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/create-managed-domain.html). -The resulting OpenSearch domain is intended for use with the Camunda platform, the following components utilize OpenSearch: +The resulting OpenSearch domain is intended for use with Camunda, the following components utilize OpenSearch: - Orchestration Cluster (Zeebe, Operate, Tasklist) - Optimize diff --git a/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/terraform-setup.md b/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/terraform-setup.md index 8873ba34790..0bfe4e37a17 100644 --- a/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/terraform-setup.md +++ b/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/amazon/amazon-eks/terraform-setup.md @@ -111,7 +111,7 @@ After completing this guide, you will have: - An Amazon EKS Kubernetes cluster running with four nodes ready for Camunda 8 installation. - The [EBS CSI driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html), installed and configured. This is used by the Camunda 8 Helm chart to create [persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/). - (Optional) A managed [Aurora PostgreSQL](https://aws.amazon.com/rds/postgresql/) instance for Camunda. -- (Optional) A managed [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) domain created and configured for use with the Camunda platform. +- (Optional) A managed [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) domain created and configured for use with Camunda. - (Optional) [IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) configured so Kubernetes workloads can assume IAM roles without stored credentials. ## 1. Configure AWS and initialize Terraform @@ -410,7 +410,7 @@ If you choose not to use this module, you'll need to either provide a managed El Additionally, you must delete the `opensearch.tf` file within the `terraform/cluster` directory of your chosen reference as it will otherwise create the resources. ::: -The OpenSearch module creates an OpenSearch domain intended for Camunda platform. OpenSearch is a powerful alternative to Elasticsearch. For more information on using OpenSearch with Camunda, refer to the [Camunda documentation](/self-managed/deployment/helm/configure/database/using-external-opensearch.md). +The OpenSearch module creates an OpenSearch domain intended for Camunda. OpenSearch is a powerful alternative to Elasticsearch. For more information on using OpenSearch with Camunda, refer to the [Camunda documentation](/self-managed/deployment/helm/configure/database/using-external-opensearch.md). The OpenSearch or Elasticsearch database is required to support the Orchestration Cluster components described in the [reference architecture](/self-managed/reference-architecture/reference-architecture.md): Zeebe (workflow data), Operate (monitoring), Tasklist (human tasks), Optimize (analytics), and Identity (user management, sessions, OIDC mappings). diff --git a/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/azure/microsoft-aks/aks-helm.md b/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/azure/microsoft-aks/aks-helm.md index a871d856a6e..77dee41d673 100644 --- a/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/azure/microsoft-aks/aks-helm.md +++ b/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/azure/microsoft-aks/aks-helm.md @@ -17,7 +17,7 @@ This guide provides a comprehensive walkthrough for installing the Camunda 8 Hel - [jq](https://jqlang.github.io/jq/download/) to interact with some variables. - [GNU envsubst](https://www.man7.org/linux/man-pages/man1/envsubst.1.html) to generate manifests. - (optional) Custom domain name/[DNS zone](https://learn.microsoft.com/en-us/azure/dns/dns-zones-records) in Azure DNS. This allows you to expose Camunda 8 endpoints and connect via community-supported [zbctl](https://github.com/camunda-community-hub/zeebe-client-go/blob/main/cmd/zbctl/zbctl.md) or [Camunda Modeler](https://camunda.com/download/modeler/). -- A namespace to host the Camunda Platform; in this guide we will reference `camunda` as the target namespace. +- A namespace to host Camunda; in this guide we will reference `camunda` as the target namespace. For the tool versions used, check the [.tool-versions](https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/.tool-versions) file in the related repository. This contains an up-to-date list of versions we also use for testing. @@ -359,7 +359,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic This script: -- Installs (or upgrades) the Camunda platform using the Helm chart. +- Installs (or upgrades) Camunda using the Helm chart. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from `generated-values.yml`. diff --git a/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/openshift/dual-region.md b/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/openshift/dual-region.md index e26f164fd6c..edf0bbd5157 100644 --- a/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/openshift/dual-region.md +++ b/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/openshift/dual-region.md @@ -467,7 +467,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic This command: -- Installs (or upgrades) the Camunda platform using the Helm chart on each cluster. +- Installs (or upgrades) Camunda using the Helm chart on each cluster. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from the value file. diff --git a/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/openshift/redhat-openshift.md b/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/openshift/redhat-openshift.md index f9c59acf817..b535bbea157 100644 --- a/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/openshift/redhat-openshift.md +++ b/versioned_docs/version-8.8/self-managed/deployment/helm/cloud-providers/openshift/redhat-openshift.md @@ -28,7 +28,7 @@ Additional informational and high-level overview based on Kubernetes as upstream - Ensure at least **3 Elastic IPs** (one per availability zone). - Verify quotas for **VPCs, EC2 instances, and storage**. - Request increases if needed via the AWS console ([guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)), costs are only for resources used. -- A namespace to host the Camunda Platform. +- A namespace to host Camunda. For the tool versions used, check the [.tool-versions](https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/.tool-versions) file in the repository. It contains an up-to-date list of versions that we also use for testing. @@ -213,7 +213,7 @@ If you should decide to use the Red Hat endorsed [NGINX Ingress Controller](http If you do not have a domain name or do not intend to use one for your Camunda 8 deployment, external access to Camunda 8 web endpoints from outside the OpenShift cluster will not be possible. -However, you can use `kubectl port-forward` to access the Camunda platform without a domain name or Ingress configuration. For more information, refer to the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). +However, you can use `kubectl port-forward` to access Camunda without a domain name or Ingress configuration. For more information, refer to the [kubectl port-forward documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/). To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following: @@ -319,7 +319,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic This command: -- Installs (or upgrades) the Camunda platform using the Helm chart. +- Installs (or upgrades) Camunda using the Helm chart. - Substitutes the appropriate version using the `$CAMUNDA_HELM_CHART_VERSION` environment variable. - Applies the configuration from `generated-values.yml`. diff --git a/versioned_docs/version-8.8/self-managed/deployment/helm/configure/operator-based-infrastructure.md b/versioned_docs/version-8.8/self-managed/deployment/helm/configure/operator-based-infrastructure.md index f7b247ef528..e7e60167e04 100644 --- a/versioned_docs/version-8.8/self-managed/deployment/helm/configure/operator-based-infrastructure.md +++ b/versioned_docs/version-8.8/self-managed/deployment/helm/configure/operator-based-infrastructure.md @@ -52,7 +52,7 @@ Before proceeding with this guide, ensure you have: - **Cluster admin privileges**: Required to install Custom Resource Definitions (CRDs) and operators - **Command-line tools**: - `kubectl` configured to access your cluster - - `helm` CLI for deploying Camunda Platform + - `helm` CLI for deploying Camunda using the Helm chart - `openssl` for generating random passwords - `envsubst` command (part of `gettext` package) for environment variable substitution @@ -136,7 +136,7 @@ Each infrastructure component should be deployed individually in the following o | 1 | **[PostgreSQL](#postgresql-deployment)** | None | Database clusters for Keycloak, Management Identity, and Web Modeler | | 2 | **[Elasticsearch](#elasticsearch-deployment)** | None | Secondary storage for orchestration cluster components | | 3 | **[Keycloak](#keycloak-deployment)** | PostgreSQL | Authentication and identity management | -| 4 | **[Camunda Platform](#camunda-deployment)** | All above | Deploy using Helm with operator-managed infrastructure | +| 4 | **[Camunda](#camunda-deployment)** | All above | Deploy using Helm with operator-managed infrastructure | :::tip Automation with GitOps While this guide demonstrates manual deployment using command-line tools, these same configurations can be automated using GitOps solutions like ArgoCD, Flux, or other Kubernetes deployment pipelines. All configuration files referenced in this guide are designed to work seamlessly with declarative deployment approaches. @@ -525,7 +525,7 @@ With all infrastructure components deployed and configured, you can now deploy C ### Configuration files summary -Before deploying Camunda Platform, ensure you have saved all required configuration files locally. The files are organized by deployment phase: +Before deploying Camunda, ensure you have saved all required configuration files locally. The files are organized by deployment phase: #### Infrastructure deployment files (Custom Resources) @@ -549,7 +549,7 @@ Before deploying Camunda Platform, ensure you have saved all required configurat ### Pre-deployment checklist -Before deploying Camunda Platform: +Before deploying Camunda, ensure you have completed the following: - [ ] All infrastructure components deployed (PostgreSQL, Elasticsearch, Keycloak) - [ ] Configuration files saved locally from previous sections @@ -557,7 +557,7 @@ Before deploying Camunda Platform: ### Helm deployment -Deploy Camunda Platform using the infrastructure configuration files you saved from previous sections: +Deploy Camunda using the infrastructure configuration files you saved from previous sections: ```bash reference https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/operator-based/0-set-environment.sh @@ -568,7 +568,7 @@ For end-to-end configuration patterns (OIDC-enabled "Full Cluster" including Opt -Deploy Camunda Platform with external domain configuration: +Deploy Camunda with external domain configuration: ```bash helm install "$CAMUNDA_RELEASE_NAME" camunda/camunda-platform \ @@ -583,7 +583,7 @@ helm install "$CAMUNDA_RELEASE_NAME" camunda/camunda-platform \ -Deploy Camunda Platform for local development: +Deploy Camunda for local development: ```bash helm install "$CAMUNDA_RELEASE_NAME" camunda/camunda-platform \ diff --git a/versioned_docs/version-8.8/self-managed/deployment/helm/install/production/index.md b/versioned_docs/version-8.8/self-managed/deployment/helm/install/production/index.md index 837a9fbabad..f5e86df40c6 100644 --- a/versioned_docs/version-8.8/self-managed/deployment/helm/install/production/index.md +++ b/versioned_docs/version-8.8/self-managed/deployment/helm/install/production/index.md @@ -85,7 +85,7 @@ helm install camunda camunda/camunda-platform --version $HELM_CHART_VERSION -n o ### Ingress TLS setup -In order to access the Camunda Platform through HTTPS with Ingress, TLS must be enabled. Enabling TLS requires the following: +In order to access Camunda through HTTPS with Ingress, TLS must be enabled. Enabling TLS requires the following: 1. **Domain name**: A public registered domain that has configurable DNS records. This guide will use `camunda.example.com` as the domain. 2. **TLS certificate**: A TLS certificate created for your domain. The certificate must be an X.509 certificate, issued by a trusted Certificate Authority. The certificate must include the correct domain names (Common Name or Subject Alternative Names) to secure Ingress resources. Reach out to your DNS provider if you are unsure on how to create a TLS certificate. It is not recommended to use self-signed certificates. diff --git a/versioned_docs/version-8.8/self-managed/deployment/manual/cloud-providers/amazon/aws-ec2.md b/versioned_docs/version-8.8/self-managed/deployment/manual/cloud-providers/amazon/aws-ec2.md index 2ad96b95c85..a52a8554eee 100644 --- a/versioned_docs/version-8.8/self-managed/deployment/manual/cloud-providers/amazon/aws-ec2.md +++ b/versioned_docs/version-8.8/self-managed/deployment/manual/cloud-providers/amazon/aws-ec2.md @@ -233,7 +233,7 @@ If you choose not to use this module, you must provide your own Elasticsearch or Additionally, be sure to delete the `opensearch.tf` file in your reference copy—otherwise, the resources defined in it will still be created. ::: -The OpenSearch module provisions an OpenSearch domain for use with the Camunda platform. OpenSearch is a powerful alternative to Elasticsearch. +The OpenSearch module provisions an OpenSearch domain for use with Camunda. OpenSearch is a powerful alternative to Elasticsearch. :::note Migration to OpenSearch is not supported