GitOps – ArgoCD

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.

Principles of GitOps: 

Declarative configuration: The System state is described declaratively. Instead of providing a series of instructions on how to build the infrastructure, applying configurations and deploying the application, we declare the end state of what is needed. Declarative configuration is idempotent and can be run multiple times without any impact to the system consistency. 

Version controlled immutable storage: Git is the source of truth. The desired system state is versioned in Git. Multiple Git branches can be created to apply changes to different environments. A pull-request (PR) based approval process can be used along with gated check in to ensure that only approved changes are deployed to the environment.

Automated delivery: Git is the single place for operations (create, change, delete) performed by autonomous agents. An approved Git commit will result in a new deployment and a Git revert would rollback changes. 

Autonomous agents: Software agents known as operators enforce the desired state and alert on drift. These agents monitor the environment and alert for any divergence from the repository. It automatically corrects the divergence. 

Closed loop: Delivery of approved system state changes is automated.

Need of GitOps: 

Standardized workflow: Git as the source of truth improves Developer Experience and ensures easy adoption. Developers are familiar with Git. GitOps applies a consistent development workflow to operations. All operations are performed through Git commands.

Auditability: Tracking both application code & infrastructure definition in Git results in a full audit trail and compliance. GitOps promotes collaboration between development, security and operations using Git as the collaboration tool. Code reviews result in better stability of systems experiencing a high rate of change. 

Consistency: Infrastructure as a code result in easier rollback, more consistency, & standardization. Automation provides consistency reducing errors. 

Reliability: Continuous sync and Configuration drift detection results in reliable environments. 

Enhanced Security: Shifting security left to the GitOps operator. Security is also maintained as code. Traceability of who made/approved a change is automatically provided. Changes to the runtime state can only be applied by automated agents. 

GitOps Operator: 

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: 

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. 

https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/

ArgoCD dashboard with a sample application: 

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.

Environments: 

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: 1.1

1.1 Environments>dev>cluster>ArgoCD: 

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. 

https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-

bootstrapping/#app-of-apps-pattern 

b) Apps: 

All the services/applications which are needed to be deployed to the cluster are placed in the apps folder. 

c) Cluster 

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 

2. base>apps 

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.