Using Argo CD to Manage More Than Just Applications

The world of GitOps is growing up. What started as a revolutionary way to handle application delivery is now transforming how we manage entire cloud native environments. For platform engineers, this evolution is a game changer. We're moving beyond deploying simple applications to orchestrating the whole stack. And at the heart of this shift, you'll often find a powerful tool: Argo CD.

Forget thinking of Argo CD as just an application deployment tool. It's time to see it for what it can truly be: a unified control plane for your entire platform. Imagine a world where a single git push not only deploys your new microservice but also provisions the database it needs, configures the necessary networking rules, and ensures the monitoring tools are watching it. This isn't a far off dream; it's what you can build with Argo CD today.

This article will take you on a journey to unlock this power. We'll explore how to use Argo CD to manage everything, from the underlying cloud infrastructure to the services running inside your Kubernetes cluster. Get ready to level up your GitOps game.

Infrastructure as GitOps: The Terraform and OpenTofu Connection

Let's start with a common scenario. Your development team has built a new application that needs a managed database, say an Amazon RDS instance. In a traditional setup, this would involve a separate process. Someone, maybe you, would have to go into the AWS console or run some Terraform commands manually to create the database. Only after that's done can the application be deployed. This is slow, error prone, and creates a disconnect between your application and its dependencies.

Now, let's sprinkle some GitOps magic on this with Argo CD and its integration with tools like Terraform or its open source fork, OpenTofu. The idea is to manage your infrastructure just like you manage your applications: through Git.

Here’s how it works. You define your RDS database using Terraform’s declarative syntax in a .tf file. This file lives in the same Git repository as your Kubernetes manifests. Now, you can create an Argo CD application that points to this repository. But instead of just deploying Kubernetes resources, this Argo CD application will be configured to run Terraform.

A single Git commit can now trigger a beautiful chain of events. Argo CD detects the change, clones the repository, and sees the Terraform files. It then runs a terraform apply, which provisions the RDS database in your AWS account. Once the database is up and running, another Argo CD application, or even the same one, can deploy the Kubernetes application that relies on this database.

Think of it like a perfectly choreographed dance. The infrastructure gracefully takes the stage first, and then the application makes its grand entrance, all orchestrated by Argo CD from a single source of truth: your Git repository. This creates a powerful, auditable, and repeatable workflow for managing your entire environment.

Managing the Cluster Itself: The "App of Apps" Pattern

Your Kubernetes cluster isn't just a blank canvas for your applications. It’s a bustling city of its own, with essential services that need to be managed. Think about your service mesh like Istio, your monitoring stack with Prometheus and Grafana, and even Argo CD itself. These are all critical components that need to be installed, configured, and updated.

Managing these cluster level components can get messy. If you're not careful, you can end up with a collection of manually applied Helm charts and YAML files, making it difficult to track changes and ensure consistency. This is where the "App of Apps" pattern comes to the rescue.

The concept is brilliantly simple. You create a single, top level Argo CD application. We'll call it the "root app". This root app doesn't deploy a user facing application. Instead, its sole purpose is to deploy other Argo CD applications. These "child" applications are the ones that actually manage your cluster components.

For example, your root app's Git repository might contain a directory with several YAML files. One file defines an Argo CD application for Istio, another for Prometheus, and so on. When you sync the root app, Argo CD will automatically create and sync all the child applications.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: istio
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://your-git-repo.com/infra.git'
    path: istio
    targetRevision: HEAD
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: istio-system

This creates a beautiful, hierarchical structure for managing your cluster. You have a single entry point, the root app, to understand and control everything that's running on your cluster. Need to update Istio? Just update its configuration in the Git repository, and the change will automatically be rolled out. Want to add a new tool? Simply add a new Argo CD application definition to your root app's repository.

The App of Apps pattern turns your cluster management into a declarative, Git driven process. It brings the same level of control and auditability you have for your applications to the very foundation of your platform.

Extending with Custom Resource Definitions (CRDs): The Ultimate Control

So far, we've seen how to manage applications and even the cluster itself. But what about everything else? What about the vast ecosystem of cloud services that your applications depend on, like Google Cloud Pub/Sub topics, Azure Key Vaults, or any other service you can think of? This is where the true power of Argo CD as a unified control plane shines, thanks to the magic of Kubernetes operators and Custom Resource Definitions (CRDs).

A Kubernetes operator is a special kind of controller that extends the Kubernetes API. It lets you manage external resources as if they were native Kubernetes objects. Tools like Crossplane and AWS Controllers for Kubernetes (ACK) are fantastic examples of this.

Let's take Crossplane as an example. With Crossplane, you can install providers for different cloud platforms like AWS, GCP, and Azure. These providers introduce new CRDs to your cluster that represent cloud resources. For instance, you might have a RDSInstance CRD for AWS or a CloudSQLInstance CRD for GCP.

Now, instead of writing Terraform code, you can define your cloud infrastructure directly in YAML, just like any other Kubernetes resource.

apiVersion: database.aws.crossplane.io/v1beta1
kind: RDSInstance
metadata:
  name: my-cool-database
spec:
  forProvider:
    region: us-east-1
    dbInstanceClass: db.t2.small
    masterUsername: myuser
    allocatedStorage: 20
    engine: postgres
    engineVersion: "13"
    skipFinalSnapshot: true
  writeConnectionSecretToRef:
    namespace: default
    name: my-cool-database-conn

And here's the beautiful part: because these are just Kubernetes resources, Argo CD can manage them out of the box. You can create an Argo CD application that points to a Git repository containing these YAML definitions. When you sync the application, Crossplane's operator will see the RDSInstance resource and provision the actual RDS database in your AWS account.

This is incredibly powerful. You now have a single, unified workflow for managing everything. Your application's deployment manifest, the database it needs, the message queue it communicates with, and the IAM roles it assumes can all be defined in Git and managed by Argo CD. There’s no need to switch between different tools or workflows. It all flows through the same GitOps pipeline.

This approach truly centralizes your entire environment's configuration in Git, making Argo CD the ultimate control plane. It provides a level of consistency, visibility, and automation that was previously unimaginable.

The conversation around GitOps is no longer just about applications. It's about building robust, manageable, and scalable platforms. By leveraging Argo CD with tools like Terraform, OpenTofu, and Kubernetes operators, you can create a powerful, unified control plane that simplifies your operations and empowers your development teams. So go ahead, unleash the full potential of Argo CD and start managing your entire platform the GitOps way.