GitOps, a DevOps operational framework from GitLab, applies best practices and application development technology to boost collaboration, support version control and apply CI/CD – all to support infrastructure automation.
DevOps teams commonly use GitOps in conjunction with other IT automation tools, especially those that support an ‘as code’ approach such as Progress Chef.
Chef software, an ‘as code’ proponent, is part of a recent Gigamon Radar for GitOps 2024 report that dives deep into the GitOps ecosystem.
With its code-based approach, Chef software perfectly complements GitOps. “Enabled by infrastructure as code (IaC), GitOps takes advantage of the “as code” aspect to move configuration information into version control systems,” the GigaOm report explained. GitOps has a world of DevOps benefits, including simplifying how IT infrastructure, operational systems and processes, and applications are managed. Take application updates. “Changes are driven by the source control system, so staff can drive many downstream actions via source control tools. Managing infrastructure and operational resource definitions in source control also provides additional semantics and controls for these elements compared to a non-GitOps approach,” GigaOm argued.
Many GitOps customers use Chef software for configuration management, where configurations are saved in a GitOps repository, as well as numerous other GitOps’ DevOps features. Version control is another key GitOps/Chef software area.
The Chef View
The Chef product team knows a thing or two about GitOps and version control. First, GitOps is an operational model that defines a way for IT and DevOps to operate systems. GitOps supports DevOps best practices including CI/CD tooling and version control and applies these to infrastructure automation. As an open platform, GitOps is technology agnostic, so DevOps can use the GitOps model with many forms of version control. “It’s important to remember that GitOps is not a single product, plugin or platform. GitOps is a set of principles and workflows that help teams manage IT infrastructure using the same processes they already use in application development,” explained the GitOps Approach to Harden Your CI/CD Pipeline blog.
The Chef/GitOps Synergy
As a configuration management tool, Chef uses declarative language to define, apply and maintain configurations. This is known as the ‘as code’ approach which Chef takes with configuration, as well as policies and other key IT infrastructure and DevOps items.
These code-based configurations are saved as Cookbooks. For GitOps users, they can be saved in the GitOps repository. Once in the repository, these playbooks have immutability, including a complete version history.
This graphic shows how Chef and GitOps add value to each other:
Prashanth Nanjundappa, Progress VP, Product, Infrastructure Management discussed Chef/GitOps and shared his own expertise on the subject. The next part of this blog is a summary of what Prashanth discussed with us.
Prashanth Nanjundappa, Progress VP, Product, Infrastructure
Based on real world customer experience, Nanjundappa believes Chef software and GitOps are a great match. For Chef, the essential foundation is the code.
The same is true for GitOps, as it focuses on defining your infrastructure ‘as code’. In this case, there is an end state, configuration or desired state which Chef software and GitOps can always maintain. Whenever there is change, DevOps can track and get to that desired state.
Last but not least, with Chef and GitOps, DevOps now has a way of auditing, collaborating and performing many other things that center your workflow around Git and its workflows.
The result is a human free zone for automation at scale. Here, policy as code unifies the code infrastructure. The Chef pieces don’t operate just in a private cloud, but also in a hybrid cloud, which is public cloud and private cloud. Chef also operates on-premises, bringing all of these together and giving a unified approach to solve these problems – and not just limited to infrastructure – but also going into apps and devices on the edge as well.
Policy-Based Infrastructure Automation
Every business needs policies. Typically, these policies must be created and codified – then someone needs to validate and enforce them. Policy as code has been the answer from Chef.
And it is not just for authoring policies, converting it from text to a human readable code, but also to build collaboration, scalability and having continuous visibility. So, you have not just the ability to create policies but testing and managing the life cycle of those policies you created.
You also have audit trails, and all the things you expect in source code. Once you create a policy, you can validate it, and have integration, roll forward and roll back. All of this is possible through visibility, analytics, automation, and orchestration – as well as governance.
And as you see, the policy is called the center of it all: where policy enforcement, policy validation and even policy remediation gets built in.
We have use cases which span across multiple cloud providers, not just giving the ability to build and enforce policies, but also get visibility across the cloud providers.
And with Kubernetes, we are continuing to provide more and more platforms in its ecosystem.
So how is this all related to GitOps? Chef software handles infrastructure through ‘infrastructure as code’, or holistically in ‘policy as code’. But this needs to be deployed in a controlled manner. It needs to be deployed in a reliable manner and it needs to be deployed when you want it – not when it is convenient for the pool.
One use case is OS patching. When it comes to this, when you commit ‘as code’, you want it to be promoted to an integration environment.
You need to execute this job only in an integration environment, and not necessarily in production. And you want to consider scheduling, perhaps do it only when there are there are some cycles left or schedule the job on a particular time of the day or time of the month. You can control the roll out actions, so they happen when you want.
You can also have code, which is committed, but don't want to roll it out to 100% of your infrastructure. You can roll it to 5%, see if it is successful, then extend it to another 10% and so on. If you find issues anywhere, you can rollback so that the infrastructure doesn't go in a limbo state.
How GitOps Boosts Your CI/CD Pipeline
In a typical CI/CD pipeline, several credentials are used throughout a CI/CD process. There are credentials to give read/write access to the code repository letting application developers check in code.
Once a code change is checked in by DevOps, a CI tool with read-only access to the code repository, monitors those changes and triggers a software build. In most pipeline scenarios, continuous delivery relies on a pipelining tool. That CI tool will have credentials to access the destination Kubernetes environment or cluster. “In this scenario, those credentials are crossing a logical security boundary. This means if the CI system is compromised, each Kubernetes cluster or environment that the CI system has access to is compromised,” the GitOps Approach to Harden Your CI/CD Pipeline blog explained.
The GitOps Repository
The GitOps configuration repository stores configuration files for infrastructure and applications, including Progress Chef Infra recipes. The idea behind a configuration repository is to serve as the source of truth for the desired state of your applications and systems. “It is used to automate the deployment and management of those systems by using Git as the central place to track and version changes to the configuration,” the Chef CI/CD Pipeline blog explained.
