GITOPS : An ideology
There is an evolved version of DevOps called GitOps: GitOps is the practice of using Git as the single source of truth.
We didn't even know this was a term back when we first realised we can use git as sole source of truth. One of our self learned devops guy showed us small demo where he keeps the keys for deployment and at any config file change in git would get auto-deployed using jenkins, and we discover a gem
Now we follow this ideology right from building containers to code builds, CDN deploys and ton of other things , through a git and git only.These are done through pull requests and hence has a full voting rights to revert option nothing goes un-tracked.
Many enterprises are seeking to move to a GitOps model because it provides a more standardised and governed system yet offers the flexibility and automation that today's companies desire.
This table compares DevOps and GitOps.
| Principle | Focus | Main Tool | Other Tools | Flexibility | Correctness |
|---|---|---|---|---|---|
| DevOps | Automation and frequent deployments | CI/CD pipeline | Supply chain management, Cloud Configuration as Code, etc. | Less strict and more open | Less focus on correctness |
| GitOps | Correctness; doing DevOps correctly | Git | Kubernetes, Controller (e.g., Operator), separate CI/CD pipelines, Infrastructure as a Code, etc. | Stricter and less open | Designed with correctness |
If you want to find out more in detail about GitOps, please watch this video.
Pioneered in 2017, 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. With GitOps, the use of software agents can alert on any divergence between Git with what's running in a cluster, and if there's a difference, Kubernetes reconcilers automatically update or rollback the cluster depending on the case. With Git at the center of your delivery pipelines, developers use familiar tools to make pull requests to accelerate and simplify both application deployments and operations tasks to Kubernetes.
An operating model for building cloud native applications
GitOps can be summarized as these two things:
- An operating model for Kubernetes and other cloud native technologies, providing a set of best practices that unify deployment, management and monitoring for containerized clusters and applications.
- A path towards a developer experience for managing applications; where end-to-end CICD pipelines and Git workflows are applied to both operations, and development.
Principles of GitOps
To start managing your cluster with GitOps workflows, the following must be in place:
#1. The entire system described declaratively.
Kubernetes is just one example of many modern cloud native tools that are “declarative” and that can be treated as code. Declarative means that configuration is guaranteed by a set of facts instead of by a set of instructions. With your application’s declarations versioned in Git, you have a single source of truth. Your apps can then be easily deployed and rolled back to and from Kubernetes. And even more importantly, when disaster strikes, your cluster’s infrastructure can also be dependably and quickly reproduced.
#2. The canonical desired system state versioned in Git.
With the declaration of your system stored in a version control system, and serving as your canonical source of truth, you have a single place from which everything is derived and driven. This trivialises rollbacks; where you can use a `Git revert` to go back to your previous application state. With Git’s excellent security guarantees, you can also use your SSH key to sign commits that enforce strong security guarantees about the authorship and provenance of your code.
#3. Approved changes that can be automatically applied to the system.
Once you have the declared state kept in Git, the next step is to allow any changes to that state to be automatically applied to your system. What's significant about this is that you don't need cluster credentials to make a change to your system. With GitOps, there is a segregated environment of which the state definition lives outside. This allows you to separate what you do and how you're going to do it.
#4. Software agents to ensure correctness and alert on divergence.
Once the state of your system is declared and kept under version control, software agents can inform you whenever reality doesn’t match your expectations. The use of agents also ensures that your entire system is self-healing. And by self-healing, we don’t just mean when nodes or pods fail—those are handled by Kubernetes—but in a broader sense, like in the case of human error. In this case, software agents act as the feedback and control loop for your operations.
Key benefits of GitOps
Automated delivery pipelines roll out changes to your infrastructure when changes are made to Git. But the idea of GitOps goes further than that – it uses tools to compare the actual production state of your whole application with what’s under source control and then it tells you when your cluster doesn’t match the real world.
By applying GitOps best practices, there is a ‘source of truth’ for both your infrastructure and application code, allowing development teams to increase velocity and improve system reliability.
Long story short, developing and delivering cloud native applications all the way to production through automated pipelines has become boring! Jenkins X leverages GitOps generously to setup and manage environments and application versions in Git repos, and not surprisingly, trends as one of the hottest OSS projects in the world of continuous everything.
