Argo Ecosystem: Argo CD, Argo Workflows, Argo Events, Argo Rollouts, Argo Everything

Argo CD is just one of many tools under the Argo umbrella. By this point, you should be well aware of what Argo CD is: it’s a Git Ops deployment tool. If we simplify, the only thing Argo CD is doing is taking Kubernetes manifests and applying them to one or more Kubernetes clusters. It can not do anything more complex than this.

But just a fancy kubectl apply is not enough to build a complete majestic pipeline. We need to build, test, package and push the new application version. To help with these activities, there is an Argo Workflows project. The idea behind it is to give you the building blocks to run any kind of workflows on top of your Kubernetes clusters. Some of the use cases include machine learning jobs and infrastructure automation, but most interesting to us is that it can be used to build CI/CD pipelines.

Argo Workflows has many batteries included - a separate CLI, a Web Dashboard, access control, retries, various hooks, artifacts support and so son. You can build quite some powerful workflows on top of this system, and documentation claims that it scales to thousands of workflows a day, with tens of thousands nodes.

The only battery that is not really included in Argo Workflows is how to trigger those workflows. For sure, it’s fun to submit workflows with the CLI, but that’s not how you do in the real life. In the real life, at least for the CI/CD pipeline, you want your workflows to be triggered automatically, on some event, like an opened Pull Request.

Worry not, Argo got you on this front as well. There is a separate Argo Events project, the whole purpose of which is to receive and process events. It supports more than 20 different event sources, starting from the simple ones, like GitHub Webhook events, and including cloud-provider specific ones, like SQS or GCP PubSub. You can even write your own custom event processors.

Argo Events has a relatively simple architecture. Even Sources process events from external systems and write them into the event bus, powered by NATS. Sensors process those events and trigger something. They can trigger a Lambda function, send Kafka Message and, most importantly, they can trigger Argo Workflows.

If you want a whole CI/CD system, you will need both Argo Events and Argo Workflows. They share the single interface, so from the end user they would look like a well integrated system, while underlying infrastructure is a bit more decoupled. You’d need to configure Argo Events to process events from GitHub, Bitbucket or GitLab and to create Argo Workflows, which would then clone the repository, build and test the code and, probably, push some changes to GitOps styled repository, so that Argo CD picks up and rolls out the changes.

Talking about rollouts, there is another Argo project called Argo Rollouts. Rollouts is a way smaller project than Workflows, Events or CD. In a nutshell, Argo Rollouts are a replacement for Kubernetes Deployments. It’s a separate CustomResourceDefinition that gives you an ability to perform canary and blue-green deployments, by integrating with external systems for ingress and metrics. It also has a few smaller features like built-in deployment notifications and simple deployment dashboard.

Finally, if you are just looking for a simpler process to update your deployments to use the new image version, there is a separate Argo CD component named Argo CD Image Updater. It will connect to your registry, discover new tags and update your applications to use this new tag - or, optionally, it will push a commit with the new image tag to the repository where your Argo CD Application is defined.

To sum it up, Argo ecosystem is quite large and diverse. Argo CD is probably the most popular part of it, but as of today Argo covers all the possible use case around building and deploying your applications, as well as it’s capable to be a generic job execution engine and event processor. You might start with just Argo CD for some GitOps automation, but at some point you might benefit from Argo Workflows and Events. The obvious benefit is that you will use the collection of tools from the same ecosystem, tools that are built to work with each other - which is a bit better than duct taping multiple unrelated open source projects.

Here' the same article in video form for your convenience: