Website under construction

 
Figure 3-6:
Conceptual container layout 
As the illustration demonstrates, a host OS can host many containers and allow them to be completely 
isolated while sharing key components of the OS, such as the kernel. 
The interesting thing about containers is the application itself. The application might have various 
dependencies that it requires to run. These dependencies exist only within the container itself. This 
means that something bad that happens to Application A and the binaries it depends on has no 
impact on Application B and the binaries on which it depends. For example, in most environments, if 
you delete the registry from Application A, the consequences are disastrous for both Application A 
and Application B. However, with containers, Application A and Application B are each self-contained, 
and the change to the registry for Application A does not affect Application B. 
Because all binaries and dependencies are hosted within the container, the application running in the 
container is completely portable. Essentially, this means that you can deploy a container to any host 
running the container manager software, and it will start and run without any modification. For 
example, a developer can begin developing his application and deploy it into a Hyper-V Container 
using Windows 10 Anniversary Edition. When he is ready to roll it out in production, it can be run on 
Windows Server 2016, including Nano Server, in a public, private, or hybrid cloud. 
Containers are built on layers. The first layer is the base layer. This is the OS image on which all other 
layers will be built. This image is stored in an image repository so that you can reference it when 
necessary. The next layer (and sometimes the final layer) is the application framework layer that can be 
shared between all of your applications. For example, if your base layer is Windows Server Core, your 
application framework layer could be .NET Framework and Internet Information Services (IIS). The 
second layer can also be stored as an image, which, when called, also describes its dependency on the 
base layer of Windows Server Core. Finally, the application layer is where the application itself is 
stored, with references to the application framework layer and, in turn, to the base layer. 
The base layer and the application layer can be referenced at any time by any other application 
container you create. Each layer is considered read-only except the top layer of the “image” you are 
deploying. For example, if you deploy a container that depends only on the Windows Server Core 
image, this Windows Server Core layer is the top layer of the container and a sandbox is put in place 
to store all the writes and changes made during runtime. You can then store the changes made as 
another image for later reuse. The same applies if you deploy the application framework layer image; 
this layer would have its own sandbox, and if you deploy your application to it, you can then save the 
sandbox as a reusable image. 
Basically, when you deploy a container to a host, the host determines whether it has the base layer. If 
not, it pulls the base layer from an image repository. Next, it repeats the process for the application 

---

99 
CHAPTER 3 | Application platform 
framework layer and then creates the application container that you were originally trying to deploy. If 
you then want to create another container with the same dependencies, you simply issue a command 
to create the new application container, and it is provisioned almost immediately because all of the 
dependencies are already in place. If you have an application container that depends on a different 
application framework layer as well as on the original Windows Server Core base layer, you can simply 
pull the different application framework layer from an image store and start the new application 
container.