Nexus3 활용 가능성 검토

[ish-hcc]

1. Nexus3 라이선스 확인

• Nexus OSS

  • Repository: https://github.com/sonatype/nexus-public

  • EPL-1.0 license

    • https://github.com/sonatype/nexus-public?tab=EPL-1.0-1-ov-file#readme

• EPL-1.0 license 관련 사항

  • 사용자는 수정하지 않은 바이너리 파일 또는 바이너리 패키지 형태로 제 3자에게 배포할 목적으로, EPL-1.0 라이선스의 소프트웨어를 획득하였다. 이러한 경우, 독립적인 단위 또는 임베디드 단위로서, 사용자가 프로그램, 애플리케이션, 서버, 코드일부, 모듈, 라이브러리 또는 플러그인을 배포하는 것에 문제가 없다.

  • 라이선스 관련 참고

    • https://www.olis.or.kr/license/Detailselect.do?lId=1438&mapCode=010326
    • https://www.oss.kr/oss_guide/show/7eba9fa1-af46-4b72-b7b0-3f5e8ab78e26

  • Nexus3 자체의 소스 코드 수정 없이 사용을 하기 때문에 사용가능한 것으로 판단

2. Nexus3 API 호출 Golang 라이브러리 라이선스 확인

• go-nexus-client

  • Repository: https://github.com/datadrivers/go-nexus-client

  • MPL-2.0 license

    • https://github.com/datadrivers/go-nexus-client/blob/main/LICENSE

  • MPL-2.0 license 관련 사항

    • 소스 코드 수정이 아닌 라이브러리 사용에는 MPL-2.0이 적용되지 않음.

    • 소스코드 수정 없이 사용하는 것에 대한 제한 사항 없음

      • 라이선스 관련 참고

        • https://www.oss.kr/oss_license_qna/show/2620d169-de92-432b-a758-45e57c16310c

        • https://www.oss.kr/oss_guide/show/7eba9fa1-af46-4b72-b7b0-3f5e8ab78e26

  • 라이브러리 사용 가능한 것으로 판단

[sykim-etri]

Nexus 활용과 관련하여 타 과제 사용 현황, 내부 논의 등을 통해 다음과 같은 방식으로 활용 가능한 것으로 정리하였습니다.

• Nexus 활용 방식
  • 방향
    • 향후 과제 결과물의 상업적 활용 시 해당 모듈의 의존성 탈피를 위한 방안 사전 마련
  • 구체적 활용 방식
    • 각 프레임워크 소스코드 내에서 Nexus API 호출 라이브러리를 직접적으로 사용하지 말고, Nexus 제공 기능 중 필요 기능들만을 추상화한 계층(Wrapper)을 개발하고, 이를 통한 접근 방식으로 개발
  • 기타
    • (부득이하게 Nexus 확장 개발 필요시) nexus-public repo에 직접 반영하여 변경 사항 공개 (별도 저장소 유지/관리 X)

검토하시고 의견 부탁드립니다. @ish-hcc

[ish-hcc]

@sykim-etri 확인해 주셔서 감사합니다. 말씀해 주신 대로라면 최대한 Nexus를 사용하지 않고 필요한 부분을 직접 구현하는 쪽으로 생각을 해봐야 겠네요. 좀 더 고민해보도록 하겠습니다 감사합니다.

[sykim-etri]

@ish-hcc
SW 저장소 관련한 개발 방안이 정리가 되셨다면 간단하게 공유를 부탁드립니다.

[ish-hcc]

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

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

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

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

[sykim-etri]

패키지 매니저로 설치가 가능한 경우는 그렇게 처리가 가능할 것 같은데, 아래 항목들에 대해서도 처리가 가능할지 검토를 부탁드립니다.

• 상용 SW나 사용자가 직접 개발한 SW 등
• 설치 스크립트나 설정 파일 등
• 컨테이너 인프라용 도커 이미지나 쿠버네티스 Helm Chart 등

[ish-hcc]

• 설치 스크립트도 사용자 정의 등록 으로 보고 등록 가능하도록 할 예정입니다
• 상용 SW, 사용자가 직접 개발한 SW 같은 경우에는 직접 작성한 Ansible Playbook을 등록하여 운영하는 방안을 생각해 볼 수 있습니다.
• 직접 테스트를 진행해 보지는 못했지만 Ansible을 통해 Docker, Kubernetes, Helm 제어가 가능한 것으로 확인됩니다

[ish-hcc]

• Ansible로 제어가 되긴 하는데 Kubernetes, Helm 같은 경우는 다른 방안도 있을지 좀 더 고민해볼 필요는 있어보이긴 합니다

[sykim-etri]

@ish-hcc
K8S 환경의 마이그레이션과 관련하여 제약 사항 등을 예상하셨는데, 혹시 추가로 검토된 사항들이 있을까요?

[ish-hcc]

@sykim-etri
velero 라는 k8s 마이그레이션 툴이 있어 해당 툴을 통한 PoC를 고려해 볼까 하는데, 쿠버네티스 관련 작업을 진행해주시는 분도 다른 프로젝트 진행으로 인해 아직 확인은 못해봤습니다.