What is GitOps?
GitOps is a set of practices for managing infrastructure and application configurations to expand upon existing processes and improve the application lifecycle.
GitOps uses Git repositories as a single source of truth to deliver infrastructure as code (IaC). IaC is the managing and provisioning of infrastructure through code instead of through manual processes. With IaC, configuration files are created that contain your infrastructure specification and ensure that you provision the same environment every time. It is an important part of implementing DevOps practices and continuous integration/continuous delivery (CI/CD).
GitOps requires a declarative description of the desired state of the system. By using declarative tools, all configuration files and source code can be version controlled in Git. All changes to the 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 from greater visibility and auditability.
- Improved reliability with visibility and version control through Git.
- Consistency across clusters, clouds, and on-premise environments.
How is GitOps different from DevOps?
GitOps and DevOps 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.
An Introduction to GitOps
Why GitOps?
GitOps is a process change, so it can take time for teams to adjust as they adopt. It requires a new level of collaboration and communication. Cultivating a culture of feedback is a way to mitigate those challenges, but they still may arise.
Despite those challenges, GitOps takes the philosophies and approaches promised to those investing in a DevOps culture and provides a framework to start realizing the results.
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. Developers can work in the code repositories they already know, while operations adopt the same tools and techniques to manage infrastructure. 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 operations 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.
What are some GitOps tools?
There are many tools that can be used together to build a GitOps framework, like Git repositories, Kubernetes, continuous integration/continuous delivery (CI/CD) tools, and configuration management tools. To choose the right set of tools, developers should identify their needs and what features will provide a solution. Here are a few tools to consider.
CI Tools
Continuous integration (CI) refers to the practice of automatically and frequently integrating code changes into a shared source code repository. As updates are made, automated testing steps are triggered to ensure the reliability of merged code changes.
Tekton: A Kubernetes-native framework for building CI/CD systems. It provides platform engineers and developers with the flexibility, best practices, and standardization they need to build, test, and deploy across cloud providers and on-premise systems.
Jenkins: is an open source automation server based on Java. It makes it easy for developers to integrate their changes by continuously testing, building, and deploying the projects easily with minimal setup required. An extension of the Jenkins ecosystem, Jenkins X helps automate CI/CD pipelines in the cloud.
CD Tools
Continuous delivery and/or deployment (CD) is a 2 part process that refers to the integration, testing, and delivery of code changes. Continuous delivery automates the release of validated code to a repository following the automation of builds and unit and integration testing in CI. Continuous deployment is an extension of continuous delivery, and can refer to automating the release of a developer’s changes from the repository to production, where it is usable by customers.
Argo CD: A declarative continuous delivery tool for Kubernetes. It allows development teams to deploy and manage applications without needing full knowledge about Kubernetes and full access to the Kubernetes system. By monitoring running applications, ArgoCD ensures that your applications do not fall out of sync with your desired states.
Flux: A GitOps tool that automates deployment on Kubernetes clusters by keeping cluster states in sync with Git repositories. Built on a set of Kubernetes API extensions, Flux supports application deployment and infrastructure management.
How to get started with GitOps
To get started with GitOps you need infrastructure that can be declaratively managed. Because of this, GitOps is often used as an operational 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. GitOps can be used to build development pipelines, code applications, manage configurations, provision Kubernetes clusters, and deploy on Kubernetes or container registries.
What is a GitOps workflow?
GitOps can be considered an evolution in 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 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, as CD becomes the responsibility of the GitOps engine and can function independently or as part of a CI orchestrated solution.
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 and applications whenever a difference is noticed between the actual state and what exists in the repository.
Observability, which refers to any system that can be observed, is an important concept in GitOps. Observability in GitOps helps you ensure that the desired state and the observed state (or actual state) are the same. GitOps provides observability around the resources it deploys, but it doesn't function as a general monitoring tool. Instead, Red Hat® OpenShift® Observability is a comprehensive set of tools that uses metrics, logs, traces, and events to help you overcome those limitations and establish feedback loops between app systems and git repositories. Together, GitOps and OpenShift Observability can provide insights into app systems through monitoring, analyzing, and troubleshooting.
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.
How Red Hat supports GitOps
Red Hat has a range of products that support your GitOps workflow. Red Hat OpenShift is a unified application platform that administrators can configure and manage using GitOps principles, allowing consistency across Kubernetes 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 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. It enables you to build and integrate declarative git driven CD workflows directly into your application development platform. Traditionally, your CI/CD tool would be one tool like Jenkins or Tekton, but now it’s 2 tools. You can use Jenkins or Tekton for CI, and GitOps which is a CD engine. Red Hat collaborates with open source projects like Argo CD to implement a framework for GitOps. Install the Red Hat OpenShift GitOps operator and develop new tools with Argo to manage GitOps within existing Red Hat OpenShift deployments.
OpenShift GitOps is available for cloud services, self-managed, and edge computing. Managed cloud services like Red Hat OpenShift Service on AWS (ROSA), Microsoft Azure Red Hat OpenShift (ARO), and Red Hat OpenShift Dedicated (OSD) help organizations increase operational efficiency, refocus on innovation, and quickly build, deploy, and scale applications.
Self-managed editions of OpenShift like Red Hat OpenShift Virtualization Engine provide the virtualization functionality of Red Hat OpenShift to deploy, manage, and scale virtual machines (VMs). OpenShift GitOps supports the automated deployment of VMs, and paired with OpenShift Virtualization Engine, helps users migrate and manage their VMs based on their virtualization needs. At the edge, the Red Hat build of MicroShift brings the power and scalability of Kubernetes, allowing applications to be written once and run right where they are needed — next to the data source or end user.
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. Advanced Cluster Management for Kubernetes uses OpenShift GitOps as a GitOps engine. It has features that help with managing application sets, Argo instances, and GitOps cluster configurations, as well as helping deploy policies.
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. Ansible can be a great tool as part of your GitOps workflow. Because Argo and GitOps only touch Kubernetes, Ansible can be used for automation outside of Kubernetes, especially for imperative actions. 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.
The Path to GitOps: A new e-book to guide you on your GitOps journey
Continuous integration, continuous delivery (CI/CD) and DevOps — you often hear these terms used interchangeably, and you’ve likely heard them bundled in together with GitOps. So what is GitOps? And when you’re comparing GitOps vs. DevOps, how are they different?
