In-Depth
A Tale of 2 Container Deployments
Base images are used in the creation of containers (although you can also create a container from a container image). In doing so, Windows establishes a dependency between the base image and any container created from it. The container essentially becomes a child of the container image from which it was created. You can easily view this dependency when you create a container. To create a container from the WindowsServerCore base image, use the following command:New-Container –ContainerImageName 'WindowsServerCore' –Name DemoContainerThis command creates a brand new container named DemoContainer (see Figure 3).
[Click on image for larger view.]
Figure 3. The newly created container.
So now that the container has been created, what can you do with it? The first thing you'll want to do is start your container. To do so, use the following command:
Start-Container
DemoContainer
Normally, the next thing you'd do is use Windows PowerShell Remoting to establish a session with the container so that you can begin configuring the container. Doing so might involve using commands like these:
$container = Get-Container –Name DemoContainer Enter-PSSession –ContainerID $container.id –RunAsAdministrator
After establishing a remote session, you can begin installing applications and services into the container. In Figure 4, for example, I've established a remote session into my container and installed IIS.
[Click on image for larger view.]
Figure 4. Establishing a remote session into the container and installing IIS.
Hyper-V Containers
Hyper-V containers are generally the preferred container type because they provide a greater degree of isolation than what's possible using Windows Server containers.
In order to use Windows Server containers, you'll need to download a configuration script from Microsoft. For now this script can be found here. It is possible, however, that Microsoft could use a different URL after the Windows Server release.
For the purposes of this article, I'm assuming the script has been saved to a folder on the server named C:\Scripts and that the server has been configured to use an appropriate Windows PowerShell execution policy. To start using the Hyper-V containers, open an elevated Windows PowerShell window and run the following commands:
C:
Cd\
Cd Scripts
./Install-ContainerHost.ps1
Hyper-V Containers.ps1 –HyperV
It's worth noting this process can take a significant amount of time to complete. In my lab environment the deployment process took roughly two hours to finish.
Current Issues
Microsoft hasn't exactly made a secret of the fact that containers are a work in progress and there's still a significant amount of work to be done prior to the release of Windows Server 2016. Microsoft has even gone so far as to post a Work in Progress page that lists many of the current issues.
The one issue I've encountered and thus far haven't been able to find a solution to is that of IP addressing. If a container is running on Hyper-V, it behaves much like a virtual machine. The container is connected to a virtual network adapter, which is in turn connected to a virtual switch. Networking can be configured at the time the container is created or the administrator can configure networking later by using cmdlets such as Add-ContainerNetworkAdapter and Connect-ContainerNetworkAdapter.
The problem I've encountered is there doesn't currently seem to be any network support for Windows Server containers. Functionally, a Windows Server container is identical to a Hyper-V container. Both container types support exactly the same set of Windows PowerShell cmdlets. However, networking doesn't seem to work for Windows Server containers because it's impossible to associate a virtual NIC with a container unless Hyper-V has been installed. If an administrator were to go through the trouble of installing Hyper-V, then they would presumably use Hyper-V containers instead of Windows Server containers.
Initially, I assumed a Windows Server container would inherit the IP address of the container host. Upon closer inspection, however, Windows Server containers (at least as they're configured here) have no network adapter and no IP address.
It's entirely possible there's a workaround that will allow a Windows Server container to function on a network. As it stands right now, however, the Microsoft documentation focuses solely on Hyper-V with regard to network access for containers and I've been unable to find a workaround myself.
Benefits and Challenges
Containers are an excellent tool for isolating applications from one another. Even so, containers do add an additional layer of complexity and present new management challenges. This will be especially true for administrators with no previous experience with container solutions such as Docker. The best resource that I've found for getting help with container creation and management through Windows PowerShell is a TechNet article that lists all of the available cmdlets.
About the Author
Brien Posey is a seven time Microsoft MVP with over two decades of IT experience. As a freelance writer, Posey has written many thousands of articles and written or contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. When He isn't busy writing, Brien Posey enjoys exotic travel, scuba diving, and racing his Cigarette boat. You can visit his personal Web site at: www.brienposey.com.