Getting Started With Containers (Part 8)

by [Published on 7 Dec. 2016 / Last Updated on 7 Dec. 2016]

In this article we'll discuss interacting with a Windows Server container.

If you would like to be notified when Brien Posey releases the next part in this article series please sign up to our VirtualizationAdmin.com Real-Time Article Update newsletter.

If you would like to read the other parts in this article series please go to:

In my previous article in this series, I started out by posing the question – how do you interact with containers? I partially answered that question by showing you how to create a Web server container. In doing so, we created a new base image, installed IIS, added some custom Web site code, and then created a container. Even so, the question of how you can interact with the container still remains.

Interacting with a Windows Server container really isn’t that different from interacting with a virtual machine. There are however, a couple of key differences.

The key to interacting with a container is to understand that a container receives the same types of resources as any other Windows Server environment. Let me show you what I mean. In the screen capture below, the black PowerShell window is running inside of a container. I used the Docker Run command and used the -it switch to run the container interactively. I appended the CMD command to the Docker Run command, which caused the container to open a Command Prompt window. From there, I launched a PowerShell session.

Image

The blue PowerShell window is running natively on the host server. This window is not running inside of a container.

The reason why I wanted to show you these two windows is to illustrate the point that although they are running on the same server, they have different computer names and different IP addresses. This is the key to interacting with containers.

For the purposes of demonstration, I am running a generic IIS container. If you look at the figure below, you can see that my container is named Microsoft/iis.

Image

I downloaded this container directly from Microsoft by using the following command:

Docker pull Microsoft/iis

As it stands right now, this container is running a default configuration, and is completely unmodified. So with that said, let’s take a look at some ways of interacting with the container.

You have already seen one way that we can interact with the container. In the first figure in this article, I ran the container interactively, and was able to run PowerShell inside of the container. This method works great for the initial configuration process, but in a production environment you probably won’t be running containers interactively. So let’s take a look at what else we can do.

Another thing that we can obviously do is to access the application that is running inside of the container. I briefly mentioned this technique in one of the previous articles, but I want to show you what the process actually looks like.

If you look back at the first screen capture in this article, you will notice that the IP address that has been assigned to the container exists in a different subnet than the IP address used by the host server. Since the container is hosting a Web server, I should theoretically be able to enter the Web server’s IP address into a browser to see the default Web site. In this case however, it does not work because there is no path to the address.

Image

What I can do instead is to stop the container by typing Exit a couple of times, remove the container, and then run the container using a port mapping that maps the host computer’s port 80 to the container’s port 80. That way, any traffic arriving at the host computer on port 80 will be forwarded to the container. The actual command sequence that I used to accomplish this is:

Exit
Exit
Docker rm $(docker ps -a -q)
Docker run -d -p 80:80 microsoft/iis ping -t localhost

You can see the full command sequence shown below. The screen capture contains a couple of extra commands that I included just to make the process a bit clearer.

Image

Now, if I open a browser (on a different computer) and enter the IP address of the host server, I am presented with the container’s default Web site.

Image

Of course this raises the question of how you can manage IIS. For right now, the only real option seems to be to manage IIS through PowerShell. In theory, it should be possible to use the Internet Information Services (IIS) Manager to connect to the containerized Web application. However, Windows Server 2016 has not yet been released, and in spite of spending several hours attempting such a connection, I could not get it to work. Presumably, it will be possible to manage containers using graphical tools once Windows Server 2016 is eventually released.

As you may recall, I used this command to run the Microsoft/iis container:

Docker run -d -p 80:80 microsoft/iis ping -t localhost

This command provides port redirection for Port 80 so that traffic destined for port 80 is redirected to the Web server. My approach was to implement port redirection for the IIS Manager as well. The IIS Manager uses port number 8172 to connect to a Web server. As such, I ran the following command in order to force port redirection for both Port 80 and port 8172:

Docker run -d -p 80:80 -p 8172:8172 microsoft/iis ping -t localhost

Unfortunately, I never successfully established connectivity from the IIS manager to the Microsoft/iis container. In case you are wondering, I did check the required services, the firewall configuration, the container password, and anything else that I could think of. I have to assume that this functionality either does not yet work, or will not be supported. Even so, it is possible to fully manage IIS through PowerShell.

So how do you connect PowerShell to a Docker container when the container is not being run interactively? At first, this seems to be a major challenge. Remember, as it stands now, our container is on an isolated subnet so we can’t just use the Enter-PSSession cmdlet. Fortunately, Docker can help with this problem.

If you type Docker ps -a, you will see a list of all of the running containers. Each container has been assigned a name. You can use the Docker Attach command, followed by the container name to open a session with the container. As it stands now however, this doesn’t do us a lot of good. Remember, the command that we specified for the container was an infinite ping loop. As such, the connection to the container looks something like this:

Image

If however, you run the container interactively, and specify either cmd or PowerShell.exe as the command to run, then you can close the PowerShell window and reattach to the Docker container using the Docker attach command.

As it stands right now, the process is a bit buggy, but should be fixed by the time that Windows Server 2016 is released. If you look at the figure below, you can see that I used the Docker ps command to retrieve the container name, and then used Docker attach to connect to the container. At that point, the window appears to lock up. However, you can press Enter to be returned to a PowerShell prompt. When you are done interacting with the container, you can type Exit. The console won’t look any different, but to prove that I was indeed working inside of a container, I typed the DIR command before and after exiting the container. As you can see in the figure, the container has a different directory than the host server.

Image

In spite of the impending release date, Microsoft still has some work to do on its containers. Even so, containers should eventually be a very beneficial feature that changes the way that workloads are run on Windows servers.

If you would like to be notified when Brien Posey releases the next part in this article series please sign up to our VirtualizationAdmin.com Real-Time Article Update newsletter.

If you would like to read the other parts in this article series please go to:

See Also


The Author — Brien M. Posey

Brien M. Posey avatar

Brien Posey is an MCSE and has won the Microsoft MVP award for the last few years. Brien has written well over 4,000 technical articles and written or contributed material to 27 books.