Module 03: Declarative management of VMs with GitOps automation

GitOps is a modern approach to infrastructure and application management that uses Git as the single source of truth for declarative system configurations.

By using Git repositories to define and manage infrastructure, GitOps enables automated deployment, version control, and continuous delivery. Changes are made through pull requests, ensuring consistency, auditability, and rollback capabilities. This approach improves collaboration among teams while reducing human errors.

GitOps architecture diagram showing Git repository, Argo CD, and OpenShift cluster

Objectives

  • Introduction of GitOps

  • Understanding OpenShift GitOps for Virtual Machines

  • Configure and manage the travel-control domain with GitOps

About OpenShift GitOps

OpenShift GitOps, based on Argo CD, extends GitOps principles to Red Hat OpenShift environments, offering a comprehensive solution for managing Kubernetes-native applications and virtualized workloads.

Red Hat OpenShift GitOps is an operator that provides a workflow that integrates git repositories, continuous integration/continuous delivery (CI/CD) tools, and Kubernetes to realize faster, more secure, scalable software development, without compromising quality.

OpenShift GitOps enables customers to build and integrate declarative git driven CD workflows directly into their application development platform.

There’s no single tool that converts a development pipeline to "DevOps". By implementing a GitOps framework, updates and changes are pushed through declarative code, automating infrastructure and deployment requirements, and CI/CD.

Benefits of OpenShift GitOps for virtual machines (VMs)

While GitOps is typically associated with containerized applications, OpenShift GitOps also supports managing Virtual Machines (VMs) using OpenShift Virtualization. This provides several key advantages:

  • Consistent Infrastructure as Code (IaC): By managing VM configurations and lifecycle in Git, teams can apply the same declarative workflows used for Kubernetes applications, ensuring consistency and repeatability.

  • Automated Deployments and Rollbacks: OpenShift GitOps continuously monitors the desired state in Git and automatically reconciles deviations. This ensures VMs are always deployed correctly and allows quick rollbacks if needed.

  • Improved Security and Compliance: Git-based workflows enable auditable change management, allowing teams to track and review all modifications to VM configurations while enforcing policies and compliance standards.

  • Scalability and Hybrid Cloud Support: OpenShift GitOps facilitates deploying and managing VMs across on-premises and cloud environments, providing a unified approach to infrastructure automation.

By integrating GitOps principles with OpenShift Virtualization, organizations can streamline VM management, enhance security, and improve operational efficiency in hybrid cloud environments.

Getting started

All assets for this module are in the folder module-03. Please change the directory into this folder. 
cd $HOME/modernize-ocp-virt-workspace/module-03

In this module we want to deploy everything declaratively and let it be managed by OpenShift GitOps.

This is a very different approach than in earlier modules where we created a VM manually using either the console or a simple YAML manifest.

Log into the user’s Argo CD deployment

First, we are going to open the OpenShift GitOps Dashboard.

While our OpenShift deployment has a cluster-scoped Argo CD deployment that is used by the Red Hat Demo Platform team to manage the environment, such as pre-deploying the VMs that were available when we started, we will be using a user-scoped installation of Argo CD in order to perform the tasks in this module.

This cluster-scoped Argo CD deployment can be accessed through the applications menu at the top of the page and by selecting Cluster Argo CD from the drop down menu.

Applications menu with Cluster Argo CD option in the dropdown
The userX account does not have permissions to perform operations here, instead we will be opening our user-scoped Argo CD deployment found in the userX-travel-control-new project.

To do this we need to visit the Networking → Routes menu. Select the userX-travel-control-new project from the dropdown and we should see one route available to us for argocd-server.

Click on the route hyperlink to open the the Argo CD console.

Networking Routes page showing the argocd-server route in the travel-control-new project

This will bring up the Argo CD console in a new tab.

Click on the LOG IN VIA OPENSHIFT button, it should automatically log you in. If it doesn’t just make use of your current user credentials.

Argo CD login page with LOG IN VIA OPENSHIFT button

Welcome to the Argo dashboard

You will see that currently there are no Argo applications running or being managed by OpenShift GitOps.

Empty Argo CD dashboard with no applications deployed

Create an Argo CD application

Now that we’ve logged into Argo CD, let us create an app for the travel-control components.

An Argo CD application is a Kubernetes resource that defines and manages the deployment of workloads based on a Git repository. It continuously syncs the desired application state from Git to the cluster, ensuring consistency and enabling automated rollbacks if deviations occur.

In the Argo console we can create a new application by either clicking on the + New App button on the top left, or the Create Application button in the middle:

Argo CD dashboard with New App and Create Application buttons

When we do this the Create App wizard slides out.

The wizard has a number of fields to fill out, so we are going to step through the screenshots one at a time.

In the General section, give your app the name travel-control, use the argo project default, and leave the sync policy as Manual:

Create Application wizard General section with name travel-control and project default

In the SOURCE section, copy and paste the repo to Argo CD by setting repository url to the github repo url, leave revision as HEAD, and set the path to module-03/travel-control:

https://github.com/rhpds/modernize-ocp-virt-workspace
Source section with repository URL, revision HEAD, and path module-03/travel-control
We have already provided all necessary Kubernetes manifests in this repository and path. Feel free to explore this Helm Chart if you like.

In the Destination section, set cluster URL to https://kubernetes.default.svc by copying and pasting the value below, and leave the namespace empty:

https://kubernetes.default.svc
Destination section with cluster URL set to kubernetes.default.svc

In the Helm section, provide the username and URL of the Service Mesh ingress gateway by overwriting the username and ossm_ingress parameters:

userX-ingress-istio-gateway.apps.cluster.example.com
Helm section with username and ossm_ingress parameters configured

After filling out the information above, click Create at the top of the UI to create the travel-control application:

Top of the Create Application wizard with the Create button highlighted

You will return to the main Argo dashboard, where you can see that the travel-control argo application is created, and you can now view its status, which notably is in an OutOfSync state since the application is staged, but has yet to be deployed, and no resources have been created as of yet in our OpenShift cluster.

Argo CD dashboard showing travel-control application in OutOfSync status

To sync (deploy) the application, you simply have to click on the SYNC button of the travel-control application

travel-control application card with SYNC button highlighted

A new panel will be opened and then, click on SYNCHRONIZE button.

Sync panel with SYNCHRONIZE button to deploy the application

The panel will close and you will see the travel-control application begin to deploy and apply configuration changes.

Argo CD showing travel-control application deploying resources

By clicking on the travel-control application you open the details of the app, and you’ll see which resources have been applied, as well as the Sync status, last sync and application health.

Application details showing deployed resources, sync status, and health

Wait for a few minutes until everything is up and running.

In the last step we test if the whole solution is working correctly, by opening the Business Dashboard of the Booking Application again.

Click on the following link: Travel Control Dashboard

Travel Control Dashboard loading successfully through the Argo CD-deployed gateway

We can see that we’ve deployed a full application using both virtual machines and containers using Red Hat OpenShift GitOps.

Validate Argo CD self-healing

To test Argo CD’s self-healing capability, you can manually delete a Kubernetes resource managed by Argo CD. With Automated Sync and Self-Heal enabled, Argo CD will detect the drift from the desired Git state and automatically recreate the deleted resource, confirming that self-healing is working as expected.

Enable self-healing

First, we need to enable Auto-Sync and Self-Healing for the travel-control application.

Click on the DETAILS button at the top of the travel-control application.

travel-control application with DETAILS button highlighted at the top

A panel will slide out, scroll down to the Sync Policy section, and click on the ENABLE AUTO-SYNC button.

Sync Policy section with ENABLE AUTO-SYNC button

A new window will appear for Enable Auto-Sync, click on the OK button.

Enable Auto-Sync confirmation dialog with OK button

With Auto-Sync enabled, the Sync Policy section changes to include an option for Self Heal with a button next to it for Enable. Click that button.

Sync Policy section showing Auto-Sync enabled with Self Heal Enable button

A new window will appear for Enable Self Heal, click on the OK button.

Enable Self Heal confirmation dialog with OK button

Close the panel by clicking on the X in the upper right corner.

Details panel with the X close button in the upper right corner

Test self-healing

In order to test out the self-healing feature, we are going to "accidentally" delete our control-vm from our userX-travel-control-new project.

Return to your Red Hat OpenShift Console, and click on Virtualization → VirtualMachines in the left side navigation menu, followed by the userX-travel-control-new project in the center column, and the virtual machine named control-vm.

VirtualMachines page showing control-vm in the travel-control-new project
You will need to perform these next few tasks fairly quickly, or the VM may automatically restart due to Argo CD protecting the VM’s desired running state.

On this screen use either the Stop button, or select the option for Stop from the Actions drop down menu.

control-vm overview with Stop button and Actions dropdown menu

With the virtual machine stopped, you now have the option to Delete the VM available in the Actions drop down menu.

Actions dropdown menu with Delete option for the stopped control-vm

Once deleted, return to the argo dashboard where you will likely see the restore operation already in progress.

The Argo CD dashboard will step through an automated process where it will briefly show the following:

  1. Application status as "OutOfSync" – indicating that the live cluster state no longer matches the Git source.

  2. The deleted resource will disappear from the resource tree temporarily.

  3. Within moments, Argo CD will auto-sync, and the deleted resource will reappear, restoring the desired state.

  4. The status will return to "Synced" and "Healthy", confirming self-healing has taken place.

Argo CD showing travel-control application in OutOfSync and unhealthy state during self-healing

After it has completed all of this tasks, it will return to the previous healthy state with all of the application components deployed as desired.

Argo CD showing travel-control application restored to Synced and Healthy state after self-healing

You can also use this opportunity to verify that the Travel Control Dashboard is still in working order.

Congratulations!! You helped the Travel Agency company to automate their whole solution now through Red Hat OpenShift GitOps.

Summary

In this module we learned about Red Hat OpenShift GitOps, and how it can be used to deploy an application or a VM in a declarative fashion. We also demonstrated how it can be used to self-heal applications that have been affected by user error or other unforeseen circumstances by restoring resources to known good desired state.