Chapter 4. Red Hat Developer Hub integration with Microsoft Azure Kubernetes Service (AKS)
You can integrate Developer Hub with Microsoft Azure Kubernetes Service (AKS), which provides a significant advancement in development, offering a streamlined environment for building, deploying, and managing your applications.
This integration requires the deployment of Developer Hub on AKS using one of the following methods:
- The Helm chart
- The Red Hat Developer Hub Operator
4.1. Deploying Red Hat Developer Hub on Azure Kubernetes Service (AKS)
You can deploy your Developer Hub application on Azure Kubernetes Services (AKS) to access a comprehensive solution for building, testing, and deploying applications.
Prerequisites
- You have an Azure account with active subscription.
You have installed Azure CLI in your machine and configured the Resource Group and Cluster. For more information, see How to install the Azure CLI.
You can perform the following steps to configure the Resource Group and Cluster:
To access Azure, ensuring you’re logged in to our designated tenant use the following command:
az login [--tenant=<optional-directory-name>]
To create a Resource Group, run the following command:
az group create --name <your_ResourceGroup> --location <location>
Tipyou can retrieve available regions using
az account list-locations -o table
.Create an AKS cluster:
az aks create \ --resource-group <your_ResourceGroup> \ --name <your_ClusterName> \ --enable-managed-identity \ --generate-ssh-keys
You can refer to
--help
for additional options.Connect to your cluster:
az aks get-credentials --resource-group <your_ResourceGroup> --name <your_ClusterName>
The previous command configures the Kubernetes client and sets the current context in the
kubeconfig
to point to your AKS cluster.
-
You have installed
kubectl
. For more information, see Installing or updating kubectl. You have installed Helm 3 or the latest.
- Comparison of AKS specifics with the base Developer Hub deployment
-
Permissions issue: Developer Hub containers might encounter permission-related errors, such as
Permission denied
when attempting certain operations. This error can be addresssed by adjusting thefsGroup
in thePodSpec.securityContext
. Ingress configuration: In AKS, configuring ingress is essential for accessing the installed Developer Hub instance. Accessing the Developer Hub instance requires enabling the Routing add-on, an NGINX-based Ingress Controller, using the following commands:
az aks approuting enable --resource-group <your_ResourceGroup> --name <your_ClusterName>
TipYou might need to install the Azure CLI extension
aks-preview
. If the extension is not installed automatically, you might need to install it manually using the following command:az extension add --upgrade -n aks-preview --allow-preview true
NoteAfter you install the Ingress Controller, the 'app-routing-system' namespace with the Ingress Controller will be deployed in your cluster. Note the address of your Developer Hub application from the installed Ingress Controller (for example, 108.141.70.228) for later access to the Developer Hub application, later referenced as
<app_address>
.kubectl get svc nginx --namespace app-routing-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
Namespace management: You can create a dedicated namespace for Developer Hub deployment in AKS using the following command:
kubectl create namespace <your_namespace>
-
Permissions issue: Developer Hub containers might encounter permission-related errors, such as
4.1.1. Deploying the Red Hat Developer Hub on Azure Kubernetes Service (AKS) using the Helm chart
You can deploy your Developer Hub on AKS using Helm.
Procedure
Open terminal and run the following command to add the Helm chart repository:
helm repo add openshift-helm-charts https://charts.openshift.io/
To create
ImagePull Secret
, run the following command:kubectl -n <your_namespace> 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 file named
values.yaml
using the following template:global: host: <app_address> route: enabled: false upstream: ingress: enabled: true className: webapprouting.kubernetes.azure.com host: backstage: image: pullSecrets: - rhdh-pull-secret podSecurityContext: fsGroup: 3000 postgresql: image: pullSecrets: - rhdh-pull-secret primary: podSecurityContext: enabled: true fsGroup: 3000 volumePermissions: enabled: true
To install Helm Chart, run the following command:
helm -n <your_namespace> install -f values.yaml <your_deploy_name> openshift-helm-charts/redhat-developer-hub --version 1.1.1
Verify the deployment status:
kubectl get deploy <your_deploy_name>-developer-hub -n <your_namespace>
-
Access the deployed Developer Hub using the URL:
https://<app_address>
, where <app_address> is the Ingress address obtained earlier (for example,https://108.141.70.228
). To upgrade or delete the deployment, run the following command:
Upgrade command
helm -n <your_namespace> upgrade -f values.yaml <your_deploy_name> openshift-helm-charts/redhat-developer-hub --version 1.1.1
Delete command
helm -n <your_namespace> delete <your_deploy_name>
4.1.2. Deploying the Red Hat Developer Hub on Azure Kubernetes Service (AKS) using the Operator
You can deploy your Developer Hub on AKS using the Red Hat Developer Hub Operator.
Procedure
Obtain the Red Hat Developer Hub Operator manifest file, named
rhdh-operator-<VERSION>.yaml
, and modify the default configuration ofdb-statefulset.yaml
anddeployment.yaml
by adding the following fragment:securityContext: fsGroup: 300
Following is the specified locations in the manifests:
db-statefulset.yaml: | spec.template.spec deployment.yaml: | spec.template.spec
Apply the modified Operator manifest to your Kubernetes cluster:
kubectl apply -f rhdh-operator-<VERSION>.yaml
NoteExecution of the previous command is cluster-scoped and requires appropriate cluster privileges.
Create an
ImagePull Secret
namedrhdh-pull-secret
using your Red Hat credentials to access images from the protectedregistry.redhat.io
as shown in the following example:kubectl -n <your_namespace> 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 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: rhdh-ingress namespace: <your_namespace> spec: ingressClassName: webapprouting.kubernetes.azure.com rules: - http: paths: - path: / pathType: Prefix backend: service: name: backstage-<your-CR-name> port: name: http-backend
To deploy the created Ingress, run the following command:
kubectl -n <your_namespace> apply -f rhdh-ingress.yaml
Create a ConfigMap named
app-config-rhdh
containing the Developer Hub configuration using the following example:apiVersion: v1 kind: ConfigMap metadata: name: app-config-rhdh data: "app-config-rhdh.yaml": | app: title: Red Hat Developer Hub baseUrl: https://<app_address> backend: auth: keys: - secret: "${BACKEND_SECRET}" baseUrl: https://<app_address> cors: origin: https://<app_address>
Create a Secret named
secrets-rhdh
and add a key namedBACKEND_SECRET
with aBase64-encoded
string value as shown in the following example:apiVersion: v1 kind: Secret metadata: name: secrets-rhdh stringData: BACKEND_SECRET: "xxx"
Create a Custom Resource (CR) manifest file named
rhdh.yaml
and include the previously createdrhdh-pull-secret
as follows:apiVersion: rhdh.redhat.com/v1alpha1 kind: Backstage metadata: name: <your-rhdh-cr> spec: application: imagePullSecrets: - rhdh-pull-secret appConfig: configMaps: - name: "app-config-rhdh" extraEnvs: secrets: - name: "secrets-rhdh"
Apply the CR manifest to your namespace:
kubectl -n <your_namespace> apply -f rhdh.yaml
-
Access the deployed Developer Hub using the URL:
https://<app_address>
, where <app_address> is the Ingress address obtained earlier (for example,https://108.141.70.228
). Optional: To delete the CR, run the following command:
kubectl -n <your_namespace> delete -f rhdh.yaml
4.2. Monitoring and logging with Azure Kubernetes Services (AKS) in Red Hat Developer Hub
Monitoring and logging are integral aspects of managing and maintaining Azure Kubernetes Services (AKS) in Red Hat Developer Hub. With features like Managed Prometheus Monitoring and Azure Monitor integration, administrators can efficiently monitor resource utilization, diagnose issues, and ensure the reliability of their containerized workloads.
To enable Managed Prometheus Monitoring, use the -enable-azure-monitor-metrics
option within either the az aks create
or az aks update
command, depending on whether you’re creating a new cluster or updating an existing one, such as:
az aks create/update --resource-group <your-ResourceGroup> --name <your-Cluster> --enable-azure-monitor-metrics
The previous command installs the metrics add-on, which gathers Prometheus metrics. Using the previous command, you can enable monitoring of Azure resources through both native Azure Monitor metrics and Prometheus metrics. You can also view the results in the portal under Monitoring
Furthermore, metrics from both the Managed Prometheus service and Azure Monitor can be accessed through Azure Managed Grafana service. For more information, see Link a Grafana workspace section.
By default, Prometheus uses the minimum ingesting profile, which optimizes ingestion volume and sets default configurations for scrape frequency, targets, and metrics collected. The default settings can be customized through custom configuration. Azure offers various methods, including using different ConfigMaps, to provide scrape configuration and other metric add-on settings. For more information about default configuration, see Default Prometheus metrics configuration in Azure Monitor and Customize scraping of Prometheus metrics in Azure Monitor managed service for Prometheus documentation.
4.2.1. Viewing logs with Azure Kubernetes Services (AKS)
You can access live data logs generated by Kubernetes objects and collect log data in Container Insights within AKS.
Prerequisites
- You have deployed Developer Hub on AKS. For more information, see Section 4.1, “Deploying Red Hat Developer Hub on Azure Kubernetes Service (AKS)”.
Procedure
- View live logs from your Developer Hub instance
- Navigate to the Azure Portal.
-
Search for the resource group
<your-ResourceGroup>
and locate your AKS cluster<your-Cluster>
. -
Select Kubernetes resources
Workloads from the menu. -
Select the
<your-rhdh-cr>-developer-hub
(in case of Helm Chart installation) or<your-rhdh-cr>-backstage
(in case of Operator-backed installation) deployment. - Click Live Logs in the left menu.
Select the pod.
NoteThere must be only single pod.
Live log data is collected and displayed.
- View real-time log data from the Container Engine
- Navigate to the Azure Portal.
-
Search for the resource group
<your-ResourceGroup>
and locate your AKS cluster<your-Cluster>
. -
Select Monitoring
Insights from the menu. - Go to the Containers tab.
- Find the backend-backstage container and click it to view real-time log data as it’s generated by the Container Engine.
4.3. Using Microsoft Azure as an authentication provider in Red Hat Developer Hub
The core-plugin-api
package in Developer Hub comes integrated with Microsoft Azure authentication provider, authenticating signing in using Azure OAuth.
Prerequisites
- You have deployed Developer Hub on AKS. For more information, see Section 4.1, “Deploying Red Hat Developer Hub on Azure Kubernetes Service (AKS)”.
- You have created registered your application in Azure portal. For more information, see Register an application with the Microsoft identity platform.
4.3.1. Using Microsoft Azure as an authentication provider in Helm deployment
You can use Microsoft Azure as an authentication provider in Red Hat Developer Hub, when installed using the Helm Chart. For more information, see Section 4.1.1, “Deploying the Red Hat Developer Hub on Azure Kubernetes Service (AKS) using the Helm chart”.
Procedure
After the application is registered, note down the following:
-
clientId
: Application (client) ID, found under App RegistrationOverview. -
clientSecret
: Secret, found under *App RegistrationCertificates & secrets (create new if needed). -
tenantId
: Directory (tenant) ID, found under App RegistrationOverview.
-
Ensure the following fragment is included in your Developer Hub ConfigMap:
auth: environment: production providers: microsoft: production: clientId: ${AZURE_CLIENT_ID} clientSecret: ${AZURE_CLIENT_SECRET} tenantId: ${AZURE_TENANT_ID} domainHint: ${AZURE_TENANT_ID} additionalScopes: - Mail.Send
You can either create a new file or add it to an existing one.
Apply the ConfigMap to your Kubernetes cluster:
kubectl -n <your_namespace> apply -f <app-config>.yaml
Create or reuse an existing Secret containing Azure credentials and add the following fragment:
stringData: AZURE_CLIENT_ID: <value-of-clientId> AZURE_CLIENT_SECRET: <value-of-clientSecret> AZURE_TENANT_ID: <value-of-tenantId>
Apply the secret to your Kubernetes cluster:
kubectl -n <your_namespace> apply -f <azure-secrets>.yaml
Ensure your
values.yaml
file references the previously created ConfigMap and Secret:upstream: backstage: ... extraAppConfig: - filename: ... configMapRef: <app-config-containing-azure> extraEnvVarsSecrets: - <secret-containing-azure>
Optional: If the Helm Chart is already installed, upgrade it:
helm -n <your_namespace> upgrade -f <your-values.yaml> <your_deploy_name> redhat-developer/backstage --version 1.1.4
Optional: If your
rhdh.yaml
file is not changed, for example, you only updated the ConfigMap and Secret referenced from it, refresh your Developer Hub deployment by removing the corresponding pods:kubectl -n <your_namespace> delete pods -l backstage.io/app=backstage-<your-rhdh-cr>
4.3.2. Using Microsoft Azure as an authentication provider in Operator-backed deployment
You can use Microsoft Azure as an authentication provider in Red Hat Developer Hub, when installed using the Operator. For more information, see Section 2.2, “Deploying Red Hat Developer Hub on OpenShift Container Platform using the Operator”.
Procedure
After the application is registered, note down the following:
-
clientId
: Application (client) ID, found under App RegistrationOverview. -
clientSecret
: Secret, found under *App RegistrationCertificates & secrets (create new if needed). -
tenantId
: Directory (tenant) ID, found under App RegistrationOverview.
-
Ensure the following fragment is included in your Developer Hub ConfigMap:
auth: environment: production providers: microsoft: production: clientId: ${AZURE_CLIENT_ID} clientSecret: ${AZURE_CLIENT_SECRET} tenantId: ${AZURE_TENANT_ID} domainHint: ${AZURE_TENANT_ID} additionalScopes: - Mail.Send
You can either create a new file or add it to an existing one.
Apply the ConfigMap to your Kubernetes cluster:
kubectl -n <your_namespace> apply -f <app-config>.yaml
Create or reuse an existing Secret containing Azure credentials and add the following fragment:
stringData: AZURE_CLIENT_ID: <value-of-clientId> AZURE_CLIENT_SECRET: <value-of-clientSecret> AZURE_TENANT_ID: <value-of-tenantId>
Apply the secret to your Kubernetes cluster:
kubectl -n <your_namespace> apply -f <azure-secrets>.yaml
Ensure your Custom Resource manifest contains references to the previously created ConfigMap and Secret:
apiVersion: rhdh.redhat.com/v1alpha1 kind: Backstage metadata: name: <your-rhdh-cr> spec: application: imagePullSecrets: - rhdh-pull-secret route: enabled: false appConfig: configMaps: - name: <app-config-containing-azure> extraEnvs: secrets: - name: <secret-containing-azure>
Apply your Custom Resource manifest:
kubectl -n <your_namespace> apply -f rhdh.yaml
Optional: If your
rhdh.yaml
file is not changed, for example, you only updated the ConfigMap and Secret referenced from it, refresh your Developer Hub deployment by removing the corresponding pods:kubectl -n <your_namespace> delete pods -l backstage.io/app=backstage-<your-rhdh-cr>