워크플로가 실제로 도는 것을 본다

이 실습은 진짜 Argo Workflows 에서 돕니다

VM 안에 워크플로 컨트롤러 · argo-server · 아티팩트 저장소(minio) 가 실제로
떠 있습니다. 워크플로를 내면 컨트롤러가 파드를 띄우고, 단계가 진행되고, 실패
하면 재시도하고, 로그가 남습니다.

앞 모듈의 워크플로 실습은 가짜 클러스터에서 돌았습니다. 오브젝트는 받아 주지만
컨트롤러가 없어 아무 일도 일어나지 않았습니다. YAML 을 쓰는 연습까지가
전부였고, 그 YAML 이 실제로 도는지는 확인할 방법이 없었습니다.

처음 뜨는 데 4분쯤 걸립니다.

준비된 것

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

목표

워크플로의 뼈대부터 실패를 다루는 자리까지, 실제로 돌려서 확인합니다.

단계

1. 워크플로 하나를 돌리고 /root/capa/run.txt 에 담으세요.
2. DAG 로 의존성을 만들고 병렬로 도는 것을 /root/capa/dag.txt 에 담으세요.
3. 파라미터를 넘기고 결과를 받아 /root/capa/params.txt 에 담으세요.
4. 아티팩트를 다음 단계로 넘겨 /root/capa/artifacts.txt 에 담으세요.
5. retryStrategy 로 실제로 재시도가 도는 것을 /root/capa/retry.txt 에 담으세요.
6. onExit 이 실패했을 때도 도는 것을 /root/capa/exit.txt 에 담으세요.
7. WorkflowTemplate 을 만들어 재사용하고 /root/capa/template.txt 에 담으세요.
8. /root/capa/report.md 에 workflows_run=, retry_attempts=, exit_ran=yes 세 줄과 설명을 쓰세요.

참고

• argo submit -n argo <파일> --wait 로 내고 끝날 때까지 기다립니다.
• argo get -n argo @latest 로 단계별 상태를, argo logs -n argo @latest 로 로그를 봅니다.
• 단계 하나에 90초가 있습니다. 각 워크플로가 그 안에 끝나도록 sleep 을 짧게 잡으세요.
• 흔한 실수: entrypoint 가 가리키는 이름이 templates 안에 없는 것. 그러면 워크플로가 시작조차 하지 못합니다.
• 흔한 실수: DAG 의 시작 노드에 dependencies 를 붙이는 것. 아무도 만족시키지 못해 영원히 대기합니다.

단계 8개

1. 진짜로 돈다
2. 의존성이 순서를 만든다
3. 값을 주고받는다
4. 파일을 다음 단계로 넘긴다
5. 실패하면 다시 해 본다
6. 실패해도 도는 자리
7. 정의를 재사용한다
8. 무엇을 배웠나