Create software templates for VMs with OpenShift Virtualization

In the previous articles in this series, we demonstrated how Red Hat OpenShift Virtualization and Red Hat Developer Hub can increase developer productivity by building virtual machines with a click of a button and showcased the user experience for developers when building a new virtual machine based on the definitions of platform engineering and operations. In this installment, we explore software templates concepts, architecture, and how to use them to build virtual machines (VMs).

The technology stack 

Figure 1 depicts the various technologies used in this solution.

Red Hat OpenShift is a unified platform to build, modernize, and deploy applications at scale. Work smarter and faster with a complete set of services for bringing apps to market on your choice of infrastructure.

Red Hat OpenShift GitOps is an operator that uses Argo CD as the declarative GitOps engine. It enables GitOps workflows across multicluster OpenShift and Kubernetes infrastructure. Using Red Hat OpenShift GitOps, administrators can consistently configure and deploy Kubernetes-based infrastructure and applications across clusters and development lifecycles.

Helm is a package manager for Kubernetes used in this case to build software templates, read from the Developer Hub template parameters and translate it into the Helm values file. 

GitLab, used for this demo content, is the SCM used to store the software templates and the VM manifest definitions. Developer Hub supports Gitea and GitHub. See supported documentation.

Software templates overview

Defining a Kubernetes object based on pipelines, deployments, virtual machines, and etc., software templates allow us to build Kubernetes objects using best practices and scale these to the rest of the organization. It will be defined in a source repository and managed by GitOps to ensure the objects are created in the target cluster. Red Hat Developer Hub will create a backstage component using the software templates with the user’s parameters entered in the creation process (Bringing a self-service experience for Developers to build Virtual Machines (VMs) with Red Hat Developer Hub). The component will be used to build new source code repositories and Kubernetes manifests. 

Overview of the software templates components

Software templates are customizable, but you need at least these files to enable Red Hat Developer Hub to read from the software templates. More information: How to create a Software Template from Backstage.

• Component/catalog-info.yaml: This file will represent the object in Developer Hub,  such as name and links, as shown in Figure 2.

  

• Developer Hub, powered by GitOps, maintains the desired state as the actual state in the cluster for any template definitions, ensuring system stability. See Figure 3.

  

• GitOps application definitions and necessary secrets to read from the SCM. In this case, the argo-app-dev.yaml is the Argo CD Application pointing to the VM manifest’s folder, as shown in Figure 4.

  

• Helm Charts are great for templating. In this case, the VM manifests are implemented using Helm. See Figure 5.

  

• template.yaml file: Defines the UI experience for the end user and the desired steps to get the software templates, create repositories, create GitOps objects, and more. See Figure 6.

  

Software templates defining the template.yaml

template.yaml will define the UI experience for the end user and the desired steps to get the software templates, create repositories, create GitOps objects, and more. 

Defining the UI

In this use case, we only allow developers to choose the namespace, cluster, user owner and the virtual machine’s name. See the previous article in this series to review the UI experience. It is up to the operations and platform engineering team to decide how much developers will be able to define when they are building the VMs. Review the Software template file. Figure 7 depicts this workflow.

The figure shows a user selecting a software template, entering the required data, after which the data is mapped back into the template.yaml file and then into the values.yaml file as part of the Helm Charts.

Defining the steps for the VM creation

After the user clicks the Create button, a series of actions will happen that are all part of the VM’s creation process to build a VM using OpenShift Virtualization and Red Hat Developer Hub (Figure 8). These steps are customizable and will be defined on the template.yaml file as part of the Software templates. Review the Software template file.

Step 1: Generating the source code component

Developer Hub reads from the parameters coming from the UI and software templates definitions:

action: fetch:template

Step 2: Publishing to source code repository

From there, it clones the repo with a new source code representing the VM source code. In this case, we only have one file, the catalog-info.yaml:

action: publish:gitlab

Step 3: Registering the source code component

Using the catalog-info.yaml file, Developer Hub will register this component, making it available in the Developer Hub UI:

action: catalog:register

Step 4: Generating the deployment resources and artifacts

Building the templates using the software templates defined in the manifest folder and reading from the template.yaml file to create the manifests in a new repository representing the values required to build the VM:

action: fetch:template

Step 5: Publishing to deployment resource repository

Publish the templated source code into the GitLab repository:

action: publish:gitlab

See Figure 9.

Step 6: Create Argo CD resources

Request Argo CD  to create a GitOps application based on the previous source repository published in the last step:

action: argocd:create-resources

Using OpenShift GitOps to create a VM

The OpenShift GitOps controller will ensure that the desired state defined on the project and application are applied into the cluster. The OpenShift Virtualization operator will ensure that the VMs are being created, pods are running, and the VNC Console is accessible. See Figures 10 and 11.

Building VMs Helm charts

Below we detail the utility of using Helm Charts in conjunction with virtual machines (VMs).

Why use Helm?

As part of your overall GitOps strategy, Helm is a powerful tool that provides agility, security, and consistency across multiple environments.

Advantages of Helm for IT operations

• Agility: Help streamline and integrate into GitOps and CI/CD efforts. Helm provides agility with automatic deployment and simple, consistent upgrades.
• Simplicity: Simplify deployment by making automation generally available to developers for frequently deployed applications.
• Consistency: Automate manual tasks, significantly reducing deployment time, as well as chances of error during deployment. 

What is a Helm chart?

Helm charts are a collection of files that describe a Kubernetes cluster’s resources and package them together as an application. They are comprised of four basic components: 

• The chart: chart.yaml defines the application metadata like name, version, dependencies, etc. 

• Values: values.yaml sets values, which is how you will set variable substitutions for reusing your chart. You may also have a values JSON schema that describes a structure for the values file, which can help in creating dynamic forms and validating your values parameters.

• The templates directory: Templates/houses your templates and combines them with the values set in your values.yaml file to create manifests

• The charts directory: Charts/stores any chart dependencies you define in chart.yaml and reconstructs with Helm dependency build or Helm dependency update.

Each time you install a Helm chart, you also create an instance of it, called a release.

Using VMs from instance types

You can simplify virtual machine (VM) creation by using instance types, an easy way to define your VM's manifest. You can customize the helm charts as much as you want and use specific configurations to build your VM. Creating virtual machines from instance types. 

Your Helm chart files can represent all the virtual machine definitions. For this use case, the Helm charts are: 

• _template/helpers.tpl to hold the variables such as labels, annotations to be used on the manifest files. More information.
• template/Vm.yaml, kubevirt.io/v1 VirtualMachine object representing the instance of the virtual machine that will be created in OpenShift.
• chart.yaml
  • Including the Chart’s definition, such as name and version.
• values.yaml
  • Variables coming from the template.yaml. 

Exploring the new repository 

From GitLab, two new repositories were created by Developer Hub according to the software template definition. In this use case, the template.yaml defined two repositories: one for the GitOps files and the other for the VM source code. In this case, only the catalog-info file is needed. In the case of applications, you might have stored the application source as part of this new repository. The content was autogenerated by Developer Hub using the UI parameters and the software template definitions. See Figures 12-14.

Conclusion

Developers can create many instances from VMs' pre-defined software templates with just a few clicks. Software template customizations will determine how many templates will need to be available for Developers to access the different types of VMs required. Software Templates used in this demo.

Next

Read the full series—Part 1: Building virtual machines with Red Hat Developer Hub: The what, why, and how.