Windows Container Fundamentals
Consider the challenges highlighted at the start of this chapter: the amount of time for
provisioning environments, wasted resources (as every application has its own OS
instance in order to attain a basic level of isolation from other applications), and the
problems associated with the deployment of applications and their dependencies.
Containers solve these challenges by enabling multiple applications to share a single
OS instance while providing isolation between them. Furthermore, containers utilize a
model that enables applications to be encapsulated and dependencies to other
containers containing various libraries and binaries to be documented as part of the
container Metadata.
For any readers who may have dabbled in the desktop space, some of these features
may sound like App-V. This technology enabled desktop applications to run in their
own bubbles, with their own virtual view of the filesystem completely isolated from
other App-V virtualized applications. As you will see, similarities exist between
containers and App-V, especially related to the isolation capabilities, but containers go
a lot further.
Containers can be thought of as another type of virtualization, because they enable
any application running inside the container to perceive that it has its own isolated
operating system view that is separate from any other application that happens to be
running in a different container on the same OS instance, known as a sandbox. This
isolation is at a user-mode level. Each container has its own isolated namespace,
which provides the following to the application:
Its own view of the filesystem, which consists of its own virtual filesystem content
that is unioned with the underlying pristine OS filesystem content and any
container filesystem content upon which it is dependent. This requires updates to
NTFS. For example, I may have a web application in a container that depends on
another container that contains IIS, which depends on the Nano Server container
that contains the OS image. Inside the container instance, I would see the union of
my application container filesystem, the IIS container filesystem (containing the
IIS binaries), and the underlying container OS image (containing the OS), enabling
the application to function. Any writes from the application are made to its virtual
filesystem overlay (the sandbox), avoiding any cross-pollination to other
containers, and any other images in the dependency chain are read-only.
Its own view of the registry, and just like the filesystem, the registry layers are
unioned through a new vreg capability
Its own view of processes, hiding processes from other containers
Its own networking configuration that leverages virtual switches on the container
host (the OS instance that hosts the container instances)Figure 10.1 shows a graphical, high-level representation of containers compared to