Watch a Workflow Actually Run

This lab runs on real Argo Workflows

Inside the VM, a workflow controller, argo-server, and an artifact store (minio) are actually running. When you submit a workflow, the controller starts Pods, the steps progress, it retries on failure, and logs are left.

The workflow labs in the earlier module ran on a fake cluster. It accepted objects, but with no controller, nothing happened. All you could do was practice writing YAML, and there was no way to check whether that YAML actually runs.

It takes about 4 minutes to come up the first time.

What is prepared

네임스페이스   argo        권한도 붙어 있어 바로 낼 수 있습니다
CLI            argo        argo submit / list / get / logs
아티팩트 저장소 minio      단계 사이에 파일을 주고받습니다
미리 받은 이미지 busybox:1.36 · alpine:3.20

The Korean text in this code block says, in order, that the argo namespace already has the permissions attached so you can submit right away, that the argo CLI offers argo submit, list, get, and logs, that minio is the artifact store for passing files between steps, and that the pre-pulled images are busybox:1.36 and alpine:3.20.

Goal

From the skeleton of a workflow to handling failure, you confirm by actually running it.

Steps

1. Run one workflow and capture it in /root/capa/run.txt.
2. Build dependencies with a DAG and capture in /root/capa/dag.txt that it runs in parallel.
3. Pass parameters and receive the result, and capture it in /root/capa/params.txt.
4. Pass an artifact to the next step and capture it in /root/capa/artifacts.txt.
5. Capture in /root/capa/retry.txt that retries actually run with retryStrategy.
6. Capture in /root/capa/exit.txt that onExit runs even on failure.
7. Create a WorkflowTemplate, reuse it, and capture it in /root/capa/template.txt.
8. In /root/capa/report.md, write the three lines workflows_run=, retry_attempts=, and exit_ran=yes, plus an explanation.

Notes

• Submit with argo submit -n argo <파일> --wait and wait until it finishes (the placeholder is the workflow file).
• View the state per step with argo get -n argo @latest and the logs with argo logs -n argo @latest.
• There are 90 seconds per step. Keep sleep short so that each workflow finishes within that.
• Common mistake: the name entrypoint points to is not in templates. Then the workflow cannot even start.
• Common mistake: attaching dependencies to the starting node of a DAG. Nobody can satisfy it, so it waits forever.

It really runs

Run one workflow and capture it in /root/capa/run.txt.

Submit with argo submit --wait, and after it ends, check with argo get and kubectl get pod.

Dependencies create the order

Build dependencies with a DAG and capture in /root/capa/dag.txt that it runs in parallel.

Tasks without dependencies start at the same time. Compare the start times.

Passing values back and forth

Pass parameters and receive the result, and capture it in /root/capa/params.txt.

Read a file with the valueFrom.path of outputs.parameters, or receive a script template's standard output as result.

Pass a file to the next step

Pass an artifact to the next step and capture it in /root/capa/artifacts.txt.

Put it out with outputs.artifacts and receive it with the from of inputs.artifacts. It goes through the store.

If it fails, try again

Capture in /root/capa/retry.txt that retries actually run with retryStrategy.

retryStrategy.limit is the number of retries. The first attempt is not counted in it.

A place that runs even on failure

Capture in /root/capa/exit.txt that onExit runs even on failure.

onExit runs even if the workflow fails. You can learn the result with {{workflow.status}}.

Reuse a definition

Create a WorkflowTemplate, reuse it, and capture it in /root/capa/template.txt.

Create a WorkflowTemplate and point at it with templateRef.

What did you learn?

In /root/capa/report.md, write the three lines workflows_run=, retry_attempts=, and exit_ran=yes, plus an explanation.

Write the three lines workflows_run=, retry_attempts=, and exit_ran=yes, plus an explanation.