Overview of making Hybrid Multi-cloud GitOps works

Overview of making Hybrid Multi-cloud GitOps works

To overcome the common obstacles of going hybrid and multi-cloud, such as finding talents with multi-cloud knowledge. Secure and protect across low trust networks or just day to day operation across the board. I have identify some solutions from the study, where I will be covering in the serie of articles: 

IaC and GitOps,

Infrastructure as code (IaC) allows the infrastructure to be more visible among teams through sharable files and scripts that contain how environments are set up and configured. We can also automate to speed up the provisioning and deployment process and avoid manual misconfiguration. GitOps takes it a step further, better managing the setting and configuration files into a versioned, centralized repository as the single source of truth. This allows better collaboration. At the same time, applying pipeline along with status check and testing, is perfect for introducing the continuous integration and continuous delivery (CI/CD) practice. This eliminates configuration drift, by constantly checking if the end environment is in-sync with the desired state defined in the repository. 

How it works,

First, we start with getting the management hub ready. (for more information, see my previous post.) In short, in the management hub, we will have Red Hat Advanced Cluster Management for Kubernetes (RHACM) installed. Where it is used for provisioning/patching/updating the OpenShift/Kubernetes clusters (This is the key to hybrid and multi cloud environments). On top of RHACM, OpenShift GitOps is also installed for declarative continuous delivery, where it watches the manifests in repositories and automatically(or manually after configuration) updates deployments to the desired state. 

Here is the flow of infrastructure continuous delivery on hybrid and multi cloud: 

1. Manifest and configuration are set as code template in the form of “Kustomization” yaml. It describes the end desire state of how the managed cluster is going to be like.  When done, it is pushed into the source control management repository with version assigned to each update. 

2. OpenShift GitOps watches the repository and detects changes in the repository.  

3. OpenShift GitOps creates/updates the manifest by creating Kuberenet objects on top of RHACM.

4. ACM provision/update/delete managed clusters and configuration according to the manifest. In the manifest, you can configure what cloud provider the cluster will be on, the name of the cluster, infra node details and worker node. Governance policy can also be applied as well as provision an agent in the cluster as the bridge between the control center and the managed cluster. 

5. OpenShift GitOps will continuously watch between the code repository and status of the clusters reported back to RHACM. Any configuration drift or in case of any failure, it will automatically try to remediate by applying the manifest (Or showing alerts for manual intervention). 

For application or updating during the continuous delivery, the process is very similar: 

1. Developers have continuous integration pipelines to build application binary and images. Any changes to the infrastructure will also be pushed to the source control management repository.

2. OpenShift GitOps watches the repository and detects changes in the repository.  

3. OpenShift GitOps create/update kustomize resources directly on to the managed clusters via the control plane

4. Change locally in the managed cluster.

This concludes my study on the overall architecture of how GitOps works in Hybrid Multi-cloud environments. If you want to dive deeper into the technology, check out Ales Nosek’s youtube video, where in his video he will take you through step by step on how to do GitOps to manage your clusters.