Skip to content

TeraSky-OSS/backstage-plugins

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

26 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

TeraSky's Backstage Plugins

These plugins have been built for Backstage 1.34 and are a WIP.

Plugin overviews

There are 8 plugins currently:

  1. Kubernetes Ingestor - npm latest version - this plugin is a catalog entity provider which creates catalog entities directly from kubernetes resources. it has the ability to ingest by default all standard k8s workload types, allows supplying custom GVKs, and has the ability to auto-ingest all crossplane claims automatically as components. There are numerous annotations which can be put on the kubernetes workloads to influence the creation of the component in backstage. It also supports creating backstage templates and registers them in the catalog for every XRD in your cluster for the Claim resource type. currently this supports adding via a PR to a GitHub repo or providing a download link to the generated yaml without pushing to git.
  2. Crossplane Resource Frontend - npm latest version - this is a frontend plugin which provides visibility into the crossplane claim, composite resource and managed resources associated with a component. This relies heavily on system generated annotations from the Kubernetes Ingestor but technically does not require it if you add all the needed annotations manually. The plugin exposes general data, provides a YAML viewer for each resource including the ability to copy to clipboard the content or download the yaml file. It also supports viewing the events related to a specific resource. It also includes a graph view of the resources related to a claim.
  3. Crossplane Backend - npm latest version - This plugin implements the permission framework elements for the crossplane frontend plugin. This is needed as only backend plugins can add permissions in backstage. the plugin has no functionality beyond registering the permissions which are themselves configured in the common plugin as the definitions are also needed in the frontend where we enforce the permissions.
  4. Crossplane Common - npm latest version - This is a shared common library between the frontend and backend crossplane plugins where the permission definitions reside. This is not added into a backstage instance directly, rather it is a dependency of both of the other plugins.
  5. ScaleOps Frontend Plugin - npm latest version - this is a frontend plugin which displays basic data from scaleops regarding kubernetes entities on you component. it shows potential and realized savings, and can provide a link to the scaleops dashboard for more specific and broader data points. This plugin supports a single ScaleOps endpoint but does support multiCluster features in scaleops allowing for end to end visibility.
  6. Entity Scaffolder Plugin - npm latest version - This allows embedding a tab with scaffolder templates on a component. this can also populate the list of templates and data in the templates based on the context from which it is run.
  7. Devpod plugin - npm latest version - this plugin adds a grid item on the overview tab of components allowing for a "Open in Devpod" button. it supports allowing the user to choose the IDE it should open with, and also provides the CLI command the user could run to open it up from the command line.
  8. scaffolder actions - npm latest version - this is a package of multiple scaffolder actions:
  • terasky:claim-template - This action converts input parameters into a kubernetes yaml manifest for the crossplane claim and writes it to the filesystem of the action based on the format "<cluster>/<namespace>/<kind>/<name>.yaml"
  • terasky:catalog-info-cleaner - This action takes a backstage entity and cleans up runtime information and then outputs as a catalog-info.yaml file on the filesystem of the action the cleaned up manifest. This is usefull for auto ingested components that you want to enable a push to git of the manifest to allow for a full git based catalog management when needed.