↓Skip to main content

ArgoCD Fundamentals

·923 words·5 mins
Gitops Argocd
Vinay V
Author
Vinay V
Passionate about building scalable, reliable platforms through automation and best practices.
Table of Contents

This blog is part of my GitOps series . Before jumping on to understand argocd and its usage, feel free to read my previous blog GitOpsFundaments.

In this blog lets understand GitOps practices from the lens of argocd and how can one achieve true GitOps.

Overview
#

ArgoCD is one of the popular open-source tool for continuous delivery (CD) which focuses on managing the applications using GitOps principles

Features:

  1. Declarative Setup: All the application state (desired state) is managed in a declarative way using manifest files, and persisted in git repositories (YAML or Helm charts)

  2. Self Healing: Argocd continuously monitors the state of the applications that are deployed and when ever a drift is found between desired and actual state, self healing capability would re-sync the application back to the desired state (Git as the single source of truth).

  3. RBAC’s and Security: ArgoCD allows you to define fine grained access control for both users and Argocd agents (such as Argocd application controller). This helps us to follow the least privilege model.

  4. Multi-cluster support: ArgoCD helps to manage and deploy applications to different environments, and all of them managed declaratively.

  5. Application Health and Status: ArgoCD comes with a GUI, which gives detailed information about the health and status of applications (metrics, logs and events).

  6. Rollback and Version: With all the configurations versioned in git, rollbacks are seamless and easy whenever somethings goes wrong with a deployment.

ArgoCD is kubernetes native — This means ArgoCD works only with kubernetes ecosystem, it was built with kubernetes as its primary target platform

Key Concepts
#

Below are the some of the key concepts which are worth discussing before we go to the setup.

  1. Application

This is the basic unit of ArgoCD deployed as a Custom Resource Definition. It provides the definition for how the application needs to be deployment and managed based on its desired state stored in git repository or sources like helm or kustomize.

Characteristics:

  • Source — Where the application’s configuration is stored (eg: Git repository, Helm chart)
  • Destination — The target kubernetes cluster and namespace where the application should be deployed.
  • Sync policy — Defines the configuration for how and when ArgoCD should synchronise the cluster with the desired state from git.

Example YAML Definition:

We will discuss more on the Application manifest file in later chapters…

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/myorg/demo-app-repo.git'
    targetRevision: main
    path: 'sample-app'
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
  • metadata.name: The name of the ArgoCD application (e.g. demo-app).
  • spec.project: The ArgoCD project this application belongs to (can be default).
  • source.repoURL: The URL of the Git repository containing the Kubernetes manifests, Helm charts, or Kustomize configuration.
  • source.targetRevision: The branch or tag in the Git repository (e.g., main).
  • source.path: The directory in the repository containing the manifests or Helm charts.
  • destination.server: The Kubernetes cluster where the application will be deployed (default is the local Kubernetes cluster).
  • destination.namespace: The Kubernetes namespace where the application will be deployed.
  • syncPolicy: Defines the synchronization strategy.
  1. Projects:

Projects are logical grouping of related applications, which helps us to manage their settings in group instead of individual apps. Project also gives more fine-grained control over application management, incase of large environments.

  • Namespace Management: Project defines which kubernetes namespace an application should be deployed to.
  • Resource Quota: Projects allow you to set resource limits for applications within them.
  • Access Control: Projects helps manage access to set of applications via RBAC’s.

You can refer to core_concepts to know more about other concepts that are specific to argocd.

Building blocks

Below are some of the basic components which constitutes the ArgoCD ecosystem.

  1. ArgoCD API server:
  • Its the central unit of ArgoCD setup, which provides REST API’s to manage applications, project, users etc.
  • Manages user authentication and RBACs.
  • Provides an interface for managing applications, clusters and repositories.
  • Coordinates with other components like application controller, repository servers.
  1. ArgoCD Application Controller:
  • This is considered to be the heart of ArgoCD which manages the GitOps process.
  • Its responsible for monitoring and ensuring the synchronization between the desired state (in git) and the actual state in the cluster.
  1. ArgoCD Repo Server:
  • It acts as a bridge between ArgoCD and Git repositories (public and private).
  • It pulls the application configuration and manifests from the specified repositories and makes them available for other components like application controller.
  1. ArgoCD Metric Server:
  • The metric server gathers and stores application related metrics for ArgoCD. This component is responsible to display metrics related to health , status and performance of the application to users.

Components Interaction
#

alt text

Explanation:

Assuming the user requests for new application creation by making an api call or from UI.

  1. User initiates a request - defines the new app resource stored in git repository for ArgoCD (via the UI, CLI or API)

  2. API server receives the request and forwards it to the repo server. The repo server fetches the manifests from the git repository and renders them (if its using helm or kustomize) and returns it to API server.

  3. API server forwards the desired state (rendered manifests) to the application controller. The application controller compares the desired state with the actual state by querying the kubernetes API server.

  4. There is a drift found, the application controller applies the necessary changes to the cluster by sending request to kubernetes API server.

  5. Application controller updates the status of the application and sends it back to the API server.

  6. API server will then display this information on the UI, cli or API as response.