Upgrade argo-workflow to v3 #109
Conversation
to make sure only one flag is set
hanu-jenkins
force-pushed
the
dev_upgrade_argo
branch
from
aa6b28a to
bc370d2
Compare
robertchoi80
changed the title
|
test this please |
|
test this please |
| shell: >- | ||
| {{ bin_dir }}/helm install argo {{ argo_chart_source }} -n argo \ | ||
| --set workflowArchive.enabled={{ argo_workflow_archive_enabled }} \ |
There was a problem hiding this comment.
아래를 참고해서 value file 만들고 override하는 방식으로 바꾸는게 어떨까요? (cd는 이미 그렇게 적용됨)
There was a problem hiding this comment.
네 저도 생각 중이던 부분이, 그렇게 고치면 하나의 template만 사용해서 조건문으로 분기 가능할 듯 하고, 두개의 task 파일도 그냥 하나로 합치고 when 절로 분기해서 install 또는 upgrade 명령 수행하면 더 깔끔하겠네요
| @@ -0,0 +1,46 @@ | |||
| --- | |||
There was a problem hiding this comment.
기존에 workflow 작업한 내용이 db로 옮겨져야 할것 같은데..
helm upgrade를 통해 작업하면 옮겨주는 것이 포함되는 건가요?
There was a problem hiding this comment.
기존 데이터는 어차피 etcd에 들어있을 것이라 pod를 다시 띄운다고 데이터가 유실되진 않겠지만, persistence 옵션을 활성화하기 전의 workflow 데이터도 소급해서 archive를 하는지는 테스트가 필요할 것 같습니다. 근데 만약에 안된다고 해도, 초기 bootstrap 차원의 workflow (- keycloak 및 postgresql 등의 tool들을 설치하기 위한) 정도는 archive 안되어도 큰 문제 없을 것 같긴 합니다.
There was a problem hiding this comment.
argo-cd와 argo-workflow가 이제 모두 설치가 되고 있고, argo-workflow 설치시에 persistent option때문에 postgresql 설치가 필요한 상황이고, decapod로 keycloak설치시 postgresql 설치 되니 이를 연동하면서 persistence option을 나중에 enable 시키는 경우인데, 혹시 아래와 같이도 가능할까요?
argo-cd 설치 -> (이후에는 모두 argo-cd로 설치)
-> argo-cd로 argo-workflow & postgresql 설치
-> argo-cd로 decapod 체계를 갖추기 위해 필요한 (있다면) 소프트웨어 설치
decapod 시스템 설치 완료
-> 이후, decapod 기준으로 설치
이렇게 되면, 최초 decapod 구성을 위해서 필요한 모든 것들이 gitops 방식으로 argo-cd로 설치되어 관리될 수 있음.
그리고, decapod구성을 위해 설치를 해야 하는 것들도 app of apps pattern 을 따를 수도 있을 듯 하고.
https://medium.com/devopsturkiye/self-managed-argo-cd-app-of-everything-a226eb100cf0 > 이런 블로그도 있네요
@robertchoi80 @zugwan 제가 가능하고 유용한 아이디어를 말씀드리는건지 확인 부탁드려요
이게 여기 커맨트가 아니라 별도 discussion 으로 올려야 할 것 같긴 한데.
There was a problem hiding this comment.
@bluejayA 네, discussion이 좋긴 하겠네요. 일단은 discussion으로 가기 전에 임시로 간단히 의견 남기자면,
기존의 체계를 최대한 유지하면서 task 수행을 하려고 위 로직처럼 작성하였으나, 의견을 주신 김에 다시 근본적으로 생각을 해보았습니다. 말씀하신 내용은 크게 두가지 범위로 나누어 생각하면 좋을 것 같습니다.
우선 초기 bootstrap 단계에서의 postgresql 설치에만 국한해서 생각해보면, 굳이 나중에 설치될 keycloak 차트에 의존할 게 아니라 argo-wf 설치시 함께 설치해버리고 반대로 keycloak 쪽에서 이를 같이 사용한다고 하면 좀더 심플해지며, 말씀하신 argo-cd 로 설치하거나 또는 단순히 "helm install" 커맨드로도 가능할 것 같습니다. argocd로 하는게 gitops 방식으로 이력 관리에 좀더 유리하긴 하나, 어차피 최초에 argocd 설치를 helm 차트로 한다면 같은 방식으로 app을 1~2개 (postgres & argo-wf) 더 설치하는 건 큰 무리는 아닐 것 같구요. 이보다는 다음 내용 관련하여 좀더 큰 임팩트가 있지 않을까 생각이 듭니다.
다음은, 이게 좀더 근본적인 고민인데, (공유해주신 링크 참고하여) argocd를 이용한 "app of apps" 패턴을 아예 모든 app들에 대해 폭넓게 사용한다면, 사실 argo-workflow 의 역할이 거의 없어질 만큼 커버리지가 넓어지는 것 같긴 합니다. 간단히 비교해보면:
- 현재의 방식: argocd 에 app을 등록하는 스크립트 형태의 코드가 argo-wf template 형태로 만들어져있고, 이것을 다시 app name 등 파라미터와 함께 호출하는 wf 를 실행하는 방식
- argocd 방식: argocd 에 추가할 app을 manifest 형태로 git에 push하면 argocd가 자동으로 app을 등록하는 방식
결국 새로운 app이 추가될 시, wf를 수정 또는 추가할 것인지, 아니면 yaml 포맷의 manifest 를 만들어 push할 것인지 선택의 문제가 될것 같습니다. gitops라는 측면에서는 후자가 좀더 가깝긴 한데, 그외 다른 장단점이 있을 수 있으니, 금주 싱크 때 화두를 던져봄이 좋을 것 같습니다. (근데 전에 에스더님과 app of apps 관련 논의를 하셨던 걸로 기억하는데, 혹시 중복이거나 뒷북이면 죄송합니다)
There was a problem hiding this comment.
#110 에 discussion 만들었습니다.
|
방향을 바꾸어 argocd 패턴으로 리팩토링 진행 중이기에 본 PR은 close합니다 |
Argo-workflow 를 v3로 업그레이드함.
argocd와 마찬가지로 upstream chart를 사용하며, postgres DB 연동 여부에 따라 task를 두가지로 구분함
-argo.yml : DB 연동 없이 argo 설치 (decapod_enabled 시 수행)
-argo_with_db.yml : DB 연동하도록 config 추가하여 기존 helm release를 upgrade (decapod_with_db_enabled 시 수행)
초기 구축 시는 DB 없이 설치하고, decapod를 통해 keycloak 및 postgres 등이 설치되고 나면 위의 flag만 바꾸어서 다시 DB 연동 작업을 추가 수행하는 flow임
둘 중 하나의 flag만 true가 되도록 validation 로직 집어넣음.