What is GitOps? Guide to GitOps — Continuous Delivery for Cloud Native applications

Image for post
Image for post

GitOps is a way to do Kubernetes cluster management and application delivery. It works by using Git as a single source of truth for declarative infrastructure and applications, together with tools ensuring the actual state of infrastructure and applications converges towards the desired state declared in Git. With Git at the center of your delivery pipelines, developers can make pull requests to accelerate and simplify application deployments and operations tasks to your infrastructure or container-orchestration system (e.g. Kubernetes).

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.

Modern software development practices assume support for reviewing changes, tracking history, comparing versions, and rolling back bad updates; GitOps applies the same tooling and engineering perspective to managing the systems that deliver direct business value to users and customers.

Image for post
Image for post

Pull-based Deployments

Image for post
Image for post
more info @ https://gitops.tech

The Pull-based deployment strategy uses the same concepts as the push-based variant but differs in how the deployment pipeline works. Traditional CI/CD pipelines are triggered by an external event, for example when new code is pushed to an application repository. With the pull-based deployment approach, the operator is introduced. It takes over the role of the pipeline by continuously comparing the desired state in the environment repository with the actual state in the deployed infrastructure. Whenever differences are noticed, the operator updates the infrastructure to match the environment repository. Additionally the image registry can be monitored to find new versions of images to deploy.

Just like the push-based deployment, this variant updates the environment whenever the environment repository changes. However, with the operator, changes can also be noticed in the other direction. Whenever the deployed infrastructure changes in any way not described in the environment repository, these changes are reverted. This ensures that all changes are made traceable in the Git log, by making all direct changes to the cluster impossible.

In Kubernetes eco-system we have overwhelming numbers of tools to achieve GitOps. let me share some of the tools as below,

Tools

  • ArgoCD: A GitOps operator for Kubernetes with a web interface
  • Flux: The GitOps Kubernetes operator by the creators of GitOps — Weaveworks
  • Gitkube: A tool for building and deploying docker images on Kubernetes using git push
  • JenkinsX: Continuous Delivery on Kubernetes with built-in GitOps
  • Terragrunt: A wrapper for Terraform for keeping configurations DRY, and managing remote state
  • WKSctl: A tool for Kubernetes cluster configuration management based on GitOps principles
  • Helm Operator: An operator for using GitOps on K8s with Helm

Also check out Weavework’s Awesome-GitOps.

Benefits of GitOps

  1. Faster development
  2. Better Ops
  3. Stronger security guarantees
  4. Easier compliance and auditing

Demo time 😄 — We will be using Flux

Image for post
Image for post
https://github.com/fluxcd/flux
  1. Install “Fluxctl”. I have used Ubuntu 18.04 for demo.
sudo snap install fluxctl 

2. Create new namespace called “flux”

kubectl create ns flux

3. Setup flux with your environmental repo. We are using repo “flux-get-started”.

export GHUSER="YOURUSER"
fluxctl install \
--git-user=${GHUSER} \
--git-email=${GHUSER}@users.noreply.github.com \
--git-url=git@github.com:${GHUSER}/flux-get-started \
--git-path=namespaces,workloads \
--namespace=flux | kubectl apply -f -

4. Set Deploy key in Github. You will need your public key.

fluxctl identity --k8s-fwd-ns flux
Image for post
Image for post
Image for post
Image for post

5. At this point you must have following pods, Services running on your cluster. (In “flux” and “demo” namespace)

Image for post
Image for post
namespace: flux
Image for post
Image for post
namespace: demo

6. Let’s test what we have deployed.

kubectl -n demo port-forward deployment/podinfo 9898:9898 &
curl localhost:9898
Image for post
Image for post

7. Now, lets make small change in repo and commit it to master branch.

Image for post
Image for post

By default, Flux git pull frequency is set to 5 minutes. You can tell Flux to sync the changes immediately with:

fluxctl sync --k8s-fwd-ns flux
Image for post
Image for post

Let’s do one more test, assume that by mistake someone has reduced/deleted your pods on production cluster.

Image for post
Image for post

By default, Flux git pull frequency is set to 5 minutes. You can tell Flux to sync the changes immediately with:

fluxctl sync --k8s-fwd-ns flux

You have successfully restored your cluster in GitOps way. No Kubectl required!!

Whenever the deployed infrastructure changes in any way not described in the environment repository, these changes are reverted.

Image for post
Image for post

Thank You for reading.

One more tool called “ArgoCD” is interesting and has some more features then “flux”. Argo is CNCF incubating project. You can get more info on,

Cloud Solution Architect at Walmart Japan

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store