If you would like to read the other parts in this article series please go to:
- Docker and Containers (Part 1) – Understanding Containers
- Docker and Containers (Part 2) – Understanding Docker
- Docker and Containers (Part 3) – Containers and Windows Server
- Docker and Containers (Part 5) – Implementing Hyper-V Containers
- Docker and containers (Part 6)
The previous article in this series examined the basics of how container virtualization is being implemented in the soon to be released Windows Server 2016 operating system. As we saw in the previous article, there are two “flavors” of container technology coming in Windows Server 2016. These two flavors are:
- Windows Server Containers
- Hyper-V Containers
Now that you have some basic understanding of the differences (and similarities) between these two approaches to containerization in Windows Server 2016, let’s focus specifically on the first approach (Windows Server Containers) and see how you can actually implement this in the Windows Server 2016 Technical Preview 4 (TP4) preview release of the new platform.
While we can more easily create containers using the Docker Engine which is included in Windows Server 2016 TP4, it’s ultimately more useful to learn how you can do this using Windows PowerShell instead of using the Docker toolset. The rationale behind this is because most Windows Server administrators are already familiar to some degree with PowerShell and have at least some experience in writing PowerShell scripts for automating common admin tasks in their environment. As a result, this article focuses only on how you can use PowerShell to create a new container using Windows Server Containers.
Also, we’re going to use Microsoft Azure for this walkthrough since at the time of writing Azure includes a base image for Windows Server 2016 TP4 with built-in support for Windows Containers. Not only will this allow you to learn how to create containers using Windows Server Containers but you’ll also have an opportunity to learn about the Azure portal.
As an IT professional I am finding more and more that I can use Azure to build and test demos instead of having to allocate hardware from the limited availability of my own on-premises lab environment. And since Microsoft offers a free one-month trial subscription that provides you with $200 of Azure credits you can spend on any Azure services that you’d like to test, anyone can try out the steps in this walkthrough even if they don’t have a proper lab setup at home or at work. To sign up for your free one-month trial of Azure, go to https://azure.microsoft.com/en-us/pricing/free-trial/.
Creating the container host in Azure
Start by logging onto the Azure portal at https://portal.azure.com and click the New option in the left-hand menu column. Under Marketplace select Virtual Machines and then under Featured Apps select Windows Server 2016 Core with Tech Preview 4 as shown here:
Figure 1: Step 1 of creating the container host in Azure.
If TP4 isn’t available (its trial period expires on July 15, 2016) then you should be able to select an RTM version of Windows Server 2016 Core from the list of featured apps. Note also that the list of featured apps may vary depending on your trial subscription–this walkthrough is being done using a Visual Studio Premium with MSDN subscription which provides you with up to $150 per month of free Azure credits for the lifetime of your subscription. MSDN subscriptions are a great idea if you’re an IT pro or a developer. You can find out more about how to subscribe to MSDN.
Once you’ve selected Windows Server 2016 Core with Containers Tech Preview, leave Resource Manager selected as the deployment model (see the bottom of the next figure) and click Create to create the new virtual machine (VM) that you’ll be using as your container host:
Figure 2: Step 2 of creating the container host in Azure.
Resource Manager is a feature of Azure that allows you to deploy and manage resources as a group instead of needing to configure and manage them separately. You can find more about Resource Manager here and for a description of how the Resource Manager deployment method differs from the Classic deployment method see this link.
On the Basics page of the Create Virtual Machine wizard we’ll specify TESTCON as the name for our new VM container host. We’ll also specify a username, password, and resource group name for our new VM:
Figure 3: Step 3 of creating the container host in Azure.
On the Size page we’ll select an appropriate size option for the new VM as shown next:
Figure 4: Step 4 of creating the container host in Azure.
On the Settings page everything should be fine using the defaults so just review the settings and click OK at the bottom:
Figure 5: Step 5 of creating the container host in Azure.
The Summary page shows you whether you’ve specified enough information to create your new virtual machine. We can see that validation has passed, so just click OK below:
Figure 6: Step 6 of creating the container host in Azure.
At this point a notification should be displayed in the upper right of the Azure portal to indicate that deployment of the new VM is initializing:
Figure 7: Step 7 of creating the container host in Azure.
Notice that the Alert icon in the above screenshot has a number over it. This indicates that an alert message is pending for you to read. If you click the Alert icon, you should see a message that deployment has begun.
Figure 8: Step 8 of creating the container host in Azure.
If you select the Virtual Machines option (not the “classic” one) in the left menu you should also see that your new VM is currently being created:
Figure 9: Step 9 of creating the container host in Azure.
Once the new VM is created it will display as Running under Status in the console:
Figure 10: The container host has been created in Azure.
Now that our VM container host is running in Azure, let’s connect to it from our local computer. To do this, right-click on the new VM and select Connect as shown here:
Figure 11: Connecting to the container host.
You’ll see a notification bar at the bottom of your screen asking if you want to open or save TESTCON.rdp to your local computer. Save it to your desktop or some other convenient location:
Figure 12: Downloading the .rdp file to connect to the container host.
Now double-click on TESTCON.rdp to launch Remote Desktop Connection in the familiar way. Once you’ve connected to the VM container host running in Azure, you should see a blank black window with a single command prompt (CMD.exe) window displayed:
Figure 13: The container host has Windows Server Core installed.
Remember, this is Server Core you are connecting to, so there’s no GUI on the container host!
Creating a container image
A container image is the captured state information of a container you have created and customized on a container host. Once you’ve created and customized a container image for a particular purpose (for example one for deploying containers that will run web apps) you can use the container image to create new containers from it. So you can think of a container image as a kind of template for creating new containers for some specific purpose.
Let’s use PowerShell to create a container image for just this purpose i.e. for deploying new containers for running web apps. In the command prompt window, type “powershell” to launch the Windows PowerShell shell:
Figure 14: Step 1 of creating the container image.
Let’s start by using the Get-ContainerImage cmdlet to see whether there are any existing container images present on our container host:
Figure 15: Step 2 of creating the container image.
There’s only one container image and we don’t want to modify it so we’re going to create a new one. But before we do this we need to know the name of the Virtual Switch our VM container host is connected to:
Figure 16: Step 3 of creating the container image.
Use the New-Container cmdlet to create a new container named Container01 as follows:
Figure 17: Step 4 of creating the container image.
Let’s see whether the new container is running or not:
Figure 18: Step 5 of creating the container image.
We need our new container to be running, so let’s use the Start-Container cmdlet like this:
Figure 19: Step 6 of creating the container image.
Check again for the state of the container:
Figure 20: Step 7 of creating the container image.
Now we want to customize our new container by adding the Web Server role to it so we can run some web apps on our container host. To do this, we need to launch a PowerShell session from within our new container. We can do this using the Enter-PSSession cmdlet like this:
Figure 21: Step 8 of creating the container image.
Now we can use the Install-WindowsFeature cmdlet to install the Web Server role in our container:
Figure 22: Step 9 of creating the container image.
At this point we’ve customized our new container Container01 by adding the Web Server role to it. We now need to stop the container and capture a container image from it. Once we’ve done this we can delete Container01 as we’ll no longer be needing it. The series of PowerShell commands shown below accomplish this and leave us with a new container image named IISContainer:
Figure 23: Step 10 of creating the container image.
Creating a container using the container image
At this point we’re ready to create a new “work” container i.e. one that we can actually use for running a containerized web app on our VM container host in Azure. To do this, we simply use the New-Container cmdlet again only this time we specify IISContainer as the name of the container image that should be used to create our new container from. Once we’ve created our new container which we’ll name WebServer01, we can then start it and verify it’s running like this:
Figure 24: Creating a new container from a container image.
Before we can actually access our new containerized web server running in Azure, we will need to perform a few more steps. That’s because the virtual switch for the VM container host by default uses Network Address Translation (NAT) so we can’t simply type the IP address of the container’s network interface into the web browser of our local computer and see the default IIS web page displayed. In fact, what is the IP address of the network interface of our new container? We can use PowerShell to find that:
Figure 25: Displaying the internal (private) IP address of the container.
Now if we had deployed our container in host using the Classic method instead of using Resource Manager, we could simply create a static port mapping in the NAT for TCP port 80 and then configure an inbound firewall rule to allow access to TCP port 80 on our container host in Azure from the outside world. But we’ve chosen Resource Manager as our deployment method here, and that means we’ll need to use a Network Security Group (NSG) instead to accomplish all this. A colleague at Microsoft who I worked with on a System Center ebook for Microsoft will be writing up something for us about NSGs after which we’ll continue with the rest of this demo.
If you would like to read the other parts in this article series please go to:
