This documentation is for a release that is no longer maintained
See documentation for the latest supported version.Chapter 1. Installing dynamic plugins in Red Hat Developer Hub
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.yaml
file) 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.
1.1. Installing dynamic plugins with the Red Hat Developer Hub Operator
You can store the configuration for dynamic plugins in a ConfigMap
object that your Backstage
custom resource (CR) can reference.
If the pluginConfig
field references environment variables, you must define the variables in your <my_product_secrets>
secret.
Procedure
- From the OpenShift Container Platform web console, select the ConfigMaps tab.
- Click Create ConfigMap.
From the Create ConfigMap page, select the YAML view option in Configure via and edit the file, if needed.
Example
ConfigMap
object using the GitHub dynamic pluginkind: ConfigMap apiVersion: v1 metadata: name: dynamic-plugins-rhdh data: dynamic-plugins.yaml: | includes: - dynamic-plugins.default.yaml plugins: - package: './dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic' disabled: false pluginConfig: catalog: providers: github: organization: "${GITHUB_ORG}" schedule: frequency: { minutes: 1 } timeout: { minutes: 1 } initialDelay: { seconds: 100 }
kind: ConfigMap apiVersion: v1 metadata: name: dynamic-plugins-rhdh data: dynamic-plugins.yaml: | includes: - dynamic-plugins.default.yaml plugins: - package: './dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic' disabled: false pluginConfig: catalog: providers: github: organization: "${GITHUB_ORG}" schedule: frequency: { minutes: 1 } timeout: { minutes: 1 } initialDelay: { seconds: 100 }
Copy to Clipboard Copied! - Click Create.
- Go to the Topology view.
Click on the overflow menu for the Red Hat Developer Hub instance that you want to use and select Edit Backstage to load the YAML view of the Red Hat Developer Hub instance.
Add the
dynamicPluginsConfigMapName
field to yourBackstage
CR. For example:apiVersion: rhdh.redhat.com/v1alpha3 kind: Backstage metadata: name: my-rhdh spec: application: # ... dynamicPluginsConfigMapName: dynamic-plugins-rhdh # ...
apiVersion: rhdh.redhat.com/v1alpha3 kind: Backstage metadata: name: my-rhdh spec: application: # ... dynamicPluginsConfigMapName: dynamic-plugins-rhdh # ...
Copy to Clipboard Copied! - Click Save.
- Navigate back to the Topology view and wait for the Red Hat Developer Hub pod to start.
- Click the Open URL icon to start using the Red Hat Developer Hub platform with the new configuration changes.
Verification
Ensure that the dynamic plugins configuration has been loaded, by appending
/api/dynamic-plugins-info/loaded-plugins
to your Red Hat Developer Hub root URL and checking the list of plugins:Example list of plugins
[ { "name": "backstage-plugin-catalog-backend-module-github-dynamic", "version": "0.5.2", "platform": "node", "role": "backend-plugin-module" }, { "name": "backstage-plugin-techdocs", "version": "1.10.0", "role": "frontend-plugin", "platform": "web" }, { "name": "backstage-plugin-techdocs-backend-dynamic", "version": "1.9.5", "platform": "node", "role": "backend-plugin" }, ]
[ { "name": "backstage-plugin-catalog-backend-module-github-dynamic", "version": "0.5.2", "platform": "node", "role": "backend-plugin-module" }, { "name": "backstage-plugin-techdocs", "version": "1.10.0", "role": "frontend-plugin", "platform": "web" }, { "name": "backstage-plugin-techdocs-backend-dynamic", "version": "1.9.5", "platform": "node", "role": "backend-plugin" }, ]
Copy to Clipboard Copied!
1.2. Installing dynamic plugins using the Helm chart
You can deploy a Developer Hub instance using a Helm chart, which is a flexible installation method. With the Helm chart, you can sideload dynamic plugins into your Developer Hub instance without having to recompile your code or rebuild the container.
To install dynamic plugins in Developer Hub using Helm, add the following global.dynamic
parameters in your Helm chart:
plugins
: the dynamic plugins list intended for installation. By default, the list is empty. You can populate the plugins list with the following fields:-
package
: a package specification for the dynamic plugin package that you want to install. You can use a package for either a local or an external dynamic plugin installation. For a local installation, use a path to the local folder containing the dynamic plugin. For an external installation, use a package specification from a public NPM repository. -
integrity
(required for external packages): an integrity checksum in the form of<alg>-<digest>
specific to the package. Supported algorithms includesha256
,sha384
andsha512
. -
pluginConfig
: an optional plugin-specificapp-config.yaml
YAML fragment. See plugin configuration for more information. -
disabled
: disables the dynamic plugin if set totrue
. Default:false
.
-
-
includes
: a list of YAML files utilizing the same syntax.
The plugins
list in the includes
file is merged with the plugins
list in the main Helm values. If a plugin package is mentioned in both plugins
lists, the plugins
fields in the main Helm values override the plugins
fields in the includes
file. The default configuration includes the dynamic-plugins.default.yaml
file, which contains all of the dynamic plugins preinstalled in Developer Hub, whether enabled or disabled by default.
1.2.1. Example Helm chart configurations for dynamic plugin installations
The following examples demonstrate how to configure the Helm chart for specific types of dynamic plugin installations.
Configuring a local plugin and an external plugin when the external plugin requires a specific configuration
global: dynamic: plugins: - package: <alocal package-spec used by npm pack> - package: <external package-spec used by npm pack> integrity: sha512-<some hash> pluginConfig: ...
global:
dynamic:
plugins:
- package: <alocal package-spec used by npm pack>
- package: <external package-spec used by npm pack>
integrity: sha512-<some hash>
pluginConfig: ...
Disabling a plugin from an included file
global: dynamic: includes: - dynamic-plugins.default.yaml plugins: - package: <some imported plugins listed in dynamic-plugins.default.yaml> disabled: true
global:
dynamic:
includes:
- dynamic-plugins.default.yaml
plugins:
- package: <some imported plugins listed in dynamic-plugins.default.yaml>
disabled: true
Enabling a plugin from an included file
global: dynamic: includes: - dynamic-plugins.default.yaml plugins: - package: <some imported plugins listed in dynamic-plugins.custom.yaml> disabled: false
global:
dynamic:
includes:
- dynamic-plugins.default.yaml
plugins:
- package: <some imported plugins listed in dynamic-plugins.custom.yaml>
disabled: false
Enabling a plugin that is disabled in an included file
global: dynamic: includes: - dynamic-plugins.default.yaml plugins: - package: <some imported plugins listed in dynamic-plugins.custom.yaml> disabled: false
global:
dynamic:
includes:
- dynamic-plugins.default.yaml
plugins:
- package: <some imported plugins listed in dynamic-plugins.custom.yaml>
disabled: false
1.3. Installing dynamic plugins in an air-gapped environment
You can install external plugins in an air-gapped environment by setting up a custom NPM registry.
You can configure the NPM registry URL and authentication information for dynamic plugin packages using a Helm chart. For dynamic plugin packages obtained through npm pack
, you can use a .npmrc
file.
Using the Helm chart, add the .npmrc
file to the NPM registry by creating a secret. For example:
apiVersion: v1 kind: Secret metadata: name: <release_name>-dynamic-plugins-npmrc type: Opaque stringData: .npmrc: | registry=<registry-url> //<registry-url>:_authToken=<auth-token> ...
apiVersion: v1
kind: Secret
metadata:
name: <release_name>-dynamic-plugins-npmrc
type: Opaque
stringData:
.npmrc: |
registry=<registry-url>
//<registry-url>:_authToken=<auth-token>
...
- 1
- Replace
<release_name>
with your Helm release name. This name is a unique identifier for each chart installation in the Kubernetes cluster.