Red Hat Developer Hub 1.7

Orchestrator flavor installation using Helm

Install, configure, and manage the Orchestrator flavor in Red Hat Developer Hub using Helm

Red Hat Customer Content Services

Abstract

As a Red Hat Developer Hub (RHDH) administrator, you can install and configure the Orchestrator flavor using Helm, ensuring your environment is prepared for workflow orchestration with Red Hat Developer Hub.

1. Installing Red Hat Developer Hub with Orchestrator using Helm
- 1.1. Resource requirements for air-gapped environments

1. Installing Red Hat Developer Hub with Orchestrator using Helm

You can install Red Hat Developer Hub with Orchestrator by using Helm, review resource requirements for Orchestrator, and plan for resource considerations in air-gapped environments.

1.1. Resource requirements for air-gapped environments

You can deploy the Orchestrator flavor of Red Hat Developer Hub in air-gapped environments by ensuring that all container images, and Helm charts required by Red Hat Developer Hub and SonataFlow are available internally.

For workflow orchestration in air-gapped environments, the following resources are recommended:

Resource component	Recommended resources
RHDH Orchestrator plugin	2 vCPUs, 2–4 GiB memory
SonataFlow runtime	1 vCPU, 1–2 GiB memory
Knative Serving and Eventing	1–2 vCPUs, 1.5 GiB memory
PostgreSQL or External DB	1 vCPU, 1 GiB memory
Persistent storage	5 GiB (minimum), adjust based on workflow logs and artifacts

To prepare for an air-gapped deployment, complete the following steps:

Mirror container images

Mirror all required {product-very-short}, SonataFlow, Knative, and orchestrator plugin images to an internal container registry. Ensure that the image versions match the Helm chart values.

Mirror Helm charts

Pre-download the Helm charts for `redhat-developer-hub`, `orchestrator-infra`, and any dependent charts (for example, `bitnami` and `backstage`). Host them in an internal chart repository or file server.

CRD and operator installation

Download the required CRDs and YAML manifests for SonataFlow and Knative operators and apply them manually.

Configure network policies

Validate inter-pod communication and ensure internal DNS resolution to the mirrored image registry.

Use imagePullSecrets

Update your `values.yaml` file with credentials for the internal registry if it is private:

   global:
     imagePullSecrets:
       - name: internal-registry-secret

Legal Notice

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.