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.
![The icons representing the various technologies used in this solution.](/sites/default/files/sos_f1.jpg)
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.Figure 2: The source repository showing the catalog-info.yaml file from the software templates definitions. 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.
Figure 3: The image shows the source repository showing the manifest content folder from the software templates definitions. 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.Figure 4: The source repository showing the argocd files from the software templates definitions. Helm Charts are great for templating. In this case, the VM manifests are implemented using Helm. See Figure 5.
Figure 5: The source repository showing the helm charts from the software templates definitions. 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.Figure 6: The source repository showing the template.yaml file from the software templates definitions.
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.
![A user selecting a software template, entering the required data, and data mapped back into the template.yaml file and then into the values.yaml file as part of the Helm Charts.](/sites/default/files/sos_f7.png)
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.
![A depiction of the steps in the virtual machine creation process.](/sites/default/files/sos_f8.png)
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.
![A view of the source repositories app-legacy-m5 and app-legacy-m5-gitops.](/sites/default/files/sos_f9.png)
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.
![A depiction of the legacy application GitOps created based on the software templates.](/sites/default/files/sos_f10.png)
![A depiction of the legacy application related objects created based on the software templates.](/sites/default/files/sos_f11.png)
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 manifestsThe 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
.
- Variables coming from the
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.
![A view of the content of the new gitops project created in GitLab.](/sites/default/files/sos_f12.png)
![A view of the content of the new gitops project created in GitLab. within the argocd folder.](/sites/default/files/sos_f13.png)
![A view of the Helm directory containing the VMs Helm definitions needed to build the VM.](/sites/default/files/sos_f14.png)
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.
Last updated: August 20, 2024