CloudTruth and Flux (GitOps)

Throughout the engineering trends of containerization, orchestration, and configuration data for both app developers and platform engineers, there's a newish movement for organizations - GitOps.

Although GitOps is great by itself, there are still a ton of parameters, variables, secrets, and other options that are needed when utilizing the methodology.

In this blog post, you'll learn about what GitOps is, how it works well with CloudTruth, and how to get started in any environment right now.

Prerequisites

To follow along with the hands-on section of this blog post, you'll need:

• A CloudTruth account. If you don't have one, you can sign up for free here.
• A CloudTruth project. If you don't have one, you can learn how to create a Project here.
• A Kustomize configuration. If you don't have one, you can use a sample which you can find here.
• A GitHub account, which you can sign up for free.
• A Kubernetes cluster. This can be anything from Minikube to a cluster running in the cloud.
• The CloudTruth CLI. If you don't already have it installed, you can install it here.

Why GitOps

Kubernetes made a few things easier, including:

• Autoscaling without having to worry about multiple dedicated servers.
• Self-healing.
• Managing containers at scale.

Essentially, you can now manage your infrastructure with an API. Instead of logging into a UI or using a CLI, you can go straight to the SDK. Whether you want to use YAML, which is the standard Kubernetes approach to deploying containerized apps, or even use an SDK. Any method that's available to interact with an API, you can use for Kubernetes.

The problem is that now there are a ton of configuration files to deploy. Using kubectl apply -f on the terminal doesn't seem like a huge deal when you have one or two Manifests, but what about ten? Or twenty? And each of those have to get deployed daily or weekly? It can begin to get cumbersome.

GitOps comes into play by using a Git-based repo as the source of truth. Then, it uses that source of truth to deploy Kubernetes Manifests. For example, let's say you have a Kubernetes Manifest that makes up a frontend web app. It contains the container image, the tag, ports to use, volumes if needed, etc… If the Manifest exists in, for example, GitHub, the GitOps tool you're using will look at the repo where the Kubernetes Manifest exists and deploy it automatically. If any changes occur, it'll deploy those changes as well.

GitOps is configuration management with a Git-based repository as the source of truth.

Why CloudTruth and GitOps

When you're setting up a GitOps tool/controller, for example, Flux, there's a lot of configuration data that you have to pass in.

The list includes:

• Authentication to your Git org/repo.
• The repository you want to target for deployments.
• The branch you want to target for deployments.
• The namespace you want containerized apps to be deployed to in your Kubernetes cluster.
• The repository where your GitOps config lives.
• The interval in which you want the GitOps controller to check into the repo to see if there were any changes to the Kubernetes Manifest(s).

and a few other pieces of configuration data.

With all of the values that you have to pass in, you need a central location that you can use to store all of those values, update them easily when needed, and ensure that they're stored safely.

That solution is CloudTruth.

Getting Started With CloudTruth and GitOps

Now that you've learned about GitOps and why you'd want to use CloudTruth with GitOps, let's dive into a hands-on example.

First, you'll need to have some parameters to pass into the Flux configuration. The parameters include:

• The branch name that you want to target for the repo that contains the Kuztomize configuration that you want to deploy.
• The name of your Kubernetes cluster.
• A GitHub Personal Access Token (PAT) which authenticates Flux to your GitHub org.
• A GitHub username that has access to your GitHub org.
• The namespace that you want Flux to be deployed to.
• A repo name that you want the Flux configuration to be deployed to.
• The URL that points to where the Kustomize configuration exists.

An example of how the parameter names and values should look is below.

Next, you'll need to install the Flux CLI. There are a few different options, so you can take a look at the link here to download it.

Once the CloudTruth Project and Parameters are configured, along with the Flux CLI installation, it's time to start configuring Flux.

First, run the Flux precheck against your Kubernetes cluster to confirm the cluster has the proper prerequisites.

flux check --pre

Create a new file and name it git.sh. Add in the following code to git.sh. The code below contains the bootstrap configuration, which connects Flux to GitHub.

Run the script using the CloudTruth CLI.

cloudtruth --project flux run -- ./git.sh

You should see an output similar to the below.

► applying source secret "fluxnamespace/flux-system"
✔ reconciled source secret
► generating sync manifests
✔ generated sync manifests
✔ committed sync manifests to "main" ("a5a833e6c72d50b88ba63b144a1dda9986dc2491")
► pushing sync manifests to "https://github.com/adminturneddevops/fleet-gitops.git"
► applying sync manifests
✔ reconciled sync configuration
◎ waiting for Kustomization "fluxnamespace/fluxnamespace" to be reconciled
✔ Kustomization reconciled successfully
► confirming components are healthy
✔ helm-controller: deployment ready
✔ kustomize-controller: deployment ready
✔ notification-controller: deployment ready
✔ source-controller: deployment ready
✔ all components are healthy

Log into your GitHub account and you should see a new repo with whichever name you chose for the Flux repo when specifying the CloudTruth parameters. Clone the repository down to your localhost and change the directory (cd) into the repo on the terminal. All of the configurations moving forward must be done from the Flux repository.

Create a new file called flux.sh. Add in the following configuration, which creates a Bash script to create the Flux source. The source tells Flux what repository to look in for the Kubernetes Manifests that you want to deploy to a Kubernetes cluster.

#!/bin/bash -e
flux create source git nginxdeployment \
--url=$URL \
--branch=$BRANCH \
--interval=30s \
--namespace=$namespace \
--export > ./clusters/minikube/nginxdeployment-source.yaml

Run the script using the CloudTruth CLI.

cloudtruth --project flux run -- ./flux.sh

In the directory that contains the Kubernetes cluster in the Flux repo, you should see a new file called nginxdeployment-source.yaml which contains output similar to the following:

apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
name: nginxdeployment
namespace: fluxnamespace
spec:
interval: 30s
ref:
branch: main
url: https://github.com/adminturneddevops/DevRel-As-A-Service

The GitRepository resource in a resource that's created with the Flux CRD to perform the interval check-ins based on the source of where your Kubernetes Manifests exist.

The last step is to push the configuration to GitHub.

git add -A && git commit -m "Add nginxdeployment GitRepository"
git push

You can now set up your deployment to deploy your app with Flux.

Congrats! You have successfully used CloudTruth and GitOps together for easier, more efficient deployments.

Here's a screencast overview: