While CI/CD has become synonymous with application deployments, end-to-end CI/CD for infrastructure is fragmented and challenging for many enterprises.
The pace of adopting a DevOps culture within the developer community seems more agile than within infrastructure operations, as developers reap immediate benefits, with unit testing and containerization significantly reducing bugs and time to market. Standards and patterns to reskill developers to fit their SDLC into the CI/CD model has been well established over the years, with a plethora of tools and training on the market.
But when it comes to full-stack infrastructure deployments, there is a lack of parity with application deployments and automation, due to the lack of robust APIs for network components, the usage of legacy hardware or the lack of DevOps skills across infrastructure teams. But this is evolving. Modern infrastructure built declaratively on platforms like Kubernetes, OpenShift, etc., and idempotent cloud management tools like HashiCorp’s Terraform, are making continuous integration and deployment on infrastructure a reality, and GitOps is an operating model to enable it.
CIOps vs. GitOps
In traditional CIOps, at the end of the CI process, an operator or CI pipeline deploys the target infrastructure before the application pipelines, with varying levels of maturity in terms of the automation of traceability, configuration, and secret management, least privilege access, etc.
Whereas the GitOps model’s emphasis on “Everything as Code” ensures Git is the “single source of truth” for both infrastructure configurations and application code, enabling a complete audit trail of system changes.
Operationalizing GitOps Patterns
GitOps powered pipelines mandate that any change to the desired state of infrastructure is done through a pull request. The pull request explains the collection of changes to the desired state of infrastructure. Once sent, interested parties can review and approve the changes for automated deployments across target environments.
GitOps Pattern for Infrastructure Deployments
Figure 1 explains a GitOps pattern to deploy cloud infrastructure using Terraform. It all starts with an operator pushing a feature branch to the config repo. CI pipelines trigger a Terraform plan and create a pull request for the approver, with the Terraform plan attached to the pull request description. On approval, the latest code gets deployed and merged with the master, with corresponding build tags.
GitOps Pattern for Kubernetes Deployments
GitOps patterns are nothing new in the world of Kubernetes. Products like Weaveworks Weave Flux, Jenkins X and Argo CD, are mature enough to automatically synchronize the state of a Kubernetes cluster to match the config in a Git Repo. This sync operator lives inside the cluster and triggers deployments if it detects new images in the config files, to ensure every change is atomic and auditable.
Conclusion
As enterprises are making significant strides towards establishing DevOps culture with the shift-left approach, there is no doubt the GitOps operating model has the potential to streamline infrastructure deployments and empower the operators and DevOps engineers to focus more on configuration and code, rather than on managing deployments.
