Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
×

Deploy your plugin on a cluster

Build an image with Docker

To deploy your plugin on a cluster, you need to build an image and push it to an image registry.

Procedure

  1. Build the image with the following command:

    $ docker build -t quay.io/my-repositroy/my-plugin:latest .

  2. Optional: If you want to test your image, run the following command:

    $ docker run -it --rm -d -p 9001:80 quay.io/my-repository/my-plugin:latest

  3. Push the image by running the following command:

    $ docker push quay.io/my-repository/my-plugin:latest

Deploy your plugin on a cluster

After pushing an image with your changes to a registry, you can deploy the plugin to a cluster.

Procedure

  1. To deploy your plugin to a cluster, install a Helm chart with the name of the plugin as the Helm release name into a new namespace or an existing namespace as specified by the -n command-line option. Provide the location of the image within the plugin.image parameter by using the following command:

    $ helm upgrade -i  my-plugin charts/openshift-console-plugin -n my-plugin-namespace --create-namespace --set plugin.image=my-plugin-image-location

    Where:

    n <my-plugin-namespace>

    Specifies an existing namespace to deploy your plugin into.

    --create-namespace

    Optional: If deploying to a new namespace, use this parameter.

    --set plugin.image=my-plugin-image-location

    Specifies the location of the image within the plugin.image parameter.

  2. Optional: You can specify any additional parameters by using the set of supported parameters in the charts/openshift-console-plugin/values.yaml file.

    plugin:
  name: ""
  description: ""
  image: ""
  imagePullPolicy: IfNotPresent
  replicas: 2
  port: 9443
  securityContext:
    enabled: true
  podSecurityContext:
    enabled: true
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containerSecurityContext:
    enabled: true
    allowPrivilegeEscalation: false
    capabilities:
      drop:
        - ALL
  resources:
    requests:
      cpu: 10m
      memory: 50Mi
  basePath: /
  certificateSecretName: ""
  serviceAccount:
    create: true
    annotations: {}
    name: ""
  patcherServiceAccount:
    create: true
    annotations: {}
    name: ""
  jobs:
    patchConsoles:
      enabled: true
      image: "registry.redhat.io/openshift4/ose-tools-rhel8@sha256:e44074f21e0cca6464e50cb6ff934747e0bd11162ea01d522433a1a1ae116103"
      podSecurityContext:
        enabled: true
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containerSecurityContext:
        enabled: true
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
      resources:
        requests:
          cpu: 10m
          memory: 50Mi
Verification

  • View the list of enabled plugins by navigating from Administration → Cluster Settings → Configuration → Console operator.openshift.io → Console plugins or by visiting the Overview page.

It can take a few minutes for the new plugin configuration to appear. If you do not see your plugin, you might need to refresh your browser if the plugin was recently enabled. If you receive any errors at runtime, check the JS console in browser developer tools to look for any errors in your plugin code.

Plugin service proxy

If you need to make HTTP requests to an in-cluster service from your plugin, you can declare a service proxy in its ConsolePlugin resource by using the spec.proxy array field. The console backend exposes the /api/proxy/plugin/<plugin-name>/<proxy-alias>/<request-path>?<optional-query-parameters> endpoint to proxy the communication between the plugin and the service. A proxied request uses a service CA bundle by default. The service must use HTTPS.

The plugin must use the consolefetch API to make requests from its JavaScript code or some requests might fail. For more information, see "Dynamic plugin API".

For each entry, you must specify an endpoint and alias of the proxy under the endpoint and alias fields. For the Service proxy type, you must set the endpoint type field to Service and the service must include values for the name, namespace, and port fields. For example, /api/proxy/plugin/helm/helm-charts/releases?limit=10 is a proxy request path from the helm plugin with a helm-charts service that lists ten helm releases.

Example service proxy
apiVersion: console.openshift.io/v1
kind: ConsolePlugin
metadata:
  name:<plugin-name>
spec:
  proxy:
  - alias: helm-charts (1)
    authorization: UserToken (2)
    caCertificate: '-----BEGIN CERTIFICATE-----\nMIID....'en (3)
    endpoint: (4)
      service:
        name: <service-name>
        namespace: <service-namespace>
        port: <service-port>
      type: Service
1 Alias of the proxy.
2 If the service proxy request must contain the logged-in user’s OKD access token, you must set the authorization field to UserToken.

If the service proxy request does not contain the logged-in user’s OKD access token, set the authorization field to None.
3 If the service uses a custom service CA, the caCertificate field must contain the certificate bundle.
4 Endpoint of the proxy.
Additional resources

Disabling your plugin in the browser

Console users can use the disable-plugins query parameter to disable specific or all dynamic plugins that would normally get loaded at run-time.

Procedure

  • To disable a specific plugin(s), remove the plugin you want to disable from the comma-separated list of plugin names.

  • To disable all plugins, leave an empty string in the disable-plugins query parameter.

Cluster administrators can disable plugins in the Cluster Settings page of the web console

Additional resources