Argo Workflows is an open-source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Argo Workflows is implemented as a Kubernetes CRD (Custom Resource Definition). These CRDs allow you to define a series of tasks to execute, as well as the order in which they should be executed. This makes Argo Workflows a great tool for automating your CI/CD workflows or any other tasks you would normally offload to a lambda function or other serverless arichitecture.
Argo Workflows is one of the most popular workflow engines for Kubernetes and is used by many large orgainzations maninly due to it's scaleability and ease of use in a kubernetes native environment. On the surface, Argo Worklows looks and behaves like many other workflow engines, but under the hood it is a very powerful tool that gives you full controll over your workflows. Weather you are running time based workflows, event based workflows, or a combination of of many different event types Argo Workflows has you covered. Where Argo Workflows really shines is when it is teamed up with other tools in the Argo ecosystem like Argo CD and Argo Events. These tools allow you to create a fully customizable servierless architecture that can scale with your needs and fit most any use cases. Workflows truely bridges the gap left by traditional Kubernetes Jobs and CronJobs by allowing you to introduce worklow level logic into you container orchestration platform.
Let's take a look at a simple workflow that runs a classic example of whalesay. While simple enough, this example illustrates the power of Argo Workflows and how easy it is to get started with. Our workflow will consist soley of a single container that accepts a command and an argument, much like any other container in Kubernetes. First, well take a look at the workflow definition and then we'll dive into each line to see what it does.
---
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: hello-world-
labels:
workflows.argoproj.io/archive-strategy: "false"
annotations:
workflows.argoproj.io/description: |
This is a simple hello world example.
spec:
entrypoint: whalesay
templates:
- name: whalesay
container:
image: docker/whalesay:latest
command: [cowsay]
args: ["hello world"]
We can safely ignore most of the configuration outside of the spec block for now. While the spec block holds
the important part that we are mainly interested in, it is important to note the kind
and
apiVersion
. These are the two fields that Kubernetes uses to determine what kind
of object we are creating and how to handle it. In this case, we are creating a Workflow object with the
apiVersion of argoproj.io/v1alpha1. This will use the CRDs that are created when you first install Argoworkflows on your cluster.
The spec block should look very familiar to anyone who has worked with Kubernetes before with some minor differences.
The entrypoint
field is used to define the first template that should run when executing this workflow.
In this case, we are defining a template called whalesay
that will run a container with the image
docker/whalesay:latest
. Inside this container, the cowsay command should be installed
already and should allow us access to run the cowsay command with any argument we pass in. Right now the workflow
definition is very simple, and only allows us to use the "hello world" argument. We can expand on this by adding more
templates and more complex logic to our workflow, but that's another topic for another day.
Another important thing to note, is as it is now, the workflow will need to be called either through the argo workflows UI or the argo workflows CLI. This is where the rest of the ecosystem comes into play and we'll touch on Events later on. For now, lets see this thing run.
Keep checking back. I'll add more info to this page as i get more time to work on it.
Argocd app of apps definition.
Argo Workflows up and running
Automating workflows with github actions.
Simple Api using gin-gonic.
Building K8s manifests with Helm3
A collection of kubectl commands that have helped me a ton.
Configuring Role Based Access Control in Kubernetes.
Making images smaller with multi stage builds.
Keeping secrets out of your container images even while using private modules