build-stage 단계에서는 빌드 도구가 설치된 기반 이미지를 사용한다. 로컬 컴퓨터에서 소스 코드를 복사해 넣고, build 명령을 실행한다. 그리고 단위 테스트 프레임워크가 설치된 기반 이미지를 사용하며 앞서 빌드한 바이너리를 복사해 간 다음 단위 테스트를 수행하는 test-stage 단계를 추가할 수도 있다. 마지막 단계는 애플리케이션을 실행할 런타임이 들어 있는 기반 이미지로 시작한다. 그리고 build-stage에서 빌드하고 test-stage에서 테스트까지 성공적으로 마친 바이너리를 이 이미지에 복사해 넣는다.

▲ 그림 4-4 자바 애플리케이션의 멀티 스테이지 빌드 예

이런 방법으로 애플리케이션의 진정한 이식성을 확보할 수 있다. 딱 한 가지, 도커만 갖춰진다면 컨테이너를 통해 어떤 환경에서든 애플리케이션을 빌드하거나 실행할 수 있다. 빌드 서버에도 도커만 설치돼 있으면 된다. 새로 팀에 합류한 개발자도 즉시 개발 환경을 갖출 수 있으며 빌드 도구를 도커 이미지를 통해 중앙 집중적으로 관리할 수 있다. 팀 공통의 설정에서 벗어날 가능성 자체가 원천적으로 차단된다.

거의 모든 주요 애플리케이션 프레임워크는 이미 도커 허브를 통해 빌드 도구가 내장된 공식 이미지를 제공한다. 런타임만 제공되는 이미지를 별도로 제공하는 경우도 있다. 이들 이미지를 직접 활용하거나 이들을 포함하는 이미지를 새로 만들어 사용하면 된다. 이렇게 하면 프레임워크 개발 팀이 유지 보수하는 최신 업데이트를 바로바로 적용할 수 있다는 장점이 있다.