Spring Boot 애플리케이션에 최적화된 Docker 이미지 생성

컨테이너는 모든 소프트웨어 및 운영 체제 종속성과 함께 애플리케이션을 패키징한 다음 이를 다양한 환경에 제공하는 데 선호되는 수단이 되었습니다.

이 문서에서는 Spring Boot 애플리케이션을 컨테이너화하는 다양한 방법을 다룹니다.

• Docker 파일을 사용하여 Docker 이미지를 생성하고,
• Cloud-Native Buildpack을 사용하여 소스에서 OCI 이미지 생성
• 다중 계층 도구를 사용하여 JAR의 일부를 여러 계층으로 분리하여 런타임 이미지 최적화.

 코드 예

이 기사에는 작업 코드 예제가 함께 제공됩니다. GitHub에서 .

컨테이너 용어

기사에 사용된 컨테이너 용어부터 시작하겠습니다.

• 컨테이너 이미지: 특정 형식의 파일입니다. 빌드 도구를 실행하여 애플리케이션을 컨테이너 이미지로 변환하겠습니다.
• 컨테이너: 컨테이너 이미지의 실행 가능한 인스턴스입니다.
• 컨테이너 엔진: 컨테이너 실행을 담당하는 데몬 프로세스입니다.
• 컨테이너 호스트: 컨테이너 엔진이 실행되는 호스트 컴퓨터입니다.
• 컨테이너 레지스트리: 컨테이너 이미지를 게시하고 배포하는 데 사용되는 일반 위치입니다.
• OCI 표준: 오픈 컨테이너 이니셔티브(OCI) Linux Foundation 내에 형성된 경량의 개방형 거버넌스 구조입니다. OCI 이미지 사양은 모든 컨테이너 엔진이 모든 빌드 도구에서 생성된 컨테이너 이미지를 실행할 수 있도록 컨테이너 이미지 및 런타임 형식에 대한 업계 표준을 정의합니다.

애플리케이션을 컨테이너화하기 위해 애플리케이션을 컨테이너 이미지로 래핑하고 해당 이미지를 공유 레지스트리에 게시합니다. 컨테이너 런타임은 레지스트리에서 이 이미지를 검색하고 압축을 푼 다음 그 안에서 애플리케이션을 실행합니다.

Spring Boot 버전 2.3은 OCI 이미지 생성을 위한 플러그인을 제공합니다.

도커 가장 일반적으로 사용되는 컨테이너 구현이며 예제에서는 Docker를 사용하므로 이 문서의 모든 후속 컨테이너 참조는 Docker를 참조합니다.

전통적인 방식으로 컨테이너 이미지 구축

Docker 파일에 몇 가지 지침을 추가하면 Spring Boot 애플리케이션용 Docker 이미지를 만드는 것이 매우 쉽습니다.

먼저 실행 가능한 JAR 파일을 생성하고 Docker 파일 지침의 일부로 필요한 설정을 적용한 후 기본 JRE 이미지 위에 실행 가능한 JAR 파일을 복사합니다.

Spring 애플리케이션을 만들어 보겠습니다. 봄 이니셜 라이저 종속성이 있음 web, lombokи actuator. 또한 API를 제공하기 위해 나머지 컨트롤러를 추가하고 있습니다. GET방법.

Dockerfile 만들기

그런 다음 다음을 추가하여 이 애플리케이션을 컨테이너화합니다. Dockerfile:

FROM adoptopenjdk:11-jre-hotspot
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/application.jar"]

Docker 파일에는 다음의 기본 이미지가 포함되어 있습니다. adoptopenjdk, 그 위에 JAR 파일을 복사한 다음 포트를 엽니다. 8080요청을 수신합니다.

애플리케이션 구축

먼저 Maven 또는 Gradle을 사용하여 애플리케이션을 만들어야 합니다. 여기서는 Maven을 사용합니다.

mvn clean package

그러면 애플리케이션에 대한 실행 가능한 JAR 파일이 생성됩니다. Docker 엔진에서 실행하려면 이 실행 가능한 JAR을 Docker 이미지로 변환해야 합니다.

컨테이너 이미지 만들기

그런 다음 다음 명령을 실행하여 이 실행 가능한 JAR 파일을 Docker 이미지에 넣습니다. docker build이전에 생성된 Dockerfile이 포함된 프로젝트 루트 디렉터리에서 다음을 수행합니다.

docker build  -t usersignup:v1 .

다음 명령을 사용하여 목록에서 이미지를 볼 수 있습니다.

docker images 

위 명령의 출력에는 이미지가 포함됩니다. usersignup기본 이미지와 함께 adoptopenjdkDocker 파일에 지정되어 있습니다.

REPOSITORY          TAG                 SIZE
usersignup          v1                  249MB
adoptopenjdk        11-jre-hotspot      229MB

컨테이너 이미지 내부의 레이어 보기

이미지 내부의 레이어 스택을 살펴보겠습니다. 우리는 사용할 것이다 инструмент  잠수, 이 레이어를 보려면:

dive usersignup:v1

다음은 Dive 명령의 출력 일부입니다. 

보시다시피 애플리케이션 레이어는 이미지 크기의 상당 부분을 차지합니다. 우리는 최적화의 일환으로 다음 섹션에서 이 레이어의 크기를 줄이고 싶습니다.

Buildpack을 사용하여 컨테이너 이미지 만들기

조립 패키지 (빌드팩)은 소스 코드에서 컨테이너 이미지를 생성하기 위해 다양한 PAAS(Platform as a Service) 제품에서 사용되는 일반적인 용어입니다. 2011년 Heroku에 의해 출시되었으며 이후 Cloud Foundry, Google App Engine, Gitlab, Knative 및 기타 여러 곳에서 채택되었습니다.

클라우드 빌드 패키지의 장점

Buildpack을 사용하여 이미지를 생성할 때의 주요 이점 중 하나는 다음과 같습니다. 이미지 구성 변경 사항은 중앙에서(빌더) 관리하고 빌더를 사용하여 모든 애플리케이션에 전파할 수 있습니다.

빌드 패키지는 플랫폼과 긴밀하게 결합되었습니다. 클라우드 네이티브 빌드팩은 Docker 엔진에서 이미지를 실행할 수 있도록 보장하는 OCI 이미지 형식을 지원하여 플랫폼 전반에서 표준화를 가능하게 합니다.

Spring Boot 플러그인 사용

Spring Boot 플러그인은 Buildpack을 사용하여 소스에서 OCI 이미지를 빌드합니다. 이미지는 다음을 사용하여 생성됩니다. bootBuildImage작업(Gradle) 또는 spring-boot:build-image대상(Maven) 및 로컬 Docker 설치.

Docker 레지스트리에 푸시하는 데 필요한 이미지 이름을 다음에서 지정하여 사용자 정의할 수 있습니다. image tag:

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <image>
      <name>docker.io/pratikdas/${project.artifactId}:v1</name>
    </image>
  </configuration>
</plugin>

Maven을 사용해서 해보자 build-image애플리케이션 생성 및 컨테이너 이미지 생성의 목표입니다. 현재는 Dockerfile을 사용하지 않습니다.

mvn spring-boot:build-image

결과는 다음과 같습니다.

[INFO] --- spring-boot-maven-plugin:2.3.3.RELEASE:build-image (default-cli) @ usersignup ---
[INFO] Building image 'docker.io/pratikdas/usersignup:v1'
[INFO] 
[INFO]  > Pulling builder image 'gcr.io/paketo-buildpacks/builder:base-platform-api-0.3' 0%
.
.
.. [creator]     Adding label 'org.springframework.boot.version'
.. [creator]     *** Images (c311fe74ec73):
.. [creator]           docker.io/pratikdas/usersignup:v1
[INFO] 
[INFO] Successfully built image 'docker.io/pratikdas/usersignup:v1'

출력에서 우리는 paketo Cloud-Native buildpack작동하는 OCI 이미지를 만드는 데 사용됩니다. 이전과 마찬가지로 다음 명령을 실행하여 Docker 이미지로 나열된 이미지를 볼 수 있습니다.

docker images 

결론 :

REPOSITORY                             SIZE
paketobuildpacks/run                  84.3MB
gcr.io/paketo-buildpacks/builder      652MB
pratikdas/usersignup                  257MB

Jib을 사용하여 컨테이너 이미지 만들기

Jib은 소스 코드에서 컨테이너 이미지를 생성하는 대체 방법을 제공하는 Google의 이미지 생성 플러그인입니다.

구성 jib-maven-pluginpom.xml에서:

      <plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>jib-maven-plugin</artifactId>
        <version>2.5.2</version>
      </plugin>

다음으로 Maven 명령을 사용하여 Jib 플러그인을 실행하여 애플리케이션을 빌드하고 컨테이너 이미지를 생성합니다. 이전과 마찬가지로 여기서는 Docker 파일을 사용하지 않습니다.

mvn compile jib:build -Dimage=<docker registry name>/usersignup:v1

위의 Maven 명령을 실행하면 다음과 같은 출력이 표시됩니다.

[INFO] Containerizing application to pratikdas/usersignup:v1...
.
.
[INFO] Container entrypoint set to [java, -cp, /app/resources:/app/classes:/app/libs/*, io.pratik.users.UsersignupApplication]
[INFO] 
[INFO] Built and pushed image as pratikdas/usersignup:v1
[INFO] Executing tasks:
[INFO] [==============================] 100.0% complete

출력에는 컨테이너 이미지가 생성되어 레지스트리에 배치되었음을 보여줍니다.

최적화된 이미지를 만들기 위한 동기와 기술

최적화에는 두 가지 주요 이유가 있습니다.

• Производительность: 컨테이너 오케스트레이션 시스템에서는 컨테이너 이미지가 이미지 레지스트리에서 컨테이너 엔진을 실행하는 호스트로 검색됩니다. 이 과정을 계획이라고 합니다. 레지스트리에서 큰 이미지를 가져오면 컨테이너 오케스트레이션 시스템에서 예약 시간이 길어지고 CI 파이프라인에서 빌드 시간이 길어집니다.
• Безопасность: 이미지가 클수록 취약점이 있는 영역도 더 커집니다.

Docker 이미지는 레이어 스택으로 구성되며 각 레이어는 Dockerfile의 명령을 나타냅니다. 각 레이어는 기본 레이어의 변경 사항에 대한 델타를 나타냅니다. Docker 이미지를 레지스트리에서 가져오면 레이어로 가져와 호스트에 캐시됩니다.

스프링 부트 용도 "fat JAR" 기본 패키징 형식으로 사용됩니다. 두꺼운 JAR을 보면 애플리케이션이 전체 JAR에서 아주 작은 부분을 차지한다는 것을 알 수 있습니다. 가장 자주 바뀌는 부분입니다. 나머지는 Spring Framework 종속성으로 구성됩니다.

최적화 공식은 Spring Framework 종속성과 별도의 수준에서 애플리케이션을 격리하는 데 중점을 둡니다.

두꺼운 JAR 파일의 대부분을 구성하는 종속성 계층은 한 번만 다운로드되어 호스트 시스템에 캐시됩니다.

애플리케이션 업데이트 및 컨테이너 예약 중에는 애플리케이션의 얇은 계층만 가져옵니다. 이 다이어그램에 표시된 대로:

다음 섹션에서는 Spring Boot 애플리케이션에 최적화된 이미지를 생성하는 방법을 살펴보겠습니다.

Buildpack을 사용하여 Spring Boot 애플리케이션에 최적화된 컨테이너 이미지 생성

Spring Boot 2.3은 두꺼운 JAR 파일의 일부를 별도의 레이어로 추출하여 레이어링을 지원합니다. 계층화 기능은 기본적으로 비활성화되어 있으며 Spring Boot Maven 플러그인을 사용하여 명시적으로 활성화해야 합니다.

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <layers>
      <enabled>true</enabled>
    </layers>
  </configuration> 
</plugin>

이 구성을 사용하여 먼저 Buildpack으로 컨테이너 이미지를 빌드한 후 다음 섹션에서는 Docker로 컨테이너 이미지를 빌드하겠습니다.

발사하자 build-image컨테이너 이미지 생성을 위한 Maven 대상:

mvn spring-boot:build-image

Dive를 실행하여 결과 이미지의 레이어를 보면 애플리케이션 레이어(빨간색 윤곽선)가 fat JAR 형식을 사용하여 얻은 것과 비교하여 킬로바이트 범위에서 훨씬 작다는 것을 알 수 있습니다.

Docker를 사용하여 Spring Boot 애플리케이션에 최적화된 컨테이너 이미지 생성

Maven 또는 Gradle 플러그인을 사용하는 대신 Docker 파일을 사용하여 계층화된 Docker JAR 이미지를 생성할 수도 있습니다.

Docker를 사용할 때 레이어를 추출하고 이를 최종 이미지에 복사하려면 두 가지 추가 단계를 수행해야 합니다.

레이어링이 활성화된 Maven을 사용하여 빌드한 후 결과 JAR의 내용은 다음과 같습니다.

META-INF/
.
BOOT-INF/lib/
.
BOOT-INF/lib/spring-boot-jarmode-layertools-2.3.3.RELEASE.jar
BOOT-INF/classpath.idx
BOOT-INF/layers.idx

출력에는 다음과 같은 추가 JAR이 표시됩니다. spring-boot-jarmode-layertoolsи layersfle.idx파일. 이 추가 JAR 파일은 다음 섹션에 설명된 대로 계층화된 처리 기능을 제공합니다.

개별 레이어의 종속성 추출

계층화된 JAR에서 계층을 보고 추출하기 위해 시스템 속성을 사용합니다. -Djarmode=layertools달리다 spring-boot-jarmode-layertools애플리케이션 대신 JAR:

java -Djarmode=layertools -jar target/usersignup-0.0.1-SNAPSHOT.jar

이 명령을 실행하면 사용 가능한 명령 옵션이 포함된 출력이 생성됩니다.

Usage:
  java -Djarmode=layertools -jar usersignup-0.0.1-SNAPSHOT.jar

Available commands:
  list     List layers from the jar that can be extracted
  extract  Extracts layers from the jar for image creation
  help     Help about any command

출력에는 명령이 표시됩니다. list, extractи helpс help기본값이 됩니다. 다음과 같이 명령을 실행해보자 list옵션:

java -Djarmode=layertools -jar target/usersignup-0.0.1-SNAPSHOT.jar list

dependencies
spring-boot-loader
snapshot-dependencies
application

레이어로 추가할 수 있는 종속성 목록이 표시됩니다.

기본 레이어:

레이어 이름

내용

dependencies

버전에 SNAPSHOT이 포함되지 않은 모든 종속성

spring-boot-loader

JAR 로더 클래스

snapshot-dependencies

버전에 SNAPSHOT이 포함된 모든 종속성

application

애플리케이션 클래스 및 리소스

레이어는 다음에서 정의됩니다. layers.idxDocker 이미지에 추가해야 하는 순서대로 파일을 저장하세요. 이러한 레이어는 변경되지 않으므로 첫 번째 검색 후 호스트에 캐시됩니다. 업데이트된 애플리케이션 계층만 호스트에 다운로드되며, 크기가 줄어들어 속도가 빨라집니다. .

별도의 레이어로 추출된 종속성을 사용하여 이미지 빌드

다음과 같은 방법을 사용하여 두 단계에 걸쳐 최종 이미지를 구축합니다. 다단계 조립 . 첫 번째 단계에서는 종속성을 추출하고 두 번째 단계에서는 추출된 종속성을 최종 이미지에 복사합니다.

다단계 빌드를 위해 Dockerfile을 수정해 보겠습니다.

# the first stage of our build will extract the layers
FROM adoptopenjdk:14-jre-hotspot as builder
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract

# the second stage of our build will copy the extracted layers
FROM adoptopenjdk:14-jre-hotspot
WORKDIR application
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

이 구성을 별도의 파일에 저장합니다. Dockerfile2.

다음 명령을 사용하여 Docker 이미지를 빌드합니다.

docker build -f Dockerfile2 -t usersignup:v1 .

이 명령을 실행하면 다음과 같은 출력이 표시됩니다.

Sending build context to Docker daemon  20.41MB
Step 1/12 : FROM adoptopenjdk:14-jre-hotspot as builder
14-jre-hotspot: Pulling from library/adoptopenjdk
.
.
Successfully built a9ebf6970841
Successfully tagged userssignup:v1

Docker 이미지가 이미지 ID로 생성된 후 태그가 지정되는 것을 볼 수 있습니다.

마지막으로 생성된 Docker 이미지 내부의 레이어를 검사하기 위해 이전과 같이 Dive 명령을 실행합니다. Dive 명령에 대한 입력으로 이미지 ID 또는 태그를 제공할 수 있습니다.

dive userssignup:v1

출력에서 볼 수 있듯이 애플리케이션이 포함된 계층은 이제 11KB에 불과하며 종속성은 별도의 계층에 캐시됩니다. 

개별 레이어의 내부 종속성 추출

사용자 지정 종속성을 선언하여 애플리케이션과 함께 패키징하는 대신 사용자 지정 종속성을 별도의 계층으로 추출하여 애플리케이션 계층의 크기를 더욱 줄일 수 있습니다. yml유사한 파일 이름 layers.idx:

- "dependencies":
  - "BOOT-INF/lib/"
- "spring-boot-loader":
  - "org/"
- "snapshot-dependencies":
- "custom-dependencies":
  - "io/myorg/"
- "application":
  - "BOOT-INF/classes/"
  - "BOOT-INF/classpath.idx"
  - "BOOT-INF/layers.idx"
  - "META-INF/"

이 파일에는 layers.idx다음과 같은 사용자 정의 종속성을 추가했습니다. io.myorg공유 저장소에서 검색된 조직 종속성을 포함합니다.

출력

이 문서에서는 클라우드 네이티브 빌드팩을 사용하여 소스 코드에서 직접 컨테이너 이미지를 빌드하는 방법을 살펴보았습니다. 이는 Docker를 사용하여 일반적인 방법으로 컨테이너 이미지를 만드는 대신, 먼저 두꺼운 실행 가능 JAR 파일을 만든 다음 Docker 파일에 지침을 지정하여 이를 컨테이너 이미지로 패키징합니다.

또한 호스트에 캐시된 별도의 레이어로 종속성을 끌어오고 컨테이너의 실행 엔진에서 예약 시간에 애플리케이션의 씬 레이어가 로드되는 레이어링 기능을 활성화하여 컨테이너를 최적화하는 방법도 살펴보았습니다.

기사에 사용된 모든 소스 코드는 다음에서 찾을 수 있습니다. 깃허브 .

명령 참조

다음은 이 문서에서 사용한 명령에 대한 간략한 요약입니다.

컨텍스트 지우기:

docker system prune -a

Docker 파일을 사용하여 컨테이너 이미지 만들기:

docker build -f <Docker file name> -t <tag> .

Dockerfile 없이 소스 코드에서 컨테이너 이미지를 빌드합니다.

mvn spring-boot:build-image

종속성 레이어를 봅니다. 애플리케이션 JAR 파일을 빌드하기 전에 spring-boot-maven-plugin에서 계층화 기능이 활성화되어 있는지 확인하십시오.

java -Djarmode=layertools -jar application.jar list

종속성 레이어 추출. 애플리케이션 JAR 파일을 빌드하기 전에 spring-boot-maven-plugin에서 계층화 기능이 활성화되어 있는지 확인하십시오.

 java -Djarmode=layertools -jar application.jar extract

컨테이너 이미지 목록 보기

docker images

컨테이너 이미지 내부 왼쪽에서 보기(다이빙 도구가 설치되어 있는지 확인):

dive <image ID or image tag>

출처 : habr.com