스프링부트 공유라이브러리 만들고 jitpack으로 배포하기 - 1편
스프링부트 공유라이브러리 만들고 jitpack으로 배포하기 - 2편
깃허브 주소 : https://github.com/Sangyong-Jeon/practice_core-service
3. 모든 서비스에 공유할 클래스 만들기
저는 Filter를 만들겠습니다.
이 필터는 요청이 들어오면 콘솔창에 log를 남깁니다.
공유할 클래스를 만드시면 됩니다.
4. 라이브러리 jar 파일로 만들기 위한 준비작업
실행가능한 jar 파일로 빌드하지 않도록 빌드 시스템을 비활성화시키는 작업.
이 작업에서 SpringBootPlugin 비활성화하여 bootJar도 비활성화하고, 실행가능한 jar로 빌드할 수 없게 설정함.
스프링부트 의존성 관리를 위해 bom을 가져오도록 BOM_COORDINATES를 설정함.
bom 파일은 의존성 라이브러리 버전을 명세한 pom 파일.
즉, SpringBootPlugin을 비활성화 했으니 버전관리가 안되므로 이를 정상적으로 작동시키게 하는 작업임.
main 메서드 및 SpringBoot를 실행시키는 클래스 제거함.
공유 라이브러리는 다른 서비스에서 사용하기 위해 존재하기에 실행가능한 클래스파일은 필요 X
SpringBootPlugin을 비활성화하고 BOM_COORDINAES 설정함.
이후 gradle을 리로드하여 갱신
우측 Gradle 버튼을 눌려 build를 실행함.
build/libs 폴더에 jar파일이 만들어졌는지 확인함.
이러면 공유 라이브러리로 사용하기 위한 준비작업 끝.
5. 자동 구성(Auto-Configuration) 만들기
우리가 필터를 스프링 빈(컴포넌트)로 만들었지만, 다른 서비스에서 Component Scan(컴포넌트 스캔) 대상이 되지 않는다. 따라서 컴포넌트 스캔 대상으로 만들어서 스프링 빈으로 등록을 하도록 작업한다.
공식문서에 나와있는 방식으로 자동구성을 정의할 것이다.
왜냐하면 공유라이브러리의 스프링 빈(컴포넌트)들은 Component Scan(컴포넌트 스캔) 대상이 아니기 때문이다.
따라서 공유라이브러리에서 `@Bean` 또는 `@Component` 등 작성해도 다른 서비스에서는 스프링 빈으로 등록안됨.
그렇기에 다른 서비스에서도 컴포넌트 스캔 대상이 되도록 정의해야함.
우리는 Locating Auto-configuration Candidates 방식으로 자동구성을 만들어서 스캔 대상이 되도록 할 것임.
AutoConfig 클래스를 만들고 위와 같이 작성
META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 위치에 파일을 만들고 여기에 AutoConfig 클래스 위치를 적으면 됨.
이후 build를 해서 jar파일을 다시 만듦.
😈 주의사항
build를 하면 프로젝트 이름 + version의 jar 파일이 만들어진다.
자체 테스트할 때, 코드는 변경하지만 버전을 변경하지 않고 다른 서비스에 똑같은 이름의 jar 파일을 다시 테스트하는데 이러면 제대로 작동하지 않는다. 꼭 다른 이름이나 버전으로 지정해야한다.
이거 몰라서 가끔 되다가 안되다가해서 몇시간 날려먹었음.
6. 다른 서비스에서 테스트
저는 테스트하는 프로젝트를 공유 라이브러리와 동일하게 만들었음.
공유라이브러리 jar 파일을 최상단에 가져옴
build.gradle에 `implementation files('core-service-0.0.3.jar')` 을 작성하고 리로드하여 갱신함
테스트를 위해 컨트롤러를 만들고 애플리케이션을 실행
정상적으로 CustomFilter가 작동함을 볼 수 있음
7. JitPack으로 배포하기
지금껏 커밋 내역인데 편의상 아무렇게나 하셔도 상관없지만 일정한 규칙을 가져야 합니다.
태그를 위해 git flow 전략을 사용하고 커밋도 `feat: `, `fix: `, `refactor: ` 등으로 작성하셔야 합니다.
이 상태로 JitPack에 배포하면 자체적으로 build하게 되는데 이 때 기본값으로 JDK 1.8로 시도하기에 에러가 나옵니다.
따라서 JitPack 설정을 합니다.
종속성에 버전을 명시하지 않으면 JitPack에서 build할 때 에러가 발생합니다. 이 것 때문에 몇 시간 날렸습니다 ^^
build.gradle 파일에서 빨간색 네모칸에 있는 것을 추가합니다.
JitPack에서는 Gradle 프로젝트에서 build 하는 경우 maven 또는 mavne-publish 플로그인을 활성화해야 합니다.
(참고 : https://docs.jitpack.io/building/ )
이 작업은 gradle 프로젝트에서 maven local repository에 라이브러리를 배포하는 방법입니다.
프로젝트 최상위 경로에 jitpack.yml 파일을 만들어서 위 내용을 적습니다.
이 파일을 JitPack에서 읽고 그대로 실행합니다.
간단하게 설명하면 JDK를 Zulu 17.0.2 버전으로 정의하고 그걸로 build 및 publishToMavenLocal 을 한다는 의미입니다.
https://jitpack.io/ 에 들어가서 Github랑 연동하면 이렇게 뜹니다.
입력창에 저희가 만들었던 Github Repository URL(주소)를 넣고 [Look up] 버튼을 누르고 아래를 보면 저희가 릴리즈한 버전들이 나옵니다.
여기서 [Get it] 버튼을 누르고 기다리면 Log 에 결과가 나옵니다.
빨간색은 실패이고 초록색은 성공입니다. Log를 클릭하면 기록을 보여줍니다.
성공하면 [Get it] 버튼이 초록색인데 누르면 홈페이지 아래에 어떻게 사용하는지 나옵니다.
이 방법대로 다시 테스트했던 프로젝트에 적용해봅시다.
이렇게 넣고 gradle을 리로드를 하면 정상적으로 JitPack에서 공유라이브러리를 가져오는 것을 볼 수 있습니다.
이제 다른 곳에서도 편하게 라이브러리를 배포받을 수 있습니다.
🚀 또 다른 배포 방법
JitPack 말고도 Github Packages 를 사용하여 배포가 가능합니다. 그런데 단점으로는 Github Token을 발급받아서 정의해야하는데 이게 노출됩니다. 따라서 private repository로 바꾸어야하는데 이 때 비용이 발생합니다. 물론 권한을 write:packages 와 delete:packages 만을 주어서 깃허브 패키지만 건들 수 있다고 하지만 찝찝합니다.
또 다른 배포 방법으로는 사설(사내) 저장소인 Nexus(넥서스)를 사용하는 것입니다. 이러면 사내에서만 사용되기에 외부에서 접근이 불가능하고 빠른 배포가 가능합니다.
'Spring > Spring' 카테고리의 다른 글
| 스프링부트 공유라이브러리 만들고 jitpack으로 배포하기 - 1편 (1) | 2023.12.18 |
|---|---|
| Spring Cloud Config Client에서 actuator refresh 장애 (0) | 2023.07.01 |
| 로컬에서 동일한 SpringBoot 서버를 여러개 실행하는 방법 (0) | 2023.06.02 |
| SpringBoot 랜덤포트로 실행하기 (3) | 2023.05.15 |
| 선착순 쿠폰 발급을 위한 redis 분산락 (0) | 2023.05.11 |