-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade argo-workflow to v3 #109
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,46 @@ | ||
--- | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 기존에 workflow 작업한 내용이 db로 옮겨져야 할것 같은데.. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 기존 데이터는 어차피 etcd에 들어있을 것이라 pod를 다시 띄운다고 데이터가 유실되진 않겠지만, persistence 옵션을 활성화하기 전의 workflow 데이터도 소급해서 archive를 하는지는 테스트가 필요할 것 같습니다. 근데 만약에 안된다고 해도, 초기 bootstrap 차원의 workflow (- keycloak 및 postgresql 등의 tool들을 설치하기 위한) 정도는 archive 안되어도 큰 문제 없을 것 같긴 합니다. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. argo-cd와 argo-workflow가 이제 모두 설치가 되고 있고, argo-workflow 설치시에 persistent option때문에 postgresql 설치가 필요한 상황이고, decapod로 keycloak설치시 postgresql 설치 되니 이를 연동하면서 persistence option을 나중에 enable 시키는 경우인데, 혹시 아래와 같이도 가능할까요? argo-cd 설치 -> (이후에는 모두 argo-cd로 설치) 이렇게 되면, 최초 decapod 구성을 위해서 필요한 모든 것들이 gitops 방식으로 argo-cd로 설치되어 관리될 수 있음. @robertchoi80 @zugwan 제가 가능하고 유용한 아이디어를 말씀드리는건지 확인 부탁드려요 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @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 관련 논의를 하셨던 걸로 기억하는데, 혹시 중복이거나 뒷북이면 죄송합니다) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. #110 에 discussion 만들었습니다. |
||
- name: install argo-workflow chart with persistence config | ||
shell: >- | ||
{{ bin_dir }}/helm upgrade argo-workflow {{ argo_workflow_chart_source }} -n argo \ | ||
--set controller.image.registry={{ argo_workflow_controller_image_registry }} \ | ||
--set controller.image.repository={{ argo_workflow_controller_image_repo }} \ | ||
--set executor.image.registry={{ argo_workflow_executor_image_registry }} \ | ||
--set executor.image.repository={{ argo_workflow_executor_image_repo }} \ | ||
--set server.image.registry={{ argo_workflow_server_image_registry }} \ | ||
--set server.image.repository={{ argo_workflow_server_image_repo }} \ | ||
--set server.serviceType={{ argo_workflow_server_service_type }} \ | ||
--set controller.persistence.postgresql.host={{ argo_workflow_controller_persistence_postgres_host }} \ | ||
--set controller.persistence.postgresql.port={{ argo_workflow_controller_persistence_postgres_port }} \ | ||
--set controller.persistence.postgresql.database={{ argo_workflow_controller_persistence_postgres_database }} \ | ||
--set controller.persistence.postgresql.tableName={{ argo_workflow_controller_persistence_postgres_tablename }} \ | ||
--set controller.persistence.postgresql.userNameSecret.name={{ argo_workflow_controller_persistence_postgres_secret }} \ | ||
--set controller.persistence.postgresql.userNameSecret.key="username" \ | ||
--set controller.persistence.postgresql.passwordSecret.name={{ argo_workflow_controller_persistence_postgres_secret }} \ | ||
--set controller.persistence.postgresql.passwordSecret.key="password" \ | ||
--set controller.persistence.nodeStatusOffload={{ argo_workflow_offload_enabled }} \ | ||
--set controller.persistence.archive={{ argo_workflow_archive_enabled }} | ||
become: false | ||
|
||
- name: wait for argo pods become ready | ||
shell: >- | ||
{{ bin_dir }}/kubectl wait --namespace=argo --for=condition=Ready pods -l app.kubernetes.io/name={{ item }} --timeout=600s | ||
become: false | ||
delay: 10 | ||
retries: 3 | ||
with_items: | ||
- argo-workflows-server | ||
- argo-workflows-workflow-controller | ||
register: argo_pods_result | ||
until: argo_pods_result is not failed | ||
|
||
- name: check argo client exists | ||
stat: | ||
path: "{{ bin_dir }}/argo" | ||
register: stat_result | ||
|
||
- name: install argo client | ||
shell: >- | ||
cd /tmp && curl -sLO {{ argo_client_url }} && gunzip {{ argo_client_binary_name }}.gz && chmod +x {{ argo_client_binary_name }} && mv ./{{ argo_client_binary_name }} {{ bin_dir }}/argo | ||
become: true | ||
when: not stat_result.stat.exists | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
아래를 참고해서 value file 만들고 override하는 방식으로 바꾸는게 어떨까요? (cd는 이미 그렇게 적용됨)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
네 저도 생각 중이던 부분이, 그렇게 고치면 하나의 template만 사용해서 조건문으로 분기 가능할 듯 하고, 두개의 task 파일도 그냥 하나로 합치고 when 절로 분기해서 install 또는 upgrade 명령 수행하면 더 깔끔하겠네요