It is particularly difficult to see clearly between the DevOps phenomenon and the GitOps method. This article aims to clear all this confusion and leave you with an opinion on the subject and preference for the best-suited GitOps approach.
GitOps is a workflow that optimizes, streamlines, and secures releases using a VCS (a version management system). This article will discuss GitOps best practices to help you understand why you should consider it in your project. So, if you’re new to GitOps or do not yet have a strong opinion on GitOps best practices, this article is for you.
Let’s start our discussion with the GitOps concept!
Unlock the future of intelligent applications with our cutting-edge Generative AI integration services!
What is GitOps?
Appearing in August 2017, the term GitOps was coined by Weaveworks, whose developers use Git as the only source of truth.
First, Alexis Richardson, CEO of Weaveworks, wrote a series of articles on the subject and also defined GitOps as Operations By pull request. And since then, several companies have taken up this methodology.
GitOps is an approach where we describe the state of our infrastructure in Git. The git repository should contain the desired state of the infrastructure and any changes made to the project. The operator monitors changes in the repository and applies those changes to ensure that there is no gap between the desired state (the contents of the repository) and the current state (the state of the environment).
Changes are reviewed, approved, and then merged into the master branch. Changes via the user interface or the command line are prohibited. Any changes must be approved through pull requests (or merge requests). Following this approval, the modification will be applied automatically by the operator.
Without even talking about infrastructure, you certainly use various tools to describe the desired state in production:
- If you’re using Kubernetes, a Helm Chart can represent your production application stack as a file;
- If you configure your machines with Ansible, you describe what will run inside an infrastructure via several files;
- There are many other use cases.
GitOps is there to organize all of this.
We can summarize the concept in one sentence: Organize the operations related to modifying an environment (generally production, but not only) based on one (or more) git repository.
In technical language, this means combining a source of truth with automation.
SERVICE DISABLED VETERAN OWNED SMALL BUSINESS (SDVOSB)
Source of Truth
When several people are working on a production objective, and in addition, there are several visions or versions of the objective, it becomes essential to know where the current reference is. With the GitOps method, you can store all the declarative files of your wanted state in Git.
The benefits are immediate:
- From a traceability point of view
- Change history
- Who changed what?
- Management of read and edit rights
- From a methodological point of view
- Several competing branches/visions
- Ability to edit in parallel
- Possibility of merging/reconciling several competing visions
In short, you can reuse all the good methods used during application development and apply them to the management of your infrastructure.
Automating
We look to build a continuous integration pipeline based on a Git repository, like what is usually done for application code; whatever the tool, for example, Gitlab CI, Github Actions, Jenkins / Jenkins X, or others.
In other words, we seek to check the validity and quality of the declarative code, and we can take advantage of this to test certain parts of it.
At this stage, we feel ready to deploy in production! So, whether you want to increase the frequency of deployments or avoid hazardous manual actions, the GitOps method invites you to automate script execution with a trigger that can remain human.
But be careful! There are two opposing strategies for continuous deployment: Push and Pull approaches.
Let’s take a closer look!
GitOps Push
If you consider that declarative files with a CI/CD tool and pipeline are enough components or if you have the source of truth concept already in place. The push approach of GitOps will be your preference.
The concept here is simple: you use your CI/CD pipeline for the last mile to deploy in production.
In technical terms, it is a question of launching; in the same way as continuous integration, the tool is chosen based on the files stored in Git and modifying the destination environment.
Most of the time, you will enslave the pipeline to a manual trigger action to remain the boss.
The positives are numerous:
- Simplified maintenance since similar to continuous integration
- No additional tool needed
- Retain control/understanding of each action
- Unlimited customization, based on Git or manual events
- Fairly easy to replay locally on your computer to debug
GitOps Pull: Flux or ArgoCD
No more CI/CD pipeline extensions! Here we make way for specialists: solutions that push the concept much further.
Two champions share the cake for the Pull approach to GitOps: Flux and Argo.
If, at some point in history, the two projects considered merging to form a single solution, it is because they have a rather different approach to the GitOps Pull model.
Flux is a cluster-centric solution, i.e., to be installed on each cluster and behaves autonomously. It is a set of open and extensible solutions for Kubernetes that are continuous and progressive.
If you want GitOps for both apps and infrastructure, Flux should be your preference. It has built-in workload dependency management and infrastructure and can manage any Kubernetes resource. You just need to push the Git, and the rest is done by Flux, working with your existing tools in the safest way possible.
The benefits are numerous:
- Standardized / guided / documented method of release
- You no longer have to maintain a deployment pipeline
- Automatic reconciliation between the requested target state and the current state
Now, to explain GitOps best practices, we take the example of the US Department of Defence and their use of Flux for the US Air Force U-2 jets!
How the U.S. Department of Defense Uses Flux and Helm-GitOps Best Practices!
The US Department of Defense (DoD) needed GitOps to manage over 100,000 developers against node drift. They knew that the only solution they had to enable automation and manage drift was GitOps. A clear choice for them at Platform One was Flux, a CNCF Incubating project, providing full support for Helm. This offered their end users a strong ecosystem of tools.
For teams to build software safely, Chaillan (Chief Software Officer of the US Air Force) and his team created a DevSecOps platform, Platform One, to use Kubernetes clusters and other technologies that are CNCF-compliant across the DoD.
The purpose of designing PlatformOne was to gain centralized configuration management, automation, and Kubernetes cluster management. In this way, DoD became one of the early adopters of GitOps and many CNCF technologies and became the first government organization to become CNCF’s part.
In addition, besides being powered by Flux and Helm, the project also takes hold of other CNCF projects such as Fluentd/Fluentbit, Open Policy Agent (OPA) Gatekeeper, Jaeger, Argo, Kubernetes, and Envoy (Istio).
The only two options for CD by the CNCF Tech Radar are Flux and Helm. For DoD contractors, Helm is the best solution to access an entire ecosystem of tools. Since Flux uses the native Helm SDK, the combination of the two provided a fantastic solution. Their team could utilize the available experience required to meet their GitOps needs and an extensive Helm ecosystem.
The DoD contractors deploy and manage their software on Air Force U-2 jets with Flux. They trust Flux throughout their work with Platform One, both Air Force and Navy, to create a streamlined workflow for developers of the US Navy. They also benefit from the enterprise-level reliability of FLux by using it on the Air Force’s U-2 DragonLady. It also allows them to make seamless and regular updates.
In addition, unlike other solutions, they do not need tight coupling of Flux versions with other software versions. Thus, their team uses Flux to roll out almost all of their tools.
Small Disadvantaged Business
Small Disadvantaged Business (SDB) provides access to specialized skills and capabilities contributing to improved competitiveness and efficiency.
Conclusion
Adopting the GitOps method has significant gains:
- Reversibility
- Track changes by name, with authentication
- Facilitates management within large teams
- The Git repo can be considered a source of truth and correctly represents the various environments, including production
However, it is crucial to consider a few things when setting it up.
- For simple use: favor the push approach.
- To make it the cornerstone of your organization: favor the pull method, depending on the organization. But be careful to train the operational teams properly.
Indeed GitOps is a must-have in any case!
Optimize your infrastructure with the right DevOps and Kubernetes solutions with Cloud Computing Technologies (CCT). The CCT experts can design tailor-made platforms. Thanks to the end-to-end automation and the latest DevOps techniques, CCT specialists can enable you to optimize your development cycle (GitOps) and improve collaboration between your teams.
Further blogs within this GitOps Best Practices category.