Our implementation team already uses GitHub on a daily basis to track work and deploy code to our project repositories, and as a result, our Cluster Ops team has adopted the GitOps philosophy. This includes having a centralized place for all of our configuration and the ability to view all deployments in a friendly, comfortable environment that makes Kubernetes more accessible to the rest of the team.
In order to get Kubernetes into a GitOps flow, we use the following tools:
Let’s break it all down.
First, What is GitOps?
GitOps is the concept of using Git as the primary source of truth for your system operations configuration. Git does a lot of cool stuff that most developers will already be familiar with. By default, it gives us audit logs. This allows us to see what changed, when and by whom. Also, since we use GitHub, we get the power of Pull Requests. This gives us an opportunity to peer review config changes before they are deployed into the clusters. GitHub also gives us protected branches and much more.
In addition to the features provided by Git and Github, the basic underlying file system also provides additional benefits. Because we use Kubernetes, all of our DevOps infrastructure configuration is written in yaml, and using the Linux filesystem via Git to organize it creates an experience more like managing traditional Linux configuration via the /etc folder. Users who aren’t as familiar with K8s and kubectl may find it easier to browse configuration via the filesystem.
Read more: Gitops tutorial.
What Do the GitOps Tools Do?
FluxCD
FluxCD allows us to have all of our Kubernetes resource configuration in a GitHub repo, which then syncs to the cluster at regular intervals, making the Git repo the primary source of truth for configuration. Flux is also a continuous deployment tool. We can configure our Kubernetes deployments in Flux so that they’re automatically updated to reflect new Docker image releases. In a Kubernetes deployment, a Docker image repository is referenced, so Kubernetes knows where to get containers from. Flux keeps a list of all versions of a deployment’s Docker images and deploys the latest version when detected.
FluxCD Helm Operator
Helm is a package manager used to find, share, and use software built for Kubernetes. Helm isn’t GitOps compatible out of the box, so we use FluxCD Helm Operator to bridge the gap. It provides a Kubernetes Custom Resource Definition (CRD) for installing Helm charts. Instead of using Helm CLI to install charts, we simply add a HelmRelease to the Flux repo and the Helm Operator handles the rest.
Bitnami Sealed Secrets
In Kubernetes, we use Secrets, as the name implies, to store secret configuration like database passwords. Unfortunately, Secrets don’t work super well with the GitOps ecosystem because the way we define them doesn’t respect the level of secrecy that we need. We end up having to put nearly plaintext passwords into GitHub, which is a major faux pas.
Bitnami’s Sealed Secrets plugin gives us a way to store Secrets with pre-encrypted data in GitHub, which are then decrypted by the Sealed Secrets service within the Cluster and converted into traditional Kubernetes Secrets. That way, we can still store secret configuration in GitHub alongside the rest of our configuration, without sacrificing security.
Closing Thoughts
So there you have it. These are the tools we use to get Kubernetes into a GitOps flow. Do you use any of these tools? Want more information on how to install and use these tools? We’d love to know. Talk to us on Twitter!
We're building an AI-powered Product Operations Cloud, leveraging AI in almost every aspect of the software delivery lifecycle. Want to test drive it with us? Join the ProdOps party at ProdOps.ai.