Overview of GitOps
What is GitOps? Guide to GitOps — Continuous Delivery for Cloud Native applications
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.
Pull-based Deployments
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
- Faster development
- Better Ops
- Stronger security guarantees
- Easier compliance and auditing
Demo time 😄 — We will be using Flux
Prerequisites: You must have running Kubernetes cluster.
- Install “Fluxctl”. I have used Ubuntu 18.04 for demo.
sudo snap install fluxctl 2. Create new namespace called “flux”
kubectl create ns flux3. 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
5. At this point you must have following pods, Services running on your cluster. (In “flux” and “demo” namespace)
6. Let’s test what we have deployed.
kubectl -n demo port-forward deployment/podinfo 9898:9898 &
curl localhost:9898
7. Now, lets make small change in repo and commit it to master branch.
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
😃 Wow ㊗️ our changes from our repo has been successfully applied on cluster.
Let’s do one more test, assume that by mistake someone has reduced/deleted your pods on production cluster.
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 fluxYou 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.
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,
Want to read more? Here some more interesting blogs for you,
