Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 2. Red Hat Developer Hub default configuration

You can deploy a standard Red Hat Developer Hub (RHDH) instance, understand the structure, and tailor RHDH instance to meet your needs.

2.1. Red Hat Developer Hub default configuration guide
Copia collegamento

The Red Hat Developer Hub (RHDH) Operator creates a set of Kubernetes resources to deploy and manage a Backstage instance. The default configuration for these default resources is defined at the Operator level and can be customized for a specific instance using the Backstage Custom Resource (CR). This approach provides a clear starting point while offering flexibility to tailor each deployment.

The default configuration is stored in a ConfigMap named rhdh-default-config located in the rhdh-operator namespace on OpenShift. This ConfigMap contains the YAML manifests that define the foundational structure of the RHDH instance.

You can create a basic RHDH instance by applying an empty Backstage Custom Resource as follows:

Example creating a RHDH instance

apiVersion: backstage.redhat.com/v1alpha4
kind: Backstage
metadata:
name: my-rhdh-instance
namespace: rhdh
Copy to Clipboard Toggle word wrap

The Operator automatically creates the following resources in the specified RHDH namespace by default based on the default configuration:

Expand
Table 2.1. Floating action button parameters
File NameResource GVKResource NameDescription

deployment.yaml

apps/v1/Deployment

backstage-{cr-name}

(Mandatory) The main Backstage application deployment.

service.yaml

v1/Service

backstage-{cr-name}

(Mandatory) The Backstage application service.

db-statefulset.yaml

apps/v1/StatefulSet

backstage-psql-{cr-name}

The PostgreSQL database stateful set. Needed if spec.enabledDb=true.

db-service.yaml

v1/Service

backstage-psql-{cr-name}

The PostgreSQL database service. Needed if spec.enabledDb=true.

db-secret.yaml

v1/Secret

backstage-psql-{cr-name}

The PostgreSQL database credentials secret. Needed if spec.enabledDb=true.

route.yaml

route.openshift.io/v1

backstage-{cr-name}

The OpenShift Route to expose Backstage externally. (Optional) Applied to Openshift only.

app-config.yaml

v1/ConfigMap

backstage-config-{cr-name}

(Optional) Specifies one or more Backstage app-config.yaml files.

configmap-files.yaml

v1/ConfigMap

backstage-files-{cr-name}

(Optional) Specifies additional ConfigMaps to be mounted as files into Backstage Pod.

configmap-envs.yaml

v1/ConfigMap

backstage-envs-{cr-name}

(Optional) Specifies additional ConfigMaps to be exposed as environment variables into Backstage Pod.

secret-files.yaml

v1/Secret or list of v1/Secret

backstage-files-{cr-name}-{secret-name}

(Optional) Specifies additional Secrets to be mounted as files into Backstage Pod.

secret-envs.yaml

v1/Secret or list of v1/Secret

backstage-envs-{cr-name}

(Optional) Specifies additional Secrets to be exposed as environment variables into Backstage Pod.

dynamic-plugins.yaml

v1/ConfigMap

backstage-dynamic-plugins-{cr-name}

(Optional) Specifies the dynamic plugins that the Operator installs into the Backstage instance.

pvcs.yaml

list of v1/PersistentVolumeClaim

backstage-{cr-name}-{pvc-name}

(Optional) The Persistent Volume Claim for PostgreSQL database.

Note

{cr-name} is the name of the Backstage Custom Resource, for example 'my-rhdh-instance' in the above example.

2.2. Automated Operator features
Copia collegamento

You can use the Operator to automate several key processes to effectively configure your Backstage application.

2.2.1. Metadata generation
Copia collegamento

The Operator automatically generates specific metadata values for all default resources at runtime to ensure your Backstage application functions properly.

For all the default resources, metadata.name is generated according to the rules defined in the Default Configuration files, particularly the Resource name column. For example, Backstage Custom Resource (CR) named mybackstage creates Kubernetes Deployment resource called backstage-mybackstage.

The following metadata is generated for each resource:

  • deployment.yaml

    • spec.selector.matchLabels[rhdh.redhat.com/app] = backstage-{cr-name}
    • spec.template.metadata.labels[rhdh.redhat.com/app] = backstage-{cr-name}

  • service.yaml

    • spec.selector[rhdh.redhat.com/app] = backstage-{cr-name}

  • db-statefulset.yaml

    • spec.selector.matchLabels[rhdh.redhat.com/app] = backstage-psql-{cr-name}
    • spec.template.metadata.labels[rhdh.redhat.com/app] = backstage-psql-{cr-name}

  • db-service.yaml

    • spec.selector[rhdh.redhat.com/app] = backstage-psql-{cr-name}

2.2.2. Multiple resources
Copia collegamento

You can define and create multiple resources of the same type in a single YAML file. This is applicable to any resource type that is a list in the resource table. To define multiple resources, use the --- delimiter to separate each resource definition.

For example, adding the following code snip to pvcs.yaml creates two PersistentVolumeClaims (PVCs) called backstage-{cr-name}-myclaim1 and backstage-{cr-name}-myclaim2 and mounts them to the Backstage container accordingly.

Example creating multiple PVCs

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim1
...
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim2
...
Copy to Clipboard Toggle word wrap

2.2.3. Default base URLs
Copia collegamento

The Operator automatically sets the base URLs for your Backstage application in the default app-config ConfigMap known as backstage-appconfig-{CR_name}. The Operator does so based on your Route parameters and the OpenShift cluster ingress domain.

The Operator follows these rules to set the base URLs for your application:

The Operator updates the following base URLs in the default app-config ConfigMap:

  • app.baseUrl
  • backend.baseUrl
  • backend.cors.origin
Note

You can perform these actions on a best-effort basis and only on OpenShift. During an error or on non-OpenShift clusters, you can still override these defaults by providing a custom app-config ConfigMap.

2.3. Mounts for default Secrets and Persistent Volume Claims (PVCs)
Copia collegamento

You can use annotations to configure mount paths and specify containers for Secrets and Persistent Volume Claims (PVCs) that are attached to the Operator default resources in your Red Hat Developer Hub deployment. This method is specific for default objects, for instance, the Backstage Deployment that the Operator manages.

By default, the mount path is /opt/app-root/src. To specify a different path, add the rhdh.redhat.com/mount-path annotation to your resource.

Procedure

  1. To specify a PVC mount path, add the rhdh.redhat.com/mount-path annotation to your configuration file as shown in the following example:

    Example specifying the PVC mount path

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: <my_claim> # Specifies the PVC to mount
  annotations:
    # Specifies which mount path the PVC mounts to (in this case, /mount/path/from/annotation directory)
    rhdh.redhat.com/mount-path: /mount/path/from/annotation
    Copy to Clipboard Toggle word wrap

  2. To specify a Secret mount path, add the rhdh.redhat.com/mount-path annotation to your configuration file as shown in the following example:

    Example specifying where the Secret mounts

    apiVersion: v1
kind: Secret
metadata:
  name: <my_secret> # Specifies the Secret name
  annotations:
    rhdh.redhat.com/mount-path: /mount/path/from/annotation
    Copy to Clipboard Toggle word wrap

2.3.2. Mounting Secrets and PVCs to specific containers
Copia collegamento

By default, Secrets and PVCs mount only to the Red Hat Developer Hub backstage-backend container. You can add the rhdh.redhat.com/containers annotation to your configuration file to specify the containers to mount to.

Procedure

  1. To mount Secrets to all containers, set the rhdh.redhat.com/containers annotation to * in your configuration file:

    Example mounting to all containers

    apiVersion: v1
kind: Secret
metadata:
  name: <my_secret>
  annotations:
    rhdh.redhat.com/containers: *
    Copy to Clipboard Toggle word wrap

    Important

    Set rhdh.redhat.com/containers to * to mount it to all containers in the deployment.

  2. To mount to specific containers, separate the names with commas:

    Example separating the list of containers

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: <my_claim>
  annotations:
    rhdh.redhat.com/containers: "init-dynamic-plugins,backstage-backend"
    Copy to Clipboard Toggle word wrap

    Note

    This configuration mounts the <my_claim> PVC to the init-dynamic-plugins and backstage-backend containers.

Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat