diff --git a/.github/workflows/links.yml b/.github/workflows/links.yml new file mode 100644 index 00000000000..ffe86651365 --- /dev/null +++ b/.github/workflows/links.yml @@ -0,0 +1,39 @@ +name: Check external links + +on: + workflow_dispatch: + schedule: + - cron: "0 3 1 * *" + +jobs: + lint: + name: links-check + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4 + + - name: Get Current Timestamp + id: timestamp + run: echo "TIMESTAMP=$(date +%s)" >> "$GITHUB_ENV" + + - name: Restore lychee cache + uses: actions/cache@v3 + with: + path: .lycheecache + key: "cache-lychee-${{ env.TIMESTAMP }}" + restore-keys: cache-lychee- + + - name: Link Checker + uses: lycheeverse/lychee-action@v1.9.0 + with: + fail: true + args: -c ./lychee-external-links.toml --base . --cache --max-cache-age 1d . --verbose --no-progress 'docs/**/*.md' 'versioned_docs/**/*.md' + token: "${{ secrets.GITHUB_TOKEN }}" + + - name: Create Issue From File + if: ${{ github.event_name == 'schedule' && env.lychee_exit_code != 0 }} + uses: peter-evans/create-issue-from-file@v4 + with: + title: Link Checker Report + content-filepath: ./lychee/out.md + labels: report, automated issue diff --git a/docs/components/best-practices/development/service-integration-patterns.md b/docs/components/best-practices/development/service-integration-patterns.md index e367ad8978d..5c5e68ce69e 100644 --- a/docs/components/best-practices/development/service-integration-patterns.md +++ b/docs/components/best-practices/development/service-integration-patterns.md @@ -23,7 +23,7 @@ The following table gives a summary of the three options: | **Technical communication style** | Synchronous | Asynchronous | Asynchronous | | **Example** | HTTP | AMQP, JMS | AMQP, Apache Kafka | -You can dive more into communication styles in the webinar [Communication Between Loosely Coupled Microservices](https://page.camunda.com/wb-communication-between-microservices) ([slides](https://www.slideshare.net/BerndRuecker/webinar-communication-between-loosely-coupled-microservices), [recording](https://page.camunda.com/wb-communication-between-microservices) and [FAQ](https://medium.com/communication-between-loosely-coupled-microservices-webinar-faq-a02708b3c8b5)). +You can dive more into communication styles in the webinar [Communication Between Loosely Coupled Microservices](https://page.camunda.com/wb-communication-between-microservices) ([slides](https://www.slideshare.net/BerndRuecker/webinar-communication-between-loosely-coupled-microservices), [recording](https://page.camunda.com/wb-communication-between-microservices) and [FAQ](https://blog.bernd-ruecker.com/communication-between-loosely-coupled-microservices-webinar-faq-a02708b3c8b5)). ## Integrating services with BPMN tasks diff --git a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md index ef6985b0b19..c0fcfd96fc3 100644 --- a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md +++ b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md @@ -121,7 +121,7 @@ helm upgrade --install \ [Cert-manager](https://cert-manager.io/) is an open-source Kubernetes add-on that automates the management and issuance of TLS certificates. It integrates with various certificate authorities (CAs) and provides a straightforward way to obtain, renew, and manage SSL/TLS certificates for your Kubernetes applications. -To simplify the installation process, it is [recommended](https://cert-manager.io/docs/setup/helm/#crd-installation-advice) to install the cert-manager `CustomResourceDefinition` resources before installing the chart. This separate step allows for easy uninstallation and reinstallation of cert-manager without deleting any custom resources that have been installed. +To simplify the installation process, it is [recommended](https://cert-manager.io/docs/installation/helm/#3-install-customresourcedefinitions) to install the cert-manager `CustomResourceDefinition` resources before installing the chart. This separate step allows for easy uninstallation and reinstallation of cert-manager without deleting any custom resources that have been installed. ```shell kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v$CERT_MANAGER_HELM_CHART_VERSION/cert-manager.crds.yaml diff --git a/docs/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md b/docs/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md index cfc5a2f7ce6..8cad92a25a7 100644 --- a/docs/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md +++ b/docs/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md @@ -14,7 +14,7 @@ This guide provides a user-friendly approach for setting up and managing Amazon - An [AWS account](https://docs.aws.amazon.com/accounts/latest/reference/accounts-welcome.html) is required to create resources within AWS. - [AWS CLI (2.11+)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html), a CLI tool for creating AWS resources. -- [eksctl (0.163+)](https://eksctl.io/setup/), a CLI tool for creating and managing Amazon EKS clusters. +- [eksctl (0.163+)](https://eksctl.io/getting-started/), a CLI tool for creating and managing Amazon EKS clusters. - [kubectl (1.28+)](https://kubernetes.io/docs/tasks/tools/#kubectl), a CLI tool to interact with the cluster. ## Considerations diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md index 49f2f0e3f65..13281a55513 100644 --- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md +++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md @@ -169,7 +169,7 @@ helm install camunda camunda/camunda-platform --skip-crds -f values.yaml -f open #### Helm 3.2.0 and greater -If you must deploy using Helm 3.2.0 or greater, you have two options. One is to use a SCCs which defines the `RunAsUser` strategy to be at least `RunAsAny`. If that's not possible, then you need to make use of [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering). This workaround is also described in detail in the [Helm chart repository](https://github.com/camunda/camunda-platform-helm/tree/main/openshift#using-a-post-renderer). +If you must deploy using Helm 3.2.0 or greater, you have two options. One is to use a SCCs which defines the `RunAsUser` strategy to be at least `RunAsAny`. If that's not possible, then you need to make use of [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering). This workaround is also described in detail in the [Helm chart repository](https://github.com/camunda/camunda-platform-helm/tree/main/charts/camunda-platform/openshift#post-renderer-setup). :::warning If using a post-renderer, you **must** use the post-renderer whenever you are updating your release, not only during the initial installation. If you do not, the default values will be used again, which will prevent some services from starting. @@ -205,7 +205,7 @@ You also need to use a custom values file, where instead of using `null` as a va Copy these values to your values file or save them as a separate file, e.g. `openshift.yaml`: :::note -These values are also available in the [Camunda Helm chart repository](https://github.com/camunda/camunda-platform-helm/blob/main/openshift/values-patch.yaml). +These values are also available in the [Camunda Helm chart repository](https://github.com/camunda/camunda-platform-helm/blob/main/charts/camunda-platform/openshift/values.yaml). ::: ```yaml diff --git a/lychee-external-links.toml b/lychee-external-links.toml new file mode 100644 index 00000000000..303a0d3ae26 --- /dev/null +++ b/lychee-external-links.toml @@ -0,0 +1,25 @@ +# Cache the results of Lychee if ran locally in order to minimise the chance of rate limiting +cache = true +# Ignore all private link (such as localhost) to avoid errors +exclude_all_private = true +# HTTP status code: 429 (Too Many Requests) will also be treated as a valid link if Lychee gets rate limited +accept = ["200", "403"] +# retry +max_retries = 6 +retry_wait_time = 10 +max_concurrency = 3 + +# Exclude all unsupported versioned_docs +exclude_path = [ + "versioned_docs/version-1.3", + "versioned_docs/version-8.1", +] + +# Explicitly exclude some URLs +exclude = [ + "^file:", + "^http(s)?://optimize.myorg", + "^http(s)?://identity:8084", + "^http(s)?://keycloak:8080", + "^http(s)?://camunda-platform-keycloak", +] \ No newline at end of file diff --git a/versioned_docs/version-8.1/components/best-practices/development/service-integration-patterns.md b/versioned_docs/version-8.1/components/best-practices/development/service-integration-patterns.md index 066efc0c013..bded871f4b5 100644 --- a/versioned_docs/version-8.1/components/best-practices/development/service-integration-patterns.md +++ b/versioned_docs/version-8.1/components/best-practices/development/service-integration-patterns.md @@ -23,7 +23,7 @@ The following table gives a summary of the three options: | **Technical communication style** | Synchronous | Asynchronous | Asynchronous | | **Example** | HTTP | AMQP, JMS | AMQP, Apache Kafka | -You can dive more into communication styles in the webinar [Communication Between Loosely Coupled Microservices](https://page.camunda.com/wb-communication-between-microservices) ([slides](https://www.slideshare.net/BerndRuecker/webinar-communication-between-loosely-coupled-microservices), [recording](https://page.camunda.com/wb-communication-between-microservices) and [FAQ](https://medium.com/communication-between-loosely-coupled-microservices-webinar-faq-a02708b3c8b5)). +You can dive more into communication styles in the webinar [Communication Between Loosely Coupled Microservices](https://page.camunda.com/wb-communication-between-microservices) ([slides](https://www.slideshare.net/BerndRuecker/webinar-communication-between-loosely-coupled-microservices), [recording](https://page.camunda.com/wb-communication-between-microservices) and [FAQ](https://blog.bernd-ruecker.com/communication-between-loosely-coupled-microservices-webinar-faq-a02708b3c8b5)). ## Integrating services with BPMN tasks diff --git a/versioned_docs/version-8.1/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md b/versioned_docs/version-8.1/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md index 57fd1bdfb88..6f392b7a04d 100644 --- a/versioned_docs/version-8.1/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md +++ b/versioned_docs/version-8.1/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md @@ -169,7 +169,7 @@ helm install camunda camunda/camunda-platform--skip-crds -f values.yaml -f opens #### Helm 3.2.0 and greater -If you must deploy using Helm 3.2.0 or greater, you have two options. One is to use a SCCs which defines the `RunAsUser` strategy to be at least `RunAsAny`. If that's not possible, then you need to make use of [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering). This workaround is also described in detail in the [Helm chart repository](https://github.com/camunda/camunda-platform-helm/tree/main/openshift#using-a-post-renderer). +If you must deploy using Helm 3.2.0 or greater, you have two options. One is to use a SCCs which defines the `RunAsUser` strategy to be at least `RunAsAny`. If that's not possible, then you need to make use of [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering). This workaround is also described in detail in the [Helm chart repository](https://github.com/camunda/camunda-platform-helm/tree/main/charts/camunda-platform/openshift#post-renderer-setup). :::warning If using a post-renderer, you **must** use the post-renderer whenever you are updating your release, not only during the initial installation. If you do not, the default values will be used again, which will prevent some services from starting. @@ -205,7 +205,7 @@ You also need to use a custom values file, where instead of using `null` as a va Copy these values to your values file or save them as a separate file, e.g. `openshift.yaml`: :::note -These values are also available in the [Camunda Helm chart repository](https://github.com/camunda/camunda-platform-helm/blob/main/openshift/values-patch.yaml). +These values are also available in the [Camunda Helm chart repository](https://github.com/camunda/camunda-platform-helm/blob/main/charts/camunda-platform/openshift/values.yaml). ::: ```yaml diff --git a/versioned_docs/version-8.2/components/best-practices/development/service-integration-patterns.md b/versioned_docs/version-8.2/components/best-practices/development/service-integration-patterns.md index 066efc0c013..bded871f4b5 100644 --- a/versioned_docs/version-8.2/components/best-practices/development/service-integration-patterns.md +++ b/versioned_docs/version-8.2/components/best-practices/development/service-integration-patterns.md @@ -23,7 +23,7 @@ The following table gives a summary of the three options: | **Technical communication style** | Synchronous | Asynchronous | Asynchronous | | **Example** | HTTP | AMQP, JMS | AMQP, Apache Kafka | -You can dive more into communication styles in the webinar [Communication Between Loosely Coupled Microservices](https://page.camunda.com/wb-communication-between-microservices) ([slides](https://www.slideshare.net/BerndRuecker/webinar-communication-between-loosely-coupled-microservices), [recording](https://page.camunda.com/wb-communication-between-microservices) and [FAQ](https://medium.com/communication-between-loosely-coupled-microservices-webinar-faq-a02708b3c8b5)). +You can dive more into communication styles in the webinar [Communication Between Loosely Coupled Microservices](https://page.camunda.com/wb-communication-between-microservices) ([slides](https://www.slideshare.net/BerndRuecker/webinar-communication-between-loosely-coupled-microservices), [recording](https://page.camunda.com/wb-communication-between-microservices) and [FAQ](https://blog.bernd-ruecker.com/communication-between-loosely-coupled-microservices-webinar-faq-a02708b3c8b5)). ## Integrating services with BPMN tasks diff --git a/versioned_docs/version-8.2/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md b/versioned_docs/version-8.2/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md index df87504ce9e..2f842d7794c 100644 --- a/versioned_docs/version-8.2/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md +++ b/versioned_docs/version-8.2/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md @@ -172,7 +172,7 @@ helm install camunda camunda/camunda-platform--skip-crds -f values.yaml -f opens #### Helm 3.2.0 and greater -If you must deploy using Helm 3.2.0 or greater, you have two options. One is to use a SCCs which defines the `RunAsUser` strategy to be at least `RunAsAny`. If that's not possible, then you need to make use of [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering). This workaround is also described in detail in the [Helm chart repository](https://github.com/camunda/camunda-platform-helm/tree/main/openshift#using-a-post-renderer). +If you must deploy using Helm 3.2.0 or greater, you have two options. One is to use a SCCs which defines the `RunAsUser` strategy to be at least `RunAsAny`. If that's not possible, then you need to make use of [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering). This workaround is also described in detail in the [Helm chart repository](https://github.com/camunda/camunda-platform-helm/tree/main/charts/camunda-platform/openshift#post-renderer-setup). :::warning If using a post-renderer, you **must** use the post-renderer whenever you are updating your release, not only during the initial installation. If you do not, the default values will be used again, which will prevent some services from starting. @@ -208,7 +208,7 @@ You also need to use a custom values file, where instead of using `null` as a va Copy these values to your values file or save them as a separate file, e.g. `openshift.yaml`: :::note -These values are also available in the [Camunda Helm chart repository](https://github.com/camunda/camunda-platform-helm/blob/main/openshift/values-patch.yaml). +These values are also available in the [Camunda Helm chart repository](https://github.com/camunda/camunda-platform-helm/blob/main/charts/camunda-platform/openshift/values.yaml). ::: ```yaml diff --git a/versioned_docs/version-8.3/components/best-practices/development/service-integration-patterns.md b/versioned_docs/version-8.3/components/best-practices/development/service-integration-patterns.md index e367ad8978d..5c5e68ce69e 100644 --- a/versioned_docs/version-8.3/components/best-practices/development/service-integration-patterns.md +++ b/versioned_docs/version-8.3/components/best-practices/development/service-integration-patterns.md @@ -23,7 +23,7 @@ The following table gives a summary of the three options: | **Technical communication style** | Synchronous | Asynchronous | Asynchronous | | **Example** | HTTP | AMQP, JMS | AMQP, Apache Kafka | -You can dive more into communication styles in the webinar [Communication Between Loosely Coupled Microservices](https://page.camunda.com/wb-communication-between-microservices) ([slides](https://www.slideshare.net/BerndRuecker/webinar-communication-between-loosely-coupled-microservices), [recording](https://page.camunda.com/wb-communication-between-microservices) and [FAQ](https://medium.com/communication-between-loosely-coupled-microservices-webinar-faq-a02708b3c8b5)). +You can dive more into communication styles in the webinar [Communication Between Loosely Coupled Microservices](https://page.camunda.com/wb-communication-between-microservices) ([slides](https://www.slideshare.net/BerndRuecker/webinar-communication-between-loosely-coupled-microservices), [recording](https://page.camunda.com/wb-communication-between-microservices) and [FAQ](https://blog.bernd-ruecker.com/communication-between-loosely-coupled-microservices-webinar-faq-a02708b3c8b5)). ## Integrating services with BPMN tasks diff --git a/versioned_docs/version-8.3/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md b/versioned_docs/version-8.3/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md index b6d84169834..f047c917d25 100644 --- a/versioned_docs/version-8.3/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md +++ b/versioned_docs/version-8.3/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md @@ -171,7 +171,7 @@ helm install camunda camunda/camunda-platform --skip-crds -f values.yaml -f open #### Helm 3.2.0 and greater -If you must deploy using Helm 3.2.0 or greater, you have two options. One is to use a SCCs which defines the `RunAsUser` strategy to be at least `RunAsAny`. If that's not possible, then you need to make use of [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering). This workaround is also described in detail in the [Helm chart repository](https://github.com/camunda/camunda-platform-helm/tree/main/openshift#using-a-post-renderer). +If you must deploy using Helm 3.2.0 or greater, you have two options. One is to use a SCCs which defines the `RunAsUser` strategy to be at least `RunAsAny`. If that's not possible, then you need to make use of [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering). This workaround is also described in detail in the [Helm chart repository](https://github.com/camunda/camunda-platform-helm/tree/main/charts/camunda-platform/openshift#post-renderer-setup). :::warning If using a post-renderer, you **must** use the post-renderer whenever you are updating your release, not only during the initial installation. If you do not, the default values will be used again, which will prevent some services from starting. @@ -207,7 +207,7 @@ You also need to use a custom values file, where instead of using `null` as a va Copy these values to your values file or save them as a separate file, e.g. `openshift.yaml`: :::note -These values are also available in the [Camunda Helm chart repository](https://github.com/camunda/camunda-platform-helm/blob/main/openshift/values-patch.yaml). +These values are also available in the [Camunda Helm chart repository](https://github.com/camunda/camunda-platform-helm/blob/main/charts/camunda-platform/openshift/values.yaml). ::: ```yaml diff --git a/versioned_docs/version-8.4/components/best-practices/development/service-integration-patterns.md b/versioned_docs/version-8.4/components/best-practices/development/service-integration-patterns.md index e367ad8978d..5c5e68ce69e 100644 --- a/versioned_docs/version-8.4/components/best-practices/development/service-integration-patterns.md +++ b/versioned_docs/version-8.4/components/best-practices/development/service-integration-patterns.md @@ -23,7 +23,7 @@ The following table gives a summary of the three options: | **Technical communication style** | Synchronous | Asynchronous | Asynchronous | | **Example** | HTTP | AMQP, JMS | AMQP, Apache Kafka | -You can dive more into communication styles in the webinar [Communication Between Loosely Coupled Microservices](https://page.camunda.com/wb-communication-between-microservices) ([slides](https://www.slideshare.net/BerndRuecker/webinar-communication-between-loosely-coupled-microservices), [recording](https://page.camunda.com/wb-communication-between-microservices) and [FAQ](https://medium.com/communication-between-loosely-coupled-microservices-webinar-faq-a02708b3c8b5)). +You can dive more into communication styles in the webinar [Communication Between Loosely Coupled Microservices](https://page.camunda.com/wb-communication-between-microservices) ([slides](https://www.slideshare.net/BerndRuecker/webinar-communication-between-loosely-coupled-microservices), [recording](https://page.camunda.com/wb-communication-between-microservices) and [FAQ](https://blog.bernd-ruecker.com/communication-between-loosely-coupled-microservices-webinar-faq-a02708b3c8b5)). ## Integrating services with BPMN tasks diff --git a/versioned_docs/version-8.4/self-managed/platform-deployment/helm-kubernetes/platforms/amazon-eks/eks-helm.md b/versioned_docs/version-8.4/self-managed/platform-deployment/helm-kubernetes/platforms/amazon-eks/eks-helm.md index 52f0f83213d..ef07488d43e 100644 --- a/versioned_docs/version-8.4/self-managed/platform-deployment/helm-kubernetes/platforms/amazon-eks/eks-helm.md +++ b/versioned_docs/version-8.4/self-managed/platform-deployment/helm-kubernetes/platforms/amazon-eks/eks-helm.md @@ -121,7 +121,7 @@ helm upgrade --install \ [Cert-manager](https://cert-manager.io/) is an open-source Kubernetes add-on that automates the management and issuance of TLS certificates. It integrates with various certificate authorities (CAs) and provides a straightforward way to obtain, renew, and manage SSL/TLS certificates for your Kubernetes applications. -To simplify the installation process, it is [recommended](https://cert-manager.io/docs/setup/helm/#crd-installation-advice) to install the cert-manager `CustomResourceDefinition` resources before installing the chart. This separate step allows for easy uninstallation and reinstallation of cert-manager without deleting any custom resources that have been installed. +To simplify the installation process, it is [recommended](https://cert-manager.io/docs/installation/helm/#3-install-customresourcedefinitions) to install the cert-manager `CustomResourceDefinition` resources before installing the chart. This separate step allows for easy uninstallation and reinstallation of cert-manager without deleting any custom resources that have been installed. ```shell kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v$CERT_MANAGER_HELM_CHART_VERSION/cert-manager.crds.yaml diff --git a/versioned_docs/version-8.4/self-managed/platform-deployment/helm-kubernetes/platforms/amazon-eks/eksctl.md b/versioned_docs/version-8.4/self-managed/platform-deployment/helm-kubernetes/platforms/amazon-eks/eksctl.md index cfc5a2f7ce6..8cad92a25a7 100644 --- a/versioned_docs/version-8.4/self-managed/platform-deployment/helm-kubernetes/platforms/amazon-eks/eksctl.md +++ b/versioned_docs/version-8.4/self-managed/platform-deployment/helm-kubernetes/platforms/amazon-eks/eksctl.md @@ -14,7 +14,7 @@ This guide provides a user-friendly approach for setting up and managing Amazon - An [AWS account](https://docs.aws.amazon.com/accounts/latest/reference/accounts-welcome.html) is required to create resources within AWS. - [AWS CLI (2.11+)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html), a CLI tool for creating AWS resources. -- [eksctl (0.163+)](https://eksctl.io/setup/), a CLI tool for creating and managing Amazon EKS clusters. +- [eksctl (0.163+)](https://eksctl.io/getting-started/), a CLI tool for creating and managing Amazon EKS clusters. - [kubectl (1.28+)](https://kubernetes.io/docs/tasks/tools/#kubectl), a CLI tool to interact with the cluster. ## Considerations diff --git a/versioned_docs/version-8.4/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md b/versioned_docs/version-8.4/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md index b6d84169834..f047c917d25 100644 --- a/versioned_docs/version-8.4/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md +++ b/versioned_docs/version-8.4/self-managed/platform-deployment/helm-kubernetes/platforms/redhat-openshift.md @@ -171,7 +171,7 @@ helm install camunda camunda/camunda-platform --skip-crds -f values.yaml -f open #### Helm 3.2.0 and greater -If you must deploy using Helm 3.2.0 or greater, you have two options. One is to use a SCCs which defines the `RunAsUser` strategy to be at least `RunAsAny`. If that's not possible, then you need to make use of [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering). This workaround is also described in detail in the [Helm chart repository](https://github.com/camunda/camunda-platform-helm/tree/main/openshift#using-a-post-renderer). +If you must deploy using Helm 3.2.0 or greater, you have two options. One is to use a SCCs which defines the `RunAsUser` strategy to be at least `RunAsAny`. If that's not possible, then you need to make use of [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering). This workaround is also described in detail in the [Helm chart repository](https://github.com/camunda/camunda-platform-helm/tree/main/charts/camunda-platform/openshift#post-renderer-setup). :::warning If using a post-renderer, you **must** use the post-renderer whenever you are updating your release, not only during the initial installation. If you do not, the default values will be used again, which will prevent some services from starting. @@ -207,7 +207,7 @@ You also need to use a custom values file, where instead of using `null` as a va Copy these values to your values file or save them as a separate file, e.g. `openshift.yaml`: :::note -These values are also available in the [Camunda Helm chart repository](https://github.com/camunda/camunda-platform-helm/blob/main/openshift/values-patch.yaml). +These values are also available in the [Camunda Helm chart repository](https://github.com/camunda/camunda-platform-helm/blob/main/charts/camunda-platform/openshift/values.yaml). ::: ```yaml diff --git a/versioned_docs/version-8.5/components/best-practices/development/service-integration-patterns.md b/versioned_docs/version-8.5/components/best-practices/development/service-integration-patterns.md index e367ad8978d..5c5e68ce69e 100644 --- a/versioned_docs/version-8.5/components/best-practices/development/service-integration-patterns.md +++ b/versioned_docs/version-8.5/components/best-practices/development/service-integration-patterns.md @@ -23,7 +23,7 @@ The following table gives a summary of the three options: | **Technical communication style** | Synchronous | Asynchronous | Asynchronous | | **Example** | HTTP | AMQP, JMS | AMQP, Apache Kafka | -You can dive more into communication styles in the webinar [Communication Between Loosely Coupled Microservices](https://page.camunda.com/wb-communication-between-microservices) ([slides](https://www.slideshare.net/BerndRuecker/webinar-communication-between-loosely-coupled-microservices), [recording](https://page.camunda.com/wb-communication-between-microservices) and [FAQ](https://medium.com/communication-between-loosely-coupled-microservices-webinar-faq-a02708b3c8b5)). +You can dive more into communication styles in the webinar [Communication Between Loosely Coupled Microservices](https://page.camunda.com/wb-communication-between-microservices) ([slides](https://www.slideshare.net/BerndRuecker/webinar-communication-between-loosely-coupled-microservices), [recording](https://page.camunda.com/wb-communication-between-microservices) and [FAQ](https://blog.bernd-ruecker.com/communication-between-loosely-coupled-microservices-webinar-faq-a02708b3c8b5)). ## Integrating services with BPMN tasks diff --git a/versioned_docs/version-8.5/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.5/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md index ef6985b0b19..c0fcfd96fc3 100644 --- a/versioned_docs/version-8.5/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md +++ b/versioned_docs/version-8.5/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md @@ -121,7 +121,7 @@ helm upgrade --install \ [Cert-manager](https://cert-manager.io/) is an open-source Kubernetes add-on that automates the management and issuance of TLS certificates. It integrates with various certificate authorities (CAs) and provides a straightforward way to obtain, renew, and manage SSL/TLS certificates for your Kubernetes applications. -To simplify the installation process, it is [recommended](https://cert-manager.io/docs/setup/helm/#crd-installation-advice) to install the cert-manager `CustomResourceDefinition` resources before installing the chart. This separate step allows for easy uninstallation and reinstallation of cert-manager without deleting any custom resources that have been installed. +To simplify the installation process, it is [recommended](https://cert-manager.io/docs/installation/helm/#3-install-customresourcedefinitions) to install the cert-manager `CustomResourceDefinition` resources before installing the chart. This separate step allows for easy uninstallation and reinstallation of cert-manager without deleting any custom resources that have been installed. ```shell kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v$CERT_MANAGER_HELM_CHART_VERSION/cert-manager.crds.yaml diff --git a/versioned_docs/version-8.5/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md b/versioned_docs/version-8.5/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md index cfc5a2f7ce6..8cad92a25a7 100644 --- a/versioned_docs/version-8.5/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md +++ b/versioned_docs/version-8.5/self-managed/setup/deploy/amazon/amazon-eks/eksctl.md @@ -14,7 +14,7 @@ This guide provides a user-friendly approach for setting up and managing Amazon - An [AWS account](https://docs.aws.amazon.com/accounts/latest/reference/accounts-welcome.html) is required to create resources within AWS. - [AWS CLI (2.11+)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html), a CLI tool for creating AWS resources. -- [eksctl (0.163+)](https://eksctl.io/setup/), a CLI tool for creating and managing Amazon EKS clusters. +- [eksctl (0.163+)](https://eksctl.io/getting-started/), a CLI tool for creating and managing Amazon EKS clusters. - [kubectl (1.28+)](https://kubernetes.io/docs/tasks/tools/#kubectl), a CLI tool to interact with the cluster. ## Considerations diff --git a/versioned_docs/version-8.5/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.5/self-managed/setup/deploy/openshift/redhat-openshift.md index 49f2f0e3f65..13281a55513 100644 --- a/versioned_docs/version-8.5/self-managed/setup/deploy/openshift/redhat-openshift.md +++ b/versioned_docs/version-8.5/self-managed/setup/deploy/openshift/redhat-openshift.md @@ -169,7 +169,7 @@ helm install camunda camunda/camunda-platform --skip-crds -f values.yaml -f open #### Helm 3.2.0 and greater -If you must deploy using Helm 3.2.0 or greater, you have two options. One is to use a SCCs which defines the `RunAsUser` strategy to be at least `RunAsAny`. If that's not possible, then you need to make use of [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering). This workaround is also described in detail in the [Helm chart repository](https://github.com/camunda/camunda-platform-helm/tree/main/openshift#using-a-post-renderer). +If you must deploy using Helm 3.2.0 or greater, you have two options. One is to use a SCCs which defines the `RunAsUser` strategy to be at least `RunAsAny`. If that's not possible, then you need to make use of [a post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering). This workaround is also described in detail in the [Helm chart repository](https://github.com/camunda/camunda-platform-helm/tree/main/charts/camunda-platform/openshift#post-renderer-setup). :::warning If using a post-renderer, you **must** use the post-renderer whenever you are updating your release, not only during the initial installation. If you do not, the default values will be used again, which will prevent some services from starting. @@ -205,7 +205,7 @@ You also need to use a custom values file, where instead of using `null` as a va Copy these values to your values file or save them as a separate file, e.g. `openshift.yaml`: :::note -These values are also available in the [Camunda Helm chart repository](https://github.com/camunda/camunda-platform-helm/blob/main/openshift/values-patch.yaml). +These values are also available in the [Camunda Helm chart repository](https://github.com/camunda/camunda-platform-helm/blob/main/charts/camunda-platform/openshift/values.yaml). ::: ```yaml