GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD tooling, and applies them to infrastructure automation. GitOps is a methodology for continuous deployment using a Git repository as the single source of truth. The Git repository is the source of truth for both declarative infrastructures as well as application workloads.
A dedicated GitOps component reads approved changes from the Git repository and applies the changes to the Kubernetes cluster through a CD pipeline. This provides for the separation of concerns and ensures that the Git repository reflects the current state of the cluster irrespective of who made the change and when.
Basic GitOps workflow
There are many GitOps operators out there, but the two main ones are Flux and Argo CD . The Flux and Argo CD GitOps operators are designed to work with Kubernetes. We choose ArgoCD due to its ease of use and functionalities.
ArgoCD makes it easy to define a set of applications with their desired state in a repository and where they should be deployed. After a deployment, Argo CD constantly monitors the state and can even catch configuration drift.
ArgoCD’s core component is the applications Controller that executes continuous monitoring of applications and then compares them to the live application state against the target state defined within the Git repository.
The application controller retrieves the desired resources manifest from the Git repository and compares it to the live resources from the Kubernetes cluster.
The dashboard above provides a detailed view of the same Argo application deployed in the image above. However, it also provides an understanding of the status of the Kubernetes resources. Now below we have the best way to manage the folder structure in GitOps.
The environments represent the different development platforms like Dev, QA, and Prod. In each environment, we have two different folders: 1. Cluster 2. Apps
First trace to the below path:
a) App of Apps:
An app can be created that can creates other apps, which in turn can create other apps. This allows one to declaratively manage a group of apps that can be deployed and configured in concert.
All the services/applications which are needed to be deployed to the cluster are placed in the apps folder.
All the other resources which are not user-defined applications will be placed in the cluster folder. Apps such as operators which installed on the cluster. Eg: Prometheus, Secrets operator.. etc
This folder is used for customization base, the manifests placed in this folder can be inherited by apps in environments. Thus, it will reduce manifest duplication.