Windows Server 2016: Containers Deep-Dive

Through the course of IT history there have been many great advancements in technology, the latest of which is Containers. In this blog we’ll focus on Windows Server 2016 Containers! First, to level set and ensure that we are all on the same page, what seems like eons ago we were racking and stacking servers within the data center to install applications and operating systems on; this provided a 1:1 relationship. Then x86 virtualization came into the mix and at a high level Virtualization inserted an abstraction layer that separates the bare metal hardware that applications and servers used to reside on and the operating systems and applications being deployed. This provided many benefits that IT Organizations around the world are continuing to benefit with. Containers takes the foundation that server virtualization provides and takes this to the next level by allowing the kernel of an operating system to create multiple isolated user-space application instances, instead of one. The benefits an organization gains from the Container approach is the ability to accelerate application deployment as well as reducing the efforts required to deploy apps. In the public cloud space this provides massive improvements that organizations of all shapes and sizes can benefit from. The ability to on-demand and at large scale stand-up and tear down environments. Hyper-V and the traditional virtualization we are familiar with in the modern data center is hardware virtualization; Containers are Application virtualization.

In the end the ultimate goal is to better the business and have more scalable, better performing applications. Containers provide a great way for Developers to write and enhance their applications for the Cloud and continue to adopt the ‘write-once, run-anywhere’ mentality which in the end enables the business to be more agile and respond to the demands required. IT Professionals can utilize the technology to help enable their Developers by providing standardized environments for all of the Development, QA, User Acceptance Testing and Production environments. Also, by abstracting the hardware completely away from the applications and operating systems makes the underlying hardware infrastructure completely irrelevant. The common theme within Windows Server 2016 is optimization for the Cloud, whether that’s Public, Private or Hybrid. With the compute, storage and networking infrastructure layers optimally tuned and purpose built to work with these next generation virtualization technologies it’s possible to rapidly scale-up and scale-down environments based upon the changing needs of the business.

As previously mentioned, Containers provide isolated operating system environments, they run as an isolated process within their parent OS. With Windows Server 2016 Microsoft has embedded virtualization technologies within the Windows kernel that provides Windows the ability to create multiple instances of the Windows application run-time.

 

For example, Application 1, Application 2 and Application 3 depicted in the image above represent the front-end of my Sales Ordering System. Each individual application environment believes that it is its own instance of Windows. During peak holiday season or during the large annual sale the environment can quickly and easily be scaled to meet the demands.

Containers differ from the traditional VM that IT Professionals are used to deploying. VMs are completely segmented virtualized instances of hardware and operating systems that run applications. Defined within them are virtual hard disks, unique operating systems, virtual memory and virtual CPU’s, for example. Within the image depicted below each application has it’s own dedicated installation of an operating system. Application 1 could be deployed on Linux and Application 2 could be deployed on Windows – they’re 100% independent from each other. With Containers, the parent OS is shared so all application instances would need to support the OS of the parent. Windows Containers technology brings forth two distinct types of containers that we’ll discuss: Windows Containers and Hyper-V Containers. Both types are deployed, managed and function in the same fashion. They do however, differ in the level of isolation provided between containers.

Applications within Containers

From a look, smell and feel perspective Containers operate much like traditional physical servers or virtual machines. VMs and Servers have operating systems and applications, just like containers – this is where the similarities end. Several key fundamentals makeup a containerized application and should begin with thinking of in a layered approach.

• Container Host
  • Either a Virtual or Physical Windows Server 2016 Core or Nano server with the Container Feature enabled. Just like a Hyper-V host, the Container Host will run multiple Windows Containers.
• Container Image
  • With a deployed container all of the changes within the container are captured in a sandbox layer. For example, if a Windows Server Core container was deployed and then an IIS application is installed – these changes to the base are captured in the sandbox. Once the container is stopped those changes can be discarded or converted into a new container image. Highly scalable and ensures consistency.
• Container OS Image
  • This is first layer of the container; the container OS image cannot be changed. From this container OS image, multiples of the same application can be deployed.
• Sandbox
  • With a deployed container all of the changes within the container are captured in a sandbox layer.

• Container Repository
  • Location where Container OS Images are stored and deployed from. Container repositories are typically stored either in a shared location or on the Container Host itself.
• Container Management Technology
  • Windows Containers are either managed via PowerShell or Docker.

 Container Deployment and Image Creation

Container based OS image, image that is provided and certified by Microsoft. All container based OS images are exactly the same regardless of the environment. With Windows Server 2016 the two container OS images available are Windows Server Core and Nano Server. The table below illustrates the options available within TP4. For an easy getting started guide visit msdn.microsoft.com/virtualization and navigate to the Container Quick Start section.

Host Operating System	Windows Server Container	Hyper-V Container
Windows Server 2016 Full UI	Core OS Image	Nano OS Image
Windows Server 2016 Core	Core OS Image	Nano OS Image
Windows Server 2016 Nano	Nano OS Image	Nano OS Image

In the following scenario outlined below are the steps required to deploy a virtualized container host that will run Hyper-V containers. As of Technical Preview 4, Windows 10 Build 10586 or later and Windows Server Technical Preview 4 or later are required to support nested virtualization.

• At least 4 GB RAM available for the virtualized Hyper-V host.
• Windows Server 2016 Technical Preview 4, or Windows 10 build 10565, on both the physical and the virtualized host.
• A processor with Intel VT-x (this feature is currently only available for Intel processors).
• The Container host VM will also need at least 2 virtual processors.

Step 1:

Check the Windows PowerShell Execution Policy to ensure that your machine is capable of PowerShell scripts. Set-ExecutionPolicy cmdlet can be used to assign either Restricted, AllSigned, RemoteSigned or Unrestricted. In my lab I run Unrestricted, since it is of course a lab environment.

Set-ExecutionPolicy Unrestricted

Step 2:

Download the New-ContainerHost.ps1 configuration script from Microsoft. This command will automatically reach out to Microsoft and download the configuration file that will be used to gather all of the necessary bits to deploy a new container host.

wget -uri https://aka.ms/tp4/New-ContainerHost -OutFile c:New-ContainerHost.ps1

Step 3:

Create the container host within the environment. The configuration file that was obtained within Step 2 above contains all of the necessary information to download and deploy the container host (Figure 27). Afterwards we are left with our newly created Windows Server 2016 Container OS ready

There are 3 Windows Images available and are noted below in the command with the -WindowsImage switch:

• NanoServer
• ServerDatacenter
• ServerDatacenterCore

From an Elevated Command Prompt: C:WINDOWSsystem32>powershell.exe -NoProfile c:TempNew-ContainerHost.ps1 -VmName VMName -WindowsImage NanoServer -Hyperv

The command above will reach out to Microsoft and download the corresponding .iso file for whever of the 3 server images you selected. This download only happens upon the first run of the command and will then deploy a .vhd into the environment. In this case c;UsersPublicDocumentsVirtual Hard Disks is my location for Virtual Hard Disks on my Hyper-V host. Once this command completes successfully we have a fully functional virtualized Windows Server 2016 Core Hyper-V Container host. This example illustrates the deployment within a nested virtualization environment.

Step 4:

With this we are now ready to deploy our first Windows based Container.

$MyVeryFirstContainer = New-Container -Name “Container001” -ContainerImageName WindowsServerCore -SwitchName “Virtual Switch” #By adding the -runtime switch and using HyperV will make this container a Hyper-V container. $MyVeryFirstContainer = New-Container -Name “Container001” -ContainerImageName WindowsServerCore -SwitchName “Virtual Switch” -runtime HyperV

The command above will deploy a Windows Container utilizing the WindowsServerCore Image that was downloaded and deployed in Step 3 above.

To manage the container instance, Container001, that was deployed above we can leverage PowerShell direct from our management workstation. Simply Enter-PSSession into your container host and then Enter-PSSession into the Container, Container001. As an alternative an IT Administrator could Remote Desktop or use Virtual Machine Connection to the Container Host.

#PowerShell Direct to Container Host and PowerShell Direct to #the ContainerImage Enter-PSSession -VMName TestContainer1 -Credential chost001administrator   #Get-ContainerID to Enter-PSSession into Container001 Get-Container -Name Container001 | Select Name, ContainerID Enter-PSSession -ContainerID 555a3d7e-560d-40a1-9b44-672024956962 -RunAsAdministrator

The commands above provide a sample of the scenario described.

1. Enter-PSSession to enter PowerShell Direct to Container Host, TestContainer
2. Get the container ID
3. Use ContainerID to Enter-PSSession to Container001

Note: Get-ContainerImage will specify whether the ContainerImage is an ISO

As previously mentioned, now we have a Windows Container Image running nested within our Hyper-V environment ready to have applications deployed upon. Also, an Administrator could add these container images to the domain and manage them like other Windows hosts.

WindowsServerCore and NanoServer are base Image OS examples to deploy applications within. For a more comprehensive list of Container Applications that can be deployed as well as specific code samples reference Microsoft’s GitHub Virtualization-Documentation portal at https://github.com/Microsoft/Virtualization-Documentation

Docker and Windows Server 2016 Containers

Application virtualization, as discussed previously, separates the applications from the hardware (virtual or physical) by creating containerized instances of those individual applications. Linux based, Docker has become a household name in the container ecosystem as the organization has created a common toolset, packaging model and deployment mechanism to allow the distribution of the applications on any Linux host. Docker, an open-source container management suite, provides everything that an application needs to run including the system library, code, runtime – everything that the application needs to run. Just like Windows Containers, Docker containers ensure that the apps can run the same everywhere, regardless of the environment, as long as the environment was Linux…that was then. Within Windows Server 2016 Docker and Microsoft are working together to provide the same consistent experience across both Linux and Windows operating systems, regardless if the workload runs on-premises or within the public cloud. Simply put, Windows Server 2016 will allow the ability to run Docker on Windows. IT Professionals and Developers that are familiar with Docker are likely familiar with the Docker Hub. The Docker Hub is a collection of container applications that are consistently being contributed to within the open-source project. In summary, the partnership between Docker and Microsoft includes strategic investments from both parties to help develop the container ecosystem.

Windows Containers will be deployable through the Docker API libraries that developers are familiar with as well as the Docker client. Since the container instance leverages the container host kernel, Linux containers require Linux based container hosts and Windows Containers are required to run on Windows Server however, you’re able to use the Docker client to manage both.

The Windows Container image contains the necessary command line interface libraries required to deploy Docker based containers. For a complete walk through on how to create your first Docker container using the WindowsServerCore Container Image visit https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/manage_docker

Hyper-V Container

One of the key scenarios and deployment mechanisms of Windows Containers is the ability to run within multi-tenant cloud environments, i.e. Azure in the future. Either fortunately or unfortunately, depending on how you look at this, but cloud environments provide the potential multi-tenancy between applications and potentially tenants. This requires much greater lengths of isolation. Hyper-V containers, unlike Windows Containers, creates a specialized VM that provides kernel level isolation from all other container instances on the container host.

When deploying a Windows Container if the -runtime Hyper-V switch is not used the container will be deployed as a traditional Windows Container. When the -runtime Hyper-V switch is used, the container will be completely isolated from all other containers on the container host.

#By adding the -runtime switch and using HyperV will make this container a Hyper-V container. $MyVeryFirstContainer = New-Container -Name “Container001” -ContainerImageName WindowsServerCore -SwitchName “Virtual Switch” -runtime HyperV

Let’s look at an example to help explain when a Hyper-V container would be deployed versus a traditional Windows Container in a private cloud environment since as of Technical Preview 4, HyperV Runtime Containers is not supported within Azure.

Example: In an environment we have an application set that has multiple front end app servers along with a backend SQL database all running Windows Containers. All of the components within the stack are trusted amongst each other; they are within the same trust boundary. If we were to deploy another separate application with its dependencies on the same Container Host we would be introducing what Microsoft refers to as “hostile multi-tenancy.” In the trusted scenario if malware or an intrusion was made there would only be one application affected. By introducing a second, third or fourth…application on this Container Host we have now introduced multiple trust boundaries. Code from application A could affect the performance of application B, so on and so forth. Hyper-V containers brings forth further isolation allowing each container to have their own dedicated copy of the Windows kernel with directly assigned memory, CPU and IO. In the end, yes they’re isolated and the trust boundaries are secluded however, the caveat is perhaps less container density and less efficiency in container startup times.

To convert from one type to another use the Set-Container command.