Docker 데몬 없이 컨테이너 이미지 빌드(kubernetes Docker 지원 중단)
컨테이너화는 애플리케이션 배포의 필수적인 요소로 자리잡았고, Docker로 대표되는 가장 인기 있는 기술이다.
다른 k8s 문제에 대해 트러블 슈팅중에 뒤지다가 검색 키워드로 떠서 좀 찾아봤다.
kubernetes is deprecating Docker...네?
kubernetes에서 docker 지원을 중단하려고 한다는 아티클을 발견해서 허겁지겁 들어가서 탐독했다.
휴 다들 진정해 사격중지
아래 링크는 k8s 공식 문서에서 제공하는 번역본이다.
https://kubernetes.io/ko/blog/2020/12/02/dont-panic-kubernetes-and-docker/
웃긴게, 하도 논란되니까 해명하는거 같은 내용이다.
k8s은 v1.20 이후 컨테이너 런타임(CRI)으로서 도커를 사용 중단(deprecating)된다.
docker에서 빌드된 이미지는 여전히 k8s cluster에서 동작한다. 하지만 현재 cluster 내 workflow 일부가 기존 docker socket(/var/run/docker.sock)에 의존하는 경우. 즉 도커 인 도커 패턴의 경우는 workflow 사용에 문제를 일으킬 것이라고 한다.
근 4~5년 된 케케묵은 이야기지만 검색 키워드로 떴고, CRI를 따르지 않는 도커를 중단한건 이전 게시글에서 컨테이너 기술에 대해 공부하면서 작성한 적이 있다.
기사에서는 v1.20 이후 버전을 논하는데 이미 v1.4 이후로 지원 중단됐다고도 적었었다.
그치만 너무 자극적인 제목이었던걸요ㅠ
Google Jib 오픈소스
Java 개발자는 Docker 데몬 없이도 컨테이너 이미지 빌드한다. 우리들한테 편리한 녀석을 찾아서 들고 왔다.
다름아닌 Jib라는 녀석인데, 이 친구는 Google에서 제공하는 오픈소스 컨테이너 이미지 Builder이다.
Dockerfile 없이 간단한 설정만으로 컨테이너 이미지를 생성과 배포를 진행할 수 있다.
무려 도커없이 간단하게 이미지를 생성해준다!!!
사실 우리가 도커로 인식하는 애플리케이션은 많은 기술의 집합체로, 그중에서 docker 데몬의 이미지 생성은 이미지 표준 규격을 따르기에 다른 상용 Builder를 사용해도 이미지 구분없이 모두 통용된다.
기존 Docker와 JIB의 비교
- 생산성 향상
- 빨라진 빌드 속도 - 이미지 Layer를 최적화해 변경된 부분만 새로 빌드
gradle.build 파일에서 다음 jib 플러그인을 추가하면 된다.
plugins {
id 'com.google.cloud.tools.jib' version '3.4.0'
}
...
jib{
from{ image = 'open_jdk:21' }
to{
image= '이미지를 빌드할 위치(AWS ECR, DockerHub ...)'
tags = ['1.0.0']
}
container{ creationTime = "USE_CURRENT_TIMESTAMP"}
}
to(image=) 인자가 가장 중요한데, 어느 위치에 이미지를 생성할지 지정하는 파라미터이다.
그러니까 보통 AWS ECR에 레포지토리를 만들어서 쓰고 있는데 DockerHub의 계정 정보를 입력해서 허브의 레포지토리를 생성해서 push할 수도 있다.
근데 솔직히 ECR에 push하다보니 도커에 비해 체감상 느리다고 느껴진다.
도커는 평소에 로컬에 이미지 저장할때 자주 쓰니까....
출처 및 인용
https://github.com/GoogleContainerTools/jib/tree/master/jib-cli#quickstart