In this post I’m going to take a quick look at Windows Container Services Preview.
Containers have been the rage in the Linux world for the last few years and now they are finally coming to Windows with Server 2016 which is currently in preview. There is quite a lot to grasp when it comes to containers, especially if it is your first time using them, in this post I’m going to bring together the bits and pieces as far as I understand it. Since Windows containers are in preview and still evolving the information in this post will probably be out of date the moment I finish writing it 🙂
What is a container?
Containers are a virtualisation technique where you have multiple user-mode instances running on top of one kernel. Basically you are virtualising the OS instead of a machine like VMs do. Each container will have it’s own file system, registry and network settings that is isolated from the host OS but still use the kernel of that OS. Since you have this dependency on the host OS you can’t run Linux containers directly on a Windows machine, Linux containers need a Linux kernel and vice versa. You can however have a Linux VM running on a Windows host and that Linux VM can host Linux containers. This is what Docker Machine does. Basically containers are used to host applications and services.
When you create a container image it starts from a base image, in Windows your choices are Windows Server Core and Windows Nano Server. These are your only choices and all Windows containers have to use either of these as the base, you can’t create your own base images. You can chain containers together, for instance you can create a container and install IIS on it, this will be the base container for your web applications and from this base container you can create three separate containers for MVC 3.0, MVC 4.0 and MVC 5.0 applications respectively. Any changes you make to the base IIS container image, like enabling Windows Authentication in IIS will also show in the child images when you create them. Containers do not have a GUI, you can connect to the container instance using the command line or PowerShell.
Host Resources
In the initial version of Windows Container Services (WCS) you won’t be able to access host devices directly. You get access to the host’s network via a virtual NIC that is connected to a virtual switch which supports NAT or transparent (bridge) mode. You can configure shared folders between the host and the container if you need access to files on the host. The host CPU, RAM, disk and network I/O allocated to a container can also be constrained.
Container Management
There are a few options you can use to manage your containers
- PowerShell
Easiest way to explain it is to look at the quick start over here and the cmdlets reference. There are command to create containers, start them, set network options etc. - Visual Studio
The Visual Studio Tools for Docker is currently in preview and it enables application deployment directly to Linux containers and will eventually support Windows containers. - Docker
Firstly Docker is a management tool for containers, Docker itself is not the container implementation, container functionality comes from the underlying OS. Docker with help from Microsoft is busy working on a Docker Engine for Windows that will allow you to use the same commands to manage containers independent of the host OS. For instance you will use the same syntax to create a container or set the network configuration for Linux and Windows containers.
Windows Hyper-V Containers
To add to the confusion Windows will also feature Hyper-V Containers which will run each container in it’s own VM to add further isolation. This VM will use Nano Server as the VM OS with just enough functionality to run a container.
Switching to containers
Containers are not a replacement for VMs, they provide slightly different functionality but it is likely that your container hosts will be VMs. It is also likely you’ll have to change your applications and the way you develop them to truly take advantage of containers. Containers are quicker to create and start than VMs which makes them ideal for micro services and scale-out applications. Designing your applications to take advantage of this architecture is beyond this post but you can look here to get some guidelines. Containers are also useful for development scenarios, you can test your application in a standardised environment in just a few minutes as part of your build process or on the developers local machine since they are so lightweight.
