GlooOps: Progressive delivery, the GitOps way
Often times, growing teams and companies find themselves at a point where their CI/CD pipeline becomes more of a hindrance than a convenience to their application delivery. Deployments break and it’s not clear which code changes were responsible, config changes are hard to track, and getting back to a previous working state often means bootstrapping another cluster. On top of this, managing their applications’ progressive delivery in this non-declarative environment becomes a nightmare. Gloo Edge API gateway, in conjunction with Fluxcd and Flagger, aims to minimize developer pain and increase team velocity by simplifying progressive delivery through GitOps. Though we aren’t serious about the term “GlooOps” (who needs another Ops anyways?), we seriously believe that Gloo Edge and GitOps can increase developer velocity and bolster your application delivery pipeline.
Above: an illustration of GitOps from the Weaveworks blog
GitOps is a continuous delivery paradigm coined by Weaveworks. Designed around Kubernetes, it allows developers to use a familiar tool, namely Git, for cluster management and application delivery. GitOps upholds the principle that Git is the primary source of truth for a system, so the git version history becomes the entire audit trail of changes to that system. All changes to the system’s state are fully traceable commits with the associated information, like committer information and change timestamp. If a commit is made that breaks a cluster, the cluster can be rolled back to the desired state merely by reverting back to the previous working commit. Read more about GitOps and how to use your git repository as the source of truth for your system at https://fluxcd.io.
GitOps requires that the desired state of the whole system be described by a declarative specification. For example, the Kubernetes API server accepts a declaration as input, such as a YAML file, and will modify the cluster according to that declaration. So how would we describe a progressive delivery in such a declarative way? Weaveworks’ Flagger allows us to declaratively define a Canary Resource in Kubernetes, which in turn describes the progressive delivery for an application. You can follow the guide here to use Gloo Edge API gateway to perform and automate canary releases and A/B testing on an application. With Gloo Edge and Flagger, the entire rollout process can be described declaratively, allowing for all the benefits of GitOps in what was a previously manual process.
Above: Flagger orchestrating a canary release in conjunction with Gloo Edge API gateway
Mission Lane, a credit card company dedicated to helping everyone have access to fair and clear credit, adopted Gloo Edge API gateway in their GitOps operations. According to Ronak Patel, senior manager, cloud platforms at Mission Lane, using GitOps to seamlessly apply application changes to dev and production Kubernetes clusters empowers developers to build new services. For this reason, Mission Lane and many other companies looking to improve their developer experience and increase team velocity have chosen Flagger and Gloo Edge to GitOps-ify their application delivery.
If you want to bolster your application delivery pipeline and increase developer velocity, get started with Gloo Edge and Flagger by following this guide to create a simple Canary release for your application.