What is multi-cloud GitOps?

GitOps is a set of principles that guides your workflow and enables you to implement continuous deployment (CD) for cloud native applications. It helps you manage your cluster configuration and application deployments by introducing automation to a previously manual process. For example, GitOps can help you manage Red Hat^® OpenShift^® Container Platform clusters across multi-cluster Kubernetes environments. GitOps automates deployments, no matter how simple or complex, making application workflows more efficient.

GitOps can help deploy a new application or update an existing one. You update the repository, and a GitOps workflow can automate everything else. 

Specifically, GitOps can enable:

• Management of hybrid and multi-cloud deployments across both public and private clouds
• Cross-cluster governance and application lifecycle management
• Secure management of secrets across the deployment

These functions help alleviate the challenges that come with a multi-cloud approach, such as the need for consistency, security, and collaboration as workloads move across public cloud, private cloud, and even on-premises environments. 

In GitOps, the Git repository is the sole source of truth for system and application configuration. It consists of a declarative description of the infrastructure for your environment and works in tandem with automated processes handled by GitOps tooling like Argo CD. This automation makes the actual state of your environment conform to the described state. You can also use the repository to view the list of changes to the system state, because the Git history provides change tracking. 

Additionally, storing your infrastructure and configuration as code can help you reduce sprawl. You can store the configuration of clusters and applications as code within Git repositories. 

Organizations need to develop, deploy, and operate applications on an open hybrid cloud in a stable, simple, and secure way. To do so, they need a hybrid strategy that includes multi-cloud deployments. 

There are significant challenges to the multi-cloud approach. For instance, different cloud vendors provide different tools that may not work well with other vendors’ offerings. As a result, workload migration can be costly and difficult. That lack of portability also leads to higher security risks and data privacy concerns. 

However, Kubernetes has addressed many of those challenges. With Kubernetes, multiple clusters can run on different cloud environments, including on-premises. Workloads can seamlessly move across the environments without incurring those same migration and security difficulties. 

Workloads in such a deployment might be running on multiple clusters and on multiple clouds—private or public. This strategy alleviates the previous challenges, but also requires an infrastructure-as-code approach. In other words, a modern multi-cloud strategy requires GitOps. 

As explained above, GitOps uses Git repositories as a single source of truth to deliver infrastructure-as-code. Submitted code first goes through the continuous integration (CI) process, while the continuous delivery (CD) process checks and applies requirements. All changes to code are tracked, providing familiar version control and revision functionality. 

GitOps thereby enables collaboration between infrastructure teams, in order to accelerate the development process. It brings consistency to the multi-cloud approach, and does so through automated processes, as opposed to manual processes, which can be costly and risk human error. 

As such, organizations implementing a multi-cloud approach need consistency and security across their environments. They need a GitOps solution, such as Red Hat OpenShift GitOps.

Red Hat OpenShift GitOps is an operator that installs and configures an Argo CD instance for you. It manages your infrastructure configuration and application deployments, organizing the deployment process around these configuration repositories. At least two repositories are always central to the process:

• Application repository with the source code
• Environment configuration repository that defines the desired state of the application

To maintain cluster resources, Red Hat OpenShift GitOps uses Argo CD, an open-source tool for the continuous deployment portion of the continuous integration and continuous deployment (CI/CD) of applications. Namely, Argo CD acts as a controller for Red Hat OpenShift GitOps by monitoring application state descriptions and configurations, as defined in a Git repository. It compares the defined state to the actual state, and then reports any configurations that deviate from the specified description. 

Administrators can resync configurations to the defined state based on these reports. That resyncing can be manual or automated. In the case of automation, the configuration is essentially “self-healing.”

As such, Red Hat OpenShift GitOps and its automated processes allow you to:

• Ensure that clusters have similar states for configuration, monitoring, and storage
• Apply or revert configuration changes to multiple clusters
• Associate templated configuration with different environments
• Deploy applications across clusters, from staging to production

Operators are the preferred method of packaging, deploying, and managing services on the OpenShift Container Platform control plane. For example, GitOps Primer is an operator that exports Kubernetes objects, allowing them to be shared across clusters, teams, and environments. It is part of how GitOps helps bring consistency, security, and collaboration to a multi-cloud approach. 

They integrate with Kubernetes APIs and command line interface (CLI) tools to provide the means of monitoring applications, performing health checks, managing over-the-air (OTA) updates, and ensuring that applications remain in your specified state.

Two different systems manage operators in OpenShift Container Platform, depending on their purpose:

• Cluster Operators: these are managed by the Cluster Version Operator (CVO), and are installed by default to perform cluster functions.
• Optional add-on Operators: these are managed by Operator Lifecycle Manager (OLM), can be made accessible for users to run in their applications.

Operators help you create applications to monitor the running services in your cluster. They implement and automate installation and configuration operations, as well as autoscaling up and down and creating backups. All these activities are in a piece of software that runs inside your cluster.

Operators provide:

• Repeatability of installation and upgrade
• Constant health checks of every system component
• Over-the-air (OTA) updates for OpenShift components 
• A place to encapsulate knowledge from field engineers and spread it to all users, not just one or two

GitOps Primer is an operator that runs in your OpenShift cluster that gives the ability for developers to export all Kubernetes objects within a namespace. It produces a portable .zip file so that you can: 

• Transfer it to another cluster
• Share it with team members
• Push it into GitOps workflows using Argo CD or Red Hat Advanced Cluster Management for Kubernetes (RHACM). 

GitOps Primer helps facilitate the infrastructure-as-code approach that GitOps brings to multi-cloud.

Git serves as the single source of truth for infrastructure and application configuration. Both infrastructure configuration and application configurations require access to sensitive assets, most commonly called secrets (e.g. authentication tokens, private keys, etc), in order for GitOps tooling to perform that function.

However, storing secrets in your Git repository represents a security vulnerability and should not be allowed, even when the repository is considered private and contains access controls to limit the audience. Once a secret has been pushed in clear-text (or in an easily reversible state) to Git, it must be considered compromised and should be revoked immediately.

To overcome this challenge, there are two main architectural approaches for secrets management in GitOps:

• Encrypted Secrets
  • Stored within Git repositories
  • Automated processes decrypt and render them as Kubernetes Secrets
• Reference to secrets are stored in Git repositories
  • Automated processes retrieve the secrets based on these references
  • The retrieved secrets render as Kubernetes Secrets 

For an in-depth look at these two approaches, read A Guide to Secrets Management with GitOps and Kubernetes.

Now that you have a conceptual understanding of multi-cloud GitOps, you’re ready to learn how to develop with GitOps, including:

• Getting started with Argo CD and OpenShift GitOps Operator
• Getting started with syncwaves and hooks
• CI/CD with Red Hat Ansible^® Automation Platform and Jenkins on OpenShift

You can also keep browsing articles related to OpenShift GitOps, including:

• What are validated patterns?
• What is Argo CD?
• What is CI/CD?