GitOps is slowly becoming mainstream in the cloud native space. I talked a lot about GitOps in my previous videos. However, I always used ArgoCD as an example.
In this blog post, I am
- Going to show you how to get started with Flux
- Install the Starboard Helm Chart through GitOps best practices
- Manage an application through Flux
- Setup notification and monitoring with Flux
If you prefer the video tutorial, you can find it here:
What are GitOps & Flux
First of all, we need to set the scene. GitOps has been around for some time now and the process itself is not necessarily new. However, what is new are the tools that can be used to manage your GitOps workflow; namely ArgoCD and FluxCD.
I wrote about ArgoCD before, if you are curious, have a look at my previous video:
Using any cloud native tool, just for the sake of using it is highly counterproductive since cloud native applications need lots of babysitting. You cannot just deploy and then forget about them. So why would you want to get started with GitOps and Flux in the first place?
There are two main scenarios in which I see it as very useful to adopt GitOps best practices:
In a large team
If you are working in a large team, you do not want to give every user access to your Kubernetes resources and manage deployments. What you can do instead is to link a GitOps tool such as Flux or ArgoCD to one of your repositories — whenever a change in your Kubernetes manifests occurs or the specified branch, the GitOps tools will be responsible for pushing the update to your Kubernetes cluster.
As an individual or collaborating with a few people
A lot of times, using specific cloud native tools to manage deployments is considered overkill. However, if you have a highly dynamic application that you would like to manage long-term, it is extremely useful to have the update process managed automatically — as can be done through ArgoCD or Flux. This will provide you with higher insights into your deployments.
If you would like to learn more about the nitty-gritty details of Flux, GitOps and the reconciliation process, I highly suggest you check out the Flux documentation.
PS. The documentation is in its explanations really comprehensive with user flow diagrams. For instance, the following diagram outlines how flux fetches updates from Git.
Getting started with Flux
Flux is an incubating project of the CNCF. In this section, I show you how to get started with Flux.
First, we are going to install Flux
brew install fluxcd/tap/flux
For other installation methods, please check out the Flux documentation.
Next, we want to add the flux bash-completion to our terminal profile:
. <(flux completion bash)
Make sure to have your Git credentials:
export GITHUB_TOKEN=<your-token>
export GITHUB_USER=<your-username>
You can find the token within the following path https://github.com/settings/tokens
Next, ensure that you have access to your Kubernetes cluster through the CLI. I usually just check whether I have access to nodes:
kubectl get nodes
Then, check your cluster is compatible and ready for Flux:
flux check --pre
Next, we want to install Flux into our Kubernetes cluster, this is done with the Flux bootstrap command:
flux bootstrap github \\
--owner=$GITHUB_USER \\
--repository=flux-example \\
--branch=main \\
--path=./clusters/my-cluster \\
--personal
This will create a namespace inside of your Kubernetes cluster where all the Flux resources are going to be installed. Additionally, a Git repository will be created in your linked account.
The Flux toolkit
“Flux is constructed with the GitOps Toolkit components, which is a set of
- specialized tools and Flux Controllers
- composable APIs
- reusable Go packages for GitOps under the fluxcd GitHub organisation
for building Continuous Delivery on top of Kubernetes.” (Source: Taken from the Flux docs)
Below is a diagram that highlights how it all works together:
Installing the Starboard Helm Chart through Flux
Quick comment: 1 thing I really like about the Flux documentation is that it will show you the known way of doing things — for instance, if you want to deploy a Helm Chart, you will likely know how to deploy a Helm Chart without Flux. Thus, they show you that part first AND THEN they show you the new way for deploying the Helm Chart with Flux. This way, they build on your pre-existing schemas. Well done!
First, we need to create the namespace for Starboard
kubectl create ns starboard-system
Then we use the Flux client below, not the Helm client — the Helm client is just provided for reference in case you want to deploy a different Helm Chart.
Helm client:
helm install starboard-operator aqua/starboard-operator \\
--namespace starboard-system \\
--create-namespace \\
--set="trivy.ignoreUnfixed=true" \\
--version 0.10.3
Flux client:
flux create source helm starboard-operator --url <https://aquasecurity.github.io/helm-charts> --namespace starboard-system
flux create helmrelease starboard-operator --chart starboard-operator **\\**
--source HelmRepository/starboard-operator **\\**
--chart-version 0.10.3 **\\**
--namespace starboard-system
However, we can also install Starboard through Flux by deploying the following Kubernetes manifests:
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
name: starboard-operator
namespace: flux-system
spec:
interval: 1m0s
url: <https://aquasecurity.github.io/helm-charts/>
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: starboard-operator
namespace: starboard-system
spec:
chart:
spec:
chart: starboard-operator
sourceRef:
kind: HelmRepository
name: starboard-operator
namespace: flux-system
version: 0.10.3
interval: 1m0s
and then we can apply the manifests through kubectl:
kubectl apply -f helm-starboard.yaml
Next, we are going to deploy an Application through Flux that our Starboard Operator will monitor.
Create an Application through Flux
Similar to how we install applications through ArgoCD, we can ask Flux to manage our application. This can be done through several options, however, in this blog post, I am going to show you the imperative way and the declarative way.
The declarative way
The imperative way of telling Flux to install our resources is through their bootstrap command:
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
name: react-app
namespace: flux-system
spec:
interval: 1m
url: <https://github.com/AnaisUrlichs/react-article-display>
ref:
branch: main
ignore: |
# exclude all
/*
# include charts directory
!/manifests/
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
name: react-app
namespace: flux-system
spec:
interval: 5m0s
path: ./manifests
prune: true
sourceRef:
kind: GitRepository
name: react-app
targetNamespace: app
This YAML manifest can then be deployed like any other Kubernetes resource:
kubectl apply -f ./application.yaml
The imperative Way
In the imperative way, we are first going to set up the repository for Flux:
flux create source git react \\
--url=https://github.com/AnaisUrlichs/react-article-display \\
--branch=main
and then we are going to deploy the application by telling Flux the path to our Kubernetes manifests inside of the repository and how we want Flux to manage the repository:
flux create kustomization react-app \\
--target-namespace=app \\
--source=react \\
--path="./manifests" \\
--prune=true \\
--interval=5m \\
Once set up, Starboard is already busy scanning not only our application but also our Flux-related resources for vulnerabilities:
I think Flux is doing pretty well, with only one High vulnerability. This gives me higher confidence in using Flux.
For comparison, here are the scans of ArgoCD from Starboard:
Now, this might not say a lot about the application itself but for security newbies like me, it is a good starting point.
Setup an alert with Flux
In this part, we want to set up alerts on our deployments to Slack:
First, we will have to create a secret with our Slack webhook:
kubectl -n flux-system create secret generic slack-url \\
--from-literal=address=https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK
You can find the Slack Webhook in the API settings of your Slack Channel.
Then, we are going to set up our notification provider:
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
name: slack
namespace: flux-system
spec:
type: slack
channel: general
secretRef:
name: slack-url
and apply it to our Kubernetes cluster:
kubectl apply -f notification-provider.yaml
And then deploy the Alert. First, save the following content to a separate file:
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Alert
metadata:
generation: 2
name: helm-info
namespace: flux-system
spec:
providerRef:
name: slack
eventSeverity: info
eventSources:
- kind: HelmRepository
name: podinfo
- kind: HelmChart
name: default-podinfo
- kind: HelmRelease
name: podinfo
namespace: default
Once committed to Git, we can tell Flux about it through the following command:
kubectl apply -f alert.yaml
Now, we are going to make a change to our linked application repository and see whether Flux is detecting the change and making the updates accordingly & also, whether Flux will notify us about the change.
OMG it works, it just updated my container image without me touching anything:
Here is the updated policy in my Kustomization resource:
Here is the events list from the reconciliation:
The vulnerability reports for my App — i.e. for the old and the new container image:
Here are the new pods:
AND here is the Slack notification:
This is amazing!!
Monitoring Flux through Prometheus and Grafana
The Flux documentation provides a really easy to-follow-guide on setting up Prometheus (specifically, the kube-prometheus-stack Helm Chart that I also used in previous videos) and Grafana.
⭐Would I keep using Flux?⭐
So what is my opinion about Flux after playing around with it for 1.5 days (bear that in mind, I am quite a noob to Flux so I am still learning about its design and the differences to similar tools).
Community ⭐⭐⭐⭐⭐
I had some problems installing the Helm chart and the community was super responsive which made a huge difference and without them, I might not have finished this blog post.
Design ⭐⭐⭐⭐⭐
So here is the way that I see it: Other projects try to move fast, implement lots and lots of features; just to then realise that they have created gaps in their product which they then try to patch. Flux seems to have followed a different approach by placing lots of focus on its design.
Ease of installation ⭐⭐⭐
I got super confused why their Kustomization resource is called similar to Kustomize. I strongly dislike using Kustomize. Also, I had problems understanding the setup process at the beginning.
Documentation ⭐⭐⭐⭐
The docs offers lots and lots of reference resources, which help you get started with GitOps and Flux. However, the guides and getting-started guide is written from the point of view of an Engineer — some additional clarification on the process and highlighting the smaller steps in between would be highly useful.
What is next?
I highly suggest you try out Flux and Starboard.
Give both of them a Star on GitHub ⭐
Also, please do let me know what kind of content you would like to see in the future.
AND if you liked this blog post, please make sure to share it across your social media, it would mean a lot to me!!