Quick comprehensive guide to GitOps

Are you familiar with GitOps and interested in catching up with your team? Or are you wondering if adopting this approach will solve some of your problems? This article explores the benefits of GitOps and its different approaches, and explains why it's worth considering for your team.

The Git in Git-Ops: Infrastructure As Code

If you guessed from the name that we're versioning something in Git, you're correct. Specifically, we're versioning the declarative code that defines our infrastructure. and GitOps is mainly just tracking and collaborating on the code that defines your infrastructure.

The Why?

When a team uses cloud or kubernetes and have many changing parts in their cloud account or in their clusters, tracking all the changes made to cloud resources or which image should be running on your deployment is hard to achieve if not tracked via git operations (a history of commits and PRs).

The non-GitOps way would involve team members (or just one member) provisioning infrastructure imperatively using AWS Console, AWS CLI, or kubectl. However, this approach has some unbearable flaws. It lacks the traceability of changes made to your infrastructure and can lead to configuration drift, inconsistencies, and unpredictability in your environments. These issues increase the risk of downtime, security vulnerabilities, and difficulty in automation. Ultimately, it can slow down your business goals as customers may lose trust in your ability to provide reliable and secure services.

Overall declaring infra and tracking it in Git, helps your team be less clumsy, rely less on human memory, and be more confident in the single source of truth(Git) that is sanitized by PRs. Ultimately avoid configuration drift and inconsistencies in your environments.

In my pov this will only work for your team is disciplined enough to version all the changes and allow not changes to sweep imperatively.

The How?

Tools like Pulumi and Terraform have emerged to help engineers write declarative Infrastructure as Code that can be easily version controlled in Git. All you have to do is:

1. Create a GitOps repository that is gonna hold the truth for you.
2. Protect the main branch of it from any force pushed changes, allowing only changes via PRs.
3. Create and change your infrastructure code, while testing on a sandbox environment.
4. If all goes well, You commit the changes and merge them to the main branch.

The next step is automating the changes that are approved into your master branch, and how to keep your environments in sync with what's in your repository.

The Ops in Git-Ops

Now that we have our Infrastructure defined and version controlled, we want to automate the execution of changes. which means an automatic provisioning of the defined infrastructure following the change of code.

There are two different styles of achieving this, there is the push-based and pull-based.

Push-based deployment

In push-based deployment, developers push changes to the infrastructure code to a Git repository. A CD tool like Jenkins, ArgoCD, Bitbucket Pipelines or Github Actions then picks up these changes and deploys them to the target environment. Ex:

Pulumi GitHub Actions enable you to create a workflow in your continuous delivery pipeline that previews or updates your environment.

If your Infrastructure as Code (IaC) consists of Kubernetes manifests, you can use the Kubernetes Action. This action helps you push the new changed manifests to your cluster.

This method is simple because it only requires adding one integration to your existing CD pipeline. The one-way push operation is simple and optimized, as it runs once per deployment and adds no stress to our network. it can also be used in Kubernetes and non-Kubernetes environments alike.

This approaches has two drawbacks:

• To enable the CD steps to apply changes, you must share the credentials of your cloud environment or cluster access in the environment variables of your repository. which makes push-based less secure.
• Since it's a one-way push, configuration drift can still occur if changes are made to the cluster manually or from other sources, which can negatively impact the consistency of your environment.

Pull-based deployment

This approach is often used in Kubernetes environments, where tools like FluxCD are used to automate the deployment of changes to Kubernetes clusters.

In pull-based deployment, the CD tool polls the Git repository for changes to infrastructure code and/or Container registries. When changes are detected, the CD tool's reconciliation loop automatically synchronizes the changes into your cluster, making it match the desired state you defined in the repository.

This approach is more secure as you don't have to share your cluster's access with CD pipeline to apply changes like in push-based.

This approach has a flaw that only becomes problematic at large scales and with big Kubernetes clusters. With many agents polling your container registries and Git (especially self-hosted), it can overload your network resources (i.e., bandwidth) and potentially hurt your overall performance.

Tips to Learn GitOps Fast

As a beginner, I would recommend you to start with the push-based approach, as it's easier to setup and understand. Once you get the hang of it, you can move to the pull-based approach.

To achieve any progress:

• First you need to familiarize yourself enough with Git and Basic CI/CD concepts in a hobby project.
• Add infrastructure code to your repository, Then add a (Push-based) CD step to your pipeline that applies the changes to your cloud environment.
• Once you get the hang of it, you can move to the pull-based approach (containerize your app and experiment with FluxCD or ArgoCD).

In short

GitOps is a powerful way to manage infrastructure. Where you define infrastructure as code, version control it in Git, and automate deployment of changes with CD tools. There are two deployment methods: push-based and pull-based. I prefer the pull-based method because it's more secure and less prone to problems. To choose the best approach, consider your team's needs and weigh the pros and cons of each method. Either way, you'll have better collaboration and compliance, and improved automation for more stability and resilience.