[Skaffold] JIB Sync

개요

• Skaffold의 JIB를 사용해 Java spring 프로젝트를 빌드하고 배포
• JIB Sync 기능을 활용해 변경된 파일만 sync하여 재빌드 및 배포, pod 재시작 단계 생략

 

필요 조건

Skaffold는 build 옵션으로 JIB를 지원하고 있다. 이때 File Sync 기능을 활용하면 변경된 파일을 copy 해주기 때문에 파일이 변경 되더라도 재빌드 및 배포, pod 재시작 단계 없이 구동되고 있는 pod에 변경사항을 적용시킬 수 있다.

JIB Sync 기능을 auto로 사용하기 위해서는 몇가지 필요 요건이 존재한다.

 

File Sync

1. Sync 기능은 구동하는 컨테이너 내부에 tar가 존재해야 함. 즉, JIB가 build하는 base image에 tar가 포함되어야 함.
2. spring dependency로 spring-boot-devtools를 포함시켜야 함.

구동하는 컨테이너 내부에 tar 파일 포함 시키기

Skaffold는 sync 규칙에 해당하는 변경 파일을 포함하여 tar 파일을 만들고, 이 파일을 컨테이너에 전송하여 변경 사항을 적용한다.

JIB는 java로 이루어진 프로젝트를 빌드할 때 base image로 gcr.io/distroless/java를 사용한다. 그런데 이 이미지는 tar파일을 포함하지 않는 이미지이기 때문에 tar를 포함하는 gcr.io/distroless/java:debug를 base image로 사용해야 한다.

gcr.io/distroless/java:debug는 linux/arm64에서 지원되지 않는 이미지이다. (linux/amd64에서만 지원)

skaffold dev --platform=linux/amd64 명령어로 위 이미지를 사용할 수 있다.

spring-boot-devtools 포함 시키기

JIB는 Spring에서 필요한 설정들을 인지하지 못하기 때문에 spring-boot-devtools를 의존성으로 주입해 주어야 한다.

공식 문서에서는 spring의 maven(또는 gradle) 파일에 profile을 만들어주고 해당 profile로 빌드할 때에만 이 의존성을 주입하도록 하는 것을 권장하고 있다.
아래 예제에서는 dev라는 profile을 만들어 의존성을 주입하고, skaffold에서는 jib를 build할 때 dev 프로필로 maven(또는 gradle)을 동작시킨다.

<profiles>
  <profile>
    <id>dev</id>
    <dependencies>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-devtools</artifactId>
        <!-- <optional>true</optional> not required -->
      </dependency>
    </dependencies>
  </profile>
</profiles>

dependencies {
  ...
  if (project.hasProperty('dev')) {
    implementation "org.springframework.boot:spring-boot-devtools"
    // do not use developmentOnly
  }
}

# skaffold 추가할 내용
build:
  artifacts:
  - image: test-file-sync
    jib: {}

profiles:
- name: dev
  patches:
  - op: add
    path: /build/artifacts/0/sync
    value:
      - auto: true
  - op: add
    path: /build/artifacts/0/jib/args
    value:
    - -Pdev

 

테스트 및 결과

파일 변경을 감지하고 대응되는 pod에 해당 파일을 copy 하는 것을 볼 수 있다.
이 과정에서 rebuild, redeploy, restart pod 단계는 없으며 spring만 재시작 된다.

Rebuild, Redeploy 과정이 없기 때문에 Helm release의 교체가 없다. 즉, revision이 변경되지 않으므로 버전 관리가 되지 않는다. 버전 관리가 필요하다면 그 시점에 helm repository로 release 배포를 해야 한다.