Red Hat Developer Hub 1.4

Installing Red Hat Developer Hub on Google Kubernetes Engine

Red Hat Customer Content Services

Abstract

Red Hat Developer Hub is an enterprise-grade platform for building developer portals. Administrative users can configure roles, permissions, and other settings to enable other authorized users to deploy a Developer Hub instance on Google Kubernetes Engine (GKE) using either the Operator or Helm chart.

You can install Red Hat Developer Hub on Google Kubernetes Engine (GKE) using one of the following methods:

  • The Red Hat Developer Hub Operator
  • The Red Hat Developer Hub Helm chart

1. Installing the Developer Hub Operator with the OLM framework

You can install the Developer Hub Operator on GKE using the Operator Lifecycle Manager (OLM) framework. Following that, you can proceed to deploy your Developer Hub instance in GKE.

For information about the OLM, see Operator Lifecycle Manager(OLM) documentation.

Prerequisites

Procedure

  1. Connect to your GKE cluster using the following command:

    gcloud container clusters get-credentials <cluster-name> \ 1
        --location=<cluster-location> 2
    1
    Enter your GKE cluster name.
    2
    Enter your GKE cluster location.

    This command configures your Kubernetes client to point to your GKE cluster.

  2. Run the following command in your terminal to create the rhdh-operator namespace where the Operator is installed:

    kubectl create namespace rhdh-operator
  3. Create a pull secret using the following command:

    kubectl -n rhdh-operator create secret docker-registry rhdh-pull-secret \
        --docker-server=registry.redhat.io \
        --docker-username=<user_name> \ 1
        --docker-password=<password> \ 2
        --docker-email=<email> 3
    1
    Enter your username in the command.
    2
    Enter your password in the command.
    3
    Enter your email address in the command.

    The created pull secret is used to pull the Developer Hub images from the Red Hat Ecosystem.

  4. Create a CatalogSource resource that contains the Operator from the Red Hat Ecosystem:

    Example CatalogSource resource

    cat <<EOF | kubectl -n rhdh-operator apply -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: redhat-catalog
    spec:
      sourceType: grpc
      image: registry.redhat.io/redhat/redhat-operator-index:v4.17
      secrets:
      - "rhdh-pull-secret"
      displayName: Red Hat Operators
    EOF

  5. Create an OperatorGroup resource as follows:

    Example OperatorGroup resource

    cat <<EOF | kubectl apply -n rhdh-operator -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: rhdh-operator-group
    EOF

  6. Create a Subscription resource using the following code:

    Example Subscription resource

    cat <<EOF | kubectl apply -n rhdh-operator -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: rhdh
      namespace: rhdh-operator
    spec:
      channel: fast
      installPlanApproval: Automatic
      name: rhdh
      source: redhat-catalog
      sourceNamespace: rhdh-operator
      startingCSV: rhdh-operator.v1.4.0
    EOF

  7. Run the following command to verify that the created Operator is running:

    kubectl -n rhdh-operator get pods -w

    If the Operator pod shows ImagePullBackOff status, you might need permission to pull the image directly within the Operator deployment’s manifest.

    Tip

    You can include the required secret name in the deployment.spec.template.spec.imagePullSecrets list and verify the deployment name using kubectl get deployment -n rhdh-operator command. For example:

    kubectl -n rhdh-operator patch deployment \
        rhdh.fast --patch '{"spec":{"template":{"spec":{"imagePullSecrets":[{"name":"rhdh-pull-secret"}]}}}}' \
        --type=merge
  8. Update the default configuration of the Operator to ensure that Developer Hub resources can start correctly in GKE using the following steps:

    1. Edit the backstage-default-config ConfigMap in the rhdh-operator namespace using the following command:

      kubectl -n rhdh-operator edit configmap backstage-default-config
    2. Locate the db-statefulset.yaml string and add the fsGroup to its spec.template.spec.securityContext, as shown in the following example:

      db-statefulset.yaml fragment

        db-statefulset.yaml: |
          apiVersion: apps/v1
          kind: StatefulSet
      --- TRUNCATED ---
          spec:
          --- TRUNCATED ---
            restartPolicy: Always
            securityContext:
            # You can assign any random value as fsGroup
              fsGroup: 2000
            serviceAccount: default
            serviceAccountName: default
      --- TRUNCATED ---

    3. Locate the deployment.yaml string and add the fsGroup to its specification, as shown in the following example:

      deployment.yaml fragment

        deployment.yaml: |
          apiVersion: apps/v1
          kind: Deployment
      --- TRUNCATED ---
          spec:
            securityContext:
              # You can assign any random value as fsGroup
              fsGroup: 3000
            automountServiceAccountToken: false
      --- TRUNCATED ---

    4. Locate the service.yaml string and change the type to NodePort as follows:

      service.yaml fragment

        service.yaml: |
          apiVersion: v1
          kind: Service
          spec:
           # NodePort is required for the ALB to route to the Service
            type: NodePort
      --- TRUNCATED ---

    5. Save and exit.

      Wait until the changes are automatically applied to the Operator pods.

1.1. Deploying the Developer Hub instance on GKE with the Operator

You can deploy your Developer Hub instance in GKE using the Operator.

Prerequisites

  • A cluster administrator has installed the Red Hat Developer Hub Operator.
  • You have subscribed to registry.redhat.io. For more information, see Red Hat Container Registry Authentication.
  • You have installed kubectl. For more information, see Install kubetl.
  • You have configured a domain name for your Developer Hub instance.
  • You have reserved a static external Premium IPv4 Global IP address that is not attached to any virtual machine (VM). For more information see Reserve a new static external IP address
  • You have configured the DNS records for your domain name to point to the IP address that has been reserved.

    Note

    You need to create an A record with the value equal to the IP address. This process can take up to one hour to propagate.

Procedure

  1. Create a ConfigMap named app-config-rhdh containing the Developer Hub configuration using the following template:

    app-config-rhdh.yaml fragment

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: app-config-rhdh
    data:
      "app-config-rhdh.yaml": |
        app:
          title: Red Hat Developer Hub
          baseUrl: https://<rhdh_domain_name>
        backend:
          auth:
            externalAccess:
                - type: legacy
                  options:
                    subject: legacy-default-config
                    secret: "${BACKEND_SECRET}"
          baseUrl: https://<rhdh_domain_name>
          cors:
            origin: https://<rhdh_domain_name>

  2. Create a Secret named my-rhdh-secrets and add a key named BACKEND_SECRET with a Base64-encoded string as value:

    my-rhdh-secrets fragment

    apiVersion: v1
    kind: Secret
    metadata:
      name: my-rhdh-secrets
    stringData:
      # TODO: See https://backstage.io/docs/auth/service-to-service-auth/#setup
      BACKEND_SECRET: "xxx"

    Important

    Ensure that you use a unique value of BACKEND_SECRET for each Developer Hub instance.

    You can use the following command to generate a key:

    node-p'require("crypto").randomBytes(24).toString("base64")'
  3. To enable pulling the PostgreSQL image from the Red Hat Ecosystem Catalog, add the image pull secret in the default service account within the namespace where the Developer Hub instance is being deployed:

    kubectl patch serviceaccount default \
        -p '{"imagePullSecrets": [{"name": "rhdh-pull-secret"}]}' \
        -n <your_namespace>
  4. Create a Custom Resource file using the following template:

    Custom Resource fragment

    apiVersion: rhdh.redhat.com/v1alpha3
    kind: Backstage
    metadata:
      # This is the name of your Developer Hub instance
      name: my-rhdh
    spec:
      application:
        imagePullSecrets:
        - "rhdh-pull-secret"
        route:
          enabled: false
        appConfig:
          configMaps:
            - name: "app-config-rhdh"
        extraEnvs:
          secrets:
            - name: "my-rhdh-secrets"

  5. Set up a Google-managed certificate by creating a ManagedCertificate object which you must attach to the Ingress.

    Example of a ManagedCertificate object

    apiVersion: networking.gke.io/v1
    kind: ManagedCertificate
    metadata:
      name: <rhdh_certificate_name>
    spec:
      domains:
        - <rhdh_domain_name>

    For more information about setting up a Google-managed certificate, see Setting up a Google-managed certificate.

  6. Create a FrontendConfig object to set a policy for redirecting to HTTPS. You must attach this policy to the Ingress.

    Example of a FrontendConfig object

    apiVersion: networking.gke.io/v1beta1
    kind: FrontendConfig
    metadata:
      name: <ingress_security_config>
    spec:
      sslPolicy: gke-ingress-ssl-policy-https
      redirectToHttps:
        enabled: true

    For more information about setting a policy to redirect to HTTPS, see HTTP to HTTPS redirects.

  7. Create an ingress resource using the following template, customizing the names as needed:

    Example of an ingress resource configuration

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      # TODO: this the name of your Developer Hub Ingress
      name: my-rhdh
      annotations:
        # If the class annotation is not specified it defaults to "gce".
        kubernetes.io/ingress.class: "gce"
        kubernetes.io/ingress.global-static-ip-name: <ADDRESS_NAME>
        networking.gke.io/managed-certificates: <rhdh_certificate_name>
        networking.gke.io/v1beta1.FrontendConfig: <ingress_security_config>
    spec:
      ingressClassName: gce
      rules:
        # TODO: Set your application domain name.
        - host: <rhdh_domain_name>
          http:
            paths:
            - path: /
              pathType: Prefix
              backend:
                service:
                  # TODO: my-rhdh is the name of your Backstage Custom Resource.
                  # Adjust if you changed it!
                  name: backstage-my-rhdh
                  port:
                    name: http-backend

Verification

  • Wait for the ManagedCertificate to be provisioned. This process can take a couple of hours.
  • Access RHDH with https://<rhdh_domain_name>

Additional information

For more information on setting up GKE using Ingress with TLS, see Secure GKE Ingress.

2. Installing Developer Hub on GKE with the Helm chart

When you install the Developer Hub Helm chart in Google Kubernetes Engine (GKE), it orchestrates the deployment of a Developer Hub instance, which provides a robust developer platform within the GKE ecosystem.

Prerequisites

  • You have subscribed to registry.redhat.io. For more information, see Red Hat Container Registry Authentication.
  • You have installed kubectl. For more information, see Install kubetl.
  • You have installed the Google Cloud CLI. For more information, see Install the gcloud CLI.
  • You have logged in to your Google account and created a GKE Autopilot or GKE Standard cluster.
  • You have configured a domain name for your Developer Hub instance.
  • You have reserved a static external Premium IPv4 Global IP address that is not attached to any VM. For more information see Reserve a new static external IP address
  • You have configured the DNS records for your domain name to point to the IP address that has been reserved.

    Note

    You need to create an A record with the value equal to the IP address. This process can take up to one hour to propagate.

  • You have installed Helm 3 or the latest. For more information, see Installing Helm.

Procedure

  1. Go to your terminal and run the following command to add the Helm chart repository containing the Developer Hub chart to your local Helm registry:

    helm repo add openshift-helm-charts https://charts.openshift.io/
  2. Create a pull secret using the following command:

    kubectl -n <your-namespace> create secret docker-registry rhdh-pull-secret \ 1
        --docker-server=registry.redhat.io \
        --docker-username=<user_name> \ 2
        --docker-password=<password> \ 3
        --docker-email=<email> 4
    1
    Enter your GKE namespace in the command.
    2
    Enter your username in the command.
    3
    Enter your password in the command.
    4
    Enter your email address in the command.

    The created pull secret is used to pull the Developer Hub images from the Red Hat Ecosystem.

  3. Set up a Google-managed certificate by creating a ManagedCertificate object that you must attach to the ingress.

    Example of attaching a ManagedCertificate object to the ingress

    apiVersion: networking.gke.io/v1
    kind: ManagedCertificate
    metadata:
      name: <rhdh_certificate_name>
    spec:
      domains:
        - <rhdh_domain_name>

    For more information about setting up a Google-managed certificate, see Setting up a Google-managed certificate.

  4. Create a FrontendConfig object to set a policy for redirecting to HTTPS. You must attach this policy to the ingress.

    Example of attaching a FrontendConfig object to the ingress

    apiVersion: networking.gke.io/v1beta1
    kind: FrontendConfig
    metadata:
      name: <ingress_security_config>
    spec:
      sslPolicy: gke-ingress-ssl-policy-https
      redirectToHttps:
        enabled: true

    For more information about setting a policy to redirect to HTTPS, see HTTP to HTTPS redirects.

  5. Create a file named values.yaml using the following template:

    Example values.yaml file

    global:
      host: <rhdh_domain_name>
    route:
      enabled: false
    upstream:
      service:
        type: NodePort
      ingress:
        enabled: true
        annotations:
          kubernetes.io/ingress.class: gce
          kubernetes.io/ingress.global-static-ip-name: <ADDRESS_NAME>
          networking.gke.io/managed-certificates: <rhdh_certificate_name>
          networking.gke.io/v1beta1.FrontendConfig: <ingress_security_config>
        className: gce
      backstage:
        image:
          pullSecrets:
          - rhdh-pull-secret
        podSecurityContext:
          fsGroup: 2000
      postgresql:
        image:
          pullSecrets:
          - rhdh-pull-secret
        primary:
          podSecurityContext:
            enabled: true
            fsGroup: 3000
      volumePermissions:
        enabled: true

  6. Run the following command in your terminal to deploy Developer Hub using the latest version of Helm Chart and using the values.yaml file:

    helm -n <your_namespace> install -f values.yaml <your_deploy_name> \
      openshift-helm-charts/redhat-developer-hub \
      --version 1.4.0

    For the latest Helm Chart version, see this Helm Charts repository.

Verification

  • Confirm that the deployment is complete.

    kubectl get deploy <you_deploy_name>-developer-hub -n <your_namespace>
  • Verify that the service and ingress were created.

    kubectl get service -n <your_namespace>
    kubectl get ingress -n <your_namespace>
    Note

    Wait for the ManagedCertificate to be provisioned. This process can take a couple of hours.

  • Access RHDH with https://<rhdh_domain_name>
  • To upgrade your deployment, use the following command:

    helm -n <your_namespace> upgrade -f values.yaml <your_deploy_name> openshift-helm-charts/redhat-developer-hub --version <UPGRADE_CHART_VERSION>
  • To delete your deployment, use the following command:

    helm -n <your_namespace> delete <your_deploy_name>

Legal Notice

Copyright © 2024 Red Hat, Inc.
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.