Of the many building blocks that go into deploying successfully to a Kubernetes cluster, it’s hard to get more essential than Argo CD. When you use it as part of your deployment workflow, it becomes the “puppetmaster” for getting all your applications and clusters into your desired state.
At Kubefirst, we love Argo CD because it eliminates any reliance the “ClickOps” paradigm, of running `kubectl apply` or `helm install` manually, which has been the root cause of indecipherable inventories of Kubernetes resources and the dreaded secret-scattering.
But if you’re not already familiar with what it is, its value propositions, and how you deploy to Kubernetes when you use it alongside proper GitOps processes, now is the time to dig in.
Let’s start with the simplest possible definition: Argo CD is an open source GitOps continuous delivery tool for Kubernetes.
That short statement deserves to be broken down.
Argo CD listens for a webhook from your Git provider, which lets it know the state of your GitOps repository has changed due to a merge in your `main` branch. Argo CD clones the repository, calculates the desired state, and creates the necessary resources using native Custom Resource Definitions (CRDs). The best part is that all this happens within your Kubernetes cluster, dramatically simplifying how you manage and observe your deployments after the fact.
There is a way (hint, the kubefirst project) to deploy a management cluster with Argo CD easily, which allows you to view all environments’ applications from a single instance—more on our open source cloud provisioning tool a little later.
Argo CD has become one of the most popular cloud native projects because of its effectiveness and position at the heart of the Kubernetes development and deployment lifecycles. Today, the Argo community consists of more than 7,000 developers from almost 2,000 contributing companies. You can learn more about the continued velocity and diversity of the Argo community in their CNCF Project Journey Report.
It’s one thing to understand what a cloud native tool or project is on a technical level, another thing entirely to grasp how it will affect your team’s day-to-day configuration and deployment lifecycles.
While Argo CD might be a complex project under the hood, once it’s running in your cluster and connected to your GitOps repository, your workflows should get simpler. For example:
You don’t have to switch IDEs, install a half-dozen plugins, or change up how you’re doing code collaboration on GitHub or GitLab. All that changes is that you only have to worry about what goes into your GitOps repo.
Aside from a streamlined workflow, you might still be wondering the value of having a native Kubernetes CD. Why not just stick with the ClickOps fundamentals of running `kubectl apply` and `helm install`? People have been using these commands for years, and the Kubernetes community has produced countless educational resources to guide developers of all experience levels through the fundamentals.
First and foremost, when you use ClickOps, you’re getting almost none of the benefits of GitOps and all the messiness of deployment scripts and run lists of the past. It’s not that different from letting anyone click a green button to deploy an application or entire cluster without oversight from the DevOps or SRE teams. It’s not much better than `ssh`-ing into a Virtual Machine (VM) and copy-pasting a few dozen commands from a DigitalOcean tutorial directly into a Bash prompt.
When you opt for native Kubernetes CD and GitOps, all your application definitions, configurations, and environments are declarative and version controlled. When you want to create a new environment in your cluster for development or staging, for example, you can duplicate the existing folder structure for your configurations and apply new values—Argo CD takes care of the rest.
Because Argo CD uses native Kubernetes CRDs, all the calculating of state, divergence, drift, and syncs happens within your cluster for added scalability and cost savings across the board. Your security posture is improved as well, because you don’t need to provide individual developer access to your infrastructure, only Argo CD.
All in all, your entire application lifecycle is automated, auditable, and easy for anyone to understand. That spins out into other massive benefits:
If you’d like to roll Argo CD into your Kubernetes workflows today, you can always read the docs—you’ll need a running cluster, `kubectl`, a kubeconfig file, and CoreDNS. You’ll use `kubectl` to create a new namespace and deploy Argo CD’s manifests, then create a load balancer, ingress, or forwarded port to help you access the API server. Once you’ve logged in via the CLI tooling, you can integrate with your Git provider and start syncing/deploying.
If that sounds like a lot of work, you might consider giving kubefirst a shot. Our open source registry of agnostic Kubernetes projects already has all the glue and integrations you need to get started with native continuous deployment and GitOps right away. We even have a welcoming Slack community of developers and engineers who’ll be happy to share their experiences and best practices on application delivery and infrastructure management.
In just a few minutes, you’ll be able to upgrade your team out of the ClickOps doldrums with a single GitOps repository, and a `registry` folder, that automatically adds new applications/environments and keeps everything perfectly in sync. No more ClickOps, just seamless and continuous delivery from the best source of truth there is: your Git repository.