In TAP 1.6 we got the first glance at the Tanzu Developer Portal (TDP) configurator.
While the idea was promising, the functionality was extremely limited, and was closer in my mind to a proof of concept then a true value add.
This has now completely changed in TAP 1.7, and we now have an amazing tool, which opens up huge potential for all TAP customers.
Before diving deep into the technical details lets discuss what the configurator tool is, and why we need it.
Quick History
Backstage is an amazing CNCF Project which is the base for the Tanzu Developer Portal (TDP) which was previously known as TAP GUI.
While since the initial GA of TAP, we have had a great portal, which has been enhanced with every release, the portal has not been able to take full advantage of the power of backstage.
Backstage is a highly extensible project, which is built on a plugin based model, and in the open source backstage world, more then 150 plugins have been published, allowing for integrations with many common tools present in customer environments.
The Tanzu Developer Portal Configurator tool, enables you to add plugins to Tanzu Developer Portal, turning it into a customized portal!
While on one hand, TDP till now has been very locked down, the experience of integrating plugins in OSS Backstage is very tedious, and is not for the light hearted, The TDP Configurator tool, is a great step in the direction of making integrating both third party plugins as well as custom in house built plugins a much more maintainable and simple task.
How does it work
The configurator tool, is actually run as a standard TAP workload, as we want to use the Tanzu Build Service capabilities to build our custom portal container image.
When building the custom portal image, we pass it the source bundle which contains the configurator code itself, as well as a base64 encoded string which is simply a list of “wrapper” plugins we want to have added to our portal.
The TDP Configurator takes the list of the plugins that you want to add into your portal. With that list, TDP Configurator generates a developer portal customized to your specifications.
The end result of the configurator, is an OCI image which can be referenced when deploying TAP and configured the same as with the OOTB TDP image, to provide a great experience with your own custom plugin setup to meet your organizations needs.
What is a wrapper plugin
One of the challenges around OSS backstage, and the integration of plugins, is that for every plugin you need to manually edit the code base of backstage itself to include your plugins.
This process is tedious and error prone, and the TDP configurator helps in this regard by introducing the concept of surfaces, and plugin wrappers.
A surface is a discrete capability that a plug-in provides. This can include:
- The ability to show up on the sidebar
- The ability to be accessed at a URL, such as
https://YOUR_PORTAL_URL/plugin - The ability to show up as a Catalog Overview tab
Basically with a wrapper, we have a defined specification where we can define how a plugin should be visualized within the portal itself.
A wrapper is a method of exposing a plugin’s surfaces to the TDP Configurator so that the plugin can be integrated into the portal.
A wrapper imports a reference to the underlying plugin and defines the surfaces that the plugin should expose.
VMware provided wrapper plugins
In TAP 1.7, VMware have released an initial list of validated community plugin wrappers, and have published them to the public npm.js registry for all to use.
The current list of the 9 VMware validated plugins is:
- Github Actions – allows for a simple way to see the github action runs for your component and view the logs, and status of each job
- Grafana – this plugin allows easily exposing grafana alerts and links to dashboards related to a component directly on the components overview page
- Home – this plugin allows users to customize there home page to include any of the provided widgets and customize their backstage experience even more!
- Jira – this plugin ingests data from jira regarding our component and visualizes it for us on our components within backstage
- Prometheus – this plugin allows us to add metric graphs for our components to visualize key data for developers right within TDP
- Snyk – this plugin shows users the vulnerability results from snyk scans against the source repository of a component
- Sonarqube – this plugin visualizes sonarqube scan results for our components
- Stack Overflow – this plugin exposes a widget on the home page to see op results on specific topics from stack overflow with hyperlinks out to the results
- Tech Insights – this plugin performs checks and visualizes the health of our components in regards to those checks directly in the portal
While VMware have supplied us with these 9 plugins, the true power of the configurator is that you can also make your own, and if you have basic typescript and react knowledge it is extremely easy to do!
If you do not have any typescript or react knowledge, i strongly recommend learning the basics first, and then coming back to try out the configurator.
Building Custom Wrapper Plugins
While i wont go into the full details here in this blog, as the official documentation does a pretty good job of walking you through the steps, I will mention a few key things that i have learned along the way while creating over a dozen wrapper plugins over the past few days.
- In the documentation there are 2 approaches to how to build the TDP image. the second option which uses a custom supply chain is in my mind the much better approach, and i actually have my own custom supply chain, which extends the capabilities of the one in the docs a few more steps, but either approach works well. If you want to check my supply chain out it is on Github in the following repo.
- sometimes the community plugins are not well maintained, and sometimes they can be a bit buggy. The best option if that occurs to you when wrapping a plugin is to fork the source repository of the plugin, and make any changes needed and publish your own version of the plugin for initial testing. once you have the fix implemented, open a PR and contribute back your fixes to the community! while TDP is a commercial product, because it is based on OSS backstage, we get the great opportunity of being a part of the OSS community. I strongly recommend getting involved with the greater backstage community as you will learn a lot and contributing back is always a great thing!
- Be careful of the order you specify the plugins in within the TDP configurator file. while the order does not matter in terms of compilation and getting a working portal, the order has direct relation to the order of the tabs on a component, or the order of the items on the sidebar of the portal. thinking clearly about what makes the most sense is highly advisable.
- Many plugins expose a method which allows a tab to conditionally appear in the UI based on the existence of a specific annotation on the catalog-info.yaml of the component. Think carefully if you want a tab to always be shown even if no data will be available, or if you want the tab to only show up when the user explicitly has added the annotation. basically this is the old time question of opt-in or opt-out methods. I personally prefer the opt0in method, and that is why i actually created my own wrapper of the github actions plugin, and am not using VMware’s validated wrapper, because VMware configured the wrapper so that the plugin always was exposed and I preferred it differently.
What Plugins Can Be Wrapped
nearly any plugin can be wrapped into a TDP plugin. Bellow you can find a list of the plugins I have built wrappers for over the past few days:
- Github Insights – Source Plugin Repo – Published Wrapper Plugin
This plugin gives us an overview tab on our components with the details of our projects from github including releases, contributors, the readme, languages used etc. - Github Pull Requests – Source Plugin Repo – Published Wrapper Plugin
This plugin provides a tab on our components where we can see all of the PRs on our components source repository, filter by state of the PR and view basic details about them, as well as quickly use the hyperlinks to open up the PR directly on github. - Github Actions – Source Plugin Repo – Published Wrapper Plugin
This is the same plugin as is provided by VMware for seeing Github action runs for a components, and the logs and details of them, but is configured to show the tab on a component page, only when the required annotations are provided. - Todo Frontend – Source Plugin Repo – Published Wrapper Plugin
This is the frontend part of the TODO plugin, which shows us all of the TODO comments in the source code of our components with hyperlinks directly to the relevant lines in our SCM solution. - Todo Backend – Source Plugin Repo – Published Wrapper Plugin
This is the backend element of the TODO plugin which actually performs the logic behind the scenes which is visualized by the frontend plugin. - Harbor Frontend – Source Plugin Repo – Published Wrapper Plugin This is the frontend element of the harbor plugin, which shows a tab when the relevant annotation is added to a component with the list of the image tags related to this components, as well as details about the image such as size, last pull and push times, number of vulnerabilities, severity, and how many fixable vulnerabilities there are in the image, as well as a link to the specific artifact in harbor for you to get more information.
- Harbor Backend – Source Plugin Repo – Published Wrapper Plugin
This is the backend element of the harbor plugin, which performs the queries against the harbor instance in order to pull in the relevant data about our images. - FluxCD – Source Plugin Repo – Published Wrapper Plugin
This plugin exposes the FluxCD CRs related to a workload on a dedicated tab for the component, and also if given permission allows for triggering reconcilliation of source objects as well as pausing and resuming reconcilliation of flux CRs. - Tekton – Source Plugin Repo – Published Wrapper Plugin
This plugin visualizes all tekton pipelineruns related to a component and allows for simple filtering and visualization of the relevant steps. - ChatGPT Frontend – Source Plugin Repo – Published Wrapper Plugin
This is the frontend element of the ChatGPT Playground plugin, which gives a ChatGPT interface directly within your portal, as a dedicated sidebar item. While it by default works against OpenAI, I have actually forked the original plugin and exposed the ability to set the URL to be used, allowing this to work with any OpenAI compatible API such as fast chat, or Azure OpenAI for example. - ChatGPT Backend – Source Plugin Repo – Published Wrapper Plugin
This is the backend element of the ChatGPT plugin which performs the needed logic and communication with the OpenAI APIs and returns the results back to us. - Developer Toolbox – Source Plugin Repo – Published Wrapper Plugin
This plugin exposes over 20 different developer focused tools in a single page within your portal to allow for simple day to day tasks, such as generating QR codes, encoding and decoding, file diffing, format conversion etc. - K8sGPT – Source Plugin Repo – Published Wrapper Plugin
This plugin exposes the findings of the K8sGPT operator on our components for us, allowing us to see where issues exist in our application froma kubernetes perspective as well as advice on how to fix the issues.
These are the wrappers i have built as I found them to be useful and beneficial for my use cases, and while you can use these packages which have been published to a public repository on npm.js, I strongly recommend trying to wrap a plugin your self as well.
I had not touched typescript or react in a while, and that made the start of my journey a bit challenging, but after doing 2-3 wrappers, I got a hold of the concepts, and was able to build a wrapper plugin within a matter of 10-15 minutes, which is pretty awesome!
Next Steps
While I have built a bunch of plugins, and have integrated them into my own TAP environments, everything i have discussed above, i did manually. I strongly recommend building out an automation process for updating plugins within the wrappers, and building new versions of the portal image. Even if you don’t have a full fledges CI setup to also test the new image, and to validate the plugins work, automating the build time process in it of itself will bring you huge efficiency and lower the toil of managing custom plugins over time!
Summary
As I hope you can tell, the capabilities this opens, are endless, and the massive productivity boost one can gain now from TDP, by being able to add in any needed tools is quite amazing, all without the complexity of managing OSS backstage.
If the plugin wrappers above seem interesting to you, and you want to check out the code you can find all of these wrappers I have built, in the following git repo.