CI/CD / Cloud Native

The Tools You Need to Run GitOps-Based Automated Deployments

9 Sep 2019 11:54am, by

GitOps is a profound new way of looking at the operation process. GitOps focuses on making use of a version control system (such as Git) to house all information, documentation, and code for a Kubernetes deployment, setting the stage for automated deployment and even programmable infrastructure.

It’s an incredibly complex system with benefits on a level many businesses have never before experienced. Key benefits for GitOps include:

  • Increased productivity with continuous deployment automation.
  • Enhanced developer experience by pushing code and not containers.
  • Improved stability, thanks to an automated audit log of all cluster changes.
  • Higher reliability from Git’s built-in revert/rollback and fork and from a single source of truth.
  • Consistency and standardization of end-to-end workflows.
  • Stronger security, due to Git’s strong correctness and the cryptography used to track and manage changes.
  • Cost effectiveness from lower downtimes and vastly improved productivity.

If you’re sold on the idea of GitOps, your next question will be what are the tools required to make GitOps actually happen? It should come as no surprise that there are a number of tools that comprise the GitOps process.

Let’s take a look at some of the necessary pieces of software which can be used for GitOps, and what each tool does.

Kubernetes

Clearly, you cannot have GitOps without the tool at the heart of the process. Kubernetes is probably one of the most impactful systems to have arrived in the world of business IT in years. Without a Kubernetes cluster up and running, you cannot implement GitOps. For those that aren’t aware of Kubernetes, by definition, it is an open-source system for automating deployment, scaling, and management of containerized applications. Everything GitOps starts and ends with Kubernetes.

Docker

Kubernetes cannot function without the help of Docker. In fact, in order to install Kubernetes on your server, you must first install Docker. For those that have never used or been introduced to Docker, this tool serves as a set of platform-as-a-service products to deliver software in packages called containers.

Git

Git stands right behind Kubernetes as one of the most important tools for GitOps. After all, you cannot spell GitOps without git. Git stands as the central hub for GitOps. It is within Git that all of your documentation, configurations, and code necessary to deploy and maintain your cluster lives. But Git doesn’t only serve as a repository for instructions and code, used by humans to make the Kubernetes cluster function. Instead, there are automators which function with Git to make everything seamless and automatic. Configurations are read from Git and, if changes are found, the cluster is updated as dictated by the changes.

Helm

Helm is the official tool for managing Kubernetes charts, which are packages of pre-configured Kubernetes resources. With Helm, installing and managing Kubernetes packages is greatly streamlined. Helm can be used to find and use popular software (packaged as Helm charts), share your custom applications, create reproducible builds, intelligently manage your Kubernetes manifest files, and manage releases of Helm packages. In a sense, Helm is like the apt, yum, or homebrew for Kubernetes.

Flagger

Flagger is a progressive delivery operator which automates the promotion of canary deployments (a pattern for rolling out releases to a subset of users or servers). Flagger uses Istio, Linkerd, App Mesh, NGINX or Gloo routing for both traffic shaping and Prometheus metrics (for canary analysis). Flagger measures key performance indicators (such as the success rate of HTTP requests) while implementing a control loop to gradually shift traffic to the canary deployment. With regards to GitOps, Flagger is in charge of ensuring that any change made in the Git repository is viable for the cluster.

Prometheus

And speaking of Prometheus… here we have an open source monitoring solution that is the heart of the GitOps alerting system. With Prometheus, admins are alerted, in real-time, if a change (discovered by Flagger) isn’t viable. The addition of Prometheus also allows other automators (within the GitOps flow) to keep the alert system apprised if something has changed within the system.

Terraform

HashiCorp’s Terraform is an open source tool that allows you to provision any infrastructure with a consistent workflow. Terraform enables the provisioning of infrastructure through the use of a wide ecosystem of plugins. With regards to GitOps, you write a terraform file in Git to provision a Kubernetes cluster. Terraform also enables you to safely and predictably write, plan, and provision infrastructure as code. It’s that predictability which is key for GitOps.

Flux

Flux is a key component within the realm of GitOps. Flux is the central operator that makes GitOps possible within your Kubernetes cluster. With Flux in place, your cluster configuration will always match that of the configurations found in your Git repository. Flux also enables the continuous delivery of container images to the cluster. With the help of version control Flux can ensure deployment is:

  • Reproducible
  • Predictable
  • Auditable
  • Revertible

So long as Flux is in place, your team can be confident any change made to the cluster can easily be reverted.

Jenkins X

Jenkins X is an open source automation server, managed by CloudBees, that facilitates continuous integration and delivery for your Kubernetes cluster. Jenkins X automates the management of environments and the promotion of new versions between environments. Within the realm of GitOps, Jenkins X is used for rapid creation of clusters, quickstarts in many programming languages to deploy greenfield applications, importing existing brownfield applications, automated setup of containerized application deployment, automated promotions, and automated rollbacks.

Quay

The Red Hat-managed Quay is an image registry that allows you to easily manage your container images, with a high level of security and reliability. Instead of depending on the likes of GitHub, you’ll want your GitOps workflow to use an on-premises image registry. For that, your best bet is Quay.

And those are just some of the pieces that come together to form the GitOps puzzle.

CloudBees, HashiCorp and Red Hat are sponsors of The New Stack.

Feature image by analogicus from Pixabay.

A newsletter digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.