Replies: 1 comment 5 replies
-
|
저는 bootstrap 단계의 범위내에서만 생각을 했습니다. (decapod가 ready된 상태 이후에 대한 논의는 목적/요건등이 다르니까요) bootstrap 단계는 decapod 체계를 ready 시키기 위해 간단하고 관리가 쉬운 방식으로 필요한 몇 개의 소프트웨어를 설치하는게 목적이라고 생각합니다. 따라서, 복잡하게 하지 말고 script + helm install 정도로 하는게 좋다고 다들 생각하고 있는 것으로 알고 있습니다. 하지만, 현재 argo-cd, argo-wf, argo-rollout (?), postgresql 등 decapod 체계를 fully ready 시키기 위해 설치되어야 하는 소프트웨어들이 늘어나고 있는 상황에서, 어떻게 하면 이걸 설치도 쉽고, 지속적으로 관리하기 쉽게 할 수 있을까 생각을 하게 되었습니다. 그리고, 현재 논의가 postgresql을 decapod가 설치한 이후에, 다시 decapod 체계내 argo-workflow 설정을 바꾸어 다시 띄우는 이야기도 나오고 있어서, decapod로 설치되는 keyclock + postgresql은 persistent enable전에 설치되는 등, 일관성이 깨어져버리는 것 같이 보여서 이걸 어떻게 해야 할까 고민도 했습니다. 그래서 찾아보다가 생각한 것이, BOOTSTRAP단계에서 우리가 이제 argo-cd라는 배포툴을 설치하게 되었으니 이를 활용하여 설치의 일관성을 최대한 유지하는 방법이 가능하지 않을까 했고, BOOTSTRAP 단계: 새롭게 구성
DECAPOD 단계: 현재와 동일하게 유지 (현재와 같이 만든 이력과 필요성이 달라지지 않았으므로)
이렇게 되면 bootstrap단계에서 설치되는 소프트웨어들도 argo-cd로 관리하게 되는 점이, 앞으로 설치 후 관리를 하는데 더 용이해지고, argo-cd라는 배포툴을 두 단계에서 모두 공통툴로 쓰게 되는 장점이 있다고 생각했습니다. argo-cd 블로그 (self-managed argo cd + app-of-apps) 를 붙힌 이유는 현재 decapod 와의 비교가 아니라, decapod 가 구성되기 전 bootstrap 단계에서도 gitops 방식을 가져갈 수 있는 아이디어로 참조할 수 있을까 함입니다. 참고로, 위에 최태일님이 말씀하신대로 논의를 decapod의 방식과 argo-cd가 말하는 app-of-apps의 비교로 논의를 확장하는 것은 저의 원래 목적은 아니었습니다. |
Beta Was this translation helpful? Give feedback.
-
|
네, bootstrap 범위 내에서 말씀하신 것은 이해를 했었는데, 생각한 김에 조금 범위를 넓혀본 것이었습니다. 그런데 '복잡한 소프트웨어간 의존성 등' 명확한 요구사항이 있다는 걸 잠시 간과했던 것 같으니 다시 원래의 scope대로 bootstrap 쪽에 국한해서 생각하는게 좋을 것 같습니다. 말씀드린 대로 postgresql 설치 순서 때문에 argo-wf 를 persistence 설정 변경하여 다시 띄워야 하는 문제는 설치 순서 조정으로 해결 가능하니 논외로 하고, 결국 argocd 방식으로 하는 게 좋을지 기존의 script 기반 (helm 명령 포함) 으로 하는게 좋을지는 크게 설치의 편의성과 향후 관리성 (이력 관리 등), 이렇게 두가지 측면에서 따져보면 될 것 같습니다. 이 부분은 좀더 고민해보고 의견 남기겠습니다. 다른 분들도 의견 추가해주시면 좋을 것 같구요. |
Beta Was this translation helpful? Give feedback.
-
|
제안하신 방법은 시도해볼만 한 것 같습니다. Argocd로 초기 app들을 bootstrap할 경우, 해당 app들에 대한 decapod-manifest 와 argocd app 등록을 위한 manifest 파일 (meta 파일) 만 준비해놓으면, git push하는 순간 일괄 설치가 될것이고, 향후 재사용성이나 관리 측면에서도 유리한 측면이 있을 것 같습니다. app-of-apps 패턴 외에도 좀더 declarative 한 방법이 될거구요. 사실 단지 app을 1~3개 배포하는 수준에서는 helm을 이용한 설치보다 좀더 overhead가 있다고 느껴질 수 있는데, 향후 bootstrap 대상 app이 추가될 것을 감안하면 해볼만한 투자인것 같습니다. 단, 한가지 해결해야 할 문제는 postgresql 설치 후 argo-wf 가 설치되어야 하는 등 약간의 dependency가 존재하는데 이를 어떻게 해결할지는 고민이 필요합니다. |
Beta Was this translation helpful? Give feedback.
-
|
@bluejayA 님이 말씀하신 방식에 동의합니다. bootstrap단계는 decapod self-managed 방식으로 배포하는 것이 좋을 것 같습니다. |
Beta Was this translation helpful? Give feedback.
-
|
@estherk0 말씀하신 sync-wave를 사용하려면 argo-wf 차트와 postgres chart를 섞던지, 또는 차트는 별도로 두되, decapod transform 과정에서 하나의 manifests repo로 몰아줘야 하는군요 (이때 resource name 중복은 없는지 확인해야 하고..) arcd app 차원에서 repo를 복수개로 지정할 수는 없는 것 같아서요 |
Beta Was this translation helpful? Give feedback.
-
|
일단 차트 수정하는 건 간단치 않은 일이라, dependency 없이 일괄적으로 설치 수행하고, argo-wf에서 postgres가 뜰때까지 계속 접속 시도하며 잠깐 crash 나도록 놔두다가 궁극적으로는 running 상태로 바뀌는 걸 기대하며 테스트해보겠습니다. |
Beta Was this translation helpful? Give feedback.
-
#109 (comment) 에 나오는 논의사항을 discussion으로 이동시켰습니다. 아래에 위 링크에서 진행된 부분만 COPY해 두었습니다.
robertchoi80 3 days ago Author Member
기존 데이터는 어차피 etcd에 들어있을 것이라 pod를 다시 띄운다고 데이터가 유실되진 않겠지만, persistence 옵션을 활성화하기 전의 workflow 데이터도 소급해서 archive를 하는지는 테스트가 필요할 것 같습니다. 근데 만약에 안된다고 해도, 초기 bootstrap 차원의 workflow (- keycloak 및 postgresql 등의 tool들을 설치하기 위한) 정도는 archive 안되어도 큰 문제 없을 것 같긴 합니다.
@bluejayA bluejayA 2 days ago • Member
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 으로 올려야 할 것 같긴 한데.
@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 의 역할이 거의 없어질 만큼 커버리지가 넓어지는 것 같긴 합니다. 간단히 비교해보면:
결국 새로운 app이 추가될 시, wf를 수정 또는 추가할 것인지, 아니면 yaml 포맷의 manifest 를 만들어 push할 것인지 선택의 문제가 될것 같습니다. gitops라는 측면에서는 후자가 좀더 가깝긴 한데, 그외 다른 장단점이 있을 수 있으니, 금주 싱크 때 화두를 던져봄이 좋을 것 같습니다. (근데 전에 에스더님과 app of apps 관련 논의를 하셨던 걸로 기억하는데, 혹시 중복이거나 뒷북이면 죄송합니다)
Beta Was this translation helpful? Give feedback.
All reactions