GitOps w/ FluxCD: Deploying Helm Charts with FluxCD.

GitHub repos are not the only source allowed with FluxCD. In this article, we will set up an automated deployment of charts using the Helm Controller and the Helm Release object.

Installing Postgres Helm Chart w/ FluxCD

Helm repositories are a different kind of source than GitHub, and it is no surprise they need a different type of Source Object.

• Generate the manifest for a Source Object for the Helm Controller

flux create source helm lfs269 --url=https://lfs269.github.io/helm-charts --export

• Rerun the command above without --export

flux create source helm lfs269 --url=https://lfs269.github.io/helm-charts

• Verify the creation of the Helm Source

flux get sources helm

• To ensure Postgres is deployed without errors, add values.yaml in the flux-infra/clusters/staging folder.

# Assuming your active folder is flux-infra/clusters/staging

nano values.yaml

# Add the following to the file

service:
  name: db
settings:
  authMethod: trust

• We know that each Helm Chart has many releases (due to modified code-based). Typically, each release of a Chart is saved as a Secret in Kubernetes in case a rollback is needed. FluxCD has provided another Source Object called HelmReleases that takes care of version archiving.

flux create helmrelease db --source=HelmRepository/lfs269 --chart=postgres --values=./values.yaml --target-namespace=instavote

• Validate the object was created

flux get helreleases

• List all Helm-related objects created by you

flux get all | grep helm

We remember generating the HelmRepository Source Object and the HelmRelease/db object, but there is an automatically generated HelmChart/flux-system-db, something we did not directly work on.

Where did this automatically generated HelmChart come from?

When we bootstrapped the environments with fluxCD, several Controllers were installed, a Helm Controller being one of them. The mere act of generating a HelmRepository Source object and a mapped HelmReleases object triggered the HelmChart/flux-system-db object's creation.

• Validate Postgres is active

kubectl get pods -n instavote

• Commit changes made in the cluster to GitHub.

# Ensure active folder is flux-infra/clusters/staging

# Generate the manifest for HelmRelease/db
flux export helmrelease db > db-helmrelease-staging.

#Generate the manifest for HelmRepository lfs 269
flux export source helm lfs269 > lfs269-helmrepository-staging.yaml

# Commit to flux-infra/clusters/staging
git add *
git status
git commit -m 'helm'
git push origin main

• Verify code check-in was successful.

• Load the vote UI app in the browser.

Architecturally Speaking

Summary: What and Why?

Instavote Application Components Deployed So Far

GitHub Folder Structure

I write to remember, and if, in the process, I can help someone learn about Containers, Orchestration (Docker Compose, Kubernetes), GitOps, DevSecOps, VR/AR, Architecture, and Data Management, that is just icing on the cake.