In Part One, I covered the concept of Containers,
compared to server virtualization in a Microsoft context.
Today, I want to highlight the architecture of container
images and how you can use them as building blocks to speed up deployment.
Before we start
If you have a background in Server Virtualization, you
are probably very familiar with VM templates.
A VM template is a sysprep’d image that is generalized
and can be deployed over and over again. It is normally configure with its
required components and applications and kept up to date with the latest
patches.
A VM template contains the complete operating system (and
eventually its associated data disk(s)) and has been used by administrators and
developers for years when they want do rapidly be able to test and deploy their
applications on top of those VMs.
With Containers, this is a bit different. In the previous
blog post I explained that Containers are basically what we call “OS
Virtualization” and with Windows Server Containers the kernel is shared between
the container host and its
containers.
So, a container image is not the same as a VM image.
Container Image
Think of a container image as a snapshot/checkpoint of a
running container that can be re-deployed many times, isolated in its own user
mode with namespace virtualization.
Since the kernel is shared, it is no need for the
container image to contain the OS partition
When you have a running container, you can either stop
and discard the container once you are done with it, or you can stop and
capture the state and modifications you have made by transforming it into a
container image.
We have two types of container images. A Container OS image is the first layer in
potentially many image layers that make up a container. This image contains the
OS environment and is also immutable – which means it cannot be modified.
A container image is stored in its local repository so
that you can re-use the images as many times you’d like on the container host.
It is also possible to store the images in a remote repository, making them available
for multiple container hosts.
Let us see how the image creation process works with
Windows Server Containers
Working
with Container Images
In the current release, Windows
Server Containers can be managed by Docker client and PowerShell.
This blog post will focus on the
PowerShell experience and show which cmdlets you need to run in order to build
images, just as easy as you would do by playing with Lego J
First, we will explore the properties of a Container Image. An Image contains a Name, Publisher and a version
We are executing - and storing the following cmdlet in a variable: $conimage = Get-ContainerImage -Name "WinSrvCore"
Next, we create a new container based on this image by executing - and storing the following cmdlet in a variable: $con = New-Container -Name "Demo" -ContainerImage $conimage -SwitchName "VM".
Once the container is deployed, we will start it and invoke a command that installs the Web-Server role within this container ( Invoke-Command -ContainerId $con.ContainerId -RunAsAdministrator { Install-WindowsFeature -Name Web-Server } ). You can see that the picture below shows that the blue Lego block is now on top of the brown one (as in layers).
As described earlier in this blog post, we can stop the running container and create an image if we want to keep the state. We are doing that by executing New-ContainerImage -Container $con -Name Web -Publisher KRN -Version 1.0
If we now executes Get-ContainerImage, we have two images. One that has only the ServerCore, and another one that has ServerCore and the Web-Server Role installed.
We will repeat the process and create a new container based on the newly created Container Image.
In this container, we will install a web application too. The grey Lego block on top of the blue shows that this is an additional layer.
We are then stopping the running container again and creates another container image, containing the web application too.
In the local repository, we have now three different container images in a layered architecture.
Hopefully you found this useful, and I will soon be back with part three of this blog series.
Perhaps you will see more Lego as well .... :-)
-kn
