지난주에 Docker CE v17.06.0-ce가 나왔다. 이 v17.06.0-ce에는 Dockercon 2017에서 발표된 multi-stage 빌드가 포함되어 있다. 이제 정식 버전에서 실제로 사용할 수 있게 되었다.
multi-stage 빌드가 없던 환경
multi-stage 빌드는 컨테이너 이미지를 만들면서 빌드 등에는 필요하지만 최종 컨테이너 이미지에는 필요 없는 환경을 제거할 수 있도록 단계를 나누어서 기반 이미지를 만드는 방법을 얘기한다. 실제로 Docker를 사용하다 보면 불필요하게 컨테이너 이미지가 커지지만, 기존에는 multi-stage 빌드를 지원하지 않으므로 어쩔 수 없이 감수해야 하는 경우가 있다.
multi-stage 빌드를 이해하기 전에 기존에 Docker 이미지를 만드는 방법을 살펴보기 위해 다음 Dockerfile을 살펴보자.
FROM golang:1.8.3
MAINTAINER Outsider
ENV VAULT_VERSION=0.7.3
## clone vault source code
WORKDIR /go/src/github.com/hashicorp
RUN git clone https://github.com/hashicorp/vault.git
## build vault
WORKDIR /go/src/github.com/hashicorp/vault
RUN git checkout v"${VAULT_VERSION}"
RUN make bootstrap
RUN make dev
RUN mv /go/src/github.com/hashicorp/vault/bin/vault /bin/
CMD ["vault", "server", "-dev"]
이 이미지는 Vault를 빌드해서 사용하는 Docker 이미지이다.(Vault에 대해서 궁금하다면 이전 글 참고.) Vault는 OS별로 미리 빌드된 파일을 제공하지만 여기서는 직접 빌드해서 사용한다고 해보자. 여기선 예시일 뿐이지만 필요에 따라 직접 빌드해서 사용해야 하는 경우도 있고 요즘 JavaScript 같은 경우 트랜스파일을 하기 위해 Babel 등을 설치해서 js 파일을 변환해야 하는 경우가 있다.
이 Dockerfile의 경우 최종 컨테이너 이미지에서 필요한 것은 빌드가 완료된 vault 파일 뿐이지만 golang 환경도 포함되어 있고 Vault 소스코드도 들어있다. Docker에서 이런 상황이 필요하다면 이는 어쩔 수 없는 부분이고 이를 피하려면 별도로 vault 바이너리를 빌드한 후에 Docker 이미지를 만들 때 ADD로 추가해야 한다. 물론 이러면 이 바이너리 파일을 형상관리 도구 등에서 별도로 관리해야 한다.
여기서는 기반 이미지를 golang:1.8.3를 사용하고 있고 이 이미지는 각종 개발에 필요한 의존성이 포함된 buildpack-deps:jessie-scm에 기반을 두고 있다.
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
buildpack-deps jessie-scm 46157f071d19 12 days ago 291MB
golang 1.8.3 d2f558dda133 10 days ago 699MB
이 이미지를 보면 buildpack-deps:jessie-scm은 291MB인데 golang:1.8.3은 699MB이다. 이를 기반으로 앞에서 만든 Dockerfile로 docker build -t oustider-example:0.1 .를 실행해서 이미지를 만들어 보자.
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
oustider-example 0.1 e0f440079a74 19 minutes ago 1.04GB
이제 용량이 1.04GB나 되었다. 단순히 Vault를 직접 빌드해서 사용하고자 했을 뿐인데 최종 컨테이너 이미지는 엄청나게 커졌다. 동작에는 문제가 없지만 배포하거나 할 때 시간도 오래 걸리고 불필요한 트래픽을 유발하게 된다.
Docker의 multi-stage 빌드
앞에서는 golang:1.8.3 이미지를 사용했지만, 이는 실제로는 buildpack-deps:jessie-scm에 기반을 두고 있다. 여기에는 빌드를 위한 의존성이 포함되어 있으므로 최종 이미지는 debian:jessie 기반으로 만드는 정도로 충분한데 이 이미지는 123MB의 용량을 가진다.
앞에서 사용한 Dockerfile을 multi-stage 빌드를 사용하도록 변경해 보자.
# bulid stage
FROM golang:1.8.3 AS build
MAINTAINER Outsider
ENV VAULT_VERSION=0.7.3
## clone vault source code
WORKDIR /go/src/github.com/hashicorp
RUN git clone https://github.com/hashicorp/vault.git
## build vault
WORKDIR /go/src/github.com/hashicorp/vault
RUN git checkout v"${VAULT_VERSION}"
RUN make bootstrap
RUN make dev
# final stage
FROM debian:jessie
MAINTAINER Outsider
## copy vault from build
COPY --from=build /go/src/github.com/hashicorp/vault/bin/vault /bin/
CMD ["vault", "server", "-dev"]
위 파일에는 기존과 다른 점이 있다.
FROM이 2번 존재한다. 앞에서는 vault를 빌드하는 환경이고 두 번째FROM이 최종 이미지를 만드는 부분이다.- 첫
FROM에는FROM golang:1.8.3 AS build처럼 별칭을 지정했다. 이는 나중에 사용하기 위함이다. - 최종 이미지를 만들기 위해서
FROM debian:jessie을 사용했다. COPY --from=build /go/src/github.com/hashicorp/vault/bin/vault /bin/처럼 앞에서build로 지정한 환경에서 파일을 가져와서 최종 이미지에 파일을 추가한다.
사용방법을 보다시피 아주 간단하다. 이를 통해서 이미지를 만드는 데 필요한 의존성과 실제 최종 이미지에서만 필요한 의존성을 완전히 분리해서 최종 Docker 이미지를 아주 간단하게 만들 수 있다.
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
oustider-example 0.1 c03283b723ca 10 seconds ago 183MB
아까와 똑같이 Vault를 직접 빌드해서 Docker 이미지를 만들었지만, 최종 이미지는 183MB에 불과하게 됐다. 물론 동작은 둘 다 똑같이 잘 동작한다.
그리고 테스트해 본 결과 이 최종 이미지는 그냥 Docker 이미지이므로 이 이미지를 실행할 Docker도 17.06 이상일 필요는 전혀 없다. multi-stage 빌드를 위해서 Docker 이미지를 만들 때만 v17.06가 필요할 뿐이다.
Comments