Tutorial: Using ArgoCD with Helm Charts

‍What is ArgoCD?

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes applications that uses Git repositories as the source of truth for defining the desired application state. It automates application deployment and lifecycle management, making it easy to understand and audit.

Key Features and Benefits

Argo CD offers several key features and benefits, including:

• Single source of truth: Git repositories serve as the source of truth for application definitions, configurations, and environments.
• User interface: Argo CD provides a user-friendly interface for managing applications and visualizing deployment status.
• Faster updates directly in the cluster: Argo CD enables faster application updates by directly synchronizing the desired state with the live state in the cluster.
• Easy rollback: Argo CD allows for easy rollback of application deployments in case of issues.
• Cluster disaster recovery: Argo CD helps in recovering from cluster disasters by maintaining a version-controlled history of application deployments.
• Security: Argo CD provides role-based access control (RBAC) for managing the authorization of teams to specific services and clusters.
• Scalability: Argo CD can scale to manage multiple applications and clusters.
• Multi-tenancy: Argo CD supports multi-tenancy, allowing multiple teams to manage their applications independently.
• Automated configuration drift detection and visualization.
• Automated or manual syncing of applications to their desired state.

Argo CD Architecture

Argo CD's architecture follows a client-server architecture, where the server component runs within the Kubernetes cluster, and the client component is a command-line interface (CLI) or a web UI used to interact with the server.

Below are some high-level points regarding its architecture.

• Argo CD is implemented as a Kubernetes controller which continuously monitors running applications
• It compares the current, live state against the desired target state (as specified in the Git repo)
• A deployed application whose live state deviates from the target state is considered OutOfSync
• Argo CD reports & visualizes the differences while providing facilities to automatically or manually sync the live state back to the desired target state
• Any modifications made to the desired target state in the Git repo can be automatically applied and reflected in the specified target environments

ArgoCD Components

ArgoCD components include:

• Argo CD Application Controller: A Kubernetes controller that continuously monitors application definitions and configurations defined in a Git repository, comparing the specified state with the live state of the applications.
• Argo CD ApplicationSet Controller: A controller that manages multiple Argo CD Applications as a single ApplicationSet unit, supporting deployments to large numbers of clusters and improving multi-cluster and multi-tenant support within Argo CD.
• Argo CD Dex Server: An identity service that provides authentication and authorization for Argo CD, delegating authentication to external identity providers like GitHub, SAML, and others.
• Argo CD Notifications Controller: A controller that continuously monitors Argo CD applications and provides a flexible way to notify users about important changes in the application state
• Argo CD Redis: A throw-away cache used by Argo CD for storing application state. Redis can be lost and rebuilt without loss of service, as all data is persisted as Kubernetes objects in etcd.
• Argo CD Repository Server: A server that manages access to Git repositories and Helm chart repositories, providing a centralized location for storing and retrieving application configurations.
• Argo CD Server: A gRPC/REST server that exposes the API consumed by the Web UI, CLI, and CI/CD systems, responsible for application management, status reporting, invoking application operations, repository and cluster credential management, authentication, and RBAC enforcement.

What are Helm Charts?

Helm Charts are YAML configurations that define a package of pre-configured resources that can be deployed in a Kubernetes cluster. They allow users to define and deploy applications in a declarative manner, making it easier to maintain configurations.

Overview of Using ArgoCD with Helm Charts

When used together, ArgoCD and Helm Charts provide a powerful combination for managing and deploying cloud-native applications. ArgoCD automates the deployment process and the lifecycle management of applications, while Helm Charts provide a declarative way to define and package applications. In our demo, we will see how to manage applications using helm charts without Argo CD and then how deploying helm charts with Argo CD is a better option.

‍

Video Walk-through

‍Requirements: A GitHub account

TL;DR: You can find the main repo here.

PS, We will also make use of another repo for our School App but it's not essential for this blog post.

Argo CD Design Principles

ArgoCD follows the GitOps pattern, which emphasizes declarative infrastructure and version control. This approach allows for better collaboration among team members and ensures that application configurations are version-controlled. ArgoCD automates the deployment process of the desired states in the specified target environments, tracking updates to branches, tags, or pinned to a specific version of manifests at a Git commit.

Understanding Argo CD Workflow

GitOps

GitOps is a pattern that uses Git repositories as the source of truth for application definitions, configurations, and environments. This approach emphasizes declarative infrastructure and version control, allowing for better collaboration among team members and ensuring that application configurations are version-controlled.

Application Lifecycle Management

Argo CD continuously monitors application definitions and configurations defined in a Git repository, comparing the specified state with the live state of the applications. This enables developers to manage application deployments and updates through continuous delivery of simple Git commit events without the need for complicated Continuous Integration and/or Deployment Pipelines.

Configuration Synchronization

ArgoCD synchronizes the state with the declared state of configurations and ensures that new configurations are correctly deployed to a Kubernetes cluster. As all the records of all changes, including all details of the environment, are stored in Git, ArgoCD provides an auditable history of application deployments, making it easier to track changes and maintain security.

Getting started with Argo CD

To get started with ArgoCD, you'll need to install the ArgoCD CLI and have access to a Kubernetes cluster. You can run the following commands to install argo cd.

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

For more details, you can follow the official getting started guide to install Argo CD and set up your environment.

Argo CD Services

Let's take a look at all the services that Argo CD creates.

Argo CD Custom Resource Definitions (CRDs)

Below are the custom resource definitions that Argo CD creates:

kubectl get crd
NAME CREATED AT
applications.argoproj.io 2023-07-12T19:51:43Z
applicationsets.argoproj.io   2023-07-12T19:51:44Z
appprojects.argoproj.io 2023-07-12T19:51:44Z

Access ArgoCD

Let's now access the Argo CD UI.

Get the admin password

Run the command below to retrieve the admin password for Argo CD.

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

Expose the ArgoCD API Server

In a new terminal run this command:

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

Login using the UI

You can log in to the UI by opening a browser window and going to https://127.0.0.1:8002

username: admin
password: THE_PASSWORD_YOU_GOT_ABOVE

While experimenting, you may encounter a warning that the page is insecure due to the use of a self-signed certificate. Although you can proceed with this setup, it is recommended that you follow the detailed instructions in the Argo documentation to configure TLS with an Ingress route before transitioning to a production environment.

Update the Admin Password

Now go ahead and update the initial admin password that was automatically generated for you.

Delete the Initial Admin Password

Run the command below:

kubectl -n argocd delete secret argocd-initial-admin-secret

Application Deployment with Helm Charts

Let's now deploy helm charts for our application with a helm chart per service. Run the following commands:

# Setup MongoDB DB in K8s
kubectl create ns schoolapp
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install schoolapp-mongodb --namespace schoolapp \
--set auth.enabled=true \
--set auth.rootUser=schoolapp \
--set auth.rootPassword=mongoRootPass \
  bitnami/mongodb

# Add project repo to helm
helm repo add schoolapp https://gitlab.com/api/v4/projects/34240616/packages/helm/stable

# Install the Frontend
helm install frontend -n schoolapp schoolapp/schoolapp-frontend
# Install the API
helm install api -n schoolapp schoolapp/schoolapp-api

Here is the explanation for the above:

• The code sets up a MongoDB database in a Kubernetes cluster and installs a frontend and API for a school application using Helm charts.
• A new namespace called schoolapp is created using the kubectl create ns command.
• The Bitnami Helm chart repository is added using helm repo add.
• The MongoDB Helm chart is installed using helm install, with the --namespace flag specifying the namespace where the MongoDB chart will be installed, and the --set flag used to enable authentication and set the root user and password.
• The schoolapp Helm chart repository is added using helm repo add.
• The frontend and API Helm charts are installed using helm install, with the frontend and API being the names of the releases that will be created for the frontend and API Helm charts, respectively.
• The -n flag specifies the namespace where the Helm charts will be installed, which is schoolapp in this case.

Now open two new terminals to port forward the frontend and the API for our school application deployment.

# Port forward the frontend
kubectl -n schoolapp port-forward service/frontend 8001:8080
# Port forward the API
kubectl -n schoolapp port-forward service/api 5000:5000

School App Frontend

You can test the school app by going to the URL: http://127.0.0.1:8001 in your browser. You should get a welcome screen. Interact with the app and go ahead and add a course and enroll a student.

School App Architecture

Below is a diagram showing the different components of the school app.

It uses the following technology stack:

• Vue.js for the Frontend
• Python's FastAPI framework for the API
• MongoDB for its Database

Application Deployment with ArgoCD and Helm Charts

Now let's get the school app deployed using charts and our favorite GitOps continuous delivery tool, Argo CD.

Delete the Current School App

kubectl delete ns schoolapp

Create the School Application in ArgoCD

Run the following command to create the application.

kubectl apply -f argocdSchoolApp.yaml

‍

As you see in the image above, the App is deployed but the status shows that it is OutOfSync.

Syncing the Application

Now back to the Argo CD UI, you'll need to click on the sync button to synchronize the application. This will reconcile the live state with the target state. Since this is the first time we're deploying, the live state doesn't contain anything.

Now our application is synced and healthy! You can see how Argo CD gives us a nice diagram of the different components of our application if you click on the application box above.

The Application Manifest

Here is the content of the Application manifest file argocdSchoolApp.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: schoolapp
  namespace: argocd
spec:
  destination:
    namespace: schoolapp
    server: 'https://kubernetes.default.svc'
  source:
    path: schoolapp-subchart
    repoURL: 'https://github.com/samgabrail/env0-argocd.git'
    targetRevision: HEAD
  project: default
  syncPolicy:
    syncOptions:
      - CreateNamespace=true

This K8s manifest defines an ArgoCD application called schoolapp that should be deployed to the schoolapp namespace on the Kubernetes server. The application is sourced from a Git repository and uses the "HEAD" revision. The synchronization policy specifies that the namespace should be created if it does not already exist. More details are below.

• apiVersion: argoproj.io/v1alpha1: Specifies the API version of the resource.
• kind: Application: Specifies the type of Kubernetes resource, which is an ArgoCD application.
• metadata: Contains metadata about the application, including its name and namespace.

• name: schoolapp: Specifies the name of the application.
• namespace: argocd: Specifies the namespace where the application is deployed.

• spec: Specifies the desired state of the application.

• destination: Specifies the destination where the application should be deployed.

• namespace: schoolapp: Specifies the namespace where the application should be deployed.
• server: 'https://kubernetes.default.svc': Specifies the Kubernetes server where the application should be deployed.

• source: Specifies the source of the application.

• path: schoolapp-subchart: Specifies the path to the application within the Git repository.
• repoURL: 'https://github.com/samgabrail/env0-argocd.git': Specifies the URL of the Git repository where the application is stored.
• targetRevision: HEAD: Specifies the Git revision to use for the application.

• project: default: Specifies the project where the application belongs.
• syncPolicy: Specifies the synchronization policy for the application.

• syncOptions: Specifies the synchronization options for the application.

• - CreateNamespace=true: Specifies that the namespace should be created if it does not already exist.

Test the School App with ArgoCD

Once again open two terminal windows to port-forward the frontend and API.

# Port forward the frontend
kubectl port-forward service/frontend 8001:8080 -n schoolapp
# Port forward the api
kubectl port-forward service/api 5000:5000 -n schoolapp

Try creating and deleting a course as before. Everything should be working the same.

Making a Change in Git

Now let's see how Argo CD can detect drift between the live and target states. Let's make a simple change in our Git repo for the file called schoolapp-subchart/values.yaml. Change the mongodb.auth.enabled value from true to false.

mongodb:
  auth:
    enabled: false
    rootUser: 'schoolapp'
    rootPassword: 'mongoRootPass'

Then commit and push your changes.

In the Argo CD UI, Click the Refresh button and notice how the application is now OutOfSync. Also, notice that we have auto sync disabled. We'll enable it later.

You can see the components in our Argo CD tree that are out of sync.

If you click on the APP DIFF button, you will see the manifest files. Notice how the MongoDB secret will get deleted.

Notice also that the School App MongoDB Deployment will remove some environment variables and will allow authentication with an empty password.

Go ahead and click on the sync button and notice again the components that will change (the MongoDB secret and the School App MongoDB deployment).

Once you sync, Argo CD will go ahead and make the changes. However, it will not delete the secret. We can now enable auto sync along with

Enabling Auto Sync

Click on APP DETAILS and scroll down to the SYNC POLICY section. You can now enable automated sync along with pruning resources and self heal. When you do that, it will automatically sync and delete the MongoDB secret. Go ahead and have some fun in your git repo toggling the mongodb.auth.enabled from true to false and back again a few times to see auto sync in action.

History and Rollback

By clicking on the History and Rollback button, you can access previous deployments and view all the syncs that Argo has performed. This screen provides an option to restore an older version, which can be useful if a deployment introduces a bug. By rolling back to a previous version, you can avoid pushing a fix to your repository until the issue has been resolved.

ArgoCD Integrations

ArgoCD can be integrated with various tools and platforms to enhance its capabilities. Some of these integrations include:

• GitHub Actions: Automate CI/CD workflows using GitHub Actions and ArgoCD to deploy applications to Kubernetes.
• Helm Charts: Use Helm Charts to define, install, and update pre-packaged applications or consume prebuilt applications from trusted repositories.
• Datadog: Monitor your Argo CD clusters with Datadog, providing insights into key performance metrics and enabling alerts for changes in those metrics.
• New Relic: Gain observability into Argo CD performance with New Relic's instant observability quickstart, which includes alerts for detecting changes in key performance metrics.
• Tekton: Integrate Argo CD with Tekton to create a CI/CD system that includes feature branch testing and automation for creating new features with feature branches and environments.
• Red Hat OpenShift GitOps: Use Argo CD's ApplicationSets and pull request generator with Tekton and Red Hat OpenShift tools to bring GitOps workflows into your CI/CD processes.

Security in ArgoCD

ArgoCD offers several security features to ensure the safety and integrity of your Kubernetes applications. It has undergone stringent internal security evaluations and penetration tests for PCI compliance. Below are some of the highlights mentioned in the official documentation around security.

• Authentication: It uses JSON Web Tokens (JWTs) for API server authentication, with tokens obtained in one of three ways:

• For local admin users, JWTs are issued after exchanging username/password via a specific API endpoint.
• For Single Sign-On users, JWTs are obtained via an OAuth2 login flow.
• For project automation, tokens are generated using another API endpoint and are limited in their scope and privileges.

• Authorization is done by comparing group membership in a user's JWT groups claims with the roles/rules in the RBAC policy.
• All network communication uses TLS, and the Argo CD API server can enforce TLS 1.2 usage.
• Git and Helm repositories are managed by a standalone service, the repo-server, which does not store any service credentials.
• Careful: Unauthorized access to git repositories trusted by Argo CD can lead to serious security breaches.
• Sensitive Data:

• Argo CD does not return sensitive data from its API and redacts all sensitive data in payloads and logs.
• For managing external clusters, Argo CD stores their credentials as a Kubernetes Secret in the Argo CD namespace.

• Cluster RBAC:

• Argo CD's access can be revoked by deleting RBAC artifacts and removing the cluster entry from Argo CD.
• Argo CD's default ClusterRole can be fine-tuned to limit write privileges.

• Auditing: Argo CD logs application activity as Kubernetes Events, complementing the Git revision history.
• Webhook Payloads: Payloads from webhook events are considered untrusted and only used to refresh the related application.
• Security-related logs are tagged with a security field for easier analysis.
• API Logs: Argo CD does not log sensitive API requests or IP addresses of clients.
• The ApplicationSets feature of Argo CD has its own security considerations.
• Denial of Service on Directory Type Apps: Directory-type applications can consume significant repo-server memory; a config option can limit this memory usage.

Best Practices

To ensure optimal results when using ArgoCD, consider the following best practices:

1. Use a Git repository as the single source of truth for application definitions, configurations, and environments.
2. Keep application configurations declarative and version-controlled.
3. Follow the GitOps pattern for managing and deploying applications.
4. Use Helm Charts to define applications in a declarative manner and store them in a Helm repository.
5. Regularly update and maintain Helm Charts to ensure they are up-to-date and secure.

Conclusion

In this blog post, we explored ArgoCD, a powerful GitOps continuous delivery tool for Kubernetes applications. We discussed its key features, benefits, architecture, and components, as well as the role of Helm Charts in defining and managing Kubernetes applications. Additionally, we delved into application lifecycle management, configuration synchronization, and the application deployment process

By understanding and leveraging the capabilities of ArgoCD, you can streamline your application management and deployment processes, ensuring a more efficient and secure Kubernetes environment.

Try env0's CI/CD platform. env0 is a powerful platform that offers numerous benefits for managing Infrastructure as Code (IaC). By using env0, organizations can streamline their infrastructure management processes, promote collaboration, and maintain control over their infrastructure code while enjoying a more cost-effective solution. env0 also supports using Helm, check it out.