Chapter 1. Topology plugin for Backstage
The Topology plugin enables you to visualize the workloads such as Deployment, Job, Daemonset, Statefulset, CronJob, and Pods powering any service on the Kubernetes cluster.
1.1. For administrators Copy linkLink copied to clipboard!
1.1.1. Installation Copy linkLink copied to clipboard!
The Red Hat Plug-ins for Backstage (RHPIB) packages are hosted in a separate NPM registry, which is maintained by Red Hat. To use these packages, you must adjust your NPM configuration to pull the @redhat scoped packages:
# update your .npmrc or .yarnrc file
yarn config set "@redhat:registry" https://npm.registry.redhat.com
# then pull a package
yarn add @redhat/backstage-plugin-quay
For more information, see npm docs.
Creating a .npmrc file ensures that all the packages are scoped under @redhat and are fetched from Red Hat’s NPM registry, while the rest dependencies remain sourced from other registry.
Using this configuration, you can proceed with the installation of the individual packages.
Prerequisites
-
The Kubernetes plugins including
@backstage/plugin-kubernetesand@backstage/plugin-kubernetes-backendare installed and configured by following the installation and configuration guides. -
The Kubernetes plugin is configured and connects to the cluster using a
ServiceAccount. -
The
ClusterRolemust be granted toServiceAccountaccessing the cluster. If you have the Backstage Kubernetes plugin configured, then theClusterRoleis already granted. The following must be added in
customResourcescomponent in theapp-config.yamlfile to view the OpenShift route:kubernetes: ... customResources: - group: 'route.openshift.io' apiVersion: 'v1' plural: 'routes'Also, ensure that the route is granted a
ClusterRole. You can use the following code to grant theClusterRoleto the route :... apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: backstage-read-only rules: ... - apiGroups: - route.openshift.io resources: - routes verbs: - get - listThe following permission must be granted to the
ClusterRoleto be able to view the pod logs:apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: backstage-read-only rules: ... - apiGroups: - '' resources: - pods - pods/log verbs: - get - list - watchThe following code must be added in
customResourcescomponent in theapp-config.yamlfile to view the Tekton PipelineRuns list in the side panel and to view the latest PipelineRun status in the Topology node decorator:kubernetes: ... customResources: - group: 'tekton.dev' apiVersion: 'v1beta1' plural: 'pipelines' - group: 'tekton.dev' apiVersion: 'v1beta1' plural: 'pipelineruns' - group: 'tekton.dev' apiVersion: 'v1beta1' plural: 'taskruns'Also, ensure that the Pipeline, PipelineRun, and TaskRun are granted a
ClusterRole. You can use the following code to grant theClusterRoleto Pipeline, PipelineRun, and TaskRun:apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: backstage-read-only rules: ... - apiGroups: - tekton.dev resources: - pipelines - pipelineruns - taskruns verbs: - get - listThe following configuration must be added in`customResources` component in the
app-config.yamlfile to view the edit code decorator:kubernetes: ... customResources: - group: 'org.eclipse.che' apiVersion: 'v2' plural: 'checlusters'Also, ensure that the
CheClusteris granted aClusterRoleas shown in the following example code:apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: backstage-read-only rules: ... - apiGroups: - org.eclipse.che resources: - checlusters verbs: - get - listThe following annotations are added to workload resources in the
deployment.yamlfile to navigate to the GitHub repository of the associated application using the edit code decorator:annotations: app.openshift.io/vcs-uri: <GIT_REPO_URL>You can also add the following annotation to navigate to a specific branch:
annotations: app.openshift.io/vcs-ref: <GIT_REPO_BRANCH>If Red Hat OpenShift Dev Spaces (RHODS) is installed and configured and Git URL annotations are also added in the workload YAML file, then clicking on the edit code decorator redirects you to the RHODS instance. For more information about installing RHODS, see Administration guide of RHODS.
When you deploy your application using the OCP git import flow, then you do not need to add the labels as import flow to the workload YAML file. Otherwise, you would need to add the labels to the workload YAML file manually.
The labels are not similar to
backstage.io/edit-urlannotations as the added labels point to the source file of catalog entity metadata and is applied to Backstage catalog entity metadata YAML file, but not to the Kubernetes resources.You can also add the
app.openshift.io/edit-urlannotation that you want to access using the decorator.TipYou can use the prepared manifest for a read-only
ClusterRole, which provides access for both Kubernetes and Topology plugin.The following annotation is added to the entity’s
catalog-info.yamlfile to identify whether an entitiy contains the Kubernetes resources:annotations: backstage.io/kubernetes-id: <BACKSTAGE_ENTITY_NAME>The following label is added to the resources so that the Kubernetes plugin receives the Kubernetes resources from the requested entity:
labels: backstage.io/kubernetes-id: <BACKSTAGE_ENTITY_NAME>`NoteWhen using the label selector, the mentioned labels must be present on the resource.
The
backstage.io/kubernetes-namespaceannotation is added as follows to identify that the Kubernetes resources are using the defined namespace:annotations: backstage.io/kubernetes-namespace: <RESOURCE_NS>If the
backstage.io/kubernetes-namespaceannotation is added to thecatalog-info.yamlfile, then the RHODS instance is not accessible using the edit code decorator.To retrieve the instance URL, CheCluster Custom Resource (CR) is required. The instance URL is not retrieved if the namespace annotation value is different from
openshift-devspacesas CheCluster CR is created inopenshift-devspacesnamespace.A custom label selector is added, which Backstage uses to find the Kubernetes resources. The label selector takes precedence over the ID annotations. For example:
annotations: backstage.io/kubernetes-label-selector: 'app=my-app,component=front-end'If you have multiple entities while RHODS is configured and want multiple entities to support the edit code decorator that redirects to the RHODS instance, you can add the
backstage.io/kubernetes-label-selectorannotation to thecatalog-info.yamlfile for each entity as follows:annotations: backstage.io/kubernetes-label-selector: 'component in (<BACKSTAGE_ENTITY_NAME>,che)'If you are using the previous custom label selector, then make sure that you add the following labels to your resources so that the Kubernetes plugin receives the Kubernetes resources from the requested entity:
labels: component: che # add this label to your che cluster instancelabels: component: <BACKSTAGE_ENTITY_NAME> # add this label to the other resources associated with your entityYou can also write your own custom query for the label selector with unique labels to differentiate your entities. However, you need to ensure that you add those labels to the resources associated with your entities including your CheCluster instance.
The following label is added to workload resources in the
deployment.yamlfile to display runtime icon in the topology nodes:labels: app.openshift.io/runtime: <RUNTIME_NAME>Alternatively, you can include the following label to display the runtime icon:
labels: app.kubernetes.io/name: <RUNTIME_NAME>The
<RUNTIME_NAME>parameter in the previous example label supports the following values:-
django -
dotnet -
drupal -
go-gopher -
golang -
grails -
jboss -
jruby -
js -
nginx -
nodejs -
openjdk -
perl -
phalcon -
php -
python -
quarkus -
rails -
redis -
rh-spring-boot -
rust -
java -
rh-openjdk -
ruby -
spring -
spring-boot
Any other value for
<RUNTIME_NAME>parameter results in icons not being rendered for the node.-
The following label is added to display the workload resources such as Deployments and Pods in a visual group:
```yaml title="catalog-info.yaml" labels: app.kubernetes.io/part-of: <GROUP_NAME> ```The following annotation is added to display the workload resources such as Deployments and Pods with a visual connector:
```yaml title="catalog-info.yaml" annotations: app.openshift.io/connects-to: '[{"apiVersion": <RESOURCE_APIVERSION>,"kind": <RESOURCE_KIND>,"name": <RESOURCE_NAME>}]' ```For more information about the labels and annotations, see Guidelines for labels and annotations for OpenShift applications.
Procedure
Install the Topology plugin using the following command:
yarn workspace app add @redhat/backstage-plugin-topologyEnable TOPOLOGY tab in
packages/app/src/components/catalog/EntityPage.tsx:```tsx title="packages/app/src/components/catalog/EntityPage.tsx" /* highlight-add-next-line */ import { TopologyPage } from '@redhat/backstage-plugin-topology'; const serviceEntityPage = ( <EntityPageLayout> {/* ... */} {/* highlight-add-start */} <EntityLayout.Route path="/topology" title="Topology"> <TopologyPage /> </EntityLayout.Route> {/* highlight-add-end */} </EntityPageLayout> ); ```
1.2. For users Copy linkLink copied to clipboard!
1.2.1. Using the Topology plugin in Backstage Copy linkLink copied to clipboard!
Topology is a front-end plugin that enables you to view the workloads as nodes that power any service on the Kubernetes cluster.
Prerequisites
- Your Backstage application is installed and running.
- You have installed the Topology plugin. For the installation process, see Section 1.1.1, “Installation”.
Procedure
- Open your Backstage application and select a component from the Catalog page.
Go to the TOPOLOGY tab and you can view the workloads such as Deployments, Pods as nodes.
Select a node and a pop-up appears on the right side, which contains two tabs: Details and Resources.
The Details and Resources tab contain the associated information and resources of the node.
Click on the Open URL button on the top of a node.
When you click on the open URL button, it allows you to access the associated Ingresses and runs your application in a new tab.