Installing Red Hat Developer Hub on Amazon Elastic Kubernetes Service


Red Hat Developer Hub 1.3

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 Amazon Elastic Kubernetes Service (EKS) using either the Operator or Helm chart.

You can install Red Hat Developer Hub on Amazon Elastic Kubernetes Service (EKS) using one of the following methods:

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

1. Installing Developer Hub on EKS with the Operator

You can install the Red Hat Developer Hub Operator with or without the Operator Lifecycle Manager (OLM) framework.

Additonal resources

1.1. Installing the Developer Hub Operator with the OLM framework

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

Prerequisites

Procedure

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

    kubectl create namespace rhdh-operator
  2. 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.

  3. Create a CatalogSource resource that contains the Operators from the Red Hat Ecosystem:

    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.16
      secrets:
      - "rhdh-pull-secret"
      displayName: Red Hat Operators
    EOF
  4. Create an OperatorGroup resource as follows:

    cat <<EOF | kubectl apply -n rhdh-operator -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: rhdh-operator-group
    EOF
  5. Create a Subscription resource using the following code:

    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.3.0
    EOF
  6. 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, then you might need permissions 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:

    kubectl -n rhdh-operator patch deployment \
        rhdh.fast --patch '{"spec":{"template":{"spec":{"imagePullSecrets":[{"name":"rhdh-pull-secret"}]}}}}' \
        --type=merge
  7. Update the default configuration of the operator to ensure that Developer Hub resources can start correctly in EKS 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: |
          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: |
          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: |
          apiVersion: v1
          kind: Service
          spec:
           # NodePort is required for the ALB to route to the Service
            type: NodePort
      --- TRUNCATED ---
    5. Save and exit.

      Wait for a few minutes until the changes are automatically applied to the operator pods.

1.2. Installing the Developer Hub Operator without the OLM framework

Prerequisites

  • You have installed the following commands:

    • git
    • make
    • sed

Procedure

  1. Clone the Operator repository to your local machine using the following command:

    git clone --depth=1 https://github.com/redhat-developer/rhdh-operator.git rhdh-operator && cd rhdh-operator
  2. Run the following command and generate the deployment manifest:

    make deployment-manifest

    The previous command generates a file named rhdh-operator-<VERSION>.yaml, which is updated manually.

  3. Run the following command to apply replacements in the generated deployment manifest:

    sed -i "s/backstage-operator/rhdh-operator/g" rhdh-operator-*.yaml
    sed -i "s/backstage-system/rhdh-operator/g" rhdh-operator-*.yaml
    sed -i "s/backstage-controller-manager/rhdh-controller-manager/g" rhdh-operator-*.yaml
  4. Open the generated deployment manifest file in an editor and perform the following steps:

    1. 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: |
          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 ---
    2. Locate the deployment.yaml string and add the fsGroup to its specification, as shown in the following example:

        deployment.yaml: |
          apiVersion: apps/v1
          kind: Deployment
      --- TRUNCATED ---
          spec:
            securityContext:
              # You can assign any random value as fsGroup
              fsGroup: 3000
            automountServiceAccountToken: false
      --- TRUNCATED ---
    3. Locate the service.yaml string and change the type to NodePort as follows:

        service.yaml: |
          apiVersion: v1
          kind: Service
          spec:
            # NodePort is required for the ALB to route to the Service
            type: NodePort
      --- TRUNCATED ---
    4. Replace the default images with the images that are pulled from the Red Hat Ecosystem:

      sed -i "s#gcr.io/kubebuilder/kube-rbac-proxy:.*#registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.16#g" rhdh-operator-*.yaml
      
      sed -i "s#(quay.io/janus-idp/operator:.*|quay.io/rhdh-community/operator:.*)#registry.redhat.io/rhdh/rhdh-rhel9-operator:1.3#g" rhdh-operator-*.yaml
      
      sed -i "s#quay.io/janus-idp/backstage-showcase:.*#registry.redhat.io/rhdh/rhdh-hub-rhel9:1.3#g" rhdh-operator-*.yaml
      
      sed -i "s#quay.io/fedora/postgresql-15:.*#registry.redhat.io/rhel9/postgresql-15:latest#g" rhdh-operator-*.yaml
  5. Add the image pull secret to the manifest in the Deployment resource as follows:

    --- TRUNCATED ---
    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app.kubernetes.io/component: manager
        app.kubernetes.io/created-by: rhdh-operator
        app.kubernetes.io/instance: controller-manager
        app.kubernetes.io/managed-by: kustomize
        app.kubernetes.io/name: deployment
        app.kubernetes.io/part-of: rhdh-operator
        control-plane: controller-manager
      name: rhdh-controller-manager
      namespace: rhdh-operator
    spec:
      replicas: 1
      selector:
        matchLabels:
          control-plane: controller-manager
      template:
        metadata:
          annotations:
            kubectl.kubernetes.io/default-container: manager
          labels:
            control-plane: controller-manager
        spec:
          imagePullSecrets:
            - name: rhdh-pull-secret
    --- TRUNCATED ---
  6. Apply the manifest to deploy the operator using the following command:

    kubectl apply -f rhdh-operator-VERSION.yaml
  7. Run the following command to verify that the Operator is running:

    kubectl -n rhdh-operator get pods -w

1.3. Deploying the Developer Hub instance on EKS with the Operator

Prerequisites

Procedure

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

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: app-config-rhdh
    data:
      "app-config-rhdh.yaml": |
        app:
          title: Red Hat Developer Hub
          baseUrl: https://<rhdh_dns_name>
        backend:
          auth:
            externalAccess:
                - type: legacy
                  options:
                    subject: legacy-default-config
                    secret: "${BACKEND_SECRET}"
          baseUrl: https://<rhdh_dns_name>
          cors:
            origin: https://<rhdh_dns_name>
  2. Create a Secret named secrets-rhdh and add a key named BACKEND_SECRET with a Base64-encoded string as value:

    apiVersion: v1
    kind: Secret
    metadata:
      name: secrets-rhdh
    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:

    apiVersion: rhdh.redhat.com/v1alpha1
    kind: Backstage
    metadata:
     # TODO: this 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: "secrets-rhdh"
  5. Create an Ingress resource using the following template, ensuring to customize the names as needed:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      # TODO: this the name of your Developer Hub Ingress
      name: my-rhdh
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
    
        alb.ingress.kubernetes.io/target-type: ip
    
        # TODO: Using an ALB HTTPS Listener requires a certificate for your own domain. Fill in the ARN of your certificate, e.g.:
        alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-xxx:xxxx:certificate/xxxxxx
    
         alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    
        alb.ingress.kubernetes.io/ssl-redirect: '443'
    
        # TODO: Set your application domain name.
        external-dns.alpha.kubernetes.io/hostname: <rhdh_dns_name>
    
    spec:
      ingressClassName: alb
      rules:
        # TODO: Set your application domain name.
        - host: <rhdh_dns_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

    In the previous template, replace ` <rhdh_dns_name>` with your Developer Hub domain name and update the value of alb.ingress.kubernetes.io/certificate-arn with your certificate ARN.

Verification

Wait until the DNS name is responsive, indicating that your Developer Hub instance is ready for use.

2. Installing Developer Hub on EKS with the Helm chart

When you install the Developer Hub Helm chart in Elastic Kubernetes Service (EKS), it orchestrates the deployment of an Developer Hub instance, which provides a robust developer platform within the AWS ecosystem.

Prerequisites

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 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.

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

    global:
      # TODO: Set your application domain name.
      host: <your Developer Hub domain name>
    
    
    route:
      enabled: false
    
    
    upstream:
      service:
        # NodePort is required for the ALB to route to the Service
        type: NodePort
    
    
      ingress:
        enabled: true
        annotations:
          kubernetes.io/ingress.class: alb
    
    
          alb.ingress.kubernetes.io/scheme: internet-facing
    
    
          # TODO: Using an ALB HTTPS Listener requires a certificate for your own domain. Fill in the ARN of your certificate, e.g.:
          alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:xxx:xxxx:certificate/xxxxxx
    
    
          alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    
    
          alb.ingress.kubernetes.io/ssl-redirect: '443'
    
    
          # TODO: Set your application domain name.
          external-dns.alpha.kubernetes.io/hostname: <your rhdh domain name>
    
    
      backstage:
        image:
          pullSecrets:
          - rhdh-pull-secret
        podSecurityContext:
          # you can assign any random value as fsGroup
          fsGroup: 2000
      postgresql:
        image:
          pullSecrets:
          - rhdh-pull-secret
        primary:
          podSecurityContext:
            enabled: true
            # you can assign any random value as fsGroup
            fsGroup: 3000
      volumePermissions:
        enabled: true
  4. Run the following command in your terminal to deploy Developer Hub using the latest version of Helm Chart and using the values.yaml file created in the previous step:

    helm install rhdh \
      openshift-helm-charts/redhat-developer-hub \
      [--version 1.3.0] \
      --values /path/to/values.yaml
Note

Verification

Wait until the DNS name is responsive, indicating that your Developer Hub instance is ready for use.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.