What is GitOps?
GitOps takes DevOps best practices that are used for development like version control, collaboration, compliance, and CI/CD tooling, and applies them to automate infrastructure. Since the software development lifecycle has been automated and infrastructure still requires manual processes, infrastructure management requires specialized teams, which is not feasible for any organization. This is the reason that rising infrastructure demand needs infrastructure automation. Modern infrastructure needs to be elastic so that it can effectively manage cloud resources that are needed for continuous deployments.
Modern applications are developed with speed and scale in mind where automation plays a crucial role, but there is the absence of automation in infrastructure management. That’s why GitOps comes into the picture.
GitOps automates the infrastructure provisioning process. Like those teams that use application source code, operations teams that adopt GitOps use configuration files stored as code (infrastructure as code). GitOps configuration files generate the same infrastructure environment every time it’s deployed, just as application source code generates the same application binaries every time it’s built.
How Does GitOps Work?
GitOps combines Git and operations, or resource management. Git is an open-source version control system that tracks code management changes. Like DevOps, GitOps aims to use CI/CD to automatically deploy your resources by using code stored in your Git repositories. With GitOps, your infrastructure definition code, defined as JSON or YAML and stored in a .git folder in a project, lives in a Git repository that serves as a single source of truth.
While using Git’s features, an organization can see the complete change history for the infrastructure code, and once needed, teams can roll back to an earlier version. Git ensures that bad infrastructure is not used in infrastructure management, as bad infrastructure code can accidentally prove expensive cloud infrastructure and cost the company thousands of dollars per hour.
Even worse, a bad script could also take down your application, resulting in downtime for your services. Using Git, many people can review the code and prevent these mistakes
Benefits of GitOps:
- Collaboration on Infrastructure Changes: Every change, either merge request, review, or approval, goes through the same process. Hence, senior engineers can focus on other areas rather than critical infrastructure management.
- Less Risk: All changes can be rolled back to a previous state, as changes to infrastructure are tracked through merge requests.
- Faster Time to Market: Manual monitoring and correction are time-consuming. While execution via code is faster, as test cases are automated and repeatable. Thus, stable environments can be delivered rapidly.
- Simplified Auditing: Auditing across a set of multiple interfaces can be complex if done manually because data is pulled from multiple places and normalized in order to conduct the audit. But GitOps stores all changes to environments in the git log and makes auditing easy.
- Reduced Costs and Downtime: Once you automate infrastructure and remove manual testing from the practice, productivity increases and downtime reduces due to built-in revert/rollback capability. Also, automation teams manage cloud resources better, which improves cloud costs.
- Less Error-Prone: Infrastructure definition is codified and the process becomes repeatable, which makes it less prone to human error. With code reviews and collaboration in merge requests, errors can be identified and corrected before they ever make it to production.
GitOps Best Practices:
GitOps seems quite promising but you would not want to take it as an experiment. But that doesn’t mean that you don’t use it at all. Here are some of the best practices that you can implement in your GitOps strategy.
- Define All Infrastructure as Config Files:
Ensure all the infrastructure you want to manage via GitOps is described in IaaC config files. To do that, files should be written in declarative code. The biggest advantage of doing this is: you describe the end state - what you want rather than instructions of how to get there. For example, use a JSON file with properties describing how you want to set up your services, rather than a JavaScript file where you instruct a provider to create services for you.
For the best results, describe all of your infrastructures, as the omission of even one service, however it takes only a minute or two, can sabotage your GitOps strategy.
- Document What You Can’t Automate:
Some tasks can be automated and require manual efforts. In such a case, always document the instances, as it will save a lot of time. Plus, a documented process can be followed by anyone in the team. It reduces dependency and helps you maintain agility.
- Consider Multiple Environments:
It’s good practice to have multiple environments. One example you might follow is the DTAP environments: Development, Test, Acceptance, and Production. Code can be rolled out to the Development or Test environment, after which you can test whether the services are still available and working as expected. If they are, you can further roll out your changes to the next environments. After you have rolled out your code into your environments, it’s important to keep your code in sync with your running services. Once you know there’s a difference between your system and your configuration, you can fix either one. A solution to this problem is to use immutable images, such as containers so that it’s less likely to have differences.
- Make CI/CD the Access Point to Resources:
One practice that encourages a GitOps workflow, and reduces manual changes to cloud infrastructure, is to make your CI/CD tooling the access point for cloud resources. Having this access during initial development can really help teams write their code.
Conclusion
Before the introduction of cloud computing, setting up servers was a tedious task. However, it changed when organizations began to shift to cloud computing, yet something was missing. Setting up servers or VMs on particular cloud platforms was easy, as they introduced declarative code to provision the entire architecture. For example, AWS used Amazon CloudFormation and for Azure, it was Azure Resource Manager. Now the problem with using these resources is that you can’t use them to set up your servers and VMs on multiple cloud platforms.
GitOps seems to end this problem and the dependency on a specific cloud vendor. Using GitOps, you can set up your cloud resources on multiple clouds without writing different codes.
