Deploying Helm Charts with ArgoCD


main

Today, I am going to show one of the uses cases of ArgoCD. Which consists of deploying a Helm Chart using GitOps.

Before I show the step by step process. I think is important to provide an overview of Gitops. This is a definition borrowed from Cloudbees website:

GitOps is a paradigm or a set of practices that empowers developers to perform tasks which typically fall under the purview of IT operations. GitOps requires us to describe and observe systems with declarative specifications that eventually form the basis of continuous everything. (As a refresher, continuous everything includes but is not limited to continuous integration (CI), testing, delivery, deployment, analytics, governance with many more to come).

GitOps combines Git with Kubernetes’ convergence properties and serves as an operating model for developing and delivering Kubernetes-based infrastructure and applications. GitOps empowers developers to take on operations in a way that says “You own it, you ship it!” and graduates from being a slogan everyone chants at tech conferences to a reality that can be executed day in and day out.

Let’s now get our hands dirty and deploy a helm chart with Gitops and using ArgoCD.

1. Deploy ArgoCD control plane to a Kubernetes Cluster

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

You can confirm components were created with following command:

kubectl get all -n argocd

2. Define the sources (Git repositories) for our GitOps workflow

We are going to create (this is how I approached in this blog post) but it is not mandatory to instrument your git repositories the same way I am doing in here. Having said that, is important to highlight what GitOps recommend for best practices:

- System definitions are described as code.
- The desired system state and configuration is defined and versioned in Git.
- Changes to the configuration can be automatically applied using pull requests.
- A controller ensures that no configuration drifts are present.

First, I have created a git repository in Github with this structure:

cicd directory: Directory where all the ArgoCD configurations are stored.

guestbook directory: This is the directory where all kubernetes components related to the guestbook applications are stored (not related to the helm chart)

A second repository was created in Github using Github Pages in order to convert this repository in a Helm Chart. More about converting a Github repo in Helm Chart here.

3. Access ArgoCD and connect ArgoCD to a Github Repository

Let’s access the ArgoCD UI but first we need to retrieve the admin password;.

The initial password for the admin account is auto-generated and stored as clear text in the field password in a secret named argocd-initial-admin-secret in your Argo CD installation namespace. You can simply retrieve this password using kubectl:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Let’s connect to our ArgoCD UI with this command:

kubectl port-forward svc/argocd-server -n argocd 8080:443

And open https://127.0.0.1:8080 in your web browser. The username is admin.

In order to expose ArgoCD using an Ingress controller please click here to learn more

Now that we are in ArgoCD UI, let’s connect our apps. Click on settings icon on the left hand.

main

Click on Repositories and click on + CONNECT REPO USING HTTPS

main

Enter https://github.com/albertollamaso/argocd-example-appsin the Repository URL. Not username/password is required since this repository is public. Then click connect.

main

You will see your repository is connected:

main

Now, let’s create our Apps by clicking in the UI + NEW APP. What we are doing is telling ArgoCD where all our configurations are store and start to reconcile the desired status with the real status in the cluster.

Here you can see the configurations I’ve used:

main

main

main

main

We can see our helm chart has been deployed. From now on, all changes should follow the gitflow and should be PRd to this file specifically

In order to make changes to the Helm releases and customize the parameters they should be PR to the same file above and merge into the main branch. An example of passing parameters:

  spec:
    source:
      helm:
        parameters:
        - name: app
          value: $ARGOCD_APP_NAME

More about Helm in ArgoCD here

As you can see, it is super easy to deploy applications using GitOps and ArgoCD bringing us many functionalities and versatility around.

Personally, I think it is very important to introduce Gitops in the enterprise in order to empower the developers and that they are able to deploy the applications they need in their day to day. At the same time, many benefits are obtained such as visibility of changes, revision of changes and more.

Resources

Getting started with ArgoCD

ArgoCD Ingress COnfiguration

How to host your Helm chart repository on GitHub

Kafka Helm chart

ArgoCD Example Apps

More about Helm in ArgoCD

Back to blog