The Flux Factor: GitOps for Continuous Delivery
KubeCon + CloudNativeCon sponsored this post.
GitOps is often synonymized with continuous delivery for Kubernetes. More broadly, GitOps takes the best practices of DevOps — collaboration and breaking down silos, version control, automated testing and compliance, and, of course, continuous integration — which is usually applied at the application layer, and it extends them down to the infrastructure layer. GitOps, in which code changes are pushed automatically from a git repository, is meant to translate the speed and scalability of agile development for operational workflows and is most often done with abstraction at the Kubernetes layer.
In this episode of The New Stack Makers podcast, we talk to three members of the Weaveworks team: Alexis Richardson, founder and CEO, Cornelia Davis, chief technology officer, and Stefan Prodan, developer experience engineer and the architect of Flux and Flagger. They reflect on the next generation tooling in the cloud native tech community. The quartet also discusses how that tooling fits into the GitOps toolkit and, particularly, the next evolution of the Flux continuous delivery for GitOps projects. Alex Williams, founder and publisher of The New Stack, hosted this episode.
The Flux Factor: GitOps for Continuous Delivery
Flux allows for updates to be automatically deployed in the environment, without external scripts or tooling. The benefit, like most things with Kubernetes, is getting the benefit of Kubernetes without developers having to actually interact with it directly. As Container Solutions’ Steve Landry Tene wrote: “Flux connects to your Git repository and watches for all changes on a specific branch and folder. When a commit occurs, Flux will operate on the cluster in order to deploy those changes.”
Davis puts Flux as a signal of the move away from CI/CD focusing almost exclusively on the integration side, where code delivery was just something happening at the end.
“Continuous delivery is something that happens in a reconciliation loop,” she said. “It’s constantly changing and is constantly in need of reconciliation.”
GitOps then extends that delivery process even further into ongoing operations, explained Davis.
“It’s delivery and then what’s actually happening in my cluster from a runtime perspective, and how does that relate back to continuous delivery,” said Davis. “So they’re kind of dancing next to each other and then in concert together.”
Prodan builds on that, describing how it’s about extending security, too, beyond just role-based access control and into the entire change management system, both on the git side and within the cluster. As the second version of Flux begins to roll out, they are adding a third security layer by enabling multi-tenancy inside the cluster where different repositories have different access rights. In addition, they are allowing reconciliation from multiple repositories.
“What Flux is doing is looking at git instead of etcd and synchronizes git with etcd. Then the native Kubernetes controllers take over and do their own thing. So, Flux, in a way, is like an operator on top of all of those built-in or other operators as well,” Prodan explained.
Overall, Flux 2.0 looks to create a sort of GitOps toolkit that allows teams to customize their own Kubernetes workflows.
Richardson pegs this as an obvious next step in the democratization of IT — even in huge corporations.
“What we found that customers are asking for the most is ‘I’ve got my CI in place. What’s the easiest way to add CD to that?’ And what we’re showing them is the easiest way is actually to use this really cool reconciliation concept that GitOps enables,” Richardson said of the popularity of Flux for continuous deployment.
Davis describes the next steps will not be about disrupting the continuous integration that’s been working well for a while now, but rather the next step in GitOps is making sure to modernize the continuous delivery side. The end result? Pure platform team empowerment.
