SpringBoot 2.3 를 이용해 생성된 도커의 내부 구조

 

스프링부트 2.3이 되면서 CloudFoundry Buildpack을 기반으로 해서 도커 이미지를 만들 수 있게 되었다.

> spring.io/blog/2020/01/27/creating-docker-images-with-spring-boot-2-3-0-m1

> spring.io/blog/2020/08/14/creating-efficient-docker-images-with-spring-boot-2-3

데모는 위의 래퍼런스 문서들을 따라하면 된다.

 

1. 이를 위해서 Gradle Task 와 Maven Mojo 가 각각 추가 되었다.

• 메이븐  spring-boot:build-image   링크  
• 그래들  bootBuildImage 링크

2. 실제로 도커 이미지를 생성 해보면 base image 가  docker.io/cloudfoundry/cnb:0.0.43-bionic 임을 확인 할 수 있다. 처음 보는 거라 좀 찾아보니 CNCF BuildPack 을 기반으로 하는것 같다. 링크

 

---

Dockerfile도 없이 어떻게 패키징이 되어 있을까?

FROM openjdk:8-jdk-alpine
EXPOSE 8080
ARG JAR_FILE=target/my-application.jar
ADD ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

기존에는 Dockerfile 에 이러한 ENTRYPOINT 설정과 하나의 fat jar가 필요했다는 것을 기억하자

 

 

1. workspace 폴더에 dependencies jar library 와 컴파일 된  class 들이 들어가 있다.

 

2.  도커 안에서는 cnb 계정으로 데모 어플리케이션이 수행중이었다. 실행에 필요한 정보는 /layer/config 의 toml 파일을 이용하는듯 했다.

 

3. 그럼 최초에 저 'java'를 실행하는 위치는 어디일까?

docker inspect 로 확인을 해보면 entrypoint 는  "/cnb/lifecycle/launcher " 이다. 그리고  대충 감으로 때려잡아보면 github.com/buildpacks/lifecycle/blob/main/launch/launch.go 와 layer/launch.go와 관련이 있는듯 하다...

 

---

기존의 Boot Application은 Dockerfile & Build Script 또는  github.com/GoogleContainerTools/jib/ 를 이용하여 도커 이미지를 만들었다. 첫 번째의 spring.io 래퍼런스에서는  두가지의 문제점을 말하고 있는데
1. not unpacked ( 음 docker 컨테이너 안에 들어가서 직접 파일을 볼 경우가 ....? )
2. 매번 fat-jar로 빌드하다보니 그 효율이 떨어진다는 점 (캐시 레이어의 무용지물) 
이를 위해서 buildpack 의 지원과 layered jar 를 지원한다고 했다. 

이를 위해서 BOOT-INF 폴더의 계층 구조를 활용하고 있다고 하는데.. 이건 다음에 다시 보는걸로~
add)  어라 ... image publish 관련 태스크가 없는 것 같다. 그럼 push 를 따로 관리해야하나? (이것도 같이 찾아봐야겟다)