Implementing a GitOps UI with Spotify’s Backstage
In this post we’ll show you how to use Spotify’s open source framework, Backstage to create a GitOps plugin with a UI that can be offered through a developer portal.
Back by popular demand: GitOps on AWS webinar series
How to Build a Kick-ass Team Operation with GitOps
There’s More to GitOps Than Meets the Eye
GitOps is a cluster operational model that makes it easy to spin up and manage fully configured Kubernetes platforms and the applications that run on them. In this post we’ll show you how to use Spotify’s open source framework, Backstage to create a GitOps plugin with a UI that can be offered through a developer portal.
I previously built a GitOps workflow for EKS with GitHub Actions and intended to write a user interface for it, however I’m not a front-end developer. What I needed was a front-end framework that could help get things done quickly without a lot of complexity between the front-end and back-end.
Backstage is a framework that unifies the UX of your frequently used infrastructure tools and makes them available from a service catalogue. I had a very successful trial with Backstage on a previous project where I learned a lot. In this project, I’ll describe exactly how to implement a UI for a GitOps plugin with Backstage and make it available as a tool for spinning up and managing preconfigured machine learning clusters.
Spotify open sourced parts of its internal project, Backstage, on GitHub. The first phase of backstage was a UI framework. The project is currently in its second phase, focusing on API and backend integration.
The Backstage’s UI Plugin Architecture
Building GUIs with Backstage’s plugin architecture is incredibly easy. Adding new functionality to the Backstage application is as simple as creating a plugin, defining the plugin url (for example,
`/gitops-clusters`), wiring it up to the application’s router, and then adding the plugin url to the sidebar.
It is important to note that a plugin can be either an in-tree package of Backstage itself or it can be published as an NPM. Both methods allow users to leverage the underlying architecture in order to develop highly extensible applications.
Although Backstage is built on React, it is relatively easy to understand, even for somebody like me who rarely writes front-end applications. Since Backstage and the community have made a large set of ready-to-use React components available it's even easier to build GUIs with a limited background in React.
Backstage not only shines through a rich set of UI components, but it also provides conventions for defining APIs to talk to backend services. Its use of TypeScript proved to be very helpful when mapping client-side JSON structures to those in server-side Golang. I was surprised by how constructs in both languages matched nicely.
Bootstrapping EKS from GitHub Actions - the GitOps way
When provisioning an EKS cluster with EKSctl, we have to manually enter the command `eksctl create cluster`. The GitOps loop kicks off after enabling the GitOps functionality with the
`eksctl enable gitops` command.
To make the provisioning process start from the GitHub workflow, we can implement the provisioner as a GitHub Action. However, I wanted the cluster bootstrapping process to be more GitOps-ish, so this is what I did.
I developed a cluster provisioner as a GitHub Action. The cluster provisioner GitHub Action detects the `cluster.yaml` in a GitHub repository and uses the provided configuration to provision an EKS cluster. The cluster.yaml is defined as a YAML config wrapping around the EKSctl ClusterConfig. Here’s an example:
Once the cluster config is stored together with a pre-configured GitHub Actions workflow file in the same GitHub repository, it becomes a ready-to-use cluster template for EKS.
The GitOps-profiles plugin
The plugin is called
`gitops-profiles` which allows users to provision GitOps-managed clusters directly from Backstage. Under the hood the profile uses the command line interface, EKSctl with GitHub Actions to provision a Highly Available Kubernetes cluster that includes a preloaded profile within a few minutes.
The preloaded profile is a Machine Learning profile and the COVID-ML profile. The set of profiles is extensible. The plugin is already merged to Backstage upstream.
Here’s an example of a cluster repository created and provisioned by the UI:
The plugin appears in the Tools section on the Explore pages on Backstage. Users can click Explore → GitOps Clusters to create and manage clusters using the GitOps plugin.
Backstage gave me a fresh experience for developing complex front-end applications by letting me focus on my essential tasks. The framework provides many opportunities for developers to create GUIs for Cloud Native applications.