A GitOps deployment with Flux on DigitalOcean Kubernetes – The new stack

GitOps is gaining ground as the preferred mechanism for continuous deployment. Based on the demo I presented at the DigitalOcean Deploy Conference in November 2021, I bring you the GitOps step-by-step tutorial for performing large-scale deployments.

We will manage the deployment of a simple web application on three different DigitalOcean Kubernetes clusters operating in the Bangalore, Singapore and London regions. The most popular CD tool, the Open Source Stream managed by Weaveworks, will be used to bootstrap GitOps, configure the Ingress infrastructure and finally deploy the application.

We’ll be following some of GitOps best practices for this tutorial, such as using git as a single source of truth, using the git workflow to deploy infrastructure and applications.

With the exception of bootstrapping, we will always use the git command and not rely on CLI (fluxctl and kubectl) for configuration. We will gradually add an input component (infrastructure) as a Helm graph and a web application (applications) declared in a set of YAML files to the repository, which will ultimately be reconciled across all clusters.

Whether it’s a cluster or tens of thousands of clusters, the workflow remains the same. The objective of this tutorial is to show a large-scale deployment targeting multiple Kubernetes clusters.

Preconditions

Step 1: Prepare the environment

Let’s start by launching Kubernetes clusters with doctl CLI. By the end of this step, we should have three clusters operating in three different regions of the Digital Ocean cloud platform. Once the clusters are provisioned, we will download kubeconfig and rename the context.

Next, create a GitHub repository that will be used to store the artifacts. Let’s call it do-gitops-demo.

Assuming you’ve created a GitHub personal access token, set the environment variable for Flux to access the repository.

export GITHUB_TOKEN=YOUR_GITHUB_PERSONAL_ACCESS_TOKEN

Step 2: Seeding the Clusters for GitOps

Let’s make sure the cluster is ready for Flux. We will do this by running the command, flux check.

Let’s bootstrap the clusters by pointing them to the GitHub repository created in the previous step.

This results in two things – Flow adding manifests to fleet repo directory and reconcile the cluster with the manifests.

The directory structure looks like this:

You can check the flux-system namespace on each cluster. This confirms the success of the bootstrap.

We are now ready to configure the infrastructure components (Ingress) and deploy them through the same workflow.

Step 3: Deploy Ingress via GitOps

With the GitOps Flux agent running in all clusters, we can leverage it to push new deployments by committing artifacts in the Git repository.

In this step, let’s create a namespace ingress-system and install the NGINX Entry Helm Chart. Let’s take advantage of the helmrepositories and helmreleases CRDs added by Flux.

Start by cloning the Git repository on your local workstation.

git clone https://github.com/$OWNER/do-gitops-demo.git.

At this point, this repository contains the YAML artifacts responsible for deploying the Flux operator. We will add a new directory, infrastructure and validate YAML files with Helm Chart for NGNIX based input.

cd do-gitops-demo
mkdir infrastructure

Let’s add the YAML files to the directory.

These three files result in approximately the same sequence of commands executed to install the NGINX entry:

kubectl create ns ingress-system

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install --namespace ingress-system
nginx-ingress ingress-nginx/ingress-nginx

Finally, we need to add a Kustomization to the cluster directory under fleet which will serve as a pointer to the components of the infrastructure. From the directory, fleet is registered with Flux agent during boot, this is the best location to add the YAML file below.

For example, to target the Bangalore cluster, copy the file below to fleet/blr1 phone book. This approach gives us the ability to customize the artifact by cluster at a later stage.

Add the file to all clusters to make sure they deploy the entry.

Note the addition of infrastructure.yaml in each directory specific to a cluster and the infrastructure directory with YAML artifacts.

It’s time to validate the new artifacts and push them to the remote GitHub repository.

git add .
git commit -m "Added infrastructure components"
git push

As soon as the modifications are validated, the Flux agent starts the reconciliation process. In a few minutes, you should see all the clusters creating the ingress-system namespace.

Because creating an entry will provision a load balancer, the Digital Ocean cloud console indicates that there are three load balancers created per cluster.

This step showed how to deploy a Helm charter via the GitOps workflow. Let’s move on to the next step where we will deploy the web application that leverages the entry created in this step.

Step 4: Deploying a Web Application Using GitOps

For the web application, let’s follow the same steps to add the manifests to the file apps directory, then adding a kustomization file to the fleet phone book.

cd do-gitops-demo
mkdir apps

Inside of apps directory, create the YAML files below:

Finally add the kustomization file below to all clusters under the fleet phone book.

With in addition to apps, notice how the directory structure has changed.

git add .
git commit -m "Added web application"
git push

In a few minutes you will see the mywebapp namespace with the web application.

Access it by visiting the IP address of the load balancer to see the web page below:

Modify the do-gitops-demo/apps/web.yaml to update the image tag from v1 to v2.

Validate the code and upload it to the remote GitHub repository. Go to the load balancer IP address again to see the V2 version of the web application.

If you roll back the last commit, you can roll back the deployment to V1. That’s the beauty of using GitOps.

This completes the step-by-step guide to using FluxCD with DigitalOcean Kubernetes. In the next few tutorials, we’ll explore how to use kustomization to customize the deployment for each cluster. Stay tuned.