k8s 환경만 있다면 Argo 설치는 간단했습니다.

Argo 설치

kubectl create namespace argo
kubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo/stable/manifests/install.yaml

네임스페이스(argo)를 만들고

yaml 파일을 apply 하면 끝 입니다.

Argo 설치 후 Pod 확인

kubectl get pod -n argo
NAME                                   READY   STATUS    RESTARTS   AGE
argo-server-55f5985454-gwlkv           1/1     Running   60         6d11h
workflow-controller-7dffbf956c-nv8vn   1/1     Running   0          6d11h

그리고 생성한 네임스페이스에 떠있는 pod을 확인해보면

두가지가 있는데(이전에 생성했던거라 AGE가 올라가 있습니다)

argo-server, workflow-controller 입니다.

Argo-Server

argo-server는 argo-ui로 기본적으로 2746을 포트로 하고 있고 브라우저를 통해 접속해보면

flow를 작성해서 submit 한다거나 모니터링이 가능합니다.

최근 2.5에서는 cron도 추가 된것을 확인 할 수 있습니다.

보통 저는 사용이 필요할때

kubectl -n argo port-forward deployment/argo-server 2746:2746

커맨드를 통해서 포트포워딩 하여 활용하고 있습니다.

Workflow-Controller

workflow-controller는 argo에서 사용하는 crd(커스텀 리소스)인 wf(WorkFlow)나 cwf(cronWorkFlow) 를 처리 합니다

Argo 기능들

Argo는 Step과 DAG(그래프 방식) 지원하지만

추가적인 기능들도 제공하고 있습니다.

추후 Argo를 통해 제공해야할 업무가 있어서

추가적인 기능들을 하나씩 파악하며 예제를 돌려보았습니다.

suspend & resume
- suspend 초, 분, 시, 일 단위 가능, 시간을 안주면 approve 방식으로도 가능
- resume은 UI에서 가능, argo cli에서도 가능

retry
- 재처리 duration(s,m,h,day)
- maxDuration, 이 시간동안 성공안하면 실패
- limit 

exit-handlers
- 워크플로우 상태에 따라 처리할수 있도록, {{workflow.status}}
- 마지막 종료 실패 결과를 운영자에게 알리기 위해서 주로 활용할듯 함(이메일, SMS)

volumeMounts
- 기존에 만들어둔 Volume을 마운트 시키거나, Flow내 LifeCycle을 갖는 Volume을 마운트 하여 Step간 파일 전달

Daemon Containers
- 워크 플로우가 실행되는 동안 사용될 컨테이너를 실행할 수 있음
- Step중에 Daemon으로 설정하게 되면 해당 Pod은 내려가지 않고 다음 Step 실행

Sidecars
- 실행하는 Step의 Pod에 sidecar(한 pod 안에 같이 뜨는 컨테이너)를 지정할 수 있음

이미지 출처 : https://github.com/argoproj/argo/blob/master/docs/architecture.md

업무상 필요에 의해 

Container 기반 WorkFlow 엔진을 알아볼 필요가 있었습니다.

(배치의 Flow에 활용할까? 하는 부분 때문이죠)

물론 짧은 시간동안 알아봤기 때문에 깊이는 부족하지만 기억력이 좋지 않아 글로 남깁니다.

Argo(프로젝트 중 WorkFlow, https://github.com/argoproj/argo) 

vs

AirFlow(https://airflow.apache.org/)

Argo는 Container 기반, 즉 단계마다 KubeContainer를 각각 띄움

AirFlow는 AirFlow 서버가 떠있다 가정하고(airflow scheduler) 동작하는것으로 보여

필요한것은 Kube 기반이 필요했기 때문에 Argo를 살펴봤습니다.

Argo는 KubeFlow에도 활용되고 오픈소스 컨테이너 워크 플로우로 

Go로 작성 되어있습니다.

설치하는 부분을 살펴보면 workFlow를 처리하기 위한 커스텀 컨트롤러(workflow-controller) 를 설치하는 부분들이 나오고

(https://argoproj.github.io/docs/argo/docs/getting-started.html)

실제 workFlow를 사용하는것도 yaml파일에 kind를 Workflow(커스텀 리소스)를 활용해서 동작합니다.

Argo는 WorkFlow 기능을 제공하는 만큼 다양한 기능들을 제공하는데

(https://argoproj.github.io/docs/argo/examples/README.html)

단순 Flow를 위한 Step이나 더 복잡한 flow처리를 위한 DAG, 

종료에 따른 Flow처리를 위한 Condition 등 많은 기능들을 살펴보고 있는데

(사실.. 이 각 부분은 추가로 살펴볼 부분이...없...)

추가로 살펴볼 예정인것은 artifact 부분인데, 앞에 실행한 output 들에 대해

다른 Job을 처리시 넘겨주거나 할때 artifact를 통해 처리하는것 같아 보이고

(아직은 확실하지는 않지만..)

artifact storage로 'Minio'(Open Source Object Storage server) 라는 것들 지원한다고 합니다..

음.. 오브젝트 스토리지라...

저장소긴 한데.. Minio가 뭘해주는지 Job간 어떻게 데이터를 전달하는지 추가로 봐야할듯 합니다..

일단은.. 여기까지..