Multi-Stage Builds With Docker

one of the key announcements at dockercon 2017 was the launch of multi-stage builds. it is available in docker version 17.05 onwards and is one of most exciting features coming out. in this post, we will do a quick demo of the feature and then discuss the details.

setup

one of the quickest ways to get our hands dirty with this feature is to sign up for a docker lab and add a new instance. this will spin up a new docker-in-docker container, which can be used for our experimentation. before going ahead, let's ensure the docker version is correct by running the command docker version .

if the version of docker server is less than 17.05, perform the following steps:

• to download the docker daemon 17.05-dev, run the following command:

curl -l https://master.dockerproject.org/linux/amd64/dockerd-17.05.0-dev -o dockerd

• run the following command to overwrite the existing dockerd:

mv ./dockerd /usr/local/bin/dockerd && chmod +x /usr/local/bin/dockerd

• kill the dockerd process by running ps -a and r un the following command to start the docker daemon again

nohup /usr/local/bin/dockerd &

• verify the docker daemon version by running docker version

building the image the old way

clone the git repo of this sample go-lang application and cd to the code directory. we will now build an image of the demo app via the default go-lang parent as a base image using the command docker build -t demo-go-app:1.0 . . one of the key things to notice here is the content of dockerfile, which is simply the golang image’s on-build tag:

from golang:1.6.3-onbuild

once the image is built, verify the image size using the command docker images . the image is about 756mb.

the world of multi-stage builds

now check out the multi-stage branch of the same repo. one of the first things you will notice is a starkly different dockerfile:

from golang:1.6.3-alpine
run mkdir /app
add . /app/
workdir /app
run cgo_enabled=0 goos=linux go build -a -installsuffix cgo -o main .
from alpine:latest
workdir /root/
copy --from=0 /app/main .
cmd ["/root/main"]

there are two from directives in this file, which was not allowed before. with multi-stage builds, a dockerfile allows multiple from directives, and the image is created via the last from directive of the dockerfile.

the next interesting statement is copy –from=0 /app/main . . this takes the file /app/main from the previous stage and copies it to the workdir. this basically copies the compiled go binary created from the previous stage.

now let's run the docker build command docker build -t demo-go-app:2.0 . and verify the size by running docker images again:

the image size is around 13.1 mb, which is a fraction of the older size (756mb).

a word of caution

if the build product is a compiled binary, a consistent platform has to be maintained. a binary compiled for linux will not work on alpine. for example, below are the file attributes of the above application when it is built via golang:1.6.3-onbuild:

root@44fee7671056:/go/src/app# file /go/bin/app
/go/bin/app: elf 64-bit lsb executable, x86-64, version 1 (sysv), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped

looking at the same application when compiled via golang:1.6.3-alpine:

$ docker exec -it c7a6afccf5509c2032444f14906cf17267994a3191e5d368fad9cff679797377 file /root/main
/root/main: elf 64-bit lsb executable, x86-64, version 1 (sysv), statically linked, not stripped

if the application compiled via golang:1.6.3-onubild gets copied to an alpine container, the application wont execute and will give an error, as below:

$ ./app
bash: ./app: cannot execute binary file: exec format error

this is why the dockerfile used in multi-stage build of the demo application is using golang:1.6.3-alpine as its base image, instead of golang:1.6.3-on-build.

why is the multi-stage image so small?

the main reason for the image being so small is that its parent image itself is very small. while the golang:1.6.3 image was about 750mb, the alpine image was a mere 3.99 mb. why alpine images so small, and their other advantages, are explained in detail here . the golang base image contains golang installation + python installation and many supporting modules, which are not really needed once the compiled application is ready.

consider another approach, where you would use alpine as a base image and create an application over it. this would mean adding every little dependency by hand to your dockerfile and adding more steps to image creation, which is certainly not desirable.

a third option is to use the alpine distribution of golang, such as golang:1.6.3-alpine. this also creates an image of around 300 mb, since the os is barebones but all golang dependencies and support modules are present.

multi-stage builds solve the above problems by giving the developer the flexibility to use bloated base images to create an executable/jar file. once the application is compiled, the remaining bloatware is not needed and the application itself can be easily injected into a minimal image, giving all the advantages of a small image size.