Code Library

What is a container?
A container in its simplest form is exactly that—a container. It is an isolated environment in which you can run an application without fear of changes due to applications or configuration. Containers share key components (kernel, system drivers, and so on) that can reduce startup time and provide greater density than you can achieve with a VM.

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 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.

Source of Information : Microsoft Introduction Windows Server 2016