Why Windows Server Containers and Why You Need to Look at Containers? Hands on…

Hello Developers and IT Pros!

In the unlikely event that you have not heard that Microsoft has released Technical Preview 3 of Windows Server 2016 which includes the first public release of Windows Server Containers. If you have not looked at them yet – you really should!

In the previous blog post, we discussed what is Windows Server Containers versus Hyper-V Containers.

In today’s post, we will deep dive into why Windows Server Container and what is the goals for Developers and IT Professionals.

The Tension Between Developers and IT

The Developers need to create applications at a competitive rate without worrying about IT. The new applications run smoothly on developer’s machines, but malfunction in traditional IT server, so the Developer productivity and application innovation become suspended.

In the other side, the IT department needs to manage servers and maintain compliance with little disruption. IT is unsure of how to integrate unfamiliar applications, and require help from the Dev team in most cases, the IT is unable to focus on server protection and application compliance.

Containers will empower the Developers to create innovative applications at a competitive rate without disrupting IT’s ability to manage server and maintain control, so it becomes a nice solution for some of theses challenges that we traditionally faced.

What is Containers?

In short, containers are a new approach to build, ship, deploy, and instantiate applications at the speed of light!

Traditionally, applications were built and deployed onto physical systems with 1:1 relationship. New applications often required new physical systems for isolation of resources.

Then Server Virtualization came with higher consolidation ratios and better utilization. We had faster App deployment than in a traditional, physical environment. These Apps deployed into Virtual Machines with high compatibility success. The Apps benefited from key VM features such as Live Migration, and Clustering.

What Containers came to do is to give us the flexibility of choice deployment on Physical (bare metal) or inside a Virtual Machine. The key benefits is to accelerate of Application deployment, reduce effort to deploy Apps, streamline development and testing, lower the cost of associated App deployment and increase server consolidation.

Why are we looking at Containers?

The applications are fueling innovation in today’s “Mobile First – Cloud First” world.

For Developers, Containers unlock ultimate productivity and freedom. They can write-once, and run-anywhere apps, It can be deployed as multi-tier apps in IaaS/PaaS models. Containers offers powerful abstraction for micro services.

As for IT Professionals, Containers enhances the IT deployment models, it provides standardized environments for development, quality assurance, and production teams. It abstracts the differences in OS distributions and underlying Infrastructure. It gives higher utilization and compute density comparing to Virtual Machines and rapid scale-up and scale-down in response to changing business needs.

In short, Containers enables true DevOps that integrate people, process, and tools for an optimized App development process. The IT department focus on standardized the Infrastructure, and the Developers focus on building, deploying and testing the Apps.

Containers Capabilities

Every application running inside a container has it’s own dependencies which includes both software (services, libraries) and hardware (CPU, network, memory, and storage).

Container engine is a light weight virtualization mechanism which isolates these dependencies per each application by packaging them into virtual containers. All the containers are sharing the kernel space with the host OS and other containers, however the user space and processes are isolated from other containers. They are very flexible, the differences in underlying OS and infrastructure are abstracted away, which stream the “deploy anywhere” approach. Containers are super fast, so you can create a container almost instantly, which help enabling rapid scale-up and scale-down in response to changes in demand.

How Containers differ from Virtual Machines?

Machine virtualization is the creation of an abstracted execution environment which presents the appearance of a computer with CPU, memory and I/O resources. This execution environment is called a virtual machine (VM). Virtual machines were designed to be transparent so that existing operating systems and existing applications can work without modification with few exceptions. In a virtual machine, you install an operating system, install applications and manage similarly to physical machines.

So when we talk about a virtual machine, It’s important to think about the fact that a virtual machine has it’s own copy of the guest OS, now this is both a benefit and a deferment in many cases, so if we took at the example in Figure 1, we can see that each virtualized app inside a virtual machine includes the app itself which requires binaries, libraries and a guest OS, which may consist of multiple GB of data.

Why-Windows-Server-Containers-01

Figure 1 – Virtual Machine (Image Credit: Microsoft)

As you can see in Figure 1 that each VM can have a different OS from other VMs, along with a different OS to the host itself.

Containers is the process of a host operating system creating logical execution environments where each guest has its own user mode instance of the operating system while the kernel is shared between the host and all guests. (I’m referring here to Windows Server Containers and not Hyper-V Containers. I’ll get to those shortly).

So Containers shared the Host (bare metal) or Guest OS (VM) which means I get higher density of Containers versus Virtual Machines, and it’s not necessary to start the Operating System each and every time.

Virtual Machines can be migrated to other hosts to balance resource usage and for host maintenance, without downtime.

By combining containers with VMs, users can deploy multiple, different VM operating systems, and inside, deploy multiple containers within those guest OSs.

What I generally see that most often people will look at Containers and Virtual Machines together, so they can run an instance of the Operating System and then they run multiple Containers inside of a Virtual Machine as illustrated in Figure 2, so by Combining containers with VMs, fewer Virtual Machines would be required to support a larger number of Apps, which of course would result in a reduction in storage consumption. Each VM would support multiple isolated Apps, increasing overall density of Containers, and in terms of flexibility, running Containers inside Virtual Machines enables features such as live migration for optimal resource utilization and host maintenance.

Why-Windows-Server-Containers-02

Figure 2 – Container (Image Credit: Microsoft)

Windows Server Containers Key Capabilities

If we look at what Windows Server Container allows us to do, the Developers will use familiar development tools, such as Visual Studio, to write Apps to run within Containers, so by building modular apps leveraging containers, modules can scale independently, and be updated on independent cadences. The Container capabilities built into Windows Server, so you can deploy and manage containers using PowerShell, or using Docker.

If we look at the example in Figure 3, we have three Containers comprising of three tier application, we have Web tier, App tier and database tier, now commonly when we look at the development model what we find that the App tier and the Web tier which share the same library, what Containers up doing because of how Microsoft are doing the layering, they actually load in memory one copy of that library, all the containers are using that have a read only access to the same copy of that binary, in contrast with a Virtual Machine where we actually have a copy of that binary for each and every Virtual Machine instance, however for the database tier in this example doesn’t have any common libraries with the container Web and the App tier, so it has it’s own copy of the libraries loaded in, but at the bottom layer is the host Operating System that all are sharing, so all Containers are sharing the same (Kernel space) same Operating System services layer as each other, so we can have a very high level of density.

Why-Windows-Server-Containers-03

Figure 3 – Windows Server Container (Image Credit: Microsoft)

In Windows Server 2016 Technical Preview 3, what you can do is the ability for each Container to have either a NAT’d IP address or to utilize DHCP addresses for networking, as for static IP address and resources constraint such as (CPU, Memory and Network Throughput) will come in subsequent preview builds as Microsoft go forward.

Hyper-V Containers Key Capabilities

Last month Mark Russinovich CTO for Microsoft Azure did a great blog post on Hyper-V Containers.

Hyper-V Containers (this is not available in Technical Preview 3) use the same APIs as Windows Server Containers to ensure consistency across management and deployment toolsets. Hyper-V Containers use the exact same images as Windows Server Containers. Each Hyper-V Container has it’s own dedicated copy of the kernel, they are highly trusted, isolated and secured built with proven Hyper-V virtualization technology and the virtualization layer and the operating system have been specifically optimized for Containers. Welcome to Nested Virtualization!

As illustrated in Figure 4, Hyper-V Containers is an optimized Virtual Machine and an optimized instance of Windows Server that is specifically designed for running a container inside, and then we run a Windows Server container inside of that environment.

What I think is really very unique about Hyper-V Containers is that because this is part of the Operating System, you can optimize both the Virtual Machine layer through Hyper-V and the Operating System layer specifically for the ability to run a container inside.

Why-Windows-Server-Containers-04

Figure 4 – Hyper-V Container (Image Credit: Microsoft)

Hands on with Windows Server Containers

Microsoft has published a step by step documentation in the form of walkthroughs that demonstrate creating and running Windows Containers using command line tools, either through Docker or PowerShell.

For the purpose of this demo, I will be using Windows Server Container in a Hyper-V Virtual Machine to deploy IIS in a container and managing it through PowerShell.

In order to try Windows Server Containers, you do not necessarily need to install Windows Server 2016 TP3 directly. Microsoft has a PowerShell script which you can run to deploy a Container host in a Virtual Machine, and one of the tasks included in the script as showing in Figure 5, is to download a suitable OS image to use as the base to create further container images.

Why-Windows-Server-Containers-05Why-Windows-Server-Containers-06

Figure 5 – Creating Windows Server Container Host in a Hyper-V Virtual Machine (Image Credit: Charbel Nemnom)

Once the container host is deployed, we will connect to it and start creating containers.

First, we will look at the existing container images by running ( Get-ContainerImage ), then we will create a new container by running ( New-Container –Name C-IIS01 –ContainerImage WindowsServerCore –SwitchName “Virtual Switch” ), then we will start the container ( Start-Container C-IIS01 ), and then I will use the invoke command to install the Web-Server role within this container ( Invoke-Command -ContainerId $Container01.Id -RunAsAdministrator {Install-WindowsFeature -Name Web-Server} ).

Why-Windows-Server-Containers-07

Note: You might need to run the Invoke-Command again, because the Web-Server role might fail during the installation. Please remember that this is a technical preview, and Microsoft are working on making it better.

We will login to the Web Server Container as administrator using ( Enter-PSSession –ContainerId )

Why-Windows-Server-Containers-08

As you can see the IIS Web-Server role was installed successfully.

We can stop the running container and create a container image if we want to keep the state or we can deploy multiple containers later base on this image, which will help you enabling rapid scale-up and scale-down in response to changes in business demand.

Let’s stop the container by running ( Stop-Container C-IIS01 ), and then create a new container image by executing ( New-ContainerImage –Container C-IIS01 –Name IISWebServer –Publisher MySelf –Version 1.0.0.0 ).

First we need to Exit from the container.

If you run ( Get-ContainerImage ), we will see two images now, the first one has only WindowsServerCore, and the second one that has WindowsServerCore with Web-Server role installed.

Why-Windows-Server-Containers-09

We can repeat the process and create 9 additional containers based on the newly created WebServer Container Image.

Why-Windows-Server-Containers-10Why-Windows-Server-Containers-11

As described earlier in this blog post, each container has unique IP address on the network, we can verify this by executing Invoke-Command.

Why-Windows-Server-Containers-12

The last thing that we need to is to create port mapping. In order to do so we will need to know the IP address of the Web-Server container and the internal (application) and external (container host) ports that will be configured. For this demo let’s keep it simple and map port 80 from the container to port 80 of the container host. Using the Add-NetNatStaticMapping command, the –InternalIPAddress will be the IP address of the Web-Server C-IIS01 container which for this walkthrough is ‘172.16.0.2’.

Add-NetNatStaticMapping -NatName “ContainerNAT” -Protocol TCP -ExternalIPAddress 0.0.0.0 -InternalIPAddress 172.16.0.2 -InternalPort 80 -ExternalPort 80

Why-Windows-Server-Containers-13

When the port mapping has been created you will also need to configure an inbound firewall rule for the configured port. To do so for port 80 run the following command on the container host.

New-NetFirewallRule -Name “HostTCP80” -DisplayName “HTTP on TCP/80” -Protocol TCP -LocalPort 80 -Action Allow -Enabled True

Why-Windows-Server-Containers-14

Last but not least with the web server container created, you can now checkout the Web-Server hosted in the container. To do so, open up a browser on different machine and enter the IP address of the container host. Notice here that you will be browsing to the IP Address of the Container Host and not the container (Web-Server) itself.

Why-Windows-Server-Containers-17

Hope this was useful for you and Thank you for reading!

See you in the next post. Until then, peace…

@Charbel

About Charbel Nemnom 310 Articles
Charbel Nemnom is a Microsoft Cloud Consultant and Technical Evangelist, totally fan of the latest's IT platform solutions, accomplished hands-on technical professional with over 15 years of broad IT Infrastructure experience serving on and guiding technical teams to optimize performance of mission-critical enterprise systems. Excellent communicator adept at identifying business needs and bridging the gap between functional groups and technology to foster targeted and innovative IT project development. Well respected by peers through demonstrating passion for technology and performance improvement. Extensive practical knowledge of complex systems builds, network design and virtualization.

Be the first to comment

Leave a Reply