넥서스 설치 및 설정

제품 종류 선택

넥서스는 오픈소스 버전(Nexus OSS)과 상용 버전(Nexus Pro) 두 개의 제품으로 나뉘어 있다. 오픈 소스 버전은 버전 1.9 까지는 AGPL 이었으므로 기업 내부 프로젝트에서 사용할 경우 라이선스 이슈가 발생할 여지가 있었다.

2.x 부터는 Eclipse Public License 로 변경이 되어서 기업 내부의 프로젝트에서 오픈소스 버전을 사용해도 큰 문제는 없다.

다만 상용 버전은 오픈소스보다 더 풍부한 기능을 제공하므로 다음과 같은 기능이 필요하다면 상용 버전 사용도 고려해 볼 만하다.

고가용성 제공

Pro 버전은 다수의 인스턴스를 통해 고가용성을 제공하므로 대규모의 팀이나 팀원이 여러 지역에 흩어져 있는 프로젝트라면 네트워크의 장애나 특정 저장소 다운등의 이상 상황에서도 동작할 수 있다.

아티팩트 조달 관리

회사에서 진행하는 프로젝트이고 상용화 예정이고 소스를 공개하지 않을 것이라면 프로젝트에서 사용하고 있는 외부 아티팩트들의 라이선스가 문제될 만한 것은 없는지 파악해야 한다.

특히 GPL 이나 AGPL 인 아티팩트를 사용할 경우 문제가 될 수 있으므로 이 라이선스를 따르는 아티팩트는 주의해서 사용해야 한다.

하지만 나날이 복잡해지고 수많은 오픈소스를 사용하는 소프트웨어 개발 프로젝트에서 사용하고 있는 아티팩트들의 라이선스를 확인하는 것은 쉬운 일이 아니다. 더군다나 버전이 올라되면서 라이선스가 변경되는 경우도 있다.

Pro 버전은 저장소에 등록된 아티팩트중 기업에서 사용할 경우 문제가 되는게 있는지 확인하고 자세한 정보를 출력하는 기능을 제공하고 있다.

아티팩트 취약점 관리

개발한 제품은 보안에 신경써서 견고한 제품을 만들었는데 사용한 아티팩트에 취약점이 있다면 제품 자체의 보안성도 저하되게 된다.

하지만 프로젝트에 사용한 수많은 아티팩트가 취약점이 있는지 관리하는 건 보통 일이 아니다.

Pro 버전은 현재 저장소에 등록된 아티팩트중 OSVDB(Open Sourced Vulnerability Database) 나 CVE(Common Vulnerabilities and Exposures) 에 취약점이 등록된 제품을 찾아서 보고해 주므로 제품의 보안 강화에 도움을 줄 수 있다.

SSO(single Sign On) 지원

LDAP 이나 atlassian Crowd 등의 솔루션을 통한 SSO 를 지원하므로 계정 및 권한 관리를 손쉽게 할 수 있다.

그외에 NET 플랫폼 지원, OSGi 지원, 기술 지원등의 기능이 제공된다.

프로 버전은 상용이므로 비용이 발생하며 라이선스는 시트(Seat) 라는 단위로 매겨진다.

하나의 시트는 넥서스에 연결하는 클라이언트의 IP 별로 책정되며 개별 시트로 판매하지 않고 10, 20, 50 등 시트를 묶음 단위로 판매하므로 개발자가 많다면 많은 비용이 발생할 수 있는 문제가 있다. 

그러므로 작은 시트의 상용 버전을 구매하고 일반적인 빌드와 디플로이시는 오픈 소스 버전을 사용하고 릴리스 준비 단계에서부터 상용 버전을 사용하는 등 비용을 절감하기 위해 두 개를 같이 혼용하는 방법도 있다.

설치

이제 어떤 제품을 사용할 지 결정했다면 설치를 진행해 보자. 오픈소스와 상용 버전은 배포하는 URL 만 다르고 설치 과정은 동일하므로 이 책에서는 오픈소스 버전 설치에 대해서만 설명하겠다.

사전 준비 사항

넥서스는 별도의 DB 를 사용하여 정보를 관리하지 않는다. 모든 설정과 데이타는 파일 시스템에 저장하며 효율적인 검색을 위해 오픈 소스 검색 엔진인 Lucene 을 사용하여 인덱싱한다.

구동에는 서블릿 컨테이너가 필요하나 내장하고 있으므로 사전에 설치해야 할 것은 자바 런타임밖에 없다. 버전 2.6 이상부터는 JRE 7u21(JRE 8은 지원하지 않는다) 이상 버전을 요구하므로 사전에 설치하도록 하자.

아마 전 장에서 톰캣을 설치한 독자라면 이미 JRE 도 설치되어 있을 것이다.

넥서스는 패키지에 Jetty 라는 경량 WAS 를 내장하고 있으므로 별도의 WAS 가 필요없다. 기본 사용 포트는 8081 이므로 일반 사용자로 구동하는게 바람직하다. 

구동할 사용자와 그룹을 생성해 보자.

이제 su - nexus 명령어로 계정을 전환한 후에 작업을 진행하면 된다.

다운로드

이제 개발사 웹사이트에서 넥서스를 다운로드 해보자. 메인 페이지는 최신 버전만 링크되어 있으므로 예전 버전을 사용하려면 보관 페이지에 들어가야 한다.

웹브라우저를 열고 http://www.sonatype.org/nexus/archived 에 연결한 후에 2.7.2 버전을 클릭하고 .tgz 패키지를 다운받자.

혹은 넥서스를 설치하려는 리눅스에 로그인한후에 curl 로 다운받을 수도 있다. 다음 명령을 실행하자.

curl 의 -L 옵션은 컨텐츠가 이동되었을 경우 따라가며 -O 옵션은 저장시 원격지의 파일 이름대로 저장하는 옵션이다.

설치

이제 다운받은 넥서스를 설치해 보자. 

1. tar 로 압축을 해제한다. 

   tar zxvf nexus-2.7.2-bundle.tar.gz

2. 압축이 해제된 폴더로 이동한다.

   cd nexus-2.7.2-03

3. ls 를 해보면 여러 개의 서브 디렉터리가 있는게 보일 것이다. 중요한 디렉터리들은 다음과 같다.
   1. bin : 넥서스 실행 스크립트(nexus)가 위치한다.
   2. conf : 넥서스 설정 파일(nexus.properties)과 jetty 설정 파일이 위치한다.
   3. logs : 넥서스 실행 로그가 저장된다. 로그 파일명은 wrapper.log  이다.
   4. nexus: 실제 넥서스 어플리케이션이다.

설정 및 구동

넥서스를 구동하기 전에 먼저 구동 환경을 설정해 보자. 설정할 것은 많지 않지만 중요한 설정이 있다. 설정 파일은 conf/nexus.properties 이므로 이 파일을 선호하는 에디터로 열어 보자.

설정에서 가장 중요한 부분은 진하게 표시한 세 부분이다. 이제 하나씩 내용을 확인해 보자.

• application-port=8081 - 넥서스가 사용할 포트이다. 기본 포트는 8081 이다.
• nexus-webapp-context-path=/nexus - 넥서스의 웹 어플리케이션 컨텍스트 경로이다. 기본 값은 nexus 이며 다음과 같이 연결해야 넥서스를 사용할 수 있다. 
  http://servername/nexus 
  필자는 nexus.example.com 등의 도메인을 부여하고 바로 http://nexus.example.com 으로 연결하는 것을 선호한다. 이럴 경우 컨텍스트 경로를 다음과 같이 nexus 부분을 제거해야 한다.
  nexus-webapp-context-path=/ 
• nexus-work=${bundleBasedir}/../sonatype-work/nexus - 넥서스의 실제 저장소 데이타와 메타 데이타가 저장되는 경로이다.
  넥서스 프로그램과 데이타를 분리한 이유는 이렇게 하면 프로그램의 갱신과 변경이 쉽고 데이타 백업과 복구가 용이하기 때문이다.
  기본 설정은 넥서스 설치의 바로 윗 경로에 sonatype-work 이라는 디렉터리를 만들고 여기에 메타 데이타를 저장하는 것이다. 다른 경로에 넥서스 데이타를 저장하고 싶은 경우 이 설정을 변경해 주면 된다. 
  이 폴더는 중요한 폴더이므로 임의로 수정/삭제하면 안 된다.
  필자는 넥서스의 데이타는 /var/sonatype-work  디렉터리 밑에 저장하고 있다. 이럴 경우 설정을 다음과 같이 변경해야 한다. 
  nexus-work=/var/sonatype-work/nexus 
  
  

이제 기본 설정은 끝났으니 구동해 보자. 구동은 bin/nexus 스크립트로 가능하며 구동시에는 start 옵션을, 정지시에는 stop 옵션, 재구동시에는 restart 옵션을 주면 된다. 

정상 구동 여부는 로그 파일을 통해서도 알수 있다. tail 명령어로 로그 파일을 확인해 보자.

8081 포트에 대해 iptables 을 열지 않았으므로 넥서스가 설치된 서버에서만 연결이 가능하다. 정상 구동 여부를 curl 을 사용해서 확인해 보자.

HTML 이 출력된다면 정상 설정된 것이다.

아파치 웹서버와 연동

넥서스를 http://nexus.example.com:8081/ 와 같이 사용할 경우 8081 포트를 오픈해야 하고 또 개발자들이 포트를 기억해야 하지만 보통 도메인 이름은 기억해도 넥서스가 8081 포트에 떠 있다는 사실을 기억하기 쉽지 않다.

이런 문제 해결을 위해 아파치 웹서버를 사용하여 http 또는 https 를 통해 넥서스를 서비스 해보자.

전 장의 톰캣 부분에서 설명한 아파치와 연계 부분을 되돌려 보자. mod_jk 는 톰캣 전용이므로 사용할 수 없으므로 아파치 웹서버와 넥서스를 연동하려면 mod_proxy 가 유일한 대안이다.

아파치 웹서버의 가상 호스트 설정을 통해 넥서스와 연동해 보자. 다음 가상 호스트 설정을 아파치 설정 파일에 추가하자.

아파치 웹서버 장에서 설명했듯이 기본 경로는 /etc/httpd/conf/httpd.conf 이며 필자는 가상 호스트 파일은 /etc/httpd/conf/httpd-vhost.conf 로 분리해서 관리하고 있다.

ProxyPass 와 ProxyPassReverse 항목을 유심히 살펴보자. nexus-webapp-context-path=/nexus 부분을 수정하지 않은 독자라면 이 부분을 다음과 같이 수정해야 한다.

ProxyPass /nexus http://localhost:8081/nexus
ProxyPassReverse /nexus  http://localhost:8081/nexus

이제 사용자가 http://nexus.example.com (수정하지 않은 독자는 http://nexus.example.com/nexus)  으로 연결하면 아파치의 프록시 모듈은 8081 포트에 뜬 넥서스에 연결하여 사용자에게 전달하게 된다.

아파치가 8081 포트에 연결해야 한다는 얘기에 감을 잡은 독자들도 많을 것이다.

짐작대로 8081 포트는 아파치에게 허용된 포트가 아니므로 SELinux 설정을 변경해 주어야 한다.

SELinux 장에서 배운 setsebool 명령어로 httpd_can_network_connect 를 1로 설정하는 방법도 있지만 이럴 경우 아파치 웹서버가 모든 네트워크 포트에 접근 가능하므로 좋은 방법은 아니다. 

명확하게 넥서스에만 연결 가능하도록 http_port_t 컨텍스트에 8081 포트를 추가해 보자.

이제 service httpd restart 로 아파치 웹서버를 재시작하고 웹브라우저로 연결하면 다음과 같은 화면이 보인다면 정상적으로 설치된 것이다.

SSL 연동

여러 이유로 넥서스에 SSL 로 연결하고 싶을 수가 있다. 아파치 웹서버는 SSL 에서도 가상 호스트가 가능하므로 위 설정을 다음과 같이 변경하면 된다. 이왕이면 mod_rewrite 를 사용하여 HTTP 로 들어온 클라이언트는 모두 HTTPS 로 전환하도록 하자.

다음은 conf/httpd-vhost.conf 파일이다. HTTPS 가 아닐 경우 https 로 전환하게 rewrite 규칙을 적용했다.

이제 conf.d/ssl.conf 파일을 편집해 보자.

독자의 환경에 따라 수정해야 할 부분은 진하게 표시했으니 각자 환경에 맞게 수정하기를 바란다.

마지막 부분의 RequestHeader  부분을 살펴 보자. nexus 는 기본 설정이 http 이며 아파치 웹서버는 https 일 경우 꼭 설정해야 하는 부분이다.

이 설정이 빠지면 넥서스의 모든 링크가 http 이므로 제대로 동작하지 않으므로 https 로 넥서스에 연결하려면 설정하도록 하자.

아파치를 재구동하여 http://nexus.example.com 에 연결하면 자동으로 https://nexus.example.com 으로 전환되는 것을 확인할 수 있을 것이다.

설치후 할 일

넥서스가 정상적으로 설치되었다면 꼭 해줘야할 기본적인 설정이 있다.

관리자 암호 변경

가장 먼저 해야 할 일은 관리자 암호 변경이다. 기본 관리자 계정은 admin 이고 암호는 admin123 이다. 우측 상단의 Log In 을 클릭하고 관리자로 로그인해 보자.

로그인 했다면 좌측의 메뉴에서 Security -> Users 를 선택하면 상단에 전체 사용자 목록이 표시된다.

여기에서 admin 을 선택하고 마우스 우측 버튼을 눌러서 팝업 메뉴를 호출하고 메뉴에서 Set Password 를 선택하여 암호를  변경하면 된다. Reset Password 는 암호를 재설정하고 등록한 이메일로 보내주는 기능이므로 여기에서는 적절하지 않다.

그리고 하단에 표시되는 사용자 정보 화면에서 이름과 이메일 주소도 수정해 주자.

SMTP 서버 설정

넥서스는 사용자 암호 리셋이 이메일로 전달하므로 이 기능을 사용하려면 이메일 서버를 설정해야 한다. 좌측의 Administration-> Server 를 선택한후에 SMTP 정보를 설정하자.

localhost 에 SMTP 가 있다면 로그인할 필요가 없으므로 Username/Password 항목은 설정하지 않아도 된다.

설정이 끝났다면 Test SMTP settings 를 클릭하여 정상 동작 여부를 확인해 보자.

HTTP/HTTPS Proxy 설정

넥서스는 주기적으로 외부에 있는 저장소에 연결하여 변경된 아티팩트를 가져와야 한다. 넥서스가 설치된 서버가 보안 문제때문에 직접 외부에 연결하지 못하고 포워드 프록시를 사용한다면 프록시 설정을 해주어야 외부에서 아티팩트를 가져올 수 있다.

Server 메뉴에서 중간 부분에 설정이 있으므로 이런 환경에서 넥서스를 사용한다면 설정해 주자.

deploy 계정 암호 변경

넥서스 설치시 admin 과 함께 deployment 라는 계정이 기본 생성된다. 이 계정은 넥서스에 아티팩트를 올리는데 사용하는 계정으로 기본 암호는 deployment123 이다. 아무나 아티팩트를 올리거나 삭제할 수 있으므로 기본 암호를 변경하자.

저장소 관리

저장소 관리는 넥서스의 가장 중요한 기능중 하나이다. 먼저 넥서스가 제공하는 저장소의 종류에 대해 알아보도록 하자.

저장소의 종류

프록시 저장소(Proxy Repository)

프록시 저장소는 메이븐 중앙 저장소등 원격지에 있는 저장소를 미러링한다. 넥서스는 기본적으로 3개의 원격지 저장소가 등록되어 있다.

호스트 저장소

호스트 저장소는 기업용 사설 저장소이다. 넥서스는 기본적으로 3개의 호스트 저장소가 설정되어 있다.

저장소 설정

이제 관리자로 로그인하여 저장소를 설정해 보자. 저장소 목록은 좌측의 Views/Repositories 메뉴에서 Repositories를 선택하면 된다. 관리자일 경우 상단의 저장소 목록을 클릭하면 하단에 여러 개의 탭이 표시된다. 

Repository

저장소의 이름이 표시되는 컬럼이다. 그룹 저장소는 볼드체로 표시된다.

Type

 저장소의 종류로 위에서 proxy, 호스트, virtual, group 4가지 종류가 있다.

Health Check

 저장소 헬스 체크 기능을 수행하며 자세한 보고서를 얻으려면 상용 버전의 넥서스를 구매해야 한다.

Format

 저장소의 포맷을 의미하며 일반적으로 maven2 이다.

Policy

 deployment 정책을 표시하며 Snapshot 또는 Release 두 개중 하나의 정책을 설정할 수 있다.

이제 하단의 설정 항목을 살펴보자. 다양한 설정이 있지만 넥서스 사용시 꼭 필요한 항목만 알아 보자. 설정은 저장소가 프록시인지 호스트 인지에 따라 약간 다르다.

먼저 기본 포함된 호스트 저장소인 3rd party 를 클릭해 보자

설정이 불가능한 항목은 회색으로 표시되며 설정할 수 있는 항목은 하얀색으로 표시된다. 중요한 설정 항목은 다음과 같다.

Repository Name

장소 목록에 표시할 이름이다.

Repository Policy

Release 또는 Snapshot 저장소인지를 설정할 수 있다.

Deployment Policy

아티팩트 디플로이 정책을 설정한다. 기본은 Disable Redeploy 이며 이럴 경우 아티팩트의 버전을 디플로이 했으면 다시 할 수는 없다. 아티팩트에 버그가 있거나 잘못 되어 있으면 버전을 변경하여 다시 디플로이 해야 한다.

Allow Redeploy 로 설정하면 다시 디플로이할 수 있지만 이럴 경우 많은 문제가 발생할 수 있다. 예로 아티팩트 ID가 my-lib 이고 버전이 1.1 인 아티팩트를 디플로이했다고 하자.

1.1 버전이 잘못된걸 알고 수정한 후에 동일 버전으로 재디플로이 하면 이미 1.1 버전을 받아간 개발자의 메이븐은 아티팩트가 변경되지 않았다고 판단하므로 동일한 문제가 발생할 수 있다.

컴포넌트 버전 관리에 맞지 않는 방법이므로 Redeploy 로 설정하는 것은 충분히 영향을 숙지한 후에 설정하는게 좋다.

Allow File Browsing

True 일 경우 웹 브라우저로 저장소를 브라우징 할 수 있다.

Include in Search

True 일 경우 아티팩트 검색시 이 저장소에 있는 아티팩트를 포함시킨다.

Publish URL

True 일 경우 이 저장소의 URL 을 퍼블리싱하므로 외부에서 URL 로 접근이 가능하다. 

이제 기본 포함된 호스트 저장소인 Central 을 클릭해 보자

옵션은 많지만 설정을 변경 해야 하는건 별로 없다. Remote Repository Access 설정부터 각 항목의 의미를 알아보자.

Remote Repository Location

메이븐 중앙 저장소등 미러링할 원격지 서버의 URL이다. URL 이 변경되지 않은 이상 변경할 일이 없다.

Download Remote Indexes 

기본은 False 이다. 넥서스를 설치한후에 True 로 변경해 주면 아티팩트들에 대한 인덱스 파일을 다운로드한다.

메이븐 중앙 저장소에는 몇 천개의 아티팩트가 있으므로 모두 다운로드하고 인덱싱하려면 시간이 꽤 오래 걸린다.

True 로 설정하면 인덱스 파일을 받아서 사용하므로 인덱싱이 필요없어서 검색 속도가 빨라지고 검색 결과도 좋아진다.

Checksum Policy

저장소에 있는 아티팩트들의 체크섬이 잘못되었을 경우 어떻게 처리할지 설정한다. 기본값은 Warning 이며 Ignore, StrictIfExists, Strict도 설정이 가능하다.

• Ignore - 체크섬이 잘못되도 무시한다.
• Warn - 로그 파일에 경고 메시지를 남긴다.
• StrictIfExists - 체크섬 파일이 있을 경우에만 계산한 체크섬과 저장소의 체크섬이 일치하지 않을 경우 캐싱하지 않는다.  
• Strict - 계산한 체크섬과 저장소의 체크섬이 일치하지 않을 경우나 체크섬 파일이 없다면 캐싱하지 않는다.

다음은 캐시 관련 설정이다. 

Not Found Cache TTL

넥서스가 원격 저장소에서 아티팩트를 못 찾았을 경우 설정한 시간이 지난후에 재시도한다. 기본 값은 24시간이다.

Artifact Max Age

원격 저장소에서 새 버전을 다운로드 받기전 아티팩트의 최대 시간을 설정한다. 릴리스 저장소일 경우 -1 이며 스냅샷은 24시간이다. 

Metadata Max Age

넥서스는 원격 저장소에서 설정한 시간이 지나면 메타 데이타를 다운로드 받는다. 기본 설정은 24시간이다.

저장소에 아티팩트 올리기

메이븐을 통해 저장소에 아티팩트를 디플로이할 수 있지만 넥서스 관리자에서도 할 수 있다. 업로드는 호스트 저장소만 가능하다. MariaDB JDBC 를 3rd party 저장소에 디플로이해보자.

1. 관리자로 로그인한후에 저장소 목록중 3rd party를 클릭하여 하단에 설정 화면을 띄운다.
2. GAV(Group, Artifact, Version) Definition 탭에서 GAV Parameters 를 선택하고 GAV와 Packaing 을 다음과 같이 설정한다.
   1. Group: org.mariadb.jdbc
   2. Artifact: mariadb-java-client
   3. Version: 1.1.7
   4. Packaging: jar 선택
3. Select Artifact(s) to Upload... 를 클릭하고 다운로드받은 mariadb jar 파일을 선택한다.
4. Add Artifact 버튼을 클릭하여 선택한 아티팩트를 추가한다.

5. 하단의 Upload Artifact(s) 를 클릭하면 아티팩트가 업로드된다.

   

추가한 아티팩트는 Browse Index 탭에서 확인해 볼수 있다.

만약 방금 추가한 아티팩트가 보이지 않으면 Refresh 를 누르면 된다.

또 아티팩트를 클릭하면 우측에 Maven 탭에서 메이븐에 연동하기 위한 XML 정보를 볼수 있으며 Artifact 탭을 누르면 다운로드도 받을수 있고 삭제도 가능하다.

추가된 아티팩트는 파일 시스템에 저장되므로 ls 명령어를 통해서도 확인해 볼 수 있다. ls 명령어로 저장소의 파일 시스템을 보면 아티팩트 추가를 확인할 수 있다.

ls -l ../sonatype-work/nexus/storage/thirdparty/org/

 

아티팩트 추가 시점

ls -l 로 넥서스 스토리지의 저장소 내 파일 목록을 확인해 본 독자들은 의아한 부분을 발견했을 것이다.  바로 프록시 저장소의 경우 어떤 아티팩트가 없기 때문이다.

넥서스는 중앙 저장소와 주기적으로 아티팩트를 동기화 하지 않는다.

단지 클라이언트가 아티팩트를 요청했을 때 넥서스에 없을 경우 중앙 저장소에 요청 하고 받아온 아티팩트를 스토리지내 저장소에 저장한 후에 클라이언트에게 서비스 한다.

그러므로 초기에는 용량이 작지만 클라이언트들이 다양한 아티팩트를 요청할 수록 스토리지가 사용하는 용량이 점점 커지게 된다.

이 때문에 넥서스를 백업할 경우 파일 시스템내 프록시 저장소는 제외해도 문제가 없다.