Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Installing and viewing plugins in Red Hat Developer Hub

Red Hat Developer Hub 1.4

Red Hat Customer Content Services

Abstract

Administrative users can install and configure plugins to enable other users to use plugins to extend RHDH functionality.

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.

Note

If the pluginConfig field references environment variables, you must define the variables in your <my_product_secrets> secret.

Procedure

  1. From the OpenShift Container Platform web console, select the ConfigMaps tab.
  2. Click Create ConfigMap.

  3. 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 plugin

    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 Toggle word wrap

  4. Click Create.
  5. Go to the Topology view.

  6. 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.

    operator install 2

  7. Add the dynamicPluginsConfigMapName field to your Backstage CR. For example: 

    apiVersion: rhdh.redhat.com/v1alpha3
kind: Backstage
metadata:
  name: my-rhdh
spec:
  application:
# ...
    dynamicPluginsConfigMapName: dynamic-plugins-rhdh
# ...
    Copy to Clipboard Toggle word wrap
  8. Click Save.
  9. Navigate back to the Topology view and wait for the Red Hat Developer Hub pod to start.
  10. 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"
  },
]
    Copy to Clipboard Toggle word wrap

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 include sha256, sha384 and sha512.
    • pluginConfig: an optional plugin-specific app-config.yaml YAML fragment. See plugin configuration for more information.
    • disabled: disables the dynamic plugin if set to true. Default: false.
  • includes: a list of YAML files utilizing the same syntax.
Note

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: ...
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
1 

type: Opaque
stringData:
  .npmrc: |
    registry=<registry-url>
    //<registry-url>:_authToken=<auth-token>
          ...
Copy to Clipboard Toggle word wrap
1
Replace <release_name> with your Helm release name. This name is a unique identifier for each chart installation in the Kubernetes cluster.

Chapter 2. Third-party plugins in Red Hat Developer Hub
링크 복사

You can integrate third-party dynamic plugins into Red Hat Developer Hub to enhance its functionality without modifying its source code or rebuilding it. To add these plugins, export them as derived packages.

While exporting the plugin package, you must ensure that dependencies are correctly bundled or marked as shared, depending on their relationship to the Developer Hub environment.

To integrate a third-party plugin into Developer Hub:

  1. First, obtain the plugin’s source code.
  2. Export the plugin as a dynamic plugin package. See Section 2.1, “Exporting third-party plugins in Red Hat Developer Hub”.
  3. Package and publish the dynamic plugin. See Section 2.2, “Packaging and publishing third-party plugins as dynamic plugins”.
  4. Install the plugin in the Developer Hub environment. See Section 2.3, “Installing third-party plugins in Red Hat Developer Hub”.

2.1. Exporting third-party plugins in Red Hat Developer Hub
링크 복사

To use plugins in Red Hat Developer Hub, you can export plugins as derived dynamic plugin packages. These packages contain the plugin code and dependencies, ready for dynamic plugin integration into Developer Hub.

Prerequisites

  • The @janus-idp/cli package is installed. Use the latest version (@latest tag) for compatibility with the most recent features and fixes.
  • Node.js and NPM is installed and configured.
  • The third-party plugin is compatible with your Red Hat Developer Hub version. For more information, see Version compatibility matrix.

  • The third-party plugin must have a valid package.json file in its root directory, containing all required metadata and dependencies.

    Backend plugins

    To ensure compatibility with the dynamic plugin support and enable their use as dynamic plugins, existing backend plugins must be compatible with the new Backstage backend system. Additionally, these plugins must be rebuilt using a dedicated CLI command.

    The new Backstage backend system entry point (created using createBackendPlugin() or createBackendModule()) must be exported as the default export from either the main package or an alpha package (if the plugin instance support is still provided using alpha APIs). This doesn’t add any additional requirement on top of the standard plugin development guidelines of the plugin instance.

    The dynamic export mechanism identifies private dependencies and sets the bundleDependencies field in the package.json file. This export mechanism ensures that the dynamic plugin package is published as a self-contained package, with its private dependencies bundled in a private node_modules folder.

    Certain plugin dependencies require specific handling in the derived packages, such as:

    • Shared dependencies are provided by the RHDH application and listed as peerDependencies in package.json file, not bundled in the dynamic plugin package. For example, by default, all @backstage scoped packages are shared.

      You can use the --shared-package flag to specify shared dependencies, that are expected to be provided by Red Hat Developer Hub application and not bundled in the dynamic plugin package.

      To treat a @backstage package as private, use the negation prefix (!). For example, when a plugin depends on the package in @backstage that is not provided by the Red Hat Developer Hub application.

    • Embedded dependencies are bundled into the dynamic plugin package with their dependencies hoisted to the top level. By default, packages with -node or -common suffixes are embedded.

      You can use the --embed-package flag to specify additional embedded packages. For example, packages from the same workspace that do not follow the default naming convention.

      The following is an example of exporting a dynamic plugin with shared and embedded packages:

      Example dynamic plugin export with shared and embedded packages

      npx @janus-idp/cli@latest export-dynamic-plugin --shared-package '!/@backstage/plugin-notifications/' --embed-package @backstage/plugin-notifications-backend
      Copy to Clipboard Toggle word wrap

      In the previous example:

    • @backstage/plugin-notifications package is treated as a private dependency and is bundled in the dynamic plugin package, despite being in the @backstage scope.
    • @backstage/plugin-notifications-backend package is marked as an embedded dependency and is bundled in the dynamic plugin package.
    Front-end plugins

    Front-end plugins can use scalprum for configuration, which the CLI can generate automatically during the export process. The generated default configuration is logged when running the following command:

    Example command to log the default configuration

    npx @janus-idp/cli@latest export-dynamic
    Copy to Clipboard Toggle word wrap

    The following is an example of default scalprum configuration:

    Default scalprum configuration

    "scalprum": {
  "name": "<package_name>",  // The Webpack container name matches the NPM package name, with "@" replaced by "." and "/" removed.
  "exposedModules": {
    "PluginRoot": "./src/index.ts"  // The default module name is "PluginRoot" and doesn't need explicit specification in the app-config.yaml file.
  }
}
    Copy to Clipboard Toggle word wrap

    You can add a scalprum section to the package.json file. For example:

    Example scalprum customization

    "scalprum": {
  "name": "custom-package-name",
  "exposedModules": {
    "FooModuleName": "./src/foo.ts",
    "BarModuleName": "./src/bar.ts"
    // Define multiple modules here, with each exposed as a separate entry point in the Webpack container.
  }
}
    Copy to Clipboard Toggle word wrap

    Dynamic plugins might need adjustments for Developer Hub needs, such as static JSX for mountpoints or dynamic routes. These changes are optional but might be incompatible with static plugins.

    To include static JSX, define an additional export and use it as the dynamic plugin’s importName. For example:

    Example static and dynamic plugin export

    // For a static plugin
export const EntityTechdocsContent = () => {...}

// For a dynamic plugin
export const DynamicEntityTechdocsContent = {
  element: EntityTechdocsContent,
  staticJSXContent: (
    <TechDocsAddons>
      <ReportIssue />
    </TechDocsAddons>
  ),
};
    Copy to Clipboard Toggle word wrap

Procedure

  • Use the package export-dynamic-plugin command from the @janus-idp/cli package to export the plugin:

    Example command to export a third-party plugin

    npx @janus-idp/cli@latest package export-dynamic-plugin
    Copy to Clipboard Toggle word wrap

    Ensure that you execute the previous command in the root directory of the plugin’s JavaScript package (containing package.json file).

    The resulting derived package will be located in the dist-dynamic subfolder. The exported package name consists of the original plugin name with -dynamic appended.

    Warning

    The derived dynamic plugin JavaScript packages must not be published to the public NPM registry. For more appropriate packaging options, see Section 2.2, “Packaging and publishing third-party plugins as dynamic plugins”. If you must publish to the NPM registry, use a private registry.

2.2. Packaging and publishing third-party plugins as dynamic plugins
링크 복사

After exporting a third-party plugin, you can package the derived package into one of the following supported formats:

  • Open Container Initiative (OCI) image (recommended)
  • TGZ file

  • JavaScript package

    Important

    Exported dynamic plugin packages must only be published to private NPM registries.

2.2.1. Creating an OCI image with dynamic packages
링크 복사

Prerequisites

Procedure

  1. Navigate to the plugin’s root directory (not the dist-dynamic directory).

  2. Run the following command to package the plugin into an OCI image:

    Example command to package an exported third-party plugin

    npx @janus-idp/cli@latest package package-dynamic-plugins --tag quay.io/example/image:v0.0.1
    Copy to Clipboard Toggle word wrap

    In the previous command, the --tag argument specifies the image name and tag.

  3. Run one of the following commands to push the image to a registry:

    Example command to push an image to a registry using podman

    podman push quay.io/example/image:v0.0.1
    Copy to Clipboard Toggle word wrap

    Example command to push an image to a registry using docker

    docker push quay.io/example/image:v0.0.1
    Copy to Clipboard Toggle word wrap

    The output of the package-dynamic-plugins command provides the plugin’s path for use in the dynamic-plugin-config.yaml file.

2.2.2. Creating a TGZ file with dynamic packages
링크 복사

Prerequisites

Procedure

  1. Navigate to the dist-dynamic directory.

  2. Run the following command to create a tgz archive:

    Example command to create a tgz archive

    npm pack
    Copy to Clipboard Toggle word wrap

    You can obtain the integrity hash from the output of the npm pack command by using the --json flag as follows:

    Example command to obtain the integrity hash of a tgz archive

    npm pack --json | head -n 10
    Copy to Clipboard Toggle word wrap

  3. Host the archive on a web server accessible to your RHDH instance, and reference its URL in the dynamic-plugin-config.yaml file as follows:

    Example dynamic-plugin-config.yaml file

    plugins:
  - package: https://example.com/backstage-plugin-myplugin-1.0.0.tgz
    integrity: sha512-<hash>
    Copy to Clipboard Toggle word wrap

  4. Run the following command to package the plugins:

    Example command to package a dynamic plugin

    npm pack --pack-destination ~/test/dynamic-plugins-root/
    Copy to Clipboard Toggle word wrap

    Tip

    To create a plugin registry using HTTP server on OpenShift Container Platform, run the following commands:

    Example commands to build and deploy an HTTP server in OpenShift Container Platform

    oc project my-rhdh-project
oc new-build httpd --name=plugin-registry --binary
oc start-build plugin-registry --from-dir=dynamic-plugins-root --wait
oc new-app --image-stream=plugin-registry
    Copy to Clipboard Toggle word wrap

  5. Configure your RHDH to use plugins from the HTTP server by editing the dynamic-plugin-config.yaml file:

    Example configuration to use packaged plugins in RHDH

    plugins:
  - package: http://plugin-registry:8080/backstage-plugin-myplugin-1.9.6.tgz
    Copy to Clipboard Toggle word wrap

2.2.3. Creating a JavaScript package with dynamic packages
링크 복사

Warning

The derived dynamic plugin JavaScript packages must not be published to the public NPM registry. If you must publish to the NPM registry, use a private registry.

Prerequisites

Procedure

  1. Navigate to the dist-dynamic directory.

  2. Run the following command to publish the package to your private NPM registry:

    Example command to publish a plugin package to an NPM registry

    npm publish --registry <npm_registry_url>
    Copy to Clipboard Toggle word wrap

    Tip

    You can add the following to your package.json file before running the export command:

    Example package.json file

    {
  "publishConfig": {
    "registry": "<npm_registry_url>"
  }
}
    Copy to Clipboard Toggle word wrap

    If you modify publishConfig after exporting the dynamic plugin, re-run the export-dynamic-plugin command to ensure the correct configuration is included.

2.3. Installing third-party plugins in Red Hat Developer Hub
링크 복사

You can install a third-party plugins in Red Hat Developer Hub without rebuilding the RHDH application.

The location of the dynamic-plugin-config.yaml file depends on the deployment method. For more details, refer to Installing dynamic plugins with the Red Hat Developer Hub Operator and Installing dynamic plugins using the Helm chart.

Plugins are defined in the plugins array within the dynamic-plugin-config.yaml file. Each plugin is represented as an object with the following properties:

  • package: The plugin’s package definition, which can be an OCI image, a TGZ file, a JavaScript package, or a directory path.
  • disabled: A boolean value indicating whether the plugin is enabled or disabled.
  • integrity: The integrity hash of the package, required for TGZ file and JavaScript packages.
  • pluginConfig: The plugin’s configuration. For backend plugins, this is optional; for frontend plugins, it is required. The pluginConfig is a fragment of the app-config.yaml file, and any added properties are merged with the RHDH app-config.yaml file.
Note

You can also load dynamic plugins from another directory, though this is intended for development or testing purposes and is not recommended for production, except for plugins included in the RHDH container image. For more information, see Chapter 3, Enabling plugins added in the RHDH container image.

2.3.1. Loading a plugin packaged as an OCI image
링크 복사

Prerequisites

Procedure

  1. Define the plugin with the oci:// prefix in the following format in dynamic-plugins.yaml file:

    oci://<image-name>:<tag>!<plugin-name>

    Example configuration in dynamic-plugins.yaml file

    plugins:
  - disabled: false
    package: oci://quay.io/example/image:v0.0.1!backstage-plugin-myplugin
    Copy to Clipboard Toggle word wrap

  2. Configure authentication for private registries by setting the REGISTRY_AUTH_FILE environment variable to the path of the registry configuration file. For example, ~/.config/containers/auth.json or ~/.docker/config.json.

  3. To perform an integrity check, use the image digest in place of the tag in the dynamic-plugins.yaml file as follows:

    Example configuration in dynamic-plugins.yaml file

    plugins:
  - disabled: false
    package: oci://quay.io/example/image@sha256:28036abec4dffc714394e4ee433f16a59493db8017795049c831be41c02eb5dc!backstage-plugin-myplugin
    Copy to Clipboard Toggle word wrap

  4. To apply the changes, restart the RHDH application.

2.3.2. Loading a plugin packaged as a TGZ file
링크 복사

Prerequisites

Procedure

  1. Specify the archive URL and its integrity hash in the dynamic-plugins.yaml file using the following example:

    Example configuration in dynamic-plugins.yaml file

    plugins:
  - disabled: false
    package: https://example.com/backstage-plugin-myplugin-1.0.0.tgz
    integrity: sha512-9WlbgEdadJNeQxdn1973r5E4kNFvnT9GjLD627GWgrhCaxjCmxqdNW08cj+Bf47mwAtZMt1Ttyo+ZhDRDj9PoA==
    Copy to Clipboard Toggle word wrap

  2. To apply the changes, restart the RHDH application.

2.3.3. Loading a plugin packaged as a JavaScript package
링크 복사

Prerequisites

Procedure

  1. Run the following command to obtain the integrity hash from the NPM registry: 

    npm view --registry <registry-url> <npm package>@<version> dist.integrity
    Copy to Clipboard Toggle word wrap

  2. Specify the package name, version, and its integrity hash in the dynamic-plugins.yaml file as follows:

    Example configuration in dynamic-plugins.yaml file

    plugins:
  - disabled: false
    package: @example/backstage-plugin-myplugin@1.0.0
    integrity: sha512-9WlbgEdadJNeQxdn1973r5E4kNFvnT9GjLD627GWgrhCaxjCmxqdNW08cj+Bf47mwAtZMt1Ttyo+ZhDRDj9PoA==
    Copy to Clipboard Toggle word wrap

  3. If you are using a custom NPM registry, create a .npmrc file with the registry URL and authentication details:

    Example code for .npmrc file

    registry=<registry-url>
//<registry-url>:_authToken=<auth-token>
    Copy to Clipboard Toggle word wrap

  4. When using OpenShift Container Platform or Kubernetes:

    • Use the Helm chart to add the .npmrc file by creating a secret. For example:

      Example secret configuration

      apiVersion: v1
kind: Secret
metadata:
  name: <release_name>-dynamic-plugins-npmrc
      1 
      
type: Opaque
stringData:
  .npmrc: |
    registry=<registry-url>
    //<registry-url>:_authToken=<auth-token>
      Copy to Clipboard Toggle word wrap

      1
      Replace <release_name> with your Helm release name. This name is a unique identifier for each chart installation in the Kubernetes cluster.

    • For RHDH Helm chart, name the secret using the following format for automatic mounting:

      <release_name>-dynamic-plugins-npmrc

  5. To apply the changes, restart the RHDH application.

2.3.4. Example of installing a third-party plugin in Red Hat Developer Hub
링크 복사

This section describes the process for integrating the Todo plugin into your Developer Hub.

  1. Obtain the third-party plugin source code: Clone the plugins repository and navigate to the Todo plugin directory:

    Obtain the third-party plugin source code

    $ git clone https://github.com/backstage/community-plugins
$ cd community-plugins/workspaces/todo
$ yarn install
    Copy to Clipboard Toggle word wrap

  2. Export backend and front-end plugins: Run the following commands to build the backend plugin, adjust package dependencies for dynamic loading, and generate self-contained configuration schema:

    Export the backend plugin

    $ cd todo-backend
$ npx @janus-idp/cli@latest package export-dynamic-plugin
    Copy to Clipboard Toggle word wrap

    Output of exporting the backend plugin commands

    Building main package
  executing     yarn build ✔
Packing main package to dist-dynamic/package.json
Customizing main package in dist-dynamic/package.json for dynamic loading
  moving @backstage/backend-common to peerDependencies
  moving @backstage/backend-openapi-utils to peerDependencies
  moving @backstage/backend-plugin-api to peerDependencies
  moving @backstage/catalog-client to peerDependencies
  moving @backstage/catalog-model to peerDependencies
  moving @backstage/config to peerDependencies
  moving @backstage/errors to peerDependencies
  moving @backstage/integration to peerDependencies
  moving @backstage/plugin-catalog-node to peerDependencies
Installing private dependencies of the main package
   executing     yarn install --no-immutable ✔
Validating private dependencies
Validating plugin entry points
Saving self-contained config schema in /Users/user/Code/community-plugins/workspaces/todo/plugins/todo-backend/dist-dynamic/dist/configSchema.json
    Copy to Clipboard Toggle word wrap

    You can run the following commands to set default dynamic UI configurations, create front-end plugin assets, and to generate a configuration schema for a front-end plugin:

    Export the front-end plugin

    $ cd ../todo
$ npx @janus-idp/cli@latest package export-dynamic-plugin
    Copy to Clipboard Toggle word wrap

    Output of exporting the front-end plugin commands

    No scalprum config. Using default dynamic UI configuration:
{
  "name": "backstage-community.plugin-todo",
  "exposedModules": {
    "PluginRoot": "./src/index.ts"
  }
}
If you wish to change the defaults, add "scalprum" configuration to plugin "package.json" file, or use the '--scalprum-config' option to specify an external config.
Packing main package to dist-dynamic/package.json
Customizing main package in dist-dynamic/package.json for dynamic loading
Generating dynamic frontend plugin assets in /Users/user/Code/community-plugins/workspaces/todo/plugins/todo/dist-dynamic/dist-scalprum
  263.46 kB  dist-scalprum/static/1417.d5271413.chunk.js
...
...
...
  250 B      dist-scalprum/static/react-syntax-highlighter_languages_highlight_plaintext.0b7d6592.chunk.js
Saving self-contained config schema in /Users/user/Code/community-plugins/workspaces/todo/plugins/todo/dist-dynamic/dist-scalprum/configSchema.json
    Copy to Clipboard Toggle word wrap

  3. Package and publish a third-party plugin: Run the following commands to navigate to the workspace directory and package the dynamic plugin to build the OCI image:

    Build an OCI image

    $ cd ../..
$ npx @janus-idp/cli@latest package package-dynamic-plugins --tag quay.io/user/backstage-community-plugin-todo:v0.1.1
    Copy to Clipboard Toggle word wrap

    Output of building an OCI image commands

      executing     podman --version ✔
Using existing 'dist-dynamic' directory at plugins/todo
Using existing 'dist-dynamic' directory at plugins/todo-backend
Copying 'plugins/todo/dist-dynamic' to '/var/folders/5c/67drc33d0018j6qgtzqpcsbw0000gn/T/package-dynamic-pluginsmcP4mU/backstage-community-plugin-todo
No plugin configuration found at undefined create this file as needed if this plugin requires configuration
Copying 'plugins/todo-backend/dist-dynamic' to '/var/folders/5c/67drc33d0018j6qgtzqpcsbw0000gn/T/package-dynamic-pluginsmcP4mU/backstage-community-plugin-todo-backend-dynamic
No plugin configuration found at undefined create this file as needed if this plugin requires configuration
Writing plugin registry metadata to '/var/folders/5c/67drc33d0018j6qgtzqpcsbw0000gn/T/package-dynamic-pluginsmcP4mU/index.json'
Creating image using podman
  executing     echo "from scratch
COPY . .
" | podman build --annotation com.redhat.rhdh.plugins='[{"backstage-community-plugin-todo":{"name":"@backstage-community/plugin-todo","version":"0.2.40","description":"A Backstage plugin that lets you browse TODO comments in your source code","backstage":{"role":"frontend-plugin","pluginId":"todo","pluginPackages":["@backstage-community/plugin-todo","@backstage-community/plugin-todo-backend"]},"homepage":"https://backstage.io","repository":{"type":"git","url":"https://github.com/backstage/community-plugins","directory":"workspaces/todo/plugins/todo"},"license":"Apache-2.0"}},{"backstage-community-plugin-todo-backend-dynamic":{"name":"@backstage-community/plugin-todo-backend","version":"0.3.19","description":"A Backstage backend plugin that lets you browse TODO comments in your source code","backstage":{"role":"backend-plugin","pluginId":"todo","pluginPackages":["@backstage-community/plugin-todo","@backstage-community/plugin-todo-backend"]},"homepage":"https://backstage.io","repository":{"type":"git","url":"https://github.com/backstage/community-plugins","directory":"workspaces/todo/plugins/todo-backend"},"license":"Apache-2.0"}}]' -t 'quay.io/user/backstage-community-plugin-todo:v0.1.1' -f - .
    ✔
Successfully built image quay.io/user/backstage-community-plugin-todo:v0.1.1 with following plugins:
  backstage-community-plugin-todo
  backstage-community-plugin-todo-backend-dynamic

Here is an example dynamic-plugins.yaml for these plugins:

plugins:
  - package: oci://quay.io/user/backstage-community-plugin-todo:v0.1.1!backstage-community-plugin-todo
    disabled: false
  - package: oci://quay.io/user/backstage-community-plugin-todo:v0.1.1!backstage-community-plugin-todo-backend-dynamic
    disabled: false
    Copy to Clipboard Toggle word wrap

    Push the OCI image to a container registry:

    $ podman push quay.io/user/backstage-community-plugin-todo:v0.1.1
    Copy to Clipboard Toggle word wrap

    Output of pushing the OCI image command

    Getting image source signatures
Copying blob sha256:86a372c456ae6a7a305cd464d194aaf03660932efd53691998ab3403f87cacb5
Copying config sha256:3b7f074856ecfbba95a77fa87cfad341e8a30c7069447de8144aea0edfcb603e
Writing manifest to image destination
    Copy to Clipboard Toggle word wrap

  4. Install and configure the third-party plugin: Add the following plugin definitions to your dynamic-plugins.yaml file:

    Plugin definitions in dynamic-plugins.yaml file

    packages:
 - package: oci://quay.io/user/backstage-community-plugin-todo:v0.1.1!backstage-community-plugin-todo
   pluginConfig:
     dynamicPlugins:
       frontend:
         backstage-community.plugin-todo:
           mountPoints:
             - mountPoint: entity.page.todo/cards
               importName: EntityTodoContent
           entityTabs:
             - path: /todo
               title: Todo
               mountPoint: entity.page.todo
 - package: oci://quay.io/user/backstage-community-plugin-todo:v0.1.1!backstage-community-plugin-todo-backend-dynamic
   disabled: false
    Copy to Clipboard Toggle word wrap

Chapter 3. Enabling plugins added in the RHDH container image
링크 복사

In the RHDH container image, a set of dynamic plugins is preloaded to enhance functionality. However, due to mandatory configuration requirements, most of the plugins are disabled.

You can enable and configure the plugins in the RHDH container image, including how to manage the default configuration, set necessary environment variables, and ensure the proper functionality of the plugins within your application.

Prerequisites

  • You have access to the dynamic-plugins.default.yaml file, which lists all preloaded plugins and their default configuration.
  • You have deployed the RHDH application, and have access to the logs of the install-dynamic-plugins init container.
  • You have the necessary permissions to modify plugin configurations and access the application environment.
  • You have identified and set the required environment variables referenced by the plugin’s default configuration. These environment variables must be defined in the Helm Chart or Operator configuration.

Procedure

  1. Start your RHDH application and access the logs of the install-dynamic-plugins init container within the RHDH pod.
  2. Identify the Red Hat supported plugins that are disabled by default.
  3. Copy the package configuration from the dynamic-plugins.default.yaml file.

  4. Open the plugin configuration file and locate the plugin entry you want to enable.

    The location of the plugin configuration file varies based on the deployment method. For more details, see Installing dynamic plugins with the Red Hat Developer Hub Operator and Installing dynamic plugins using the Helm chart.

  5. Modify the disabled field to false and add the package name as follows:

    Example plugin configuration

    plugins:
  - disabled: false
    package: ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic
    Copy to Clipboard Toggle word wrap

    For more information about how to configure dynamic plugins in Developer Hub, see Installing dynamic plugins in Red Hat Developer Hub.

Verification

  1. Restart the RHDH application and verify that the plugin is successfully activated and configured.
  2. Verify the application logs for confirmation and ensure the plugin is functioning as expected.

Chapter 4. Viewing installed plugins
링크 복사

Using the Dynamic Plugins Info front-end plugin, you can view plugins that are currently installed in your Red Hat Developer Hub application. This plugin is enabled by default.

Procedure

  1. Open your Developer Hub application and click Administration.
  2. Go to the Plugins tab to view a list of installed plugins and related information.

Legal Notice
링크 복사

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat맨 위로 이동