Cloud-Migrator v0.3.0 릴리스 추진 계획

릴리스 일정 및 대상

릴리스 리드 : (주) 김윤곤, (부) 각 저장소 메인테이너
통합 테스트 및 프리릴리스 목표일: 2024. 11. 14(수)
최종 릴리스 목표일: 2024. 11. 27(수)
릴리스 대상 저장소 (check: 완료)
협업 저장소
- https://github.com/cloud-barista/mc-data-manager

통합 및 연동 테스트 방법 (담당: 전체)

통합 및 연동 테스트 목적 (v0.3.0)

서브시스템간 API 및 GUI를 통해 기능을 유기적으로 수행할 수 있는 통합 시스템 기반 확보
Cloud-Migrator v0.3.0 포함 기능은 올해 풀 스펙을 목표로 함
Cloud-Migrator v0.3.0 단일 플랫폼으로 시연 예정 (11월 초)
Cloud-Migrator 플랫폼 목표치
- 컴퓨팅 인프라 전환을 지원하는 클라우드 마이그레이션 플랫폼 기술 개발
- 3종 클라우드 전환 지원: AWS, Azure, (1종 추후 공유)
- 3종 자원 전환 지원: 물리 서버를 VM으로 전환하기 위한 자원 (목표치 달성 완료, 고도화에 집중)

통합 세부 일정

🔈 일정에 이슈가 있는 경우, 미리 이슈화 및 조율하여 주십시오. 🙏 연관된 API 그룹/세트의 개발이 완료될 때 마다, 상시/소규모 pre-release/release 추진하여 주시길 부탁드립니다. 👉 서브시스템들의 API docs: https://cloud-barista.github.io/api/

완료일정	작업	비고
9/4(수)	예정 API 및 활용 방법 제공, 서브시스템간 API 검토 및 논의	Swagger API v2.0 문서 제공 (실제 구동 여부 무관)
10/8(화)	서브시스템 프리릴리스 및 중간 점검	구현이 완료된 API들에 한해 약식 테스트 및 통합
11/14(수)	서브시스템간 테스트, 통합, 최종 점검 후, 각 서브시스템 저장소 v0.2.x 프리릴리스	Butterfly를 통해 시나리오 구동 확인
11/21(수)	각 서브시스템별 최종 확인/보완 및 각 서브시스템 저장소 v0.3.0 릴리스
11/27(수)	각 서브시스템 저장소 v0.3.0 릴리스 주요 기능 시연 동영상 제작
11/27(수)	Cloud-Migrator 플랫폼 v0.3.0 릴리스

서브시스템간 연간 관계 및 테스트/통합 순서(안)

🤗 다음은 서브시스템간 연관 관계 및 테스트/통합 순서를 간략히 정리한 자료입니다. 참고하시기 바랍니다.

통합 주요 기능 및 관계도

연동 시나리오

(참고) Cloud-Migrator v0.2.0 컴퓨팅 인프라 마이그레이션 테스트/통합 시나리오

[사용자] 컴퓨팅 인프라 마이그레이션
1. 웹 콘솔 접속
2. 소스 컴퓨팅 환경 연결 및 조회
3. 수집기 배포 및 형상 정보 추출/조회 (Raw: 형상 정보 메트릭, Refined: 소스 모델(온프레미스 모델))
4. 컴퓨팅 인프라 목표 모델(클라우드 모델) 추천 활용
  - Input: 소스 컴퓨팅 인프라 형상 정보 메트릭
  - Ouput: 목표 모델(클라우드 모델)
5. 인프라 마이그레이션 워크플로우 템플릿 조회
6. 목표 모델 활용해 인프라 마이그레이션 워크플로우 작성 및 생성
7. 인프라 마이그레이션 워크플로우 실행 및 제어
8. 인프라 마이그레이션 상태 및 현황 확인

Cloud-Migrator v0.3.0 연동 시나리오

[운영자] 환경 구성
1. 서브시스템 구동 가이드에 따라 플랫폼 전체 구동 및 환경 설정
[사용자] 컴퓨팅 인프라 마이그레이션
1. 웹 콘솔 접속
2. 소스 컴퓨팅 환경 연결 및 조회
3. 수집기 배포 및 형상 정보 추출/조회 (Raw: 형상 정보 메트릭, Refined: 소스 모델(온프레미스 모델))
4. 컴퓨팅 인프라 소스 모델(온프레미스 모델) 등록, 수정, 관리 등
5. 컴퓨팅 인프라 목표 모델(클라우드 모델) 등록, 추천, 수정, 관리 등
6. 인프라 마이그레이션 워크플로우 템플릿 조회, 인프라 마이그레이션 워크플로우 작성, 수정, 생성, 등
7. 인프라 마이그레이션 워크플로우 실행 및 제어
8. 인프라 마이그레이션 상태 및 현황 확인
[사용자] SW 마이그레이션 (TBD)
1. 웹 콘솔 접속
2. 소스 컴퓨팅 환경 연결 및 조회
3. 수집기 배포 및 형상 정보 추출/조회 (Raw: 형상 정보 메트릭, Refined; 소스 모델 (SW 모델))
4. SW 소스 모델(Legacy SW 모델) 등록, 수정, 관리 등
5. SW패키지 등록, 조회, 수정, 관리 등
6. SW 목표 모델(???) 등록, 수정 관리 등
7. SW 마이그레이션 워크플로우 템플릿 조회, SW 마이그레이션 워크플로우 작성, 수정, 생성, 등
8. SW 마이그레이션 워크플로우 실행 및 제어
9. SW 마이그레이션 상태 및 현황 확인

통합 시험 목표 및 대상 (TBD)

목표: 3종 클라우드로 3종 자원 전환 지원

🔈 안내: 아래 사항들을 공유 및 논의하기 위한 온라인 회의를 계획하고 있습니다.

소스 컴퓨팅 환경:
- 컴퓨팅 인프라:
  - TBD (종류, 규모, 형상 등)
- SW:
  - TBD (종류, 규모, 형상 등)
목표 컴퓨팅 환경:
- 컴퓨팅 인프라
- 3종 클라우드: AWS, (추가 2종 선정 필요)
- 7종 자원:
  - VM 인프라 6종: VPC/Subnet, SG, SSH key, Public-IP, VM, Disk, 등
- SW:
- TBD (종류, 규모, 형상 등)

저장소별 추진 상세 사항 (담당: 각 저장소 메인테이너)

통합 플랫폼 릴리스

담당: ETRI 멤버

각 장소의 Pre-release v0.2.x 및 통합 테스트 수행사항을 바탕으로 통합 플랫폼 릴리스를 진행

https://github.com/cloud-barista/cloud-migrator 저장소 소스 업데이트 (Git Submodule 활용)
https://github.com/cloud-barista/cloud-migrator 저장소 Readme 및 사용 방법 업데이트
https://github.com/cloud-barista/cloud-migrator 릴리스 관련 문서 업데이트 및 릴리스 생성 (v0.3.0). 끝.

@yunkon-kim 추진 계획 기반으로 테스트 가능한 api들이 있으면 어느 정도 파악이 가능하니 우선 급한 부분은 다음과 같을 것 같습니다.

현재 각 연계 시스템들을 정상적으로 구동을 못 시키고 있어서 아직 연계 기능의 정상 동작 유무 파악이 안되고 있는데 각 기관별로 Docker‐Compose 작성 관련 Wiki 참고해서 제안사항의 내용처럼 각 Framework별로 ETRI Docker Hub 기반 Docker 이미지와 연계된 Docker 이미지(예:MySQL) 기반으로 구동하는 방법에 대한 가이드(README or docker-compose.yaml)의 빠른 처리가 필요 할 것 같습니다.
cm-damselfly의 경우 현재 공개된 API가 없기 때문에 웹에 필요한 화면 기획 및 규모 파악을 위해 가급적 cm-damselfly의 api는 조금 더 빨리 공개되면 좋을 것 같습니다.
API부터 선 공개되더라도 아무런 기능 동작이 없는 것 보다는 가능하면 간단한 연계 테스트가 가능하도록 Dummy 데이터 기반으로 동작했으면 좋겠습니다.
연동 시나리오 범위 확정 및 통합 테스트를 위한 웹 기반의 상세 시나리오를 엑셀 등의 파일을 공유해서 온라인에서 공통으로 작성 필요
기능 테스트를 위한 환경 정보 등록을 비롯하여 전체 Flow가 웹에서 어떤 순서로 진행되는지 각 F/w의 세부 기능 파악이 필요 함.
- xxx 과정에서는 어떤 F/w의 어떤 API를 어떤 식으로 이용하는지와 같은 Flow 상의 연계 API 사용 가이드도 필요 함.
  - 개별 F/w의 API 사용 가이드는 9/4 배포 예정인 사용 가이드에 포함될 것으로 예상함.
- 위 연동 시나리오와 동일할 수도 있지만 연동 시나리오는 큰 틀의 시나리오라서 세세한 기능 테스트가 빠질 수 있기에 , 현재 항목의 경우 개별 기능 테스트에 가까워서 각 기능에 어떤 API가 사용되는지 파악이 필요 함.)

메가존이 필요한 것 요약

ETRI Docker Hub에 Push된 Docker Image & ETRI Docker Hub에 Push된 Image기반 사용법(docker-compose.yaml)
API 및 API 활용 순서와 세부 사용 방법
환경 설정부터 각 F/w간의 세부 Flow및 API 관계 [서브시스템간 연간 관계 및 테스트/통합 순서(안)] / [통합 주요 기능 및 관계도]가 일부 관련 설명이 될 듯
웹 기반 테스트 시나리오

@yunkon-kim

cb-spider

cb-spider 관련하여 Azure의 경우 현재 Deprecated 된 SDK가 사용중임에 따라 공식 가이드에 맞춰 개발하는데 어려움이 있거나 현재 사용중인 SDK에서 사용이 불가능한 경우가 다수 존재합니다. 따라서, 추후 개발 용이성을 위해 신규 SDK를 적용하여 테스트 후 PR 진행 상태입니다. https://github.com/cloud-barista/cb-spider/pull/1275

cm-grasshopper

grasshopper 의 경우 소프트웨어 저장소를 따로 두기 보다 마이그레이션 관점으로 보고 소프트웨어 별로 Ansible과 SSH, OS별 패키지 매니저 (apt, yum)을 활용 SQLite에 소프트웨어 별로 등록하고, 매칭 될 수 있는 이름 목록을 같이 등록할 수 있도록 하려고 합니다

예로 telegraf 를 설치하려고 할때 Ansible로 등록된 telegraf가 있으면 대상 노드에 Ansible을 통해 설치 할 수 있도록 하고,

apache2 를 설치한다고 할 경우 SQLite DB에 소프트웨어 명은 apache2로 등록하고 설치 방식은 패키지 매니저 사용, 매칭될 수 있는 이름: httpd, apache, apache2 와 같이 저장하여

설치하고자 하는 목록중에 httpd, apache, apache2 중 하나가 매칭 될 경우 패키지 매니저를 통해 설치가 진행될 수 있도록 하는 방안으로 진행하려고 합니다

사용자 스크립트도 비슷한 방식으로 등록 가능할 것으로 보입니다.

Ansible에서 K8S 및 Helm 제어가 지원이 되긴 하지만 K8S와 관련해서는 세부 구조및 구동 방법 파악을 위해서 시간을 좀 더 투자할 필요가 있어보입니다.
grasshopper 에서 Conatainer 및 K8S 기반 마이그레이션 수행 시 목표 환경에서는 모두 K8S로 마이그레이션을 진행할지 아니면, Container -> Container, K8S -> K8S 로 그대로 마이그레이션 할 지 논의가 필요할 것 같습니다.
또한, K8S 환경을 마이그레이션 한다고 할 때, 많은 제약 사항이 발생할 것 같습니다. 예로 간단하게 Pod 관점에서 마이그레이션을 수행하는 것은 간단하게 컨테이너 마이그레이션과 비슷하게 진행 되겠지만, 그 외 커스텀 리소스, 서비스, 인그레스 등 복잡성을 요구하는 리소스들에 대해서는 많은 고민이 필요할 것 같습니다.
Helm의 경우에도 간단하게 helm repo 등록 -> 설치 는 간단하게 진행될 수 있갰지만, values.yaml 을 수정하거나 그 외 커스텀을 요구하는 경우에는 별도로 고민해볼 필요가 있을것 같습니다.

안녕하세요. 현재 (2024-08-12) 기준 ant 에서 테스트 한 csp 는 다음과 같습니다.

AWS, AZURE, GCP, ALIBABA, TENCEN, IBM

해당 링크에 spider 의 price info 관련 지원 현황 정보가 나와있습니다.

AZURE 와 IBM 의 경우 일부 spec 정보를 미지원하는 이슈가 있습니다. 테스트 진행한 azure 와 ibm 의 경우 지원하는 spec 정보에 대해서 테스트를 진행한 것으로 파악됩니다.

cloud-barista / cloud-migrator

Cloud-Migrator v0.3.0 release #11