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.
To follow along with the hands-on section of this blog post, you'll need:
Kubernetes made a few things easier, including:
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.
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:
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.
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:
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.
#!/bin/bash -e
flux bootstrap github \
--owner=$GITHUB_USER \
--repository=fleet-gitops \
--branch=$BRANCH \
--path=./clusters/minikube \
--namespace=$namespace \
--personal
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: