What is GitOps?

GitOps uses Git repositories as a single source of truth to deliver infrastructure as code. Submitted code checks the CI process, while the CD process checks and applies requirements for things like security, infrastructure as code, or any other boundaries set for the application framework. All changes to code are tracked, making updates easy while also providing version control should a rollback be needed.

GitOps delivers:

• A standard workflow for application development
• Increased security for setting application requirements upfront
• Improved reliability with visibility and version control through Git
• Consistency across any cluster, any cloud, and any on-premise environment

Many other tools can be used together to build a GitOps framework. For example, git repositories, Kubernetes, continuous integration/continuous delivery (CI/CD) tools, and configuration management tools.

GitOps takes the philosophies and approaches promised to those investing in a DevOps culture and provides a framework to start realizing the results. Organizations who practice DevOps realize significant improvements to the rate of innovation in applications and code, as well as stability, according to the annual State of DevOps Report. 

By using the same Git-based workflows that developers are familiar with, GitOps expands upon existing processes from application development to deployment, application life cycle management, and infrastructure configuration. Every change throughout the application life cycle is traced in the Git repository and is auditable. Making changes via Git means developers can finally do what they want: code at their own pace without waiting on resources to be assigned or approved by operations teams.

For ops teams, visibility to change means the ability to trace and reproduce issues quickly, improving overall security. With an up-to-date audit trail, organizations can reduce the risk of unwanted changes and correct them before they go into production. 

These changes in code from development to production make organizations more agile in responding to changes in the business and competitive landscape.

To get started with GitOps you need infrastructure that can be declaratively managed. Because of this, GitOps is often used as an operating model for Kubernetes and cloud-native application development and can enable continuous deployment for Kubernetes.

But using Kubernetes is not a requirement of GitOps. GitOps is a technique that can be applied to other infrastructure and deployment pipelines.   

Like Kubernetes, Ansible is a desired state engine that enables declarative modeling of traditional IT systems and can therefore be used for GitOps. An Ansible user can manage applications on Kubernetes, on an existing IT infrastructure, or across both through one control plane using Ansible modules.

GitOps can be used to build development pipelines, code applications, manage configurations, provision Kubernetes clusters, and deploy on Kubernetes or container registries.

Red Hat® OpenShift® is a declarative Kubernetes platform that administrators can configure and manage using GitOps principles. Working within Kubernetes-based infrastructure and applications, consistency can be applied across clusters and development life cycles. Red Hat OpenShift consolidates the administration and management of applications spread across on-premise and public cloud resources to:

• Check that clusters have similar states (configurations, monitoring, storage), making application constraints known early in the development cycle.
• Roll back a change in code across multiple clusters by recovering clusters from a known state.
• Roll out a change submitted to Git across multiple Red Hat OpenShift clusters.
• Associate templated configurations across the hybrid cloud.

Red Hat collaborates with open source projects like ArgoCD and Tekton to implement a framework for GitOps. Install the Red Hat OpenShift Pipelines operator and learn how the Red Hat OpenShift GitOps operator is developing new tools with Argo to manage GitOps within existing Red Hat OpenShift deployments.

Red Hat Advanced Cluster Management for Kubernetes provides multicluster management of the Kubernetes cluster life cycle. Red Hat Advanced Cluster Management uses a subscription and channel framework, along with placement rules, to automatically deploy applications in a desired state model across multiple clusters.

Red Hat Ansible® Automation Platform does the work of getting your systems to the desired state, no matter their current state. Ansible playbooks, written in YAML, describe the desired state of your systems, which are usually kept in source control. 

With Ansible Automation Platform you can apply GitOps practices to traditional IT systems, like networking, cloud, and bare metal, in addition to Kubernetes. Automation webhooks are built into Ansible Automation Platform to support IaC and GitOps practices. Webhooks allow you to link a Git repository and Ansible Automation Platform natively. Once a repo link is set up, Ansible Automation Platform catches Git commits from the Git system and uses those events to trigger automation jobs to update projects, manage inventories, and perform deployments.

With the integration of Red Hat Advanced Cluster Management, Red Hat OpenShift GitOps, and Red Hat Ansible Automation Platform, DevOps teams can ensure configurations are managed and maintained at scale to improve CI/CD pipelines.

GitOps can be considered an evolution in Infrastructure as Code (IaC) that uses Git as the version control system for infrastructure configurations. IaC often follows a declarative approach to infrastructure management by defining the desired state of the system and tracking the system’s actual state.

As with IaC, GitOps requires you to declaratively describe the desired state of the system. By using declarative tools, all of your configuration files and source code can be version controlled in Git.

CI/CD pipelines are usually triggered by an external event, like code being pushed to a repository. In a GitOps workflow, changes are made using pull requests which modify state in the Git repository. 

To roll out a new release using a GitOps workflow, a pull request is made in Git, which makes a change to the declared state of the cluster. The GitOps operator, which sits between the GitOps pipeline and the orchestration system, picks up the commit and pulls in the new state declaration from Git.  

Once the changes are approved and merged, they will be applied automatically to the live infrastructure. Developers can continue to use their standard workflow and (CI/CD) practices.

When using GitOps with Kubernetes, the operator will often be a Kubernetes Operator. The operator compares the desired state in the repository to the actual state of the deployed infrastructure. The operator will update the infrastructure whenever a difference is noticed between the actual state and what exists in the repository. The operator can also monitor a container image repository and make updates in the same way to deploy new images.

Observability, which refers to any system that can be observed, is an important concept in GitOps. Observability in GitOps lets you ensure that the desired state and the observed state (or actual state) are the same.

Using pull requests and a version control system like Git introduces visibility into the deployment process. It lets you view and track any changes made to a system, provides an audit trail, and gives you the ability to roll back changes if something breaks.

GitOps workflows can increase productivity and the velocity of development and deployments, while improving the stability and reliability of systems.

GitOps and DevOps do share some of the same principles and goals. DevOps is about cultural change and providing a way for development teams and operations teams to work together collaboratively.

GitOps gives you tools and a framework to take DevOps practices, like collaboration, CI/CD, and version control, and apply them to infrastructure automation and application deployment.  Developers can work in the code repositories they already know, while operations can put the other necessary pieces into place.