Create and customize virtual machine files within the repository

This second lesson will walk you through configuring the necessary files for our Infrastructure as Code (IaC) plan and provide some best practices for configuring your environment.

In order to get full benefit from taking this lesson, you need to:

• Have completed lesson 1, or have an existing repository configured within the OpenShift GitOps Argo CD instance.

In this lesson, you will:

• Populate the repository with existing virtual machine YAML files or create new ones.
• Configure GitOps Overlays to customize the virtual machines.

Populate the Git repository with virtual machine YAML files

In the previous lesson, we configured the repository from within OpenShift. Now let’s populate the repo with files to be used for configuring our virtual machines. The files used here are available in this Git repository if you choose to follow along. The directory structure of the repository is shown in the code block below. The base directory contains all of the files that we will be using to create customized virtual machines for our environment. We will delve further into the overlays directory in the next section, but first, let’s discuss some considerations for using GitOps for VMs. See below:

├── base
│   ├── base-vm-disk.yaml
│   ├── base-vm-import-source.yaml
│   ├── base-vm.yaml
│   └── kustomization.yaml
├── overlays
│   ├── base-vm-import-source.yaml
│   ├── dev
│   │   ├── config.yaml
│   │   ├── dev-vm-patch.yaml
│   │   └── kustomization.yaml
│   ├── kustomization.yaml
│   └── prod
│       ├── config.yaml
│       ├── kustomization.yaml
│       └── prod-vm-patch.yaml

Considerations for virtual machines in OpenShift

In addition to the policies that your organization may have in place for GitOps usage, below are some additional items to think about when you move towards managing virtual machines in OpenShift.

Control desired states with code pushes

Control the desired states of OpenShift VMs solely by code pushes after deciding to implement GitOps and IaC. Avoid managing the VMs manually via CLI or console because GitOps sees those changes and puts the applications from within Argo CD out of sync, which can have potentially hazardous consequences.

Import images directly to avoid cloning issues

When creating a VM, it can be tempting to clone one of the many images provided by Red Hat. This can be problematic in an environment where you need tight control over what is deployed. The images that can be cloned directly from OpenShift Virtualization have the effective tag of "latest", and are updated periodically. This is somewhat equivalent to having different versions of dependencies in software development. Avoid issues that could arise from cloning by importing images directly. These can be found on the Red Hat registry located here to ensure consistent OS versioning. 

Podman can be used to find the image version that you are looking for. In the case of Red Hat Enterprise Linux (RHEL) 9, we can show what tags are associated with the images by first logging into registry.redhat.io using podman login, and then searching for the tags using the following command: podman search --list-tags registry.redhat.io/rhel9/rhel-guest-image.

Use volume import populators for storage

Volume import populators are a good storage solution due to their increased compatibility with the underlying Kubernetes infrastructure. Using DataVolumes and the dataVolumeTemplates section of the VM spec causes PersistentVolumeClaims (PVCs) to be created implicitly, and these PVCs appearing in a project can confuse OpenShift GitOps. Using PVCs explicitly (with populators) avoids this issue, and we will demonstrate their usage below.

Consider auto synchronization carefully

When deciding on how to implement GitOps into your environment, take some time to carefully consider auto synchronization of changes to the virtual machines. This doesn’t mean that you should refrain from auto-synchronizing across the board; chances are that your development and test environments can be safely auto-synced. For production environments, synchronization done outside of maintenance windows could be less than desirable.

Use overlays for custom virtual machines 

Now that we have discussed some of the choices you can make for your VMs, let’s work on the overlays that will provide our organization with custom virtual machines. The overlays directory contains two subdirectories, dev and prod, which will be used to provide the VMs with differentiating configurations.

In the overlays directory are two files: base-vm-import-source.yaml and kustomization.yaml. The base-vm-import-source file defines the import populator (see above) from which we will pull our chosen RHEL image and the kustomization.yaml file tells GitOps what our resources are for the virtual machine configurations contained in the dev and prod subdirectories.

The files used to create our customized VMs are in the dev and prod subdirectories. In our next lesson, we will learn about those files and create the Argo CD application which will then create our virtual machines after synchronization.