초록 파이프라인의 사라진 파일을 추적한다

목표

업무 성공과 산출물 보존·정리 성공을 구분하고, 충돌 없는 키와 최소 권한으로 검증합니다.

왜 중요한가

업무가 성공해도 최종 파일이 사라지거나 중간 파일이 계속 쌓일 수 있습니다. 이 실습은
VM 안의 실제 Argo Workflows 4.1.3과 SeaweedFS 4.46을 사용합니다. 화면의 성공 표시가
아니라 실행 UID와 실제 파일 바이트, GC의 오류를 함께 확인합니다. 기본 클러스터와
저장소는 자동 준비되고, 학생은 정책을 수정하거나 비교 시나리오를 직접 실행합니다.

단계

1. argo 네임스페이스의 artifact-repositories와 Service seaweed를 읽으세요. /root/capa-artifacts/inventory.json에 namespace=argo, endpoint=seaweed:8333, writer_bucket=artifacts, anonymous_allowed=false를 기록합니다. 채점은 실제 허용 계정의 파일 읽기, 익명 요청과 다른 팀 버킷 접근 거절도 대조합니다.
2. 준비된 /root/capa-artifacts/isolated.yaml의 produce 출력 두 개에서 s3.key만 고칩니다. temporary는 runs/{{workflow.uid}}/temp.txt, final은 runs/{{workflow.uid}}/final.json입니다. 나머지 파이프라인과 최종 Never는 유지하고 실험 도우미로 isolated를 실행하세요. 서로 다른 두 Workflow의 UID와 최종 파일 내용을 비교합니다.
3. isolated 두 실행의 완료 후 저장소를 확인합니다. /root/capa-artifacts/retention.json에 business=Succeeded, temporary=deleted, final=retained, final_policy=Never를 기록합니다. 두 최종 파일의 생산 UID가 다르고 A의 정리 시점에 B의 입력은 살아 있었는지 실험 기록도 확인하세요.
4. 준비된 missing-retain.yaml은 최종 artifact의 Never를 일부러 뺐습니다. 도우미로 missing-retain을 실행한 뒤 /root/capa-artifacts/missing.json에 business=Succeeded, final_present=false, fix=Never를 기록하세요. 이 비교 실행의 YAML을 정상 정책으로 바꾸지 않습니다. 오류 원인과 고칠 필드를 설명하는 단계입니다.
5. 준비된 gc-denied.yaml은 Role 없는 GC 계정 gc-denied를 사용합니다. 도우미로 gc-denied를 실행하고 /root/capa-artifacts/gc-error.json에 business=Succeeded, condition=ArtifactGCError, cause=RBAC, force_finalizer=false를 적습니다. 실제 forbidden 로그와 남은 두 파일을 읽고, finalizer를 지우지 않습니다.
6. /root/capa-artifacts/gc-binding.yaml에 RoleBinding capa-gc-repair를 작성·적용하세요. 네임스페이스는 argo, roleRef는 apiGroup=rbac.authorization.k8s.io, kind=Role, name=artifact-gc이고 subjects는 argo의 ServiceAccount gc-denied 하나입니다. 기존 Role을 넓히지 말고 gc-repaired.yaml로 새 실행을 확인합니다. 원래 실패 Workflow의 기록과 finalizer는 보존합니다.
7. collision.yaml의 shared/{{workflow.parameters.batch}} 키를 유지하고 도우미로 collision을 실행하세요. A의 입력이 B의 UID로 덮이고 A가 실패한 뒤, A의 GC가 B의 입력을 지워 B도 실패하는지 확인합니다. 두 Workflow의 Failed/Error는 이 비교의 기대 결과입니다. 단순히 파일을 지워 실패를 흉내 내지 않습니다.
8. on-deletion.yaml은 OnWorkflowDeletion과 최종 Never를 함께 사용합니다. 도우미로 on-deletion을 실행하세요. 도우미는 성공 직후 파일을 관측하고, 정확한 Workflow UID를 확인해 그 Workflow만 삭제한 뒤 다시 관측합니다. 업무 완료 때는 두 파일이 있고 삭제 뒤에는 최종 파일만 남아야 합니다.
9. /root/capa-artifacts/report.json에 lost_result_uid는 missing-retain의 실제 UID, gc_failure_uid는 gc-denied의 실제 UID를 적습니다. same_business_status=true, same_storage_result=false, status_is_retention_proof=false를 기록하세요. 두 Succeeded가 왜 다른 조치를 요구하는지 실제 파일 상태와 오류 계층을 근거로 설명합니다.

참고

• 준비된 YAML은 /root/capa-artifacts/에 있습니다. 2단계의 두 key 외에는 비교에 필요한

잘못된 설정을 지우지 마세요. 각 단계 카드에 정확한 변경·관측 항목이 있습니다.

• 실행: python3 /opt/fixtures/capa-lifecycle/runtime.py run isolated /root/capa-artifacts/isolated.yaml

다른 시나리오도 같은 형식이며 이름은 해당 YAML의 파일명에서 .yaml을 뺀 것입니다.

• 상태: python3 /opt/fixtures/capa-lifecycle/runtime.py status isolated
• status가 보여 주는 attempt의 전후 관측 원문은

/var/lib/labhub/capa-lifecycle/attempts/<attempt>.json에 있습니다. before는 생산 후,
after는 소비·정리 후, while_a_finished는 A가 끝났을 때 B의 상태입니다.
학생 답안이 아니라 도우미의 관측 기록이므로 직접 편집하지 않습니다.

• 실제 실행 조회: kubectl -n argo get workflow WORKFLOW_NAME -o yaml

실제 파드 조회: kubectl -n argo get pods -l workflows.argoproj.io/workflow=WORKFLOW_NAME
로그 조회: kubectl -n argo logs POD_NAME --all-containers=true
WORKFLOW_NAME과 POD_NAME은 앞 명령으로 찾은 실제 이름으로 바꿉니다.

• 저장소 목록: kubectl -n argo exec store-admin -- mc --config-dir /tmp/mc ls --recursive store/artifacts/

파일 읽기: kubectl -n argo exec store-admin -- mc --config-dir /tmp/mc cat store/artifacts/runs/<UID>/final.json
store-admin은 이 VM 안의 관측용 관리 도구입니다. 업무 업로드와 GC는 별도의
artifact-writer 계정을 사용하며, 1단계는 그 계정의 버킷 제한을 검사합니다.

• 관측 시간이 끝나도 실행은 계속될 수 있습니다. 같은 작업을 wait isolated로 확인하고,

살아 있는 작업을 중복 생성하지 마세요. 같은 YAML의 완료 기록은 재사용합니다.
종료된 실험을 의도적으로 새로 비교할 때만 run에 --new-attempt를 붙입니다.

• 도우미는 업로드 후 일시정지·관측·소비 재개를 수행합니다. 실행 도우미의 완료는

정답 통과가 아닙니다. 잘못된 YAML로 끝난 실행은 채점에서 거절됩니다.

• kubectl에는 KUBECONFIG=/etc/rancher/k3s/k3s.yaml을 사용합니다. argo CLI에는

--kubeconfig=/etc/rancher/k3s/k3s.yaml을 명시하면 홈 디렉터리에 의존하지 않습니다.

• 저장소 HTTP와 emptyDir는 폐기 가능한 실습용입니다. 세션이 끝나면 파일과 VM이

모두 회수됩니다. Never도 세션 종료를 넘어 보존하거나 백업하는 기능은 아닙니다.

단계 9개

1. 정상 읽기와 거절할 읽기를 구분
2. 두 실행의 산출물 키를 분리
3. 중간 파일을 지우고 최종 결과는 보존
4. 최종 보존을 빠뜨린 성공 분석
5. 업무 성공과 GC 권한 실패 분리
6. 최소 GC 권한으로 새 실행 검증
7. 공유 키가 만드는 두 번의 실패
8. 완료 시점과 삭제 시점 비교
9. 같은 성공에 숨은 다른 저장 결과 보고