Windows Server 2016 Modern Application Platform Features -3: Containers

Posted 2020-09-07

Microsoft has made a focused shift to ensuring that customers today, whether they are in the public or private cloud, have a solid foundation for their application portfolio. There are two new technologies introduced in Microsoft Windows Server 2016: Nano Server and containers. With these new technologies, you can take advantage of a highly optimized, scalable, and secure experience for Application Platform.

Containers

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.

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

For details, please ref the Microsoft free book: Introducing Windows Server 2016  at http://aka.ms/mspressfree  or email me at [email protected]