Key Learnings from GitOps Days EMEA

[weaveworks]

After an overwhelming response to our inaugural GitOps Days event in May 2020, we hosted a follow-up GitOps Days EMEA last month. We had a great line up of speakers with fresh and interesting perspectives on the application, implementation, and security of GitOps along with some technical deep dives. You can view the entire playlist here. This is the first in a series of blog posts covering various topics that were discussed during GitOps Days EMEA.

Before we get started, what is GitOps?

GitOps is a standard operating model for managing clusters and delivering applications. It can be summarized as these two things:

1. An operating model for Kubernetes and other cloud native technologies, providing a set of best practices that unify deployment, management and monitoring for containerized clusters and applications.
2. A path towards a developer experience for managing applications; where end-to-end CICD pipelines and Git workflows are applied to both operations, and development.

For more on GitOps, check out the GitOps manifesto, our Guide to GitOps, or the Official GitOps FAQ.

Helm + GitOps

In this first blog post, we’re going to focus on Helm - the Kubernetes package manager. Check out our exciting playlist of the Helm talks from Helm maintainer, and Weaveworks' DX engineer, Scott Rigby (@r6by), and friends!

The Business Value of Helm + the Business Value of GitOps =

Scott Rigby covered the business value of Helm and how that value is made more robust with a GitOps approach. Scott explains the value of implementing Helm, which includes team velocity, decreased downtime, and improved reliability. Below we cover ways that GitOps makes Helm more robust.

Reconciliation

The first value point of running Helm specifically with GitOps is reconciliation. When things fail or errors happen, Kubernetes attempts to retry your desired Helm configuration. There’s a constant attempt to ensure that the Helm release you have configured deploys in the way that you want it to (by storing those values in Git). Even with this type of automation, your engineers still have control. By using Flux, the manual work and human error is reduced. You can pause reconciliation to ensure correctness or put in manual gates and then resume it.

Reliability and consistency

Helm is a client that allows you to run imperative commands and tell Helm what you want it to do. By adding GitOps capabilities with tools such as Flux, you declare what you want your Helm release to look like. If something goes awry, you don’t have to figure out what went wrong. You let Kubernetes do it for you. You’ve declared how you want your release to look and how all those resources should look for you.

Flux also adds retries, so if a rollback doesn’t work initially you can configure what your retries should look like. You have an infinite or specified number of retries, and you can specify a wait time between retries. This is extremely helpful because there are cases where a retry won’t work because your application is dependent on something else outside of your release (for example, an image to be present).

Another major point for reliability is that teams can debug in a way that is a lot more convenient for them than a standard Helm release. In a non-production environment your team may want to add an option to keep the last failed release in order to figure out what happened.

Observable

Ultimately telemetry is important. The ability to see all of what’s happening all in one place, is one of the really nice things that Flux specifically adds to Helm releases. Flux attaches logging and errors to your Kubernetes resources. It’s built in so that you don’t have to send this from some other system into a common observability reporting engine. Flux supports Prometheus out of the box and can integrate with other telemetry export tools. Your team has access to what’s happened by getting feedback straight into their terminal. 

Auditable

All of your changes to your Helm releases and all of your configurations are controlled through pull requests and version control. You can look through the Git history to understand exactly what happened. You can also revert back to your last “good” commit. The notification controller in Flux integrates with various communication tools for your team such as Slack!

More to come!

Stay tuned for more in this series on how GitOps approaches can bring reliability, consistency, observability, security and more to your app delivery and operations!

Helm v2 deprecated

For a more in-depth look at why Helm v2 is being deprecated, please check out the other two videos in this playlist:

• Fidelity Helm 2 Deprecation and What it means for you
• Deep dive for Helm users: What Flux v2 can do for you!

View the full article