 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
GitOps, in its simplest form, is the principle of defining all of your resources in Git, a free and open source distributed version control system. The term was coined by Weaveworks in 2017. However, since then several new players are advancing the game with:
This article will provide an overview of those developments and how they aim to advance GitOps.
First and foremost, GitOps is a practice for deploying software. It refers to the role of git for deployments, the frequency of deployments, and the human-to-machine-interaction. When implementing GitOps, git is used as a single source of truth for all deployment resources. When rolling out new deployments to your clusters, developers will interact with all resources through git. As a result, if all of your resources are defined within git, it becomes easier to automate processes and implement tools for higher observability. This in turn allows teams to deploy more often and gain higher confidence in their deployments.
Before we start talking about the fancy new platforms and tools that are being developed and are in use to enable GitOps at scale, we should have a look at what is needed at a minimum to fall under GitOps:
So far, GitOps has largely been driven by open source projects, such as ArgoCD and Flux. Throughout the past year, more projects started emerging. With the GitOps space being still in its infancy, every project takes a slightly different approach to implementing GitOps. Since Argo and Flux are the most prominent, the next two sections will take a closer look at those.
ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes. ArgoCD is part of the Argo project family, a set of projects that are incubated within the Cloud Native Computing Foundation (CNCF). All Argo resources are Kubernetes Definitions, and as such are deployed like other Kubernetes resources to your cluster. This makes it possible for Argo to directly interact with your deployments. The CLI and their UI provide a comprehensive toolset for deploying in git defined resources to your cluster.
Flux was initially developed by Weaveworks before becoming a CNCF project. It is a continuous delivery solution for Kubernetes. Similar to ArgoCD, all the deployment resources are defined in Git. New deployments are rolled out based on pull requests, rather than direct interactions with your Kubernetes cluster. Flux itself is deployed through a set of Kubernetes controllers and APIs, also referred to as the GitOps Toolkit.
Besides the open source tools and platforms mentioned in previous sections, we can see more commercial vendors getting involved. For instance, Weaveworks is providing GitOps tools through its development of Weave Cloud and its Enterprise Kubernetes Platform. At the same time, Codefresh is integrating with ArgoCD to provide advanced GitOps tooling. These are just two examples of several organizations, which are getting involved and contribute to the development of GitOps.
To gain a balanced understanding of GitOps, it is important to look at both its benefits but also current critiques and suggested improvements. Codefresh published a series of articles that provide a comprehensive overview of the shortcomings found in GitOps, as it is implemented today (we have also published about this on The New Stack). Similar shortcomings have been explored by other organizations in the cloud native space. These conversations led to further improvements and collaboration, such as the GitOps Working Group.
The GitOps Working Group was set up by Amazon, Codefresh, GitHub, Microsoft and Weaveworks in November 2020. It is an open CNCF community project with the goal of providing organizations and individuals with the resources to implement GitOps.
As of today, the space has developed different definitions and practices around GitOps. The GitOps Working Group aims to pave the way to define and standardize those, to make it easier to collaborate and to drive further adoption.
Codefresh published a vision for GitOps 2.0 and the direction that we want to take to work on improving the aforementioned shortcomings. These are centered around standardized methodologies for the processing of information used within deployments, higher observability into deployments, and ways that tools can provide further value for GitOps by highlighting the right information.
It is worth mentioning that GitOps is still in its very early stages, with lots of experimentation and research to be done to create a cohesive understanding.
GitOps is a new paradigm, so it might be hard to find enough content around best practices and recommendations. These are some resources that provide further information to develop a good understanding of GitOps:
Feature image via Pixabay.
