일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- 리눅스
- 알고리즘
- 도커
- 네트워크
- 쿠버네티스
- 프로그래머스
- DPDK
- Elasticsearch
- Java
- springboot
- Python
- 스프링부트
- 백엔드
- Spring
- 개발자
- programmers
- docker
- 카카오
- 파이썬
- Linux
- Kakao
- C
- 프로그래머스 #카카오 #IT #코딩테스트
- 자바
- 코딩테스트
- 스프링
- 엘라스틱서치
- IT
- 캐시
- 운영체제
- Today
- Total
저고데
[Spring Boot]10. 배포를 해보자 본문
개발이 전부는 아니야! 스프링 부트의 배포 장점
서비스를 완성했다고 해서 끝이 아니다.
배포까지 진행해야 비로소 어플리케이션을 완성했다고 할 수 있다.
스프링 부트 어플리케이션을 배포할 때는 WAR이나 JAR 파일로 생성할 수 있다.
하지만 대부분은 JAR을 선택하는데, 그 이유는 실행 가능한 파일이기 때문이다.
이는 독립적이며 테스트가 가능하고 배포 가능한 단일 단위로 최대의 사용성과 다양성을 제공한다.
생성과 반복이 빠르고 환경 변화에 따라 동적으로 자체 구성이 가능하다는 것을 의미하고 배포 및 유지 관리가 간단하다.
또한, AWS, Azure, GCP 등 클라우드 제공업체는 프로덕션 배포를 통해 가장 기본적인 배포 환경을 제공한다.
이 때, JAR 파일은 이러한 환경에 자연스럽게 들어맞으며 충돌 없는 실행을 위해서는 JDK만 있으면 된다는 장점이 있다.
따라서 작업량과 비용이 크게 준다.
JAR의 기본적인 특징
JAR를 생성하는 기능은 모든 문제를 해결할 방책은 아니지만, 필요할 때 기본 유닉스와 리눅스 기반 시스템과의 심층 통합을 위한 고유한 기능을 제공한다.
java -jar 명령어를 통해 JAR 파일을 생성할 수 있다.
추출된 JAR 파일을 tree 명령어를 통해 살펴보면, 기본적으로 class, library, springframework의 기본 class 들을 계층적으로 한 눈에 볼 수 있다.
이를 통해 배포 과정에서 필요한 의존성을 호출할 수 있다.
컨테이너?
앞서 언급했듯이 AWS, Azure, GCP 등 클라우드 제공업체는 프로덕션 배포를 통해 가장 기본적인 배포 환경을 제공한다.
그리고 앱 개발자가 제공한 기본값과 설정을 통해 개발자를 대신하여 컨테이너 이미지를 생성한다.
컨테이너는 격리된 환경에서 응용 프로그램과 의존성을 실행하는 경량 가상화 단위이다.
이미지는 해당 프로그램을 실행하는데 필요한 설치 항목들을 나열할 것이라고 보면 된다.
python에서의 requirements.txt와 유사하다.
개발자가 실행가능한 JAR 파일을 플랫폼에 푸시하면 플랫폼이 자동으로 나머지의 기능을 처리하여 배포한다.
하지만 스프링 부트에서 자체적으로 이미지를 생성하는 것은 최적의 방법은 아니다.
주로 도커를 사용하는데, 이는 스프링 부트 책 한 회독 이후에 진행할 예정이다.
만약 스프링 부트에서 이미지를 생성한다고 하면, 스프링 부트의 플러그인을 사용하여 할 수 있다.
0장에서 언급한, '자동 설정' 개념을 통해 이미지 콘텐츠를 계층화하고, 각 코드 단위의 예상 변경 빈도를 기반으로 코드와 라이브러리를 분리하여 이미지 생성을 최적화한다.
이 때, 예상 변경 빈도라고 했는데, 코드가 변동될 수 있음을 의미한다.
코드 변동성(변경 경향과 빈도)은 일반적으로 레이어 목록의 위에서 아래로 이동할 때 증가한다.
때문에 변동 가능성이 있는 휘발성 코드를 배치할 때는 별도의 레이어를 생성함으로써 후속 이미지를 효율적으로 빠르게 생성할 수 있다.
Pack and Dive
컨테이너 이미지를 작동하기 위해서는 유틸리티 도구가 필요하다.
Pack과 Dive는 이러한 유틸리티 도구 중에서 유용하게 쓰이는 도구 중 하나이다.
Pack은 클라우드 네이티브(Paketo) 빌드팩과 빌드팩 자체를 사용하여 스프링 부트 어플리케이션 컨테이너 이미지 생성에 들어가는 자료를 검사한다.
pack inspect-image <유저명>/<class명>
과 같이 CLI 명령어로 실행하여 해당 이미지의 기반으로 사용된 도커 기본 이미지와 리눅스 버전, 이미지를 채우는 데 사용된 빌드팩, 어떤 프로세스가 어떤 수단으로 실행될 지에 대한 정보를 얻을 수 있다.
또한 로컬과 원격 리포지터리가 모두 지정된 이미지에 대해 폴링되기 때문에 둘의 모든 세부 정보가 제공된다.
따라서 다른 위치에서의 이미지 발생 문제를 진단할 수 있다.
Dive는 컨테이너 이미지의 매우 세분화된 OCI 이미지 레이어와 전체 이미지 파일 시스템의 트리 구조를 보는 데 사용된다.
스프링 부트 계층 구조의 어플리케이션 수준보다 더 깊게(운영체제의 깊이 정도로) 파고들어간다.
따라서 pack보다 덜 유용하고 무겁지만 특정 파일에 대한 정보만을 확인하는 데는 유용하다. (근데 거의 안쓴다)
'Spring Boot' 카테고리의 다른 글
[Spring Boot]12. 자주 보이는 어노테이션 총 정리! (1) | 2024.01.02 |
---|---|
[Spring Boot]11. 리엑티브에서의 테스트 코드와 디버깅 (0) | 2024.01.02 |
[Spring Boot]9. 보안을 적용해보자 (0) | 2023.12.31 |
[Spring Boot]8. 테스트 코드를 작성해보자 (0) | 2023.12.30 |
[Spring Boot]7. 스프링 부트에서 리액티브란? (1) | 2023.12.29 |