Installing Red Hat Developer Hub on Amazon Elastic Kubernetes Service (EKS)
Running Red Hat Developer Hub on Amazon Elastic Kubernetes Service (EKS) by using either the Operator or Helm chart
Abstract
- 1. Installing Developer Hub on Amazon Elastic Kubernetes Service (EKS) by using the Operator
- 1.1. Installing the Developer Hub Operator on Amazon Elastic Kubernetes Service (EKS) by using the OLM framework
- 1.2. Provisioning your custom Red Hat Developer Hub configuration
- 1.3. Provision your Red Hat Ecosystem pull secret to your Red Hat Developer Hub instance namespace
- 1.4. Using the Red Hat Developer Hub Operator to run Developer Hub with your custom configuration
- 1.5. Exposing your operator-based Red Hat Developer Hub instance on Amazon Elastic Kubernetes Service (EKS)
- 2. Installing Developer Hub on EKS with the Helm chart
Red Hat Developer Hub (RHDH) 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 RHDH instance on Amazon Elastic Kubernetes Service (EKS) using either the Operator or Helm chart.
1. Installing Developer Hub on Amazon Elastic Kubernetes Service (EKS) by using the Operator
To benefit from over-the-air updates and catalogs provided by Operator-based applications distributed with the Operator Lifecycle Manager (OLM) framework, consider installing Red Hat Developer Hub by using the Red Hat Developer Hub Operator distributed in the Red Hat Ecosystem.
On EKS, the most notable differences over an OpenShift-based installation are:
- The OLM framework and the Red Hat Ecosystem are not built-in.
- The Red Hat Ecosystem pull-secret is not managed globally.
- To expose the application, Ingresses replace OpenShift Routes.
For clarity, the content is broken down in sections highlighting these platform-specific additional steps.
1.1. Installing the Developer Hub Operator on Amazon Elastic Kubernetes Service (EKS) by using the OLM framework
The Red Hat Ecosystem, based on the Operator Lifecycle Manager (OLM) framework, contains a distribution of the Red Hat Developer Hub Operator, aimed at managing your Red Hat Developer Hub instance lifecycle.
However, on Amazon Elastic Kubernetes Service (EKS):
- The Operator Lifecycle Manager (OLM) framework and the Red Hat Ecosystem are not built-in.
- The Red Hat Ecosystem pull-secret is not managed globally.
Therefore, install the OLM framework, the Red Hat Ecosystem, and provision your Red Hat Ecosystem pull secret to install Developer Hub Operator.
Prerequisites
-
You have installed the
kubectl
CLI on your local environment. - Your system meets the sizing requirements for Red Hat Developer Hub.
- You have installed the Operator Lifecycle Manager (OLM).
Your credentials to the Red Hat Container Registry:
- <redhat_user_name>
- <redhat_password>
- <email>
-
You have set the context to the EKS cluster in your current
kubeconfig
. For more information, see Creating or updating a kubeconfig file for an Amazon EKS cluster.
Procedure
Create the
rhdh-operator
namespace to contain the Red Hat Developer Hub Operator:$ kubectl create namespace rhdh-operator
Create a pull secret using your Red Hat credentials to pull the container images from the protected Red Hat Ecosystem:
$ kubectl -n rhdh-operator create secret docker-registry rhdh-pull-secret \ --docker-server=registry.redhat.io \ --docker-username=<redhat_user_name> \ --docker-password=<redhat_password> \ --docker-email=<email>
Create a catalog source that contains the Red Hat Ecosystem Operators:
$ 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.18 secrets: - "rhdh-pull-secret" displayName: Red Hat Operators EOF
Create an operator group to manage your operator subscriptions:
$ cat <<EOF | kubectl apply -n rhdh-operator -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: rhdh-operator-group EOF
Create a subscription to install the Red Hat Developer Hub Operator:
$ 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.7.0 EOF
To wait until the Operator deployment finishes to be able to run the next step, run:
until kubectl -n rhdh-operator get deployment rhdh-operator &>/dev/null; do echo -n . sleep 3 done echo "RHDH Operator Deployment created"
Include your pull secret name in the Operator deployment manifest, to avoid
ImagePullBackOff
errors:$ kubectl -n rhdh-operator patch deployment \ rhdh-operator --patch '{"spec":{"template":{"spec":{"imagePullSecrets":[{"name":"rhdh-pull-secret"}]}}}}' \ --type=merge
Verification
Verify the deployment name:
$ kubectl get deployment -n rhdh-operator
1.2. Provisioning your custom Red Hat Developer Hub configuration
To configure Red Hat Developer Hub, provision your custom Red Hat Developer Hub config maps and secrets to Amazon Elastic Kubernetes Service (EKS) before running Red Hat Developer Hub.
On Red Hat OpenShift Container Platform, you can skip this step to run Developer Hub with the default config map and secret. Your changes on this configuration might get reverted on Developer Hub restart.
Prerequisites
- By using the Kubernetes CLI ('kubectl'), you have access, with developer permissions, to the Kubernetes cluster aimed at containing your Developer Hub instance.
Procedure
Author your custom
<my_product_secrets>.txt
file to provision your secrets as environment variables values in a Kubernetes secret, rather than in clear text in your configuration files. It contains one secret per line inKEY=value
form.Author your custom
app-config.yaml
file. This is the main Developer Hub configuration file. You need a customapp-config.yaml
file to avoid the Developer Hub installer to revert user edits during upgrades. When your customapp-config.yaml
file is empty, Developer Hub is using default values.- To prepare a deployment with the Red Hat Developer Hub Operator on EKS, you can start with an empty file.
To prepare a deployment with the Red Hat Developer Hub Helm chart, or on Kubernetes, enter the Developer Hub base URL in the relevant fields in your
app-config.yaml
file to ensure proper functionality of Developer Hub. The base URL is what a Developer Hub user sees in their browser when accessing Developer Hub. The relevant fields arebaseUrl
in theapp
andbackend
sections, andorigin
in thebackend.cors
subsection:Example 1. Configuring the
baseUrl
inapp-config.yaml
app: title: Red Hat Developer Hub baseUrl: https://<my_developer_hub_domain> backend: auth: externalAccess: - type: legacy options: subject: legacy-default-config secret: "${BACKEND_SECRET}" baseUrl: https://<my_developer_hub_domain> cors: origin: https://<my_developer_hub_domain>
Optionally, enter your configuration such as:
Provision your custom configuration files to your EKS cluster.
Create the <my-rhdh-project> {namespace} aimed at containing your Developer Hub instance.
$ oc create namespace my-rhdh-project
Provision your
app-config.yaml
file to themy-rhdh-app-config
config map in the <my-rhdh-project> project.$ oc create configmap my-rhdh-app-config --from-file=app-config.yaml --namespace=my-rhdh-project
Provision your
<my_product_secrets>.txt
file to the<my_product_secrets>
secret in the <my-rhdh-project> project.$ oc create secret generic
<my_product_secrets>
--from-file=<my_product_secrets>.txt
--namespace=my-rhdh-project
Next steps
- To use an external PostgreSQL database, provision your PostgreSQL database secrets.
- To enable dynamic plugins, provision your dynamic plugins config map.
- To configure authorization by using external files, provision your RBAC policies config map.
1.3. Provision your Red Hat Ecosystem pull secret to your Red Hat Developer Hub instance namespace
On Amazon Elastic Kubernetes Service (EKS), the Red Hat Ecosystem pull-secret is not managed globally. Therefore add your pull-secret in your Red Hat Developer Hub instance namespace.
Prerequisites
Your credentials to the Red Hat Container Registry:
- <redhat_user_name>
- <redhat_password>
- <email>
-
You created the
{my-rhdh-project}
namespace on EKS to host your Developer Hub instance.
Procedure
Create a pull secret using your Red Hat credentials to pull the container images from the protected Red Hat Ecosystem:
$ kubectl -n {my-rhdh-namespace} create secret docker-registry my-rhdh-pull-secret \ --docker-server=registry.redhat.io \ --docker-username=<redhat_user_name> \ --docker-password=<redhat_password> \ --docker-email=<email>
To enable pulling Developer Hub images 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": "my-rhdh-pull-secret"}]}' \ -n {my-rhdh-namespace}
1.4. Using the Red Hat Developer Hub Operator to run Developer Hub with your custom configuration
To use the Developer Hub Operator to run Red Hat Developer Hub with your custom configuration, create your Backstage custom resource (CR) that:
- Mounts files provisioned in your custom config maps.
- Injects environment variables provisioned in your custom secrets.
Prerequisites
- By using the Kubernetes CLI ('kubectl'), you have access, with developer permissions, to the EKS cluster aimed at containing your Developer Hub instance.
- Your administrator has installed the Red Hat Developer Hub Operator in the cluster.
-
You have provisioned your custom config maps and secrets in your
<my-rhdh-project>
project.
Procedure
Author your Backstage CR in a
my-rhdh-custom-resource.yaml
file to use your custom config maps and secrets.Minimal
my-rhdh-custom-resource.yaml
custom resource example:apiVersion: rhdh.redhat.com/v1alpha3 kind: Backstage metadata: name: my-rhdh-custom-resource spec: application: appConfig: mountPath: /opt/app-root/src configMaps: - name: my-rhdh-app-config extraEnvs: secrets: - name: <my_product_secrets> extraFiles: mountPath: /opt/app-root/src route: enabled: true database: enableLocalDb: true
my-rhdh-custom-resource.yaml
custom resource example with dynamic plugins and RBAC policies config maps, and external PostgreSQL database secrets:apiVersion: rhdh.redhat.com/v1alpha3 kind: Backstage metadata: name: <my-rhdh-custom-resource> spec: application: appConfig: mountPath: /opt/app-root/src configMaps: - name: my-rhdh-app-config - name: rbac-policies dynamicPluginsConfigMapName: dynamic-plugins-rhdh extraEnvs: secrets: - name: <my_product_secrets> - name: my-rhdh-database-secrets extraFiles: mountPath: /opt/app-root/src secrets: - name: my-rhdh-database-certificates-secrets key: postgres-crt.pem, postgres-ca.pem, postgres-key.key route: enabled: true database: enableLocalDb: false
- Mandatory fields
- No fields are mandatory. You can create an empty Backstage CR and run Developer Hub with the default configuration.
- Optional fields
spec.application.appConfig.configMaps
- Enter your config map name list.
Mount files in the
my-rhdh-app-config
config map:spec: application: appConfig: mountPath: /opt/app-root/src configMaps: - name: my-rhdh-app-config
Mount files in the
my-rhdh-app-config
andrbac-policies
config maps:spec: application: appConfig: mountPath: /opt/app-root/src configMaps: - name: my-rhdh-app-config - name: rbac-policies
spec.application.extraEnvs.envs
Optionally, enter your additional environment variables that are not secrets, such as your proxy environment variables.
Inject your
HTTP_PROXY
,HTTPS_PROXY
andNO_PROXY
environment variables:spec: application: extraEnvs: envs: - name: HTTP_PROXY value: 'http://10.10.10.105:3128' - name: HTTPS_PROXY value: 'http://10.10.10.106:3128' - name: NO_PROXY value: 'localhost,example.org'
spec.application.extraEnvs.secrets
Enter your environment variables secret name list.
Inject the environment variables in your Red Hat Developer Hub secret:
spec: application: extraEnvs: secrets: - name: <my_product_secrets>
Inject the environment variables in the Red Hat Developer Hub and
my-rhdh-database-secrets
secrets:spec: application: extraEnvs: secrets: - name: <my_product_secrets> - name: my-rhdh-database-secrets
Note<my_product_secrets>
is your preferred Developer Hub secret name, specifying the identifier for your secret configuration within Developer Hub.spec.application.extraFiles.secrets
Enter your certificates files secret name and files list.
Mount the
postgres-crt.pem
,postgres-ca.pem
, andpostgres-key.key
files contained in themy-rhdh-database-certificates-secrets
secret:spec: application: extraFiles: mountPath: /opt/app-root/src secrets: - name: my-rhdh-database-certificates-secrets key: postgres-crt.pem, postgres-ca.pem, postgres-key.key
spec.database.enableLocalDb
Enable or disable the local PostgreSQL database.
Disable the local PostgreSQL database generation to use an external postgreSQL database:
spec: database: enableLocalDb: false
On a development environment, use the local PostgreSQL database:
spec: database: enableLocalDb: true
spec.deployment
- Optionally, enter your deployment configuration.
Apply your Backstage CR to start or update your Developer Hub instance:
$ oc apply --filename=my-rhdh-custom-resource.yaml --namespace=my-rhdh-project
1.5. Exposing your operator-based Red Hat Developer Hub instance on Amazon Elastic Kubernetes Service (EKS)
On Amazon Elastic Kubernetes Service (EKS), to expose your Red Hat Developer Hub instance, Kubernetes ingresses replace OpenShift Container Platform routes. The Red Hat Developer Hub operator does not create ingresses. Therefore, to access your Developer Hub instance via a domain name, create the required ingresses on EKS and point your domain name to it.
Prerequisites
- You have installed Red Hat Developer Hub by using the Red Hat Developer Hub Operator.
- You have an EKS cluster with AWS Application Load Balancer (ALB) add-on installed. For more information, see Application load balancing on Amazon Elastic Kubernetes Service and Installing the AWS Load Balancer Controller add-on.
- You have configured a domain name for your Developer Hub instance. The domain name can be a hosted zone entry on Route 53 or managed outside of AWS. For more information, see Configuring Amazon Route 53 as your DNS service documentation.
- You have an entry in the AWS Certificate Manager (ACM) for your preferred domain name. Make sure to keep a record of your Certificate ARN.
-
You have set the context to the EKS cluster in your current
kubeconfig
. For more information, see Creating or updating a kubeconfig file for an Amazon EKS cluster.
Procedure
Create an Ingress manifest file, named
rhdh-ingress.yaml
, specifying your Developer Hub service name as follows:apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-rhdh-ingress 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' external-dns.alpha.kubernetes.io/hostname: <my_developer_hub_domain> spec: ingressClassName: alb rules: - host: <my_developer_hub_domain> http: paths: - path: / pathType: Prefix backend: service: name: my-rhdh-custom-resource port: name: http-backend EOF
Replace <my_developer_hub_domain> with your Developer Hub domain name and update the value of
alb.ingress.kubernetes.io/certificate-arn
with your certificate ARN.To deploy the created Ingress, run:
$ kubectl -n my-rhdh-project apply -f rhdh-ingress.yaml
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 a Developer Hub instance, which provides a robust developer platform within the AWS ecosystem.
Prerequisites
- You have an EKS cluster with AWS Application Load Balancer (ALB) add-on installed. For more information, see Application load balancing on Amazon Developer Hub and Installing the AWS Load Balancer Controller add-on.
- You have configured a domain name for your Developer Hub instance. The domain name can be a hosted zone entry on Route 53 or managed outside of AWS. For more information, see Configuring Amazon Route 53 as your DNS service documentation.
- You have an entry in the AWS Certificate Manager (ACM) for your preferred domain name. Make sure to keep a record of your Certificate ARN.
-
You have subscribed to
registry.redhat.io
. For more information, see Red Hat Container Registry Authentication. -
You have set the context to the EKS cluster in your current
kubeconfig
. For more information, see Creating or updating a kubeconfig file for an Amazon EKS cluster. -
You have installed
kubectl
. For more information, see Installing or updating kubectl. - You have installed Helm 3 or the latest. For more information, see Using Helm with Amazon EKS.
- Make sure that your system meets the minimum sizing requirements. See Sizing requirements for Red Hat Developer Hub.
Procedure
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/
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
The created pull secret is used to pull the Developer Hub images from the Red Hat Ecosystem.
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
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.7.0] \ --values /path/to/values.yaml
For the latest chart version, see https://github.com/openshift-helm-charts/charts/tree/main/charts/redhat/redhat/redhat-developer-hub
Verification
Wait until the DNS name is responsive, indicating that your Developer Hub instance is ready for use.