Are you ready to take your development process to the next level by seamlessly integrating deployment into your workflow? If so, you might be wondering where exactly to incorporate this crucial aspect. Chances are, your code development is already organized within a Git repository, serving as a central hub for editing, testing, and saving your code. To streamline the process further, you've integrated CI/CD into your Git repository for efficient testing and integration. However, when it comes to deploying your application onto a Kubernetes or OpenShift environment, you find yourself doing it manually. Your entire process revolves around your source code residing in GitHub, acting as the single source of truth.

Imagine if your Git repository could also house the application deployment configurations. Picture having a mechanism that automatically deploys applications onto your Kubernetes cluster, continuously monitors their state, and securely updates the deployment to match the desired state from the Git repository. Sounds incredible, right?

Well, the solution to all these requirements is GitOps! In this blog, we will delve into the world of GitOps and explore how it empowers developers to effortlessly manage application deployments and maintain consistency throughout the development lifecycle. Join us as we unravel the potential of GitOps on Red Hat OpenShift, bringing automation, security, and simplicity to your software development journey.

What is GitOps

GitOps is a development methodology that revolves around a Git repository, serving as the sole source of truth for cloud-native system and application configurations. Within this repository, a set of declarative manifest files exists, describing the desired state and components of the infrastructure. GitOps continuously monitors the application state within the repository and handles the installation and synchronization of applications on the cluster by pulling updated changes from Git. By adopting GitOps, it becomes possible to address inconsistencies between the infrastructure and application configurations across clusters and repositories.

Why GitOps

The significance of GitOps stems from its developer-centric nature, empowering team members to efficiently manage and control cloud-native applications. It facilitates seamless automation of continuous delivery for such applications, allowing businesses to streamline their deployment processes.

At its core, GitOps adheres to key principles:

• Declarative infrastructure: Developers can focus on application development without diving into manual configuration, setup, and deployment. The configuration is written and stored alongside the source code in the Git repository, establishing a "single source of truth." The goal is to achieve the desired state through configuration, enabling easy rollbacks to a previous known good state in case of errors.
• Version control: With Git as the "single source of truth," application deployments can be version controlled. This empowers the operations (Ops) team to execute more effective deployments or rollbacks to the desired state.
• Self-healing: GitOps ensures that the application state remains synchronized with the desired state defined in the configuration, automatically correcting mismatches or failures.

GitOps brings numerous benefits:

• Reduced manual intervention: GitOps enables automation of redundant tasks in application deployment and facilitates rollbacks, minimizing downtime. Developers can focus on application development and delivery, while the Ops team benefits from increased automation and streamlined production deployment.
• Enhanced security checks: GitOps conducts security scans on previous states, enabling identification of the point at which a security issue was introduced.
• Faster and multiple deployments: Automation with GitOps simplifies the deployment process—merging changes in Git triggers automatic deployment in production. This leads to faster and multiple deployments.
• Faster error recovery: In case of deployment issues, rolling back to a previously committed state undoes the deployment, ensuring faster error recovery.
• Self-documented deployment: All code, configuration, and infrastructure changes are captured through Git commits, preserving a complete history of changes. This documentation of changes is easily retrievable and maintainable.

How GitOps works

To implement GitOps, an agent needs to be installed and run within the Kubernetes cluster. There are several tools available that serve as agents for GitOps operations, with one popular choice being ArgoCD. ArgoCD is an open-source project and a declarative continuous delivery tool specifically designed for Kubernetes.

From a deployment perspective, the process unfolds as follows:

1. Developers/Ops team make updates to the cloud-native manifest files, commit those changes, and push them to the Git repository. They then raise a Pull Request (PR).
2. Once the PR is approved, the updates are merged into the deployment Git repository.
3. Within the Kubernetes cluster, ArgoCD containers continuously monitor the Git repository for changes.
4. When ArgoCD detects new changes, it automatically pulls the updated changes from the Git repository and proceeds to install or update the application on cluster.

Red Hat OpenShift GitOps

Red Hat has developed the OpenShift GitOps framework, powerd by ArgoCD to serve as a robust tool for continuous integration and continuous delivery (CI/CD) processes.

The initial release of GitOps for Power, version 1.6.0, introduced the capabilities and benefits of GitOps to Power users.

To get started with OpenShift GitOps on a Red Hat OpenShift cluster running on Power, the GitOps Operator can be easily installed through OperatorHub.

To ensure that your installation was successful, look for the presence of ‘Red Hat Openshift GitOps’ in the Installed Operators tab.

You can also validate the installation by using the CLI

$ oc get csv -n openshift-operators | grep openshift-gitops-operator
openshift-gitops-operator.v1.9.0          Red Hat OpenShift GitOps      1.9.0     openshift-gitops-operator.v1.8.3   Succeeded

With the installation completed, you are now ready to proceed to the ArgoCD user interface (UI) and begin creating your ArgoCD application.

ArgoCD application

An ArgoCD application represents a resource object that encompasses essential information. This information primarily includes the desired cloud-native application or manifest that is to be deployed on the cluster. The ArgoCD application comprises two crucial pieces of information:

• Source: This refers to the Git URL of the repository, along with its revision and the path to the manifest files containing the desired state.
• Destination: This specifies the target cluster and namespace where the cloud-native application or manifest will be deployed.

The ArgoCD application acts as a bridge, allowing you to define and manage the deployment of your desired cloud-native application effortlessly.

Strategies to implement Red Hat OpenShift GitOps

Following are a few strategies that you can follow for implementing OpenShift GitOps:

• Application and ArgoCD are on the same OpenShift cluster. ArgoCD pulls the deployment and other manifest files from the Git repository.
• ArgoCD, that is on OpenShift cluster, pulls and deploys applications on other clusters.
• Application scoped ArgoCDs - Deployments from application repositories on OpenShift cluster in application namespaces.

Create a new application with ArgoCD

1. Access the ArgoCD user interface (UI) from OpenShift GitOps link as shown.
2. The ArgoCD login page will appear.
   
   Choose one of the available login methods:
   •  Login via OpenShift
   •  Username and Password
   .Note: Keycloak login can be enabled in ArgoCD as an additional method.By default, the username is ‘admin’ and the password can be obtained from the command line using the following command:
   

   # oc get secret/openshift-gitops-cluster -n openshift-gitops 
   -o jsonpath='{.data.admin\.password}' | base64 -d

   After successfully logging in, the ArgoCD dashboard will be displayed, where you can manage ArgoCD settings, such as repositories, clusters, ArgoCD projects, and repository certificates. Additionally, you can create and manage new applications directly from the dashboard.
3. Click +New App button.
4. Provide the necessary details for creating the application, including the Application Name, Project Name, Sync Policy, Source, and Destination. Then, click the "Create" button.Application Name: Provide a name for the new application.
   Project Name: Select the project name within ArgoCD (default value is "default"). New  project names can be created in Settings
   Sync Policy: Choose either Manual (synced manually by the Ops team) or Automatically   (ArgoCD handles automatic syncing).
   Source: Enter the Git Repository URL, Revision (branch), and the Path in the repository where the application config files are located.
   Destination: Provide the target Cluster URL (default is the current cluster URL, managed in Settings) and the Namespace where the application will be created.
   Configure additional settings, such as the Directory, input arguments, and external values required for application creation.
   For creating this sample application, we will use publicly available repositories that have been forked for Pipelines testing. These repositories have been updated with the desired images for Power.
   • pipelines-vote-ui
   • pipelines-vote-api
5. After the application is successfully created, you will be able to see it listed on the dashboard.
6. By expanding the application, you can view a summary of its details, including the application name, project name, source repository, config path, destination, namespace, and creation time.Additionally, you can view the application details directly on the cluster from a developer's perspective.
7. Run and test the application by accessing the application URL (voting between Cat vs. Dog).
8. Update the repository with a new image tag, commit the changes, and push them to the Git repository. ArgoCD will automatically sync the application on the dashboard with the repository changes, implementing the latest commit on the cluster.
9. Verify the application to see the updated changes, such as the vote changing to Owl vs. Dog.Bingo!! Now, the vote has been updated to Owl vs Dog.
10. Check the history to see the changes made by ArgoCD. The red box highlights the latest synced commit number, while the orange box indicates older commit numbers.Congratulations! You have successfully installed an application on a Power-based OpenShift cluster using ArgoCD and witnessed its automatic updates.

With ArgoCD, managing and deploying applications becomes effortless, ensuring your applications stay up-to-date with the latest changes from the Git repository.

Application rollback

Sometimes, it may happen that the application update fails with the new change. Ops team then decides to revert the change and rolls back the installation. But, with OpenShift GitOps (ArgoCD) reverting the changes is easier than ever.

 There are two methods to achieve rollback with ArgoCD:

• Revert the changes in the Git repository by creating a new commit. ArgoCD will automatically detect the change, sync, and reinstall the application on the cluster.
• Roll back to a desired previous commit from the application's history. This method requires updating the Sync Policy to manual mode.

Let's explore the second method for rolling back changes using the ArgoCD dashboard:

1. Select the application and navigate to the App Details page. Click History and Rollback.
2. On the History and Rollback page, choose the revision you want to roll back. Click the ellipses icon and select Rollback.
3. A confirmation message will be displayed. Click OK to proceed.
4. The application rollback will revert the previous configurations on the cluster. You will now see the application status as 'OutOfSync’ with the repository but 'Healthy' on the cluster.By utilizing the rollback feature in ArgoCD, you can easily revert changes and restore the application to a previous known state, ensuring stability and minimizing downtime.

create and manage application using CLI

Apart from the UI, you can create and manage the application from command line as well, using the argocd tool.

1. Create a new namespace in OpenShift cluster using the following command.

   $ oc new-project voting-on-power

2. Use the following command to add cluster-admin rights to the service account openshift-gitops-argocd-application-controller in namespace openshift-gitops.

   $ oc adm policy add-cluster-role-to-user cluster-admin -z openshift-
   gitops-argocd-application-controller -n openshift-gitops
   clusterrole.rbac.authorization.k8s.io/cluster-admin added: 
   "openshift-gitops-argocd-application-controller"

3. Use the following command to get ArgoCD admin login password.

   $ argoPass=$(oc get secret/openshift-gitops-cluster -n openshift-
   gitops -o jsonpath='{.data.admin\.password}' | base64 -d)

4. Use the following command to get ArgoCD server URL.

   $ argoURL=$(oc get route openshift-gitops-server -n openshift-gitops 
   -o jsonpath='{.spec.host}{"\n"}')
   $ echo $argoURL
   openshift-gitops-server-openshift-gitops.apps.ppc64le-
   qe45.psi.redhat.com
   

5. Use the following command to connect with server with user as admin and its password.

   $ argocd login --insecure --grpc-web $argoURL  --username admin --
   password $argoPass
   'admin:login' logged in successfully
   Context 'openshift-gitops-server-openshift-gitops.apps.ppc64le-
   qe45.psi.redhat.com' updated
   

6. Deploy applications in declarative way using ‘oc’ command.

   $ cat << EOF | oc apply -f -
   > apiVersion: argoproj.io/v1alpha1
   > kind: Application
   > metadata:
   >   name: voting-api
   >   namespace: openshift-gitops
   > spec:
   >   destination:
   >     namespace: voting-on-power
   >     server: https://kubernetes.default.svc
   >   project: default
   >   source:
   >     path: k8s
   >     repoURL: https://github.com/kabhiibm/pipelines-vote-api.git
   >     targetRevision: master
   >   syncPolicy:
   >     automated:
   >       prune: true
   >       selfHeal: false
   >     syncOptions:
   >     - CreateNamespace=true
   > EOF
   application.argoproj.io/voting-api created
   $ cat << EOF | oc apply -f -
   > apiVersion: argoproj.io/v1alpha1
   > kind: Application
   > metadata:
   >   name: voting-ui
   >   namespace: openshift-gitops
   > spec:
   >   destination:
   >     namespace: voting-on-power
   >     server: https://kubernetes.default.svc
   >   project: default
   >   source:
   >     path: k8s
   >     repoURL: https://github.com/kabhiibm/pipelines-vote-ui.git
   >     targetRevision: master
   >   syncPolicy:
   >     automated:
   >       prune: true
   >       selfHeal: false
   >     syncOptions:
   >     - CreateNamespace=true
   > EOF
   application.argoproj.io/voting-ui created
   

7. Use the following command to list apps from the ArgoCD.

   $ argocd app list
   NAME              CLUSTER                    NAMESPACE        PROJECT  STATUS  HEALTH   SYNCPOLICY  CONDITIONS  REPO                              PATH  TARGET
   openshift-gitops/voting-api  https://kubernetes.default.svc  voting-on-power  default  Synced  Healthy  Auto-Prune  <none> https://github.com/kabhiibm/pipelines-vote-api.git  k8s   master
   openshift-gitops/voting-ui   https://kubernetes.default.svc  voting-on-power  default  Synced  Healthy  Auto-Prune  <none> https://github.com/kabhiibm/pipelines-vote-ui.git   k8s   master
   

8. Use the following command to sync the app manually.

   $ argocd app sync openshift-gitops/voting-api

Delete an application from ArgoCD

To delete an application from ArgoCD, perform the following steps.

1. Click Delete button on the ArgoCD dashboard to delete the app from UI.
2. Enter the conformation text and click OK to delete the application.

Alternatively, you can also delete the app from the command line using the following command:

$ argocd app delete voting-ui

GitOps vs DevOps

GitOps and DevOps are related but distinct approaches to software development and deployment. Here's a comparison between GitOps and DevOps:

DevOps is a combination of a framework, practice and tools for development and operation teams to work together collaboratively to increase the ability to deliver applications and services at high velocity.

GitOps leverages the ability of Continuous Deployment (CD) in DevOps. It takes advantages of the GitOps tools like ArgoCD, Git and Kubernetes as well as collaborating with other CICD tools like Jenkins, Tekton and version controls to seamlessly apply them to infrastructure automation and application deployment.

The figure depicts a pipeline of different stages from code development till deployment within the ecosystem of Red Hat OpenShift on IBM Power with various CI/CD tools and OpenShift GitOps.

Conclusion

In conclusion, GitOps is an emerging approach that brings significant benefits to both Developers and Operations teams. With Red Hat OpenShift on Power, GitOps becomes even more powerful as a deployment tool in CI/CD operations. This blog uses a simple example to demonstrate the usefulness of GitOps. By integrating GitOps with DevOps tools like Jenkins and Tekton, organizations can build a more complex system and leverage the advantages of pipeline development for continuous integration, continuous delivery, and continuous deployment. GitOps is just the beginning, and its feature set has the potential to greatly simplify and enhance software development and deployment processes.