Multi-Stage Builds With Docker
Two FROM directives in a Dockerfile? What sorcery is this? Well, Dockercon saw the announcement of multi-stage builds, so let's tackle a golang app to see it in action.
Join the DZone community and get the full member experience.
Join For Freeone 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.
Published at DZone with permission of Harshal Shah, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments