The Evolution of Configuration Management: IaC vs GitOps

March 08, 2022

Misconfigurations are the leading cause behind security incidents in Kubernetes-orchestrated or otherwise containerized environments. Without proper configuration in place, applications would run into problems ranging from noncompliance and inconsistencies to performance bottlenecks, security vulnerabilities and functionality failure. Configuration management is a critical component in a software development lifecycle for maintaining systems in a desired, consistent state.

Related posts

The 16-point Checklist for GitOps Success

Liquid Metal is Here: Supported, Multi-Cluster Kubernetes on micro-VMs and Bare Metal

Level up Security Management with HashiCorp Vault and Flux

According to Red Hat’s State of Kubernetes Security report, misconfigurations were the leading cause behind security incidents in Kubernetes-orchestrated or otherwise containerized environments. Without proper configuration in place, applications would run into problems ranging from noncompliance and inconsistencies to performance bottlenecks, security vulnerabilities and functionality failure. This would make cloud-native systems unstable and cause them to become a liability to business. For this reason, configuration management is a critical component in a software development lifecycle for maintaining systems in a desired, consistent state. The way configuration management is done has been evolving over the years. In this post, we trace the history of configuration management with a focus on how GitOps handles this important aspect of running cloud-native applications today.

The Legacy of Configuration Management

Back in the day, when it came to managing changes in IT resources, the IT team’s focus was mainly at the server level to see if any change in the hardware would lead to problems in the rest of the stack. Each server was manually configured with the greatest of care and leisure. Virtual machines brought greater flexibility and efficiency to this process.

Infrastructure as Code (IaC) was a big step for configuration management where the entire hardware was defined as code. IaC tools such as Terraform, Chef, Puppet, and Ansible played a key role in simplifying and scaling infrastructure management. They helped speed up infrastructure provisioning and reduced costs by improving resource utilization.

Over the years, cloud-based platforms, and containers in particular, have revolutionized the way infrastructure is provisioned. With mainstream cloud adoption and Git becoming the prevailing version control system, GitOps has emerged as the latest turn in the evolution of configuration management. GitOps goes even further than IaC when it comes to describing everything as code. ‘Everything’ here includes infrastructure, networking, data, and applications.

Kubernetes and the declarative approach to infrastructure

Just as with programming, there are two approaches to provisioning infrastructure — declarative and imperative.

The imperative approach requires you to specify the exact steps to be taken to provision or modify infrastructure. It offers a hands-on experience of deploying infrastructure. On the other hand, the declarative approach is more suitable to the modern cloud-native approach that Kubernetes defines. It requires that you only define the desired state of the system, and leave its execution to a platform like Kubernetes. Kubernetes makes both infrastructure automation and declarative configuration easier.

The Shift From DevOps to GitOps

Envisioned in 2017, GitOps is a modern operational framework to manage Kubernetes clusters and deliver applications with a focus on Git. It inherits the best bits of DevOps such as CI/CD tooling, collaboration between Dev and Ops, automation of processes and applies them to the software delivery pipeline using Git as a single source of truth.

DevOps ensured collaboration between the development and operations teams and brought a cultural shift in the IT sector. But where it fell short of expectations is when organizations embraced continuous integration, and aspects of continuous delivery, but did not go all the way to continuous deployment.

This is where GitOps takes things to the next level. With the GitOps approach, teams not only define but also manage deployments and changes to their infrastructure right from a Git repository. Making changes in infrastructure is now as easy as creating a pull request — you can catch typos, do regular reviews, or even revert a commit if you have to. Using Git, developers are now able to commit code, and platform engineers are able to automatically deploy this code into production.

Using Flux & Helm for GitOps-driven configuration management

Kubernetes allows you to integrate various tools to automate scheduling, deployment, and monitoring of containers. One such tool is Helm which has become wildly popular in the GitOps ecosystem.

Helm is a powerful package manager for Kubernetes that facilitates the definition, installation, and deployment of highly repeatable applications and services used in a variety of scenarios. Helm Charts add great value to the continuous delivery environment by offering an organized packaging format for managing multiple YAML files with duplicated and hardcoded values.

In a nutshell, Helm helps you manage complex releases while keeping things simple when you scale. But it needs to be bridged to the essential Git repositories where the K8s cluster and app specifications are defined. Flux facilitates just that.

Flux is a set of open source GitOps agents that act as a bridge between Git repositories and Kubernetes clusters. It is a declarative deployment automation tool that maintains code consistency by automating Helm Chart releases when code changes are introduced. Flux synchronizes these changes from Git to the Kubernetes clusters. It does so with custom resources called HelmReleases that trigger the Helm Operator which then synchronizes the changes in the chart code. Not to mention, Flux comes with detailed drift detection functionality among other interesting features to enable declarative infrastructure management.

For a long time, configuration management was just about hardware and infrastructure, but we have come a long way since then. With the introduction of GitOps and tools facilitating it, developers and platform engineers have abundant choices to design infrastructure configurations as they please - in a declarative way.

Weave GitOps leverages Flux and Helm and empowers an effective configuration management workflow from Git repositories all the way to production Kubernetes clusters. One feature distinguishing Weave GitOps is the ability for trusted application delivery. Trusted application delivery adds policy as code to GitOps, enforcing security and compliance, application resilience and coding standards from source to production. It is a combination of secure GitOps pipelines and continuous security checks through codified policies, enforcing security best practices and higher security standards across the software development lifecycle. GitOps is the way to do configuration management for modern cloud-native systems and Weave GitOps makes this approach not only simple but also secure. Learn more about how Weave GitOps shifts security left.


Related posts

The 16-point Checklist for GitOps Success

Liquid Metal is Here: Supported, Multi-Cluster Kubernetes on micro-VMs and Bare Metal

Level up Security Management with HashiCorp Vault and Flux

eBook: GitOps for Absolute Beginners