the development scope of mc-application-manager and the relationship between the mc-application-manager and the mc-workflow-manager

[sykim-etri]

Originally written by @pbcccbeatboard-strato.

• 용어 정리
  (취지) 취지 중 하나는 jenkins라는 OSS가 가지는 기 인지된 부분에서의 파생링크를 줄여보고자 함이 크며, 다른 의도로는 현재 형상 이후 타 OSS 또는 자체 제작된 기능을 활용할 경우에도 현재와 통일된 용어를 가져가고, mc-AM과 mc-WM에서 활용하는 부분(현재 해당 앱 외 부분)의 개념적 분리 및 명명

  • mc-AM: m-cmp application-manager
  • mc-WM: m-cmp workflow-manager
  • APE(AM-APE): application provisioning engine - provisioner로 하려했으나 AP 축약어 회피
  • WE(WM-WE): workflow engine - 설계서의 메모를 참고

• application 등록 시 기본적으로 제공하는 설치(packageManager 이용 등)과정이 아닌 특정 행위가 필요할 경우 APE에 해당 과정을 설정하는 과정에 대한 이슈

  • APE에 설정된 특정 이벤트(jenkins job)를 mc-AM에 연동하여 사용하는것을 제공하나, APE에 설정하는 과정에 대한 기능등의 제공은 현재 형상의 mc-AM에 포함되지 않음
  • (현재 형상기준)APE는 jenkins를 사용하므로 WE를 jenkins로 활용하는 mc-WM를 활용하여 해당 APE에 특정 행위를 위한 단위(jenkins job(workflow))를 설정할 수 있으나, 두 application에서 설정된 엔진의 동일함을 이용한 응용범위의 활용임
  • 위의 내용에 따라 APE/WE로 활용되는 jenkins는 mc-AM과 mc-WM의 각자용도로 설치 또는 단일 설치 후 통합사용 가능
  • 통합용도로 단일설치 및 설정하여 사용할 경우 연계활용이 가능하나 workflow의 혼재사용, 운용적 종속성 이슈 존재
  • 각개용도로 각개설치 및 설정하여 사용할 경우 독립성이 보장되나 mc-AM에서 활용을 위한 APE에 단위 행위를 설정하는데에 대한 인터페이스 제공은 부재
  • mc-WM의 경우 자체적으로 설정된 workflow정보들은 내부적으로 관리하므로 WE(APE)에 직접 접근하지 않는 한 독립적인 운영이 가능
  • APE, WE가 서로 달라지는등의 가능성 및 관련계획이 있(었)으므로 APE/WE를 통합사용하는것은 권장하지는 않으나, 단일 설치로 리소스를 절약할 수 있으므로 설치/운영자 판단에 맡김

• CI/CD 관련

  • 고려 범위가 아님. mc-WM의 활용범위 차원에서의 git event등의 연계활용 예시 중 하나이며, 현재 형상 상 WE가 jenkins이기 때문에 해당 OSS의 주 활용방법에서 파생된것으로 인지 중

• jenkins 유용성 검토

  • 현재 jenkins의 APE, WE로 사용되는 주 역할은 ssh를 활용한 linux command 전달로 타 OSS(ansible 등)를 활용하는 것도 가능하며, 해당 기능은 CB-TB api(MCIS remote command 등) 및 추가VM 등을 활용한 command 실행 및 관리 모듈을 신규 제작하여 활용을 염두하고 있었으나 내부 협의 결과 기 사용 중인 젠킨스 유지로 결정
  • 현재 진행 현황 상 이번 릴리즈에서 해당부분을 변경하는것은 무리로 판단
  • 타 OSS활용이나 자체 모듈의 제작 및 활용(APE의 다양화 또는 OSS의존성 제거)은 추후 버전 진행 시 신규 담당자의 의견과 내부 조율을 통해 확장 또는 유지 등을 협의

• 0.3.0 통합형상에 있는 mc-WM과 mc-AM의 web server는 삭제 가능(각 app에서 webUI 자체 제공)

[sykim-etri]

• application 등록 시 기본적으로 제공하는 설치(packageManager 이용 등)과정이 아닌 특정 행위가 필요할 경우 APE에 해당 과정을 설정하는 과정에 대한 이슈
  • APE에 설정된 특정 이벤트(jenkins job)를 mc-AM에 연동하여 사용하는것을 제공하나, APE에 설정하는 과정에 대한 기능등의 제공은 현재 형상의 mc-AM에 포함되지 않음

이번 릴리즈에 포함될 수는 없겠지만 사용자가 mc-AM을 통해 애플리케이션 활용을 위해 필요한 설정 정보들은 관리할 수 있어야 하지 않을까요?

• jenkins 유용성 검토
  • 현재 jenkins의 APE, WE로 사용되는 주 역할은 ssh를 활용한 linux command 전달로 타 OSS(ansible 등)를 활용하는 것도 가능하며, 해당 기능은 CB-TB api(MCIS remote command 등) 및 추가VM 등을 활용한 command 실행 및 관리 모듈을 신규 제작하여 활용을 염두하고 있었으나 내부 협의 결과 기 사용 중인 젠킨스 유지로 결정
  • 현재 진행 현황 상 이번 릴리즈에서 해당부분을 변경하는것은 무리로 판단
  • 타 OSS활용이나 자체 모듈의 제작 및 활용(APE의 다양화 또는 OSS의존성 제거)은 추후 버전 진행 시 신규 담당자의 의견과 내부 조율을 통해 확장 또는 유지 등을 협의

WE로서는 jenkins가 당연히 적합하겠지만 APE로서의 적합성에 대해 다음 릴리즈에 보다 심도 있게 검토해야 할 부분으로 생각됩니다.

• 0.3.0 통합형상에 있는 mc-WM과 mc-AM의 web server는 삭제 가능(각 app에서 webUI 자체 제공)

mc-WM과 mc-AM 각각에서 WebUI를 제공하는 것으로 이해하면 될까요?

[pbcccbeatboard-strato]

이번 릴리즈에 포함될 수는 없겠지만 사용자가 mc-AM을 통해 애플리케이션 활용을 위해 필요한 설정 정보들은 관리할 수 있어야 하지 않을까요?

• 고민중에 있습니다. 범위나 처리방법등에 대한 논의가 내부적으로 계속 이루어 지고 있는 상황이라 구체적으로 상의할 수준이 되면 관련내용을 게시하여 소통할 수 있도록 전달하겠습니다.

WE로서는 jenkins가 당연히 적합하겠지만 APE로서의 적합성에 대해 다음 릴리즈에 보다 심도 있게 검토해야 할 부분으로 생각됩니다.

• 내부에서도 인지하고있는 내용으로 APE에대한 결정은 생각보다 쉽지 않네요. 위의 경우는 제가 제시했던 내용이 여러 이유로 통과되지 못했던 것 뿐이며, 현 작업자분이 개발하며 기능이나 타 내용에 의한 판단하에 유지/변경정책을 제시예정입니다. 다음 릴리즈 초기에 다시 한번 이슈업 요청드립니다.

mc-WM과 mc-AM 각각에서 WebUI를 제공하는 것으로 이해하면 될까요?

• 네 각각 ui를 제공할 예정입니다. 지난 워크샵의 경우 기존 내용의 이해도 부족과 이전 작업상황에 맞추어 임시적으로 구현되었던 것이며, 현재는 mc-AM과 mc-WM의 각 필요기능들에 대한 webUI를 각자 제공합니다. 해당 어플리케이션에서 직접 제공하는 이유는 리소스(관리 컨테이너 갯수 및 소스 등)등에 따른 편의성이 주된 포인트입니다.
  jsp등을 활용하는것이 아닌, springBoot의 정적리소스를 제공할 수 있는 경로에 Vue.js등을 이용한 ui를 저장하여 사용자에게 제공합니다.