Implementing Multi-Stage Builds to Reduce Image Size

docker-gs-ping latest 7f153fbcc0a8 7 minutes ago 1.11GB ... ``` The tag `v1.0` has been removed but you still have the `docker-gs-ping:latest` tag available on your machine, so the image is there. ## Multi-stage builds You may have noticed that your `docker-gs-ping` image weighs in at over a gigabyte, which is a lot for a tiny compiled Go application. You may also be wondering what happened to the full suite of Go tools, including the compiler, after you had built your image. The answer is that the full toolchain is still there, in the container image. Not only this is inconvenient because of the large file size, but it may also present a security risk when the container is deployed. These two issues can be solved by using [multi-stage builds](/manuals/build/building/multi-stage.md). In a nutshell, a multi-stage build can carry over the artifacts from one build stage into another, and every build stage can be instantiated from a different base image. Thus, in the following example, you are going to use a full-scale official Go image to build your application. Then you'll copy the application binary into another image whose base is very lean and doesn't include the Go toolchain or other optional components. The `Dockerfile.multistage` in the sample application's repository has the following content: ```dockerfile # syntax=docker/dockerfile:1 # Build the application from source FROM golang:1.19 AS build-stage WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY *.go ./ RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping # Run the tests in the container FROM build-stage AS run-test-stage RUN go test -v ./... # Deploy the application binary into a lean image FROM gcr.io/distroless/base-debian11 AS build-release-stage WORKDIR / COPY --from=build-stage /docker-gs-ping /docker-gs-ping EXPOSE 8080 USER nonroot:nonroot ENTRYPOINT ["/docker-gs-ping"] ``` Since you have two Dockerfiles now, you have to tell Docker what Dockerfile you'd like to use to build the image. Tag the new image with `multistage`. This tag (like any other, apart from `latest`) has no special meaning for Docker, it's just something you chose. ```console $ docker build -t docker-gs-ping:multistage -f Dockerfile.multistage . ``` Comparing the sizes of `docker-gs-ping:multistage` and `docker-gs-ping:latest` you see a few orders-of-magnitude difference. ```console $ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE docker-gs-ping multistage e3fdde09f172 About a minute ago 28.1MB docker-gs-ping latest 336a3f164d0f About an hour ago 1.11GB ``` This is so because the ["distroless"](https://github.com/GoogleContainerTools/distroless) base image that you have used in the second stage of the build is very barebones and is designed for lean deployments of static binaries. There's much more to multi-stage builds, including the possibility of multi-architecture builds, so feel free to check out [multi-stage builds](/manuals/build/building/multi-stage.md). This is, however, not essential for your progress here. ## Next steps In this module, you met your example application and built and container image for it. In the next module, you’ll take a look at how to run your image as a container.

The section explains how to implement multi-stage builds using a Dockerfile example (`Dockerfile.multistage`). It demonstrates building the application in one stage using a full Go environment and then copying the built binary into a smaller base image (distroless) in a subsequent stage. The result is a significantly smaller image size, as demonstrated by comparing the sizes of `docker-gs-ping:multistage` and `docker-gs-ping:latest`. The section concludes by pointing to further resources on multi-stage builds and setting the stage for running the image as a container in the next module.