Setup Backstage for Eventing

This page describes how to set up Backstage for Eventing in OpenShift Serverless, which allows you to discover your Eventing resources in Backstage.

In an event driven architecture, events are the first-class citizens. They are the building blocks of your application. OpenShift Serverless provides a way to create, manage, and consume events in a cloud-native way. OpenShift Serverless Eventing is built on top of Knative Eventing, which is a Kubernetes-based eventing system that provides composable primitives to build event-driven systems.

However, as the number of events and event sources grow, it becomes difficult to manage them. You need a way to discover and manage these resources. This is where Backstage comes in. Backstage is an open-source platform for building developer portals. It provides a way to discover, share, and collaborate on your services and APIs.

OpenShift Serverless Backstage integration is a Developer Preview feature only.

Developer Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Developer Preview features, see access.redhat.com/support/offerings/devpreview/.

Prerequisites

  • You have access to an OpenShift account with cluster administrator access.

  • Install the OpenShift CLI (oc).

  • Install the OpenShift Serverless Operator.

  • Install the Red Hat Developer Hub Operator and create a Backstage instance.

Enable Backstage backend for Eventing

  1. Configure KnativeEventing to create the necessary backend resources for Backstage:

    apiVersion: operator.knative.dev/v1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:

  # Other spec fields omitted ...
  # ...

  config:
    features:
      backstage-backend: enabled (1)
    1 Enables Backstage backend deployment in Eventing namespace.

  2. Apply the KnativeEventing resource:

    $ oc apply -f <filename>

Create necessary tokens for Backstage backend and OpenShift Serverless communication

Backstage backend will communicate with the OpenShift Serverless Backstage backend using a token. That token will be passed to the OpenShift Serverless backend and the it will use it to talk to the Kubernetes API server.

  1. Create a ServiceAccount:

    $ oc -n knative-eventing create serviceaccount backstage-admin

  2. Create a ClusterRole that allows the ServiceAccount to list and get the necessary resources in the cluster:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: backstage-admin
rules:
  - apiGroups:
      - eventing.knative.dev
    resources:
      - brokers
      - eventtypes
      - triggers
    verbs:
      - get
      - list

    The ClusterRole should be scoped to only allow the necessary permissions.

  3. Apply the ClusterRole resource:

    $ oc apply -f <filename>

  4. Bind the ServiceAccount to the ClusterRole:

    $ oc create clusterrolebinding backstage-admin --clusterrole=backstage-admin --serviceaccount=knative-eventing:backstage-admin

  5. Create a secret:

    apiVersion: v1
kind: Secret
metadata:
  name: backstage-admin
  namespace: knative-eventing
  annotations:
    kubernetes.io/service-account.name: backstage-admin
type: kubernetes.io/service-account-token

  6. Apply the Secret resource:

    $ oc apply -f <filename>

  7. Get the token from the secret:

    $ oc get secret backstage-admin -n knative-eventing -o jsonpath='{.data.token}' | base64 --decode

    We are going to give this token to Red Hat Developer Hub.

Install the Backstage plugin on Red Hat Developer Hub

  1. Add the BACKSTAGE_KNATIVE_BACKEND_TOKEN environment variable to the Red Hat Developer Hub deployment by modifying the Red Hat Developer Hub secret such as secrets-rhdh:

    kind: Secret
apiVersion: v1
metadata:
  name: secrets-rhdh
  namespace: rhdh-operator
  # more metadata ...
data:
  BACKSTAGE_KNATIVE_BACKEND_TOKEN: SECRET-TOKEN (1)
  # more data ...
# more fields ...
    1 The token we got from the backstage-admin secret.

  2. Modify the dynamic plugins configmap such as dynamic-plugins-rhdh and add an entry for the Backstage plugin:

    kind: ConfigMap
apiVersion: v1
metadata:
  name: dynamic-plugins-rhdh
  namespace: rhdh-operator
  # more metadata ...
data:
  dynamic-plugins.yaml: |-
    includes:
      - dynamic-plugins.default.yaml
    plugins:
      # - Other plugins omitted
      # - ...
      - package: "@knative-extensions/plugin-knative-event-mesh-backend-dynamic@1.16.0" (1)
        integrity: "sha512-Rnw7o2UyS8X7YklwhHYEtr/yHLnDHJizIACpKaDuqddW/2+WBWrdg8geAYGAeW8u/RnXwgpkcFW27DmoQ460gQ==" (2)
        disabled: false
        pluginConfig:
          catalog:
            providers:
              knativeEventMesh:
                dev:
                  token: "${BACKSTAGE_KNATIVE_BACKEND_TOKEN}" (3)
                  baseUrl: "http://eventmesh-backend.knative-eventing.svc.cluster.local:8080" (4)
                  schedule:
                    frequency: { minutes: 1 } (5)
                    timeout: { minutes: 1 } (6)
    1 The full package name of the plugin. You can find the list of available versions in NPM.
    2 The integrity of the plugin package. You can find the integrity of the package by running npm view @knative-extensions/plugin-knative-event-mesh-backend-dynamic@1.16.0 dist.integrity.
    3 This will be replaced by an environment variable we have created in the previous step.
    4 This is the URL of the Backstage backend.
    5 The frequency at which the plugin will poll the backend for new data.
    6 The timeout for the polling.

  3. Apply the ConfigMap resource:

    $ oc apply -f <filename>

The changes will not be applied to the Red Hat Developer Hub deployment automatically. You need to restart the Red Hat Developer Hub deployment to apply the changes.

The default installation of Red Hat Developer Hub might not have the dynamic plugins configmap such as dynamic-plugins-rhdh and the secret such as secrets-rhdh created. See the Red Hat Developer Hub documentation for more information on how to create these resources and to reference them in the Red Hat Developer Hub instance.