Merge branch 'main' into update/add-nav-buttons

docs/components/components-overview.md

@@ -4,6 +4,7 @@ title: Overview Components
 sidebar_label: Overview Components
 slug: /components/
 description: "This section contains product manual content for each component in Camunda Platform 8, including conceptual content."
+keywords: ["process automation tools"]
 ---
 
 This section contains product manual content for each component in Camunda Platform 8, including conceptual content. Together, these components comprise the Camunda Platform 8 SaaS experience.

docs/components/concepts/what-is-camunda-platform-8.md

@@ -2,6 +2,19 @@
 id: what-is-camunda-platform-8
 title: "What is Camunda Platform 8?"
 description: "Camunda Platform 8 orchestrates complex business processes that span people, systems, and devices."
+keywords:
+  [
+    "workflow process",
+    "workflow engine",
+    "process management software",
+    "bpm business process management",
+    "business process automation",
+    "camunda software",
+    "camunda cloud",
+    "process automation platform",
+    "process automation software",
+    "process orchestration",
+  ]
 ---
 
 [Camunda Platform 8](https://camunda.io) orchestrates complex business processes that span people, systems, and devices. With Camunda, business users collaborate with developers to model and [automate end-to-end processes using BPMN-powered flowcharts](../../guides/automating-a-process-using-bpmn.md), alongside DMN decision tables that promote speed, scale, and decision logic.

docs/components/connectors/out-of-the-box-connectors/aws-sqs-inbound.md

@@ -34,7 +34,7 @@ To configure the SQS inbound Connector and receive messages from your SQS Queue,
 1. Set the relevant IAM key and secret pair in the **Authentication** section. For example, `secrets.MY_AWS_ACCESS_KEY`. The value can be plain text, but this is not recommended due to security concerns.
 2. In the **Queue Properties** section, set the URL of your SQS Queue and its region.
 3. In the **Message polling properties** section, set the polling wait time. This is the duration (in seconds) for which the call waits for a message to arrive in the queue before returning. See the [official documentation](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html) for more details.
-4. (Optional) In the **Use next attribute names for activation condition** section, set an array of **Attribute names** or **Message attribute name** (e.g., `["attributeName1", "attributeName2"]`) to receive messages from the queue with specific metadata. Learn more about message metadata [here](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-message-metadata.html).
+4. (Optional) In the **Use next attribute names for activation condition** section, set an array of **Attribute names** or **Message attribute name** (e.g., `["attributeName1", "attributeName2"]`) to receive messages from the queue with specific metadata. Alternatively, you can leave it empty to get results with all available attributes. Learn more about message metadata [here](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-message-metadata.html).
 5. (Optional) Configure the **Activation Condition**. For example, if an external message has the body `{"messageId": 1, "body": "Hi team", "messageAttributes":{"key":{"stringValue":"value"}}...}`, the **Activation Condition** value might look like `=(messageAttributes.key.stringValue="value")`. Leave this field empty to receive all messages every time.
 
    ![activation condition](../img/connectors-aws-sqs-start-event-activation.png)

docs/components/modeler/about-modeler.md

@@ -2,6 +2,7 @@
 id: about-modeler
 title: About Modeler
 description: "Any executable process needs a BPMN diagram designed and configured beforehand. Camunda offers Web Modeler and Desktop Modeler to design and implement these."
+keywords: ["process mapping tool"]
 ---
 
 <span class="badge badge--cloud">Camunda Platform 8 only</span>

docs/components/zeebe/technical-concepts/protocols.md

@@ -33,5 +33,5 @@ If there is no client in your target language yet, you can [build your own clien
 
 ## Intercepting calls
 
-Zeebe supports [loading arbitrary gRPC server interceptors](self-managed/zeebe-deployment/interceptors.md) to intercept incoming
+Zeebe supports [loading arbitrary gRPC server interceptors](self-managed/zeebe-deployment/zeebe-gateway/interceptors.md) to intercept incoming
 calls.

docs/self-managed/platform-deployment/docker.md

@@ -1,6 +1,7 @@
 ---
 id: docker
 title: "Docker"
+keywords: ["camunda docker"]
 ---
 
 This page guides you through Camunda Platform 8 Docker images and how to run the platform in a developer setup using Docker Compose.

docs/self-managed/platform-deployment/helm-kubernetes/deploy.md

@@ -46,7 +46,7 @@ Before deploying Camunda Platform using Helm you need the following:
 
 You have to add the Camunda Helm chart repository in order to use the charts. Once this is done, Helm is able to fetch and install charts hosted in [https://helm.camunda.io](https://helm.camunda.io):
 
-```
+```bash
 helm repo add camunda https://helm.camunda.io
 helm repo update
 ```
@@ -57,7 +57,7 @@ Once this is completed, we are ready to install the Helm chart hosted in the off
 
 To install the available Camunda Platform 8 components inside a Kubernetes cluster, you can simply run:
 
-```
+```bash
 helm install <RELEASE_NAME> camunda/camunda-platform
 ```
 
@@ -75,7 +75,7 @@ Installing all the components in a cluster requires all Docker images to be down
 
 Review the progress of your deployment by checking if the Kubernetes pods are up and running with the following:
 
-```
+```bash
 kubectl get pods
 ```
 
@@ -101,7 +101,7 @@ elasticsearch-master-1                          0/1     Init:0/1            0
 
 Review the progress of your deployment by checking if the Kubernetes pods are up and running with the following:
 
-```
+```bash
 kubectl get pods
 ```
 
@@ -117,6 +117,26 @@ elasticsearch-master-0                                 1/1     Running   0
 <RELEASE_NAME>-zeebe-gateway                           1/1     Running   0          4m6s
 ```
 
+### Installing with latest updates for certain Camunda Helm chart
+
+Although the Camunda Platform 8 Helm chart gets the latest version of [Camunda Platform 8 applications](../../../reference/supported-environments.md), the version is still possible to diverge slightly between the chart and the applications/dependencies due to different releases.
+
+To have the latest version of the chart and applications/dependencies at any time, install the chart as follows:
+
+```bash
+# This will install the latest Camunda Platform Helm chart v8.2.x with the latest applications/dependencies of v8.2.x.
+helm install <RELEASE_NAME> camunda/camunda-platform \
+    --values https://raw.githubusercontent.com/camunda/camunda-platform-helm/main/charts/camunda-platform/values/values-latest.yaml
+```
+
+The same works for previous supported versions as follows:
+
+```bash
+# This will install Camunda Platform Helm chart v8.1.x with the latest applications/dependencies of v8.1.x.
+helm install <RELEASE_NAME> camunda/camunda-platform --version 8.1 \
+    --values https://raw.githubusercontent.com/camunda/camunda-platform-helm/main/charts/camunda-platform/values/values-v8.1.yaml
+```
+
 ### Installing Web Modeler
 
 :::note

docs/self-managed/platform-deployment/helm-kubernetes/upgrade.md

@@ -7,6 +7,12 @@ description: "To upgrade to a more recent version of the Camunda Platform Helm c
 
 To upgrade to a more recent version of the Camunda Platform Helm charts, there are certain things you need to keep in mind.
 
+:::caution
+
+Ensure to review the [instructions for specific version](#version-update-instructions) before staring the actual upgrade.
+
+:::
+
 ### Upgrading where Identity disabled
 
 Normally for a Helm upgrade, you run the [Helm upgrade](https://helm.sh/docs/helm/helm_upgrade/) command. If you have disabled Camunda Identity and the related authentication mechanism, you should be able to do an upgrade as follows:
@@ -19,11 +25,7 @@ However, if Camunda Identity is enabled (which is the default), the upgrade path
 
 ### Upgrading where Identity enabled
 
-If you have installed the Camunda Platform 8 Helm charts before with default values, this means Identity and the related authentication mechanism are enabled. For authentication, the Helm charts generate for each web app the secrets randomly if not specified on installation.
-
-## If you just tried upgrading to a newer chart version
-
-If you have installed the Camunda Platform 8 Helm charts before with default values, this means Identity and the related authentication mechanism are enabled. For authentication, the Helm charts generate the secrets randomly if not specified on installation for each web app. If you run `helm upgrade` to upgrade to a newer chart version, you likely will see the following return:
+If you have installed the Camunda Platform 8 Helm charts before with default values, this means Identity and the related authentication mechanism are enabled. For authentication, the Helm charts generate the secrets randomly if not specified on installation for each web application. If you run `helm upgrade` to upgrade to a newer chart version, you likely will see the following return:
 
 ```shell
 helm upgrade camunda-platform-test camunda/camunda-platform
@@ -89,7 +91,122 @@ For more details on the Keycloak upgrade path, you can also read the [Bitnami Ke
 
 ## Version update instructions
 
-The following sections are only needed if you are updating to v8.0.13 or the versions after v8.0.13.
+### v8.2
+
+#### Connectors
+
+Camunda Platform 8 Connectors component is one of our applications which performs the integration with an external system.
+
+Currently, in all cases, either you will use Connectors v8.2 or not, this step should be done. You need to create the Connectors secret object (more details about this in [camunda-platform-helm/656](https://github.com/camunda/camunda-platform-helm/issues/656)).
+
+First, generate the Connectors secret:
+
+```bash
+helm template <RELEASE_NAME> camunda/camunda-platform --version 8.2 \
+    --show-only charts/identity/templates/connectors-secret.yaml >
+    identity-connectors-secret.yaml
+```
+
+Then apply it:
+
+```bash
+kubectl apply --namespace <NAMESPACE_NAME> -f identity-connectors-secret.yaml
+```
+
+#### Keycloak
+
+Camunda Platform v8.2 uses Keycloak v19 which depends on PostgreSQL v15. That is a major change for the dependencies. Currently there are two recommended options to upgrade from Camunda Platform 8.1.x to 8.2.x:
+
+1. Use the previous version of PostgreSQL v14 in Camunda Platform v8.2, this should be simple and it will work seamlessly.
+2. Follow the official PostgreSQL upgrade guide: [Upgrading a PostgreSQL Cluster v15](https://www.postgresql.org/docs/15/upgrading.html). However, it requires some manual work and longer downtime to do the database schema upgrade.
+
+**Method 1: Use the previous version PostgreSQL v14**
+
+You can set the PostgreSQL image tag as follows:
+
+```yaml
+identity:
+  keycloak:
+    postgresql:
+      image:
+        tag: 14.5.0
+```
+
+Then follow the [normal upgrade steps](#upgrading-where-identity-enabled).
+
+**Method 2: Upgrade the database schema to work with PostgreSQL v15**
+
+The easiest way to upgrade major versions of postgresql is to start a port-forward,
+and then run `pg_dump` or `pg_restore`. The postgresql client versions are fairly flexible
+with different server versions, but for best results, we recommend using the newest
+client version.
+
+1. In one terminal, start a `port-forward` against the postgresql service:
+
+```bash
+kubectl port-forward svc/<RELEASE_NAME>-postgresql 5432
+```
+
+Follow the rest of these steps in a different terminal.
+
+2. Get the 'postgres' users password from the postgresql service:
+
+```bash
+kubectl exec -it statefulset/<RELEASE_NAME>-postgresql -- env | grep "POSTGRES_POSTGRES_PASSWORD="
+```
+
+3. Scale identity down using the following command:
+
+```bash
+kubectl scale --replicas=0 deployment <RELEASE_NAME>-identity
+```
+
+4. Perform the database dump:
+
+```bash
+pg_dumpall -U postgres -h localhost -p 5432 | tee dump.psql
+Password: <enter password from previous command without POSTGRES_POSTGRES_PASSWORD=>
+```
+
+`pg_dumpall` may ask multiple times for the same password. The database will be dumped into `dump.psql`.
+
+5. Scale database down using the following command:
+
+```bash
+kubectl scale --replicas=0 statefulset <RELEASE_NAME>-postgresql
+```
+
+6. Delete the PVC for the postgresql instance using the following command:
+
+```bash
+kubectl delete pvc data-<RELEASE_NAME>-postgresql-0
+```
+
+7. Update the postgresql version using the following command:
+
+```bash
+kubectl set image statefulset/<RELEASE_NAME>-postgresql postgresql=docker.io/bitnami/postgresql:15.3.0
+```
+
+8. Scale the services back up using the following command:
+
+```bash
+kubectl scale --replicas=1 statefulset <RELEASE_NAME>-postgresql
+```
+
+9. Restore the database dump using the following command:
+
+```bash
+psql -U postgres -h localhost -p 5432 -f dump.psql
+```
+
+10. Scale up identity using the following command:
+
+```bash
+kubectl scale --replicas=1 deployment <RELEASE_NAME>-identity
+```
+
+Then follow the [normal upgrade steps](#upgrading-where-identity-enabled).
 
 ### v8.0.13
 

docs/self-managed/platform-deployment/overview.md

@@ -3,6 +3,7 @@ id: overview
 title: "Camunda Platform 8 installation overview"
 sidebar_label: "Overview"
 description: "This chapter contains information for users who want to deploy and run Camunda Platform 8 Self-Managed in their self-controlled cloud or own hardware."
+keywords: ["camunda download"]
 ---
 
 This chapter contains information for users who want to deploy and run Camunda Platform 8 Self-Managed, typically in your self-controlled cloud (public or private) or even on your own hardware.

docs/self-managed/platform-deployment/troubleshooting.md

@@ -54,3 +54,7 @@ For security reasons, Camunda Identity requires secure access (HTTPS) when a `co
 :::note
 Also, due to limitations, the Identity `contextPath` approach is unavailable when using a browser Incognito mode.
 :::
+
+## Web Modeler database schema
+
+The Web Modeler `restapi` component requires a [database connection](../../modeler/web-modeler/configuration#database). This connection should not point to the same database as Keycloak does.

docs/self-managed/zeebe-deployment/configuration/gateway.md

@@ -270,7 +270,7 @@ longPolling:
 
 ### zeebe.gateway.interceptors
 
-It is possible to intercept requests in the gateway, which can be configured via environment variables or the `application.yaml` file. For more details, read about [interceptors](../interceptors.md).
+It is possible to intercept requests in the gateway, which can be configured via environment variables or the `application.yaml` file. For more details, read about [interceptors](/self-managed/zeebe-deployment/zeebe-gateway/interceptors.md).
 
 Each interceptor should be configured with the values described below:
 

docs/self-managed/zeebe-deployment/interceptors.md → docs/self-managed/zeebe-deployment/zeebe-gateway/interceptors.md

@@ -4,8 +4,6 @@ title: "Interceptors"
 sidebar_label: "Interceptors"
 ---
 
-> This functionality is currently only available in Camunda Platform 8 Self-Managed.
-
 All communication from a client to a broker must first pass through a gateway.
 There they can be intercepted before being dispatched. Zeebe provides a way to
 load arbitrary interceptors into the gateway. Some typical examples of what you
@@ -136,7 +134,7 @@ interceptor, you need to provide your gateway with:
   of the interceptor class, e.g. `com.acme.ExampleInterceptor`
 
 Let's continue with the LoggingInterceptor example. We can provide these
-[configurations](configuration/configuration.md)
+[configurations](/self-managed/zeebe-deployment/configuration/configuration.md)
 using a gateway config file, environment variables or a mix of both. We'll be
 using a config file here.
 

optimize/self-managed/optimize-deployment/install-and-start.md

@@ -140,23 +140,23 @@ You can also adjust logging levels using environment variables as described in t
 
 #### License key file
 
-If you want the Optimize Docker container to automatically recognize your [license key file](./configuration/license.md), you can use standard [Docker means](https://docs.docker.com/storage/volumes/) to make the file with the license key available inside the container. Replacing the `ABSOLUTE_PATH_ON_HOST_TO_LICENSE_FILE` with the absolute path to the license key file on your host can be done with the following command:
+If you want the Optimize Docker container to automatically recognize your [license key file](./configuration/license.md), you can use standard [Docker means](https://docs.docker.com/storage/volumes/) to make the file with the license key available inside the container. Replacing the `{{< absolutePathOnHostToLicenseFile >}}` with the absolute path to the license key file on your host can be done with the following command:
 
 ```
 docker run -d --name optimize -p 8090:8090 -p 8091:8091 \
-           -v ABSOLUTE_PATH_ON_HOST_TO_LICENSE_FILE:/optimize/config/OptimizeLicense.txt:ro \
+           -v {{< absolutePathOnHostToLicenseFile >}}:/optimize/config/OptimizeLicense.txt:ro \
            registry.camunda.cloud/optimize-ee/optimize:{{< currentVersionAlias >}}
 ```
 
 #### Configuration using a yaml file
 
 In a production environment, the limited set of [environment variables](#available-environment-variables) is usually not enough so that you want to prepare a custom `environment-config.yaml` file. Refer to the [Configuration](./configuration/system-configuration.md) section of the documentation for the available configuration parameters.
 
-You need to mount this configuration file into the Optimize Docker container to apply it. Replacing the `ABSOLUTE_PATH_ON_HOST_TO_CONFIGURATION_FILE` with the absolute path to the `environment-config.yaml` file on your host can be done using the following command:
+You need to mount this configuration file into the Optimize Docker container to apply it. Replacing the `{{< absolutePathOnHostToConfigurationFile >}}` with the absolute path to the `environment-config.yaml` file on your host can be done using the following command:
 
 ```
 docker run -d --name optimize -p 8090:8090 -p 8091:8091 \
-           -v ABSOLUTE_PATH_ON_HOST_TO_CONFIGURATION_FILE:/optimize/config/environment-config.yaml:ro \
+           -v {{< absolutePathOnHostToConfigurationFile >}}:/optimize/config/environment-config.yaml:ro \
            registry.camunda.cloud/optimize-ee/optimize:{{< currentVersionAlias >}}
 ```