Edition 0 Updated to asp. Net core 0

Multi-stage builds in Dockerfile 
The Dockerfile is similar to a batch script. Similar to what you would do if you had to set up the 
machine from the command line. 
It starts with a base image that sets up th
e initial context, it’s like the startup filesystem, that sits on 
top of the host OS. It’s not an OS, but you can think of it like “the” OS inside the container.
The execution of every command line creates a new layer on the filesystem with the changes from the 
previous one, so that, when combined, produce the resulting filesystem. 
Since every new layer “rests” on top of the previous one and the resulting image size increases with 
every command, images can get very large if they have to include, for example, the SDK needed to 
build and publish an application. 
This is where multi-stage builds get into the plot (from Docker 17.05 and higher) to do their magic. 

---

80 
CHAPTER 4 | Development process for Docker-based applications 
The core idea is that you can separate the Dockerfile execution process in stages, where a stage is an 
initial image followed by one or more commands, and the last stage determines the final image size. 
In short, multi-
stage builds allow splitting the creation in different “phases” and then assemble the 
final image taking only the relevant directories from the intermediate stages. The general strategy to 
use this feature is: 
1.
Use a base SDK image (doesn’t matter how large), with everything needed to build and publish 
the application to a folder and then 
2.
Use a base, small, runtime-only image and copy the publishing folder from the previous stage to 
produce a small final image. 
Probably the best way to understand multi-stage is going through a Dockerfile in detail, line by line, 
so let’s begin with the initial Dockerfile created by Visual Studio when adding Do
cker support to a 
project and will get into some optimizations later. 
The initial Dockerfile might look something like this: 
1