← Back to Engineering

ArgoCD - Simplifying GitOps Deployment

2024-07-015 min readKiran Kumar J

ArgoCD - Simplifying GitOps Deployment

Introduction to Argo CD and GitOps

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes applications. As a declarative, GitOps continuous delivery tool, it orchestrates application deployment, configuration, and lifecycle management, ensuring consistency and reliability across clusters.

Purpose of GitOps Strategy

  • Infrastructure as Code (IaC): GitOps promotes the practice of managing infrastructure and application configurations through code stored in version control systems like Git. This approach enables teams to treat infrastructure as code, facilitating versioning, collaboration, and reproducibility.
  • Consistency and Standardization: By defining infrastructure and deployment processes as code, GitOps ensures consistency across environments. This reduces the risk of configuration drift and minimizes human errors, leading to more reliable deployments.
  • Audibility and Traceability: GitOps provides a clear audit trail of all changes made to the infrastructure and application configurations. Every modification is recorded in version control, allowing teams to track who made the change, when it was made, and why, which enhances accountability and compliance.
  • Collaboration and Visibility: With GitOps, all team members have access to the same set of configuration files and deployment manifests stored in Git repositories. This fosters collaboration and transparency, as everyone can review, comment on, and contribute to the deployment process.
  • Rollback and Disaster Recovery: In case of deployment failures or issues, GitOps simplifies rollback procedures by reverting to the last known good state stored in Git. This capability enhances resilience and facilitates disaster recovery, minimizing downtime and service disruptions.

Disclaimer: This blog post exclusively presents our organization's folder structure strategy designed for managing Helm and Kubernetes files within the Argo CD ecosystem. It does not include a comprehensive briefing on Helm, Kubernetes and Argo CD. For detailed information on Kubernetes and Argo CD, please refer to their respective documentation.

What ArgoCD doesn't solve?

Our journey towards optimizing GitOps repository management with Argo CD revolves around addressing key challenges while striving for specific objectives:

  • Centralized Environment and Application Deployment: Our aim is to consolidate all application deployments for each environment and application within a single Git branch.
  • Enforcement of Naming Conventions: Adhering to predefined naming conventions for releases, Argo CD applications, and related components promotes consistency and clarity across deployments.
  • Mitigation of Human Error: We seek to minimize the risk of human error during the creation of Argo CD applications through structured folder frameworks, predefined templates, and standardized layouts.
  • Resolving Argo CD Shared Resource Warning: Implementing a well-defined folder structure helps mitigate the shared resource warning issued by Argo CD.
  • Straightforward Helm Release Management: Establishing a straightforward approach to deploying or managing Helm releases is crucial.

Folder Structure for Argo CD Deployment

To address these challenges and achieve our objectives, we've meticulously designed a folder structure tailored for Argo CD deployment:

.
├── Chart.yaml
├── templates
│   ├── _helper.tpl
│   ├── apps.yaml
│   └── extras.yaml
├── values
│   ├── bitnami-kafka.yaml
│   ├── observability.yaml
└── values.yaml

Understanding the Structure

  • Chart.yaml: This file contains essential metadata defining the chart, ensuring Argo CD recognizes our repository as a chart deployment.
  • Templates: Within this directory lies essential templates crucial for rendering Argo CD application configurations:
    • _helper.tpl: Houses the Argo CD application named template logic, ensuring seamless application rendering.
    • apps.yaml: Contains the named template for rendering Argo CD applications.
    • extras.yaml: Holds named templates for rendering Argo CD applications specific to extras.
  • Values: Here, we store Helm release information in separate YAML files for each helm release.

Application Rendering Logic - templates/_helper.tpl

{{`{{- define "tpl.argocd.application.helm" }}`}}
{{`{{ $appName := (printf "%s-%s-%s" .Values.application ((.appName).releaseName | default (.appName).chart.name) .Values.environment) }}`}}
{{`{{ $valuesFile := (printf "%s/%s%s.%s" "values" ((.path) | default "") ((.appName).releaseName | default (.appName).chart.name) "yaml") }}`}}
{{`{{- if (.appName).enabled }}`}}
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: {{`{{ $appName }}`}}
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  source:
    repoURL: {{`{{ (.appName).chart.repoURL }}`}}
    targetRevision: {{`{{ (.appName).chart.version }}`}}
    chart: {{`{{ (.appName).chart.name }}`}}
    helm:
      releaseName: {{`{{ (.appName).namespace | default .Values.namespace }}`}}
      values: |
        {{`{{- .Files.Get $valuesFile | nindent 8 }}`}}
{{`{{- end }}`}}
{{`{{- end }}`}}

Configuration Values - values.yaml

enabled: true
application: test
environment: dev
project: argocd-project-name
server: test-cluster
namespace: default
syncPolicy:
  automated:
    prune: true
    selfHeal: true
  syncOptions:
    - Validate=true
    - CreateNamespace=true
    - PrunePropagationPolicy=foreground
    - PruneLast=true
    - RespectIgnoreDifferences=true
    - ApplyOutOfSyncOnly=true
  retry:
    limit: 5
    backoff:
      duration: 5s
      factor: 2
      maxDuration: 3m

ingressNginx:
  enabled: true
  namespace: ingress-nginx
  chart:
    repoURL: https://kubernetes.github.io/ingress-nginx
    version: 4.8.3
    name: ingress-nginx

bitnami:
  kafka:
    enabled: true
    releaseName: bitnami-kafka
    namespace: kafka
    chart:
      repoURL: registry-1.docker.io/bitnamicharts
      version: 26.8.1
      name: kafka
    syncPolicy: {}
    ignoreDifferences:
      - group: apps
        kind: Service
        jsonPointers:
          - /spec

Deployment and Observations

Once you perform the Helm template operation using the command:

helm template argocd-apps . -f values.yaml > argocd-apps.yaml

After generating the argocd-apps.yaml file containing the rendered Argo CD applications, proceed to Argo CD and create an application or application set pointing to this repository and branch. Upon synchronization, you will witness a comprehensive representation of your applications, each aligning with a component within your stack.

Conclusion

With a standardized and well-organized GitOps repository structure, optimized for Argo CD, you're well-equipped to streamline application deployment, enhance collaboration, and minimize errors. This approach fosters consistency, scalability, and resilience, ensuring smoother operations and greater efficiency in managing your Kubernetes infrastructure.

Next Steps: Extending Repository for Raw Kubernetes Manifests and Helm Charts

In the next section, we'll explore how to extend this GitOps repository to deploy raw Kubernetes manifest files and Helm charts that lack official public Helm charts, such as the Istio operator. This extension will enrich your repository's capabilities, enabling seamless integration and deployment of diverse Kubernetes resources within the same repository and branch. Stay tuned!