Configuring plugins in Red Hat Developer Hub
Abstract
- 1. Plugins in Red Hat Developer Hub
- 2. Dynamic plugin installation
- 2.1. Preinstalled dynamic plugins
- 2.2. Other installable plugins
- 2.3. Installing and using Ansible plug-ins for Red Hat Developer Hub
- 2.4. Installation and configuration of Keycloak
- 2.5. Installation and configuration of Nexus Repository Manager
- 2.6. Installation and configuration of Tekton
- 2.7. Enabling and configuring Argo CD plugin
The Red Hat Developer Hub is an enterprise-grade, integrated developer platform, extended through plugins, that helps reduce the friction and frustration of developers while boosting their productivity.
1. Plugins in Red Hat Developer Hub
The Red Hat Developer Hub application offers a unified platform with various plugins. Using the plugin ecosystem within the Developer Hub application, you can access any kind of development infrastructure or software development tool.
The plugins in Developer Hub maximize the productivity and streamline the development workflows by maintaining the consistency in the overall user experience.
2. Dynamic plugin installation
The dynamic plugin support is based on the backend plugin manager package, which is a service that scans a configured root directory (dynamicPlugins.rootDirectory in the app config) for dynamic plugin packages and loads them dynamically.
You can use the dynamic plugins that come preinstalled with Red Hat Developer Hub or install external dynamic plugins from a public NPM registry.
2.1. Preinstalled dynamic plugins
Red Hat Developer Hub is preinstalled with a selection of dynamic plugins.
The following preinstalled dynamic plugins are enabled by default:
-
@janus-idp/backstage-plugin-analytics-provider-segment -
@janus-idp/backstage-scaffolder-backend-module-quay -
@janus-idp/backstage-scaffolder-backend-module-regex -
@backstage/plugin-techdocs-backend -
@backstage/plugin-techdocs
The dynamic plugins that require custom configuration are disabled by default.
Upon application startup, for each plugin that is disabled by default, the install-dynamic-plugins init container within the Developer Hub pod log displays a message similar to the following:
======= Skipping disabled dynamic plugin ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic
To enable this plugin, add a package with the same name to the Helm chart and change the value in the disabled field to ‘false’. For example:
global:
dynamic:
includes:
- dynamic-plugins.default.yaml
plugins:
- package: ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic
disabled: false
The default configuration for a plugin is extracted from the dynamic-plugins.default.yaml file, however, you can use a pluginConfig entry to override the default configuration.
2.1.1. Red Hat supported plugins
Red Hat supports the following 17 plugins:
| Name | Plugin | Version | Path and required variables |
|---|---|---|---|
|
Analytics Provider Segment |
1.7.3 |
| |
|
Argo CD |
2.6.5 |
| |
|
Argo CD |
3.0.3 |
| |
|
GitHub |
0.6.5 |
| |
|
GitHub Org |
0.1.17 |
| |
|
Keycloak |
1.13.4 |
| |
|
Kubernetes |
0.18.3 |
| |
|
OCM |
4.4.5 |
| |
|
OCM |
4.4.4 |
| |
|
Quay |
1.11.9 |
| |
|
Quay |
1.7.2 |
| |
|
RBAC |
1.29.7 |
| |
|
Regex |
1.7.2 |
| |
|
TechDocs |
1.10.7 |
| |
|
TechDocs |
1.10.9 |
| |
|
Tekton |
3.12.9 |
| |
|
Topology |
1.27.7 |
|
- For more information about configuring KeyCloak, see Configuring dynamic plugins.
- For more information about configuring TechDocs, see Configuring the TechDocs plugin in Red Hat Developer Hub.
2.1.2. Technology Preview plugins
Red Hat Developer Hub includes a select number of Technology Preview plugins, available for customers to configure and enable. These plugins are provided with support scoped per Technical Preview terms, might not be functionally complete, and Red Hat does not recommend using them for 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 on Red Hat Technology Preview features, see Technology Preview Features Scope.
2.1.2.1. Red Hat Technology Preview plugins
Red Hat provides Technology Preview support for the following 7 plugins:
| Name | Plugin | Version | Path and required variables |
|---|---|---|---|
|
Ansible Automation Platform (AAP) |
1.9.4 |
| |
|
ACR |
1.7.16 |
| |
|
Bulk Import |
1.4.11 |
| |
|
JFrog Artifactory |
1.7.10 |
| |
|
Nexus Repository Manager |
1.9.10 |
| |
|
ServiceNow |
1.7.3 |
| |
|
SonarQube |
1.7.2 |
|
- A new Technology Preview plugin for Red Hat Ansible Automation Platform (RHAAP) is available, which replaces this older one. See Other installable plugins in the Configuring plugins in Red Hat Developer Hub guide for further details. See Dynamic plugins support matrix.
2.1.2.2. Community plugins
Red Hat Developer Hub (RHDH) includes a select number of community-supported plugins, available for customers to enable and configure. These community plugins are augmented by Red Hat to be dynamic plugin capable, and are provided with support scoped per Technical Preview terms.
Details on how Red Hat provides support for bundled community dynamic plugins are available on the Red Hat Developer Support Policy page.
RHDH includes the following 43 community plugins:
| Name | Plugin | Version | Path and required variables |
|---|---|---|---|
|
3scale |
1.8.2 |
| |
|
Argo CD |
1.1.27 |
| |
|
Argo CD (Red Hat) |
1.8.10 |
| |
|
Azure |
0.1.14 |
| |
|
Azure Devops |
0.4.4 |
| |
|
Azure Devops |
0.6.5 |
| |
|
Azure Repositories |
|
0.3.0 |
|
|
Bitbucket Cloud |
0.2.9 |
| |
|
Bitbucket Cloud |
0.1.12 |
| |
|
Bitbucket Server |
0.1.36 |
| |
|
Bitbucket Server |
|
0.1.12 |
|
|
Bulk Import |
1.5.5 |
| |
|
Datadog |
2.3.0 |
| |
|
Dynatrace |
10.0.4 |
| |
|
Gerrit |
0.1.14 |
| |
|
GitHub |
0.4.0 |
| |
|
GitHub Actions |
0.6.16 |
| |
|
GitHub Insights |
2.3.31 |
| |
|
GitHub Issues |
0.4.2 |
| |
|
GitHub Pull Requests |
2.5.29 |
| |
|
GitLab |
6.6.0 |
| |
|
GitLab |
0.3.21 |
| |
|
GitLab |
6.6.0 |
| |
|
GitLab |
0.4.4 |
| |
|
GitLab Org |
0.0.5 |
| |
|
Http Request |
4.3.2 |
| |
|
Jenkins |
0.9.10 |
| |
|
Jenkins |
0.4.5 |
| |
|
Jira |
2.5.8 |
| |
|
Kubernetes |
0.11.12 |
| |
|
Ldap |
0.7.0 |
| |
|
Lighthouse |
0.4.20 |
| |
|
Logs |
0.0.1 |
| |
|
MS Graph |
0.5.30 |
| |
|
PagerDuty |
0.15.0 |
| |
|
PagerDuty |
0.6.1 |
| |
|
Pingidentity |
|
0.1.2 |
|
|
Scaffolder Relation Processor |
|
1.2.6 |
|
|
Security Insights |
2.3.19 |
| |
|
SonarQube |
0.7.17 |
| |
|
SonarQube |
0.2.20 |
| |
|
Tech Radar |
0.7.4 |
| |
|
Utils |
1.17.1 |
|
2.2. Other installable plugins
The following Technology Preview plugins are not preinstalled and must be installed from an external source:
| Name | Plugin | Version | Installation Details |
|---|---|---|---|
|
Ansible Automation Platform Frontend |
1.0.0 | ||
|
Ansible Automation Platform |
1.0.0 | ||
|
Ansible Automation Platform Scaffolder Backend |
1.0.0 | ||
|
Orchestrator Frontend |
1.22.6 | ||
|
Orchestrator Backend |
1.22.9 |
- The above Red Hat Ansible Automation Platform (RHAAP) plugins, can be used as a replacement for the older plugin listed in the Technology Preview plugins section of the Configuring plugins in Red Hat Developer Hub guide.
2.3. Installing and using Ansible plug-ins for Red Hat Developer Hub
Ansible plug-ins for Red Hat Developer Hub deliver an Ansible-specific portal experience with curated learning paths, push-button content creation, integrated development tools, and other opinionated resources.
The Ansible plug-ins are a Technology Preview feature only.
Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for 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 on Red Hat Technology Preview features, see Technology Preview Features Scope.
Additional detail on how Red Hat provides support for bundled community dynamic plugins is available on the Red Hat Developer Support Policy page.
2.3.1. For administrators
To install and configure the Ansible plugins, see Installing Ansible plug-ins for Red Hat Developer Hub.
2.3.2. For users
To use the Ansible plugins, see Using Ansible plug-ins for Red Hat Developer Hub.
2.4. Installation and configuration of Keycloak
The Keycloak backend plugin, which integrates Keycloak into Developer Hub, has the following capabilities:
- Synchronization of Keycloak users in a realm.
- Synchronization of Keycloak groups and their users in a realm.
2.4.1. For administrators
2.4.1.1. Installation
The Keycloak plugin is pre-loaded in Developer Hub with basic configuration properties. To enable it, set the disabled property to false as follows:
global:
dynamic:
includes:
- dynamic-plugins.default.yaml
plugins:
- package: ./dynamic-plugins/dist/janus-idp-backstage-plugin-keycloak-backend-dynamic
disabled: false2.4.1.2. Basic configuration
To enable the Keycloak plugin, you must set the following environment variables:
-
KEYCLOAK_BASE_URL -
KEYCLOAK_LOGIN_REALM -
KEYCLOAK_REALM -
KEYCLOAK_CLIENT_ID -
KEYCLOAK_CLIENT_SECRET
2.4.1.3. Advanced configuration
Schedule configuration
You can configure a schedule in the app-config.yaml file, as follows:
catalog:
providers:
keycloakOrg:
default:
# ...
# highlight-add-start
schedule: # optional; same options as in TaskScheduleDefinition
# supports cron, ISO duration, "human duration" as used in code
frequency: { minutes: 1 }
# supports ISO duration, "human duration" as used in code
timeout: { minutes: 1 }
initialDelay: { seconds: 15 }
# highlight-add-end
If you have made any changes to the schedule in the app-config.yaml file, then restart to apply the changes.
Keycloak query parameters
You can override the default Keycloak query parameters in the app-config.yaml file, as follows:
catalog:
providers:
keycloakOrg:
default:
# ...
# highlight-add-start
userQuerySize: 500 # Optional
groupQuerySize: 250 # Optional
# highlight-add-endCommunication between Developer Hub and Keycloak is enabled by using the Keycloak API. Username and password, or client credentials are supported authentication methods.
The following table describes the parameters that you can configure to enable the plugin under catalog.providers.keycloakOrg.<ENVIRONMENT_NAME> object in the app-config.yaml file:
| Name | Description | Default Value | Required |
|---|---|---|---|
|
|
Location of the Keycloak server, such as |
"" |
Yes |
|
|
Realm to synchronize |
|
No |
|
|
Realm used to authenticate |
|
No |
|
|
Username to authenticate |
"" |
Yes if using password based authentication |
|
|
Password to authenticate |
"" |
Yes if using password based authentication |
|
|
Client ID to authenticate |
"" |
Yes if using client credentials based authentication |
|
|
Client Secret to authenticate |
"" |
Yes if using client credentials based authentication |
|
|
Number of users to query at a time |
|
No |
|
|
Number of groups to query at a time |
|
No |
When using client credentials, the access type must be set to confidential and service accounts must be enabled. You must also add the following roles from the realm-management client role:
-
query-groups -
query-users -
view-users
2.4.1.4. Limitations
If you have self-signed or corporate certificate issues, you can set the following environment variable before starting Developer Hub:
NODE_TLS_REJECT_UNAUTHORIZED=0
The solution of setting the environment variable is not recommended.
2.4.2. For users
2.4.2.1. Import of users and groups in Developer Hub using the Keycloak plugin
After configuring the plugin successfully, the plugin imports the users and groups each time when started.
If you set up a schedule, users and groups will also be imported.
After the first import is complete, you can select User to list the users from the catalog page:
You can see the list of users on the page:
When you select a user, you can see the information imported from Keycloak:
You can also select a group, view the list, and select or view the information imported from Keycloak for a group:
2.5. Installation and configuration of Nexus Repository Manager
The Nexus Repository Manager plugin displays the information about your build artifacts in your Developer Hub application. The build artifacts are available in the Nexus Repository Manager.
The Nexus Repository Manager plugin is a Technology Preview feature only.
Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend using them for 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 on Red Hat Technology Preview features, see Technology Preview Features Scope.
Additional detail on how Red Hat provides support for bundled community dynamic plugins is available on the Red Hat Developer Support Policy page.
2.5.1. For administrators
2.5.1.1. Installing and configuring the Nexus Repository Manager plugin
Installation
The Nexus Repository Manager plugin is pre-loaded in Developer Hub with basic configuration properties. To enable it, set the disabled property to false as follows:
global:
dynamic:
includes:
- dynamic-plugins.default.yaml
plugins:
- package: ./dynamic-plugins/dist/janus-idp-backstage-plugin-nexus-repository-manager
disabled: falseConfiguration
Set the proxy to the desired Nexus Repository Manager server in the
app-config.yamlfile as follows:proxy: '/nexus-repository-manager': target: 'https://<NEXUS_REPOSITORY_MANAGER_URL>' headers: X-Requested-With: 'XMLHttpRequest' # Uncomment the following line to access a private Nexus Repository Manager using a token # Authorization: 'Bearer <YOUR TOKEN>' changeOrigin: true # Change to "false" in case of using self hosted Nexus Repository Manager instance with a self-signed certificate secure: trueOptional: Change the base URL of Nexus Repository Manager proxy as follows:
nexusRepositoryManager: # default path is `/nexus-repository-manager` proxyPath: /custom-pathOptional: Enable the following experimental annotations:
nexusRepositoryManager: experimentalAnnotations: trueAnnotate your entity using the following annotations:
metadata: annotations: # insert the chosen annotations here # example nexus-repository-manager/docker.image-name: `<ORGANIZATION>/<REPOSITORY>`,
2.5.2. For users
2.5.2.1. Using the Nexus Repository Manager plugin in Developer Hub
The Nexus Repository Manager is a front-end plugin that enables you to view the information about build artifacts.
Prerequisites
- Your Developer Hub application is installed and running.
- You have installed the Nexus Repository Manager plugin. For the installation process, see Section 2.5.1.1, “Installing and configuring the Nexus Repository Manager plugin”.
Procedure
- Open your Developer Hub application and select a component from the Catalog page.
Go to the BUILD ARTIFACTS tab.
The BUILD ARTIFACTS tab contains a list of build artifacts and related information, such as VERSION, REPOSITORY, REPOSITORY TYPE, MANIFEST, MODIFIED, and SIZE.
2.6. Installation and configuration of Tekton
You can use the Tekton plugin to visualize the results of CI/CD pipeline runs on your Kubernetes or OpenShift clusters. The plugin allows users to visually see high level status of all associated tasks in the pipeline for their applications.
2.6.1. For administrators
2.6.1.1. Installation
Prerequsites
-
You have installed and configured the
@backstage/plugin-kubernetesand@backstage/plugin-kubernetes-backenddynamic plugins. For more information about installing dynamic plugins, see Installing and viewing dynamic plugins. -
You have configured the Kubernetes plugin to connect to the cluster using a
ServiceAccount. The
ClusterRolemust be granted for custom resources (PipelineRuns and TaskRuns) to theServiceAccountaccessing the cluster.NoteIf you have the RHDH Kubernetes plugin configured, then the
ClusterRoleis already granted.-
To view the pod logs, you have granted permissions for
pods/log. You can use the following code to grant the
ClusterRolefor custom resources and pod logs:kubernetes: ... customResources: - group: 'tekton.dev' apiVersion: 'v1' plural: 'pipelineruns' - group: 'tekton.dev' apiVersion: 'v1' ... apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: backstage-read-only rules: - apiGroups: - "" resources: - pods/log verbs: - get - list - watch ... - apiGroups: - tekton.dev resources: - pipelineruns - taskruns verbs: - get - listYou can use the prepared manifest for a read-only
ClusterRole, which provides access for both Kubernetes plugin and Tekton plugin.Add the following annotation to the entity’s
catalog-info.yamlfile to identify whether an entity contains the Kubernetes resources:annotations: ... backstage.io/kubernetes-id: <BACKSTAGE_ENTITY_NAME>
You can also add the
backstage.io/kubernetes-namespaceannotation to identify the Kubernetes resources using the defined namespace.annotations: ... backstage.io/kubernetes-namespace: <RESOURCE_NS>
Add the following annotation to the
catalog-info.yamlfile of the entity to enable the Tekton related features in RHDH. The value of the annotation identifies the name of the RHDH entity:annotations: ... janus-idp.io/tekton : <BACKSTAGE_ENTITY_NAME>
Add a custom label selector, which RHDH uses to find the Kubernetes resources. The label selector takes precedence over the ID annotations.
annotations: ... backstage.io/kubernetes-label-selector: 'app=my-app,component=front-end'
Add the following label to the resources so that the Kubernetes plugin gets the Kubernetes resources from the requested entity:
labels: ... backstage.io/kubernetes-id: <BACKSTAGE_ENTITY_NAME>
NoteWhen you use the label selector, the mentioned labels must be present on the resource.
Procedure
The Tekton plugin is pre-loaded in RHDH with basic configuration properties. To enable it, set the disabled property to false as follows:
global: dynamic: includes: - dynamic-plugins.default.yaml plugins: - package: ./dynamic-plugins/dist/janus-idp-backstage-plugin-tekton disabled: false
2.6.2. For users
2.6.2.1. Using the Tekton plugin in RHDH
You can use the Tekton front-end plugin to view PipelineRun resources.
Prerequisites
- You have installed the Red Hat Developer Hub (RHDH).
- You have installed the Tekton plugin. For the installation process, see Installing and configuring the Tekton plugin.
Procedure
- Open your RHDH application and select a component from the Catalog page.
Go to the CI tab.
The CI tab displays the list of PipelineRun resources associated with a Kubernetes cluster. The list contains pipeline run details, such as NAME, VULNERABILITIES, STATUS, TASK STATUS, STARTED, and DURATION.
Click the expand row button besides PipelineRun name in the list to view the PipelineRun visualization. The pipeline run resource includes tasks to complete. When you hover the mouse pointer on a task card, you can view the steps to complete that particular task.
2.7. Enabling and configuring Argo CD plugin
You can use the Argo CD plugin to visualize the Continuous Delivery (CD) workflows in OpenShift GitOps. This plugin provides a visual overview of the application’s status, deployment details, commit message, author of the commit, container image promoted to environment and deployment history.
2.7.1. For administrators
2.7.1.1. Enabling Argo CD plugin
Prerequisites
Add Argo CD instance information to your
app-config.yamlconfigmap as shown in the following example:argocd: appLocatorMethods: - type: 'config' instances: - name: argoInstance1 url: https://argoInstance1.com username: ${ARGOCD_USERNAME} password: ${ARGOCD_PASSWORD} - name: argoInstance2 url: https://argoInstance2.com username: ${ARGOCD_USERNAME} password: ${ARGOCD_PASSWORD}Add the following annotation to the entity’s
catalog-info.yamlfile to identify the Argo CD applications.annotations: ... # The label that Argo CD uses to fetch all the applications. The format to be used is label.key=label.value. For example, rht-gitops.com/janus-argocd=quarkus-app. argocd/app-selector: '${ARGOCD_LABEL_SELECTOR}'(Optional) Add the following annotation to the entity’s
catalog-info.yamlfile to switch between Argo CD instances as shown in the following example:annotations: ... # The Argo CD instance name used in `app-config.yaml`. argocd/instance-name: '${ARGOCD_INSTANCE}'NoteIf you do not set this annotation, the Argo CD plugin defaults to the first Argo CD instance configured in
app-config.yaml.
Procedure
Add the following to your dynamic-plugins ConfigMap to enable the Argo CD plugin.
global: dynamic: includes: - dynamic-plugins.default.yaml plugins: - package: ./dynamic-plugins/dist/roadiehq-backstage-plugin-argo-cd-backend-dynamic disabled: false - package: ./dynamic-plugins/dist/janus-idp-backstage-plugin-argocd disabled: false
2.7.2. For Users
Prerequisites
- You have enabled the Argo CD plugin in Red Hat Developer Hub RHDH.
Procedures
- Select the Catalog tab and choose the component that you want to use.
Select the CD tab to view insights into deployments managed by Argo CD.
Select an appropriate card to view the deployment details (for example, commit message, author name, and deployment history).
-
Click the link icon (
) to open the deployment details in Argo CD.
-
Click the link icon (
Select the Overview tab and navigate to the Deployment summary section to review the summary of your application’s deployment across namespaces. Additionally, select an appropriate Argo CD app to open the deployment details in Argo CD, or select a commit ID from the Revision column to review the changes in GitLab or GitHub.
Additional resources
- For more information on dynamic plugins, see Dynamic plugin installation.