Let’s Understand about GitOps

Introduction to GitOps

From the history if we have seen the growth of deployment phase, it has improved lot of ways. We all know how the deployments were happen half of the decade before, mostly it was manual or some basic automation script was used. Later we all know the how it was changed once containers got introduced. Containers has helped administrators to roll-out deployments within a second. Then again it took fast ways to roll-out production deployments by ensuring the scalability so that it meets the demand via orchestrators like Kubernetes.

Same time, when it comes to standard containers, workflow, it was not able to meet the ever-growing business demands. Even though we still there are a need for more efficient deployment and scaling of container clusters over Kubernetes which still could help to improve the deployment cycle.

We have got one best solution for that now, called GitOps. In this post let’s see what is the GitOps, its principles and benefits.

What is GitOps?

From the page mentions, “GitOps is a way of implementing Continuous Deployment for cloud native applications. It focuses on a developer-centric experience when operating infrastructure, by using tools developers are already familiar with, including Git and Continuous Deployment tools.

The core idea of GitOps is having a Git repository that always contains declarative descriptions of the infrastructure currently desired in the production environment and an automated process to make the production environment match the described state in the repository. If you want to deploy a new application or update an existing one, you only need to update the repository – the automated process handles everything else. It’s like having cruise control for managing your applications in production.”

Here some details how GIT can be used,

• Code – Developers can write a code and push it to Git.
• Build (Pipeline as Code) – Build pipeline code(yaml) in Git to build code using CI tools.
• Provision (Infrastructure as Code) – Write a terraform file or any configuration management playbook or cookbooks in Git to provision a Kubernetes cluster.
• Deploy – Write a deployment manifest for Kubernetes or based on the application.

GitOps

• Use Git as a source of truth
• Get version control, history, peer review, and rollback for all your ops code
• Continuous Delivery- Automates pipelines
• Webhooks: push to trigger build/test
• PR’s & merge branch to deploy

Git Source of Truth

• Infrastructure as a Code – Terraform, Pulumi, CloudFormation.
• Configuration as a Code – Ansible, Chef, Puppet, salt etc.
• Application Configuration as Code – Kubernetes, etc.

Basic Principles

GitOps has own principles, as mentioned below,

Everything as a code

GitOps forces to keep everything as a code, such as infrastructure, policy, configuration and security etc. With this everything can be tracked and make sure all the changes are documents in detail. This helps to understand everyone about your environments and setup details.

Single source of truth

GitOps follows VCS as a single source of truth, such as git. It helps to compare the configuration drift & helps in having an audit trail to make misconfiguration tracing easy. This makes error recovery as easy as issuing a git revert and watching your environment being restored.

Approved changes

Once PR is reviewed and merged in the configuration, it gets directly applied to the system.

Easy Credential management

GitOps allows you to manage deployments completely from inside your environment. For that, your environment only needs access to your repository and image registry. That’s it. You don’t have to give your developers direct access to the environment.

How GitOps Works?

GitOps procedures are performed by an underlying orchestration system. GitOps itself is an agnostic best practice pattern. Many popular GitOps solutions today primarily use Kubernetes as the orchestration system. Some alternative GitOps tool sets are coming to market that support direct Terraform manipulation.

To achieve a full GitOps install, a pipeline platform is required. Jenkins, Bitbucket Pipelines, or CircleCi are some popular pipeline tools that are complementary to GitOps. Pipelines automate and bridge the gap between Git pull requests and the orchestration system. Once pipeline hooks are established and triggered from pull requests, commands are executed to the orchestration piece.

A new pattern or component that is specifically introduced with GitOps is the GitOps “operator,” which is a mechanism that sits between the pipeline and the orchestration system. A pull request starts the pipeline that then triggers the operator. The operator examines the state of the repository and the start of the orchestration and syncs them. The operator is the magic component of GitOps.

There is two major deployment strategy for GitOps, Pull based and Push based Deployments. Difference between both are how it is resembles the desired infrastructure. Please be noted, when possible, the Pull-based approach should be preferred as it is considered the more secure and thus better practice to implement GitOps.

Push based Deployment

In the push approach, an external system (mostly CD pipelines) is triggering deployments to the cluster, after a git repository was committed to or a previous CI pipeline was executed successfully. In this approach, the pipeline system has access to the cluster.

Pull based Deployment

The pull approach is based on the fact, that all changes are applied from inside the cluster. There is an operator inside the cluster, that regularly scans the associated git repositories and docker registries and if a change occurs, the cluster state will be updated from inside. This process is generally noted as very secure, due to the fact, that no external client has credentials with admin access to the cluster.

Benefits

The below are the benefits of GitOps mentioned:

• GitOps manages all the updates and features of the Kubernetes more rapidly. By continuously pushing features to updates making businesses more agile and respond quickly to the customer as per the demands.
• GitOps have the complete pipeline. Continuous Integration and Continuous Deployment pipelines have driven by pull request and operations tasks fully reproducible with the help of Git.
• It’s cost-effective as it reduces operational overhead, lowers downtime & vastly improves productivity.
• It provides end-to-end standardization in the workflow.
• Improves stability as audit logs of cluster changes are present for validation of changes that occurred.
• Enhancement in productivity with continuous automated deployment as it reduces time.
• Improvised security as Git provides powerful correctness & cryptography to track & manage changes.
• Git’s built-in features like a rollback fork & being a single source of truth increases the reliability.

Best Practices

Please consider below best practices of GitOps when you are enabling in your environments.

• Declarative Infrastructure as Code with version and rollback function enabled.
• Immutable deployment.
• Operational changes made by Pull Request; don’t let CI push updates into the Kubernetes cluster or use kubectl manually.
• Build each container image just once and ‘promote’ it through each test sequence/environment, do not rebuild each time. Must update declarative configuration changes in Git.
• Monitor, observe – services & infrastructure.
• Different tools detect/alert divergence.
• Sync tools enable convergence.
• Completely automated delivery pipeline.

Thanks for your time, hope this is helpful. In upcoming posts lets see more about GitOps and GitOps Tools like ArgoCD etc. Please keep provide your support.