Sonatype - Nexus

Ref. www.sonatype.com/solutions/developers

아래 내용은 좀 오래된 내용으로 없어진 링크도 제법있고, 달라진 것도 있다. 다만 저장소 관리자로 "Nexus Repository OSS" 를 왜 사용하는지에 대한 개념을 이해 할 수 있다.

가장 중요한 내용은 사설 저장소가 왜 필요하는 가이다. 아래와 같은 내용들이 있던데 나는 회사에서 개발한 라이브러리를 공유하지 않고 사용, 관리 하기 위함이다.

사설 리포지토리(Nexus Repository)가 필요한 이유

​· 회사/단체의 화이트 리스트로 인해 외부 리포지토리에 접속하기 어려운 경우 프록시 역할.

· 특히나 비상시 외부 인터넷이 느리거나 리포지토리가 다운되는 등 여러 상황에서도 빠르게 받을 수 있다.

· 현재 메이븐에 올라와 있지 않은 자료들을 효율적으로 관리하기 위하여.

· 한번 다운로드 받은 디펜던시는 로컬에 저장되지만 컴퓨터를 포맷하거나 동료가 시작할 때 설정을 해야한다.

· 서버에도 동일한 설정들을 해줘야함으로 서버 구조가 복잡할 수록 잔업도 늘어난다.

· 예외 파일로 인한 설정이 줄어들어 전체적인 일관성이 증가한다.

+

· 개발팀에서 사용하는 공통 라이브러리들을 공유한다.

· 특정 솔루션을 사용하기 위한 3rd Party 라이브러리의 관리

Ref. www.lesstif.com/sonatype-nexus/software-repository-36209229.html

패키지 관리자(Package Manager) 란

소프트웨어가 점점 복잡해지고 외부 라이브러리를 사용하는 경우가 많아지면서 외부 라이브러리를 설치하고 관리하는 문제과  의존성 지옥(dependency hell) 이라는 골치 아픈 문제가 발생했습니다.

먼저 라이브러리의 버전 갱신시 호환성 보장을 위해 버전을 기술하는 표준 명명법인 유의적 버전(Semantic Versioning) 이라는 버전 기술 방법도 제안되었습니다.

그리고 이를 기반으로 언어나 프레임워크의 사용자 커뮤니티에서는 유의적 버전에 기반하여 의존성 있는 라이브러리의 설치/갱신/삭제를 처리하는 패키지 관리자(Package Manager) 또는 의존성 관리자(Dependency Manager) 라고 부르는 전용 프로그램을 만들었고 사용자의 많은 호응을 받아서 지속적으로 발전해 가고 있습니다.

패키지 관리자는 해결하고자 하는 문제는 동일하므로 개념을 이해하면 언어나 프레임워크가 변경되어도 크게 어렵지 않게 적응할 수 있으며 유명한 패키지 관리자는 아래와 같습니다.

언어패키지 관리자

Java	maven, gradle
Ruby	RubyGems, Bundler
.NET	nuget
Python	PyPI
PHP	Composer
Node.JS	npm, Yarn

artifact, Package, Library, Component

언어나 프레임워크마다 package, library, component 를 비슷한 의미로 사용하는 경우가 많으며 일반적으로는 라이브러리라고 이해하면 됩니다. 

아티팩트는 소프트웨어 개발 프로젝트를 진행하면서 생성하는 다양한 산출물을 의미하며 각종 설계 문서, 유즈 케이스, UML 다이어그램, 소스 코드, 소스를 빌드하여 생성된 라이브러리나 실행 파일도 모두 아티팩트에 속합니다.

주로 자바 진영에서 사용하는 용어로 라이브러리나 패키지보다 더 큰 개념이라고 볼 수 있으며 자바에서 많이 사용하는 메이븐(maven) 에서는 빌드로 생성되는 프로젝트의 결과물을 의미하며, 아티팩트는 자바 프로젝트의 성격에 따라 다르지만 일반적으로는 .jar, .war, .ear 등의 확장자를 갖게 됩니다.

저장소(Repository) 란?

저장소는 아티팩트와 메타 데이타, 라이브러리, 패키지를 저장하고 관리하는 장소를 의미하며 패키지 관리자가 패키지를 다운로드받고 업로드할 수 있는 기능을 제공합니다.

패키지 관리자를 제공하는 언어들은 각자의 중앙 저장소(Central Repository)가 있으며 자바의 경우 https://repo1.maven.org/maven2, 파이썬의 경우 https://pypi.python.org, PHP 의 경우 http://packagist.org/ 등의 저장소가 있습니다. 

이외에도 상용 라이브러리이거나 내부에서 개발한 라이브러리를 사내의 다른 개발자나 프로젝트와 공유하기 위한 배포 용도로 사용하는 사설 저장소(Private Repository)도 있습니다.

저장소 관리자(Repository Manager)

저장소 관리자는 저장소의 기능을 제공하고 관리자 기능을 제공하는 소프트웨어를 의미하며 라이브러리를 등록/삭제/배포하고 컴포넌트의 생명주기를 관리하기 위한 용도로 사용됩니다.

Private Repository 회사나 개발팀에서

추가로 중요한 기능중 하나는 중앙 저장소를 미러링(Mirroring) 및 캐싱하여 빠른 속도로 빌드를 하게 해주며 중앙 저장소가 장애가 있어도 빌드 업무가 중단되지 않게 합니다.

주요 제품으로는 아파치 재단의 아카이바(archiva), JFrog 사의 아티팩토리(Artifactory), 소나타입사의 넥서스(nexus) 가 있다. 

 이 책에서는 가장 많이 사용하는 넥서스 저장소 관리자에 대해서 다룰 것이다.

이런 방식을 사용할 경우 다음과 같은 문제점들이 발생했다.

• 많은 용량 차지 - 아파치 재단의 라이브러리나 스프링 프레임워크등 공통적으로 사용되는 라이브러리들이 많이 있어도 프로젝트마다 버전 관리에 추가하여 사용하여 많은 용량이 필요하다. 
  특히 프로젝트 소스를 분기할 경우 라이브러리를 복사해야 하므로 분기 속도도 느려 진다.
• 느린 빌드 - 버전 관리 용량이 크다보니 빌드를 위해 체크 아웃 받을 경우 시간이 더 걸리고 빌드도 느려지게 된다.
• 프로젝트 라이브러리 버전 관리 어려움 - 사용하던 라이브러리를 다른 버전으로 변경한다고 가정해 보자. 새로운 라이브러리를 구한 후에 버전 관리에 커밋해야 한다. 
  만약 새로운 라이브러리가 문제가 있어서 예전 버전으로 돌아가야 할 경우 버전 관리에서 삭제하고 커밋을 거쳐야 하는등 프로젝트에서 사용하는 라이브러리의 버전 관리가 어렵다.
• 의존성 관리가 어려움 -  사용하는 라이브러리가 다른 라이브러리를 참고할 경우 개발자가 의존성을 알아서 파악해서 의존성 있는 라이브러리를 추가해 주어야 한다. 
  특히 버전이 갱신되어 의존성이 변경되거나 신규로 추가된 라이브러리일 경우 의존성 관리는 매우 번거로운 작업이다.

저장소는 위와 같은 문제점을 해결하기 위해 사용하며 다음과 같은 장점이 있다.

• 적은 용량 사용 - 저장소는 라이브러리를 보관하므로 프로젝트마다 필요한 라이브러리를 버전 관리에 추가할 필요가 없고 라이브러리에 대한 메타 데이타만 설정하면 빌드할 때 다운로드 받으므로 적은 용량을 사용한다.
• 빠른 프로젝트 체크아웃과 빌드 - 버전 관리 툴을 사용하여 프로젝트를 체크 아웃 받을 경우 용량이 적으므로 빨리 체크아웃 받을 수 있으며 빌드도 빨리 수행 가능하다.
• 라이브러리 버전 관리 용이 - 메타 데이타를 기반으로 라이브러리의 정보와 버전을 관리하므로 라이브러리 자체의 버전을 관리하기가 용이하다.
• 공유 및 협업 강화 - 저장소를 통해 컴포넌트를 공유할수 있으므로 개발자들끼리 손쉽게 산출물을 공유하고 협업할 수 있다.