GitOps : What is GitOps

 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 All Credits to the Video Creator of this link : https://www.youtube.com/watch?v=f5EpcWp0THw

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

All starts with Infrastructure as code done right with all the best practices.  

Define infrastructure as code instead of creating it manually.  This helps us in easily reproducing the infrastructure.

This is not infrastructure any more .

So once you make these changed over your github or your local computer how do you implement in yout actual infrastructure. You would manually from your laptop

• kubectl apply
• terraform apply

So to execute the code changes , each member must access the Kubernetes cluster or aws infrastructure and apply changes there from their from their local machine. And this can make it hard to trace who executed what to the infrastructure or have histories of changes applied to the infrastructure. 

And if you made a mistake in the code you will only know them once you apply them. For which you will apply those changes in the Development and to staging and production environments.

 

So even though we have infrastructure as code which already has loads of benefits ur process is still manual and inefficient .

So that's where GitOps concept comes into picture to treat the Infrastructure as Code the same way as it treats Application as Code.

So for GitOps practice we have a separate repository for "Infrastructre as Code"  for project or X as Code . And a full DevOps Pipeline for it.

How does GitOps work and why is it so useful ?

In GitOps "IaC" Infrastructure as a Code is hosted on a Git Repository where it is Version Controlled and Team Collaboration -  That's the first step

So when you make changes instead of just pushing to the Main branch you go through the same pull request process as for your application code. So any one including the junior engineer can create a Pull Request . Make changes to the code and collaborate with other team members on that pull request.

For these change you will have CI pipeline that will validate the "Configuration files" and Run Automation test just like you do application code changes after testing these commits , Other team members can approve the final changes.  This could be developers , security professionals  or other senior operations engineers  who will review and approve the pull request this way you have a - Tested and Well Reviewed configuration changes before they get applied to the environment so only after that changes will be merged back to the main branch and through the CD pipeline get deployed to the environment whether is is making changes to the Kubernetes cluster or whether it is making changes in the underlining AWS infrastructure.

So you have a Automation process which is more transparent produces high quality IaC where multiple people get collaborated and things get tested. Rather than only one engineering doing everthing from his laptop manually what other don't see and cannot review.

So we said that once we merge with the main branch things will be automatically applied to the infrastructure through a CD Pipeline right

In GitOps we have two ways of applying these changes.

These are 

• Push Deployment : Push based deployments is what we know from the traditional application pipeline on Jenkins or GitLab CI/CD etc . Application is built and a pipeline executes a command to deploy the new application version into the environment  

 

• Pull Deployment : Here is an agent installed in the environment for example in k8s cluster that actively pulls the changes from the Git Repository itself. The Agent will check regularly what is the state of the infrastructure code in the repository and compare it to the actual state in the environment where it is running.  If it sees there is a difference in the repository it will pull and apply these changes to get the environment from the actual stage to the desired stage defined in the repository.

 

 Examples of GitOps tools that work with the pull based model 

• Flux CD
• Argo CD

They run inside Kubernetes cluster and sync the changes from the Git Repository to the cluster

Kubernetes Backup & Recovery for dummies -- KASTEN

GitOps -- Making a easy Roll Back Possible 

So when you have the version control for your code and when the changes from the repository are automatically synced to the environment you can easily roll back your environment to any previous state in your code.

For example if you make changes that breaks something in the environment so your cluster doesn't work anymore you can just do

$ git revert   // to undo the latest changes and get the environment to your last working state

Single source of Truth

Instead of spreading Iac , Configuration as a code in different machines - everything is stored centrally in the Git Repository and the environment is always syncing with what is defined in that repository. And what means is that the Git repository becomes the singe source of truth for your environment.

Increases Security :

GitOps also increases security . You do not have to give every one in the team the access to change something in the repository or in Kubernetes cluster . Because it is the CD Pipeline that deploys the changes not individual team members from there laptops.

But anyone in the team can propose changes to the infrastructure in the Git Repository through pull requests. And once it is time to merge that pull request and apply those change you can have a much narrower group of people who are allowed to approve and merge those changes into the main branch so that it gets applied.

As a result you have a 

• Less Permissions to Manage 
• More Secure Environment