- Home
- >
- DevOps News
- >
- A GitOps Deployment with Flux on DigitalOcean Kubernetes – InApps 2022
A GitOps Deployment with Flux on DigitalOcean Kubernetes – InApps is an article under the topic Devops Many of you are most interested in today !! Today, let’s InApps.net learn A GitOps Deployment with Flux on DigitalOcean Kubernetes – InApps in today’s post !
Read more about A GitOps Deployment with Flux on DigitalOcean Kubernetes – InApps at Wikipedia
You can find content about A GitOps Deployment with Flux on DigitalOcean Kubernetes – InApps from the Wikipedia website
GitOps is gaining momentum as the preferred mechanism for continuous deployment. Based on the demo that I showed during the DigitalOcean Deploy Conference in November 2021, I am bringing you the step-by-step GitOps tutorial to perform deployments at scale.
We will manage the deployment of a simple web application across three different DigitalOcean Kubernetes clusters running in Bangalore, Singapore, and London regions. The Weaveworks-managed open source Flux, the most popular CD tool will be used to bootstrap GitOps, configure Ingress infrastructure, and finally deploy the application.
We will follow some of the best practices of GitOps for this tutorial such as leveraging git as the single source of truth, using git workflow to deploy infrastructure and applications.
Except for the bootstrapping, we will always use the git
command and not rely on the CLIs (fluxctl
and kubectl
) for the configuration. We will incrementally add an ingress component (infrastructure) packaged as a Helm Chart and a web application (apps) declared in a set of YAML files to the repo, which will be eventually reconciled across all the clusters.
Whether it is one cluster or tens of thousands of clusters, the workflow remains the same. The objective of this tutorial is to show at-scale deployment targeting multiple Kubernetes clusters.
Prerequisites
Step 1: Preparing the Environment
Let’s begin by launching the Kubernetes clusters with doctl
CLI. By the end of this step, we should have three clusters running 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 for storing the artifacts. Let’s call this do-gitops-demo
.
Assuming you have 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: Bootstrapping Clusters for GitOps
Let’s make sure that 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 — Flux adding the manifests to the fleet
directory of the repo and reconciling the cluster with the manifests.
The directory structure looks like this:
+— fleet │ +— blr1 │ │ +— flux–system │ │ │ +— gotk–components.yaml │ │ │ +— gotk–sync.yaml │ │ │ — kustomization.yaml │ +— lon1 │ │ +— flux–system │ │ │ +— gotk–components.yaml │ │ │ +— gotk–sync.yaml │ │ │ — kustomization.yaml │ — sgp1 │ +— flux–system │ │ +— gotk–components.yaml │ │ +— gotk–sync.yaml │ │ — kustomization.yaml |
You can verify the flux-system
namespace on each cluster. This confirms successful bootstrap.
We are now ready to configure the infrastructure components (Ingress) and deploy them through the same workflow.
Step 3: Deploying Ingress through GitOps
With the Flux GitOps agent running in all the clusters, we can leverage it to push newer deployments by committing the artifacts to the Git repository.
In this step, let’s create a namespace ingress-system
and install the NGINX ingress Helm Chart. Let’s leverage the helmrepositories
and helmreleases
CRDs added by Flux.
Start by cloning the Git repository to your local workstation.
git clone https://github.com/$OWNER/do-gitops-demo.git
.
At this point, this repo contains the YAML artifiacts responsible for deploying Flux operator. We will add a new directory, infrastructure
and commit the YAML files with Helm Chart for NGNIX-based ingress.
cd do-gitops-demo
mkdir infrastructure
Let’s add the YAML files to the directory.
These three files roughly translate to the same sequence of commands run to install NGINX ingress:
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 act as a pointer to the infrastructure components. Since the directory, fleet
is registered with the Flux agent during the bootstrapping, that’s the best location to add the below YAML file.
For example, to target the Bangalore cluster, copy the below file to fleet/blr1
directory. This approach gives us a chance to customize the artifact per cluster at a later stage.
Add the file to all the clusters to ensure that they deploy the ingress.
Notice the addition of infrastructure.yaml
in each cluster-specific directory and the infrastructure
directory with the YAML artifacts.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | +— fleet │ +— blr1 │ │ +— flux–system │ │ │ +— gotk–components.yaml │ │ │ +— gotk–sync.yaml │ │ │ — kustomization.yaml │ │ — infrastructure.yaml │ +— lon1 │ │ +— flux–system │ │ │ +— gotk–components.yaml │ │ │ +— gotk–sync.yaml │ │ │ — kustomization.yaml │ │ — infrastructure.yaml │ — sgp1 │ +— flux–system │ │ +— gotk–components.yaml │ │ +— gotk–sync.yaml │ │ — kustomization.yaml │ — infrastructure.yaml — infrastructure +— ingress–helm–release.yaml +— ingress–helm–repo.yaml — ingress–ns.yaml |
It’s time to commit the new artifacts and push them to the remote GitHub repository.
git add .
git commit -m "Added infrastructure components"
git push
The moment the changes are committed, Flux agent starts the reconciliation process. In a few minutes, you should see all the clusters create the ingress-system
namespace.
Since the creation of an ingress results in provisioning a load balancer, the Digital Ocean cloud console shows that there are three load balancers created per cluster.
This step demonstrated how to deploy a Helm chart through the GitOps workflow. Let’s move to the next step where we will deploy the web application that leverages the ingress created in this step.
Step 4: Deploying a Web App through GitOps
For the web application, let’s follow the same steps of adding the manifests to the apps
directory and then adding a Kustomization file to the fleet
directory.
cd do-gitops-demo
mkdir apps
Inside the apps
directory, create the below YAML files:
Finally, add the below Kustomization file to all the clusters under the fleet
directory.
With the addition of apps
, notice how the directory structure has changed.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | +— apps │ +— ns.yaml │ +— web–ingress.yaml │ +— web–service.yaml │ — web.yaml +— fleet │ +— blr1 │ │ +— apps.yaml │ │ +— flux–system │ │ │ +— gotk–components.yaml │ │ │ +— gotk–sync.yaml │ │ │ — kustomization.yaml │ │ — infrastructure.yaml │ +— lon1 │ │ +— apps.yaml │ │ +— flux–system │ │ │ +— gotk–components.yaml │ │ │ +— gotk–sync.yaml │ │ │ — kustomization.yaml │ │ — infrastructure.yaml │ — sgp1 │ +— apps.yaml │ +— flux–system │ │ +— gotk–components.yaml │ │ +— gotk–sync.yaml │ │ — kustomization.yaml │ — infrastructure.yaml — infrastructure +— ingress–helm–release.yaml +— ingress–helm–repo.yaml — ingress–ns.yaml |
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 load balancer IP address to see the below web page:
Edit the do-gitops-demo/apps/web.yaml
to update the image tag from v1 to v2.
Commit the code and push it to the remote GitHub repository. Access the load balancer IP again to see the V2 version of the web application.
If you revert the last commit, you can roll back the deployment to V1. This is the beauty of using GitOps.
This completes the step-by-step guide to using FluxCD with DigitalOcean Kubernetes. In the upcoming tutorials, we will explore how to use Kustomization to customize the deployment per each cluster. Stay tuned.
Source: InApps.net
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.