If you would like to read the other parts in this article series please go to:
At the end of my previous article, I mentioned that I wanted to take a step back and talk about troubleshooting some common issues. When I wrote of my intentions, I had originally envisioned talking about a few general troubleshooting tips, but had planned on keeping the troubleshooting section relatively short because I wanted to move on and talk about the container creation process. However, Microsoft has derailed my plans by making some changes to the Windows Server 2016 technical preview. In fact, the techniques that I discussed in Parts 3 and 4 of this article series no longer work.
If you think back to Part 3, you may recall that I talked about the need for creating a virtual switch, and I provided you with this command for doing so:
New-VMSwitch –Name “My Virtual Switch” –SwitchType NAT –NATSubnetAddress “172.16.0.0/12”
This command originally worked flawlessly. Part 3 even contained a screen capture showing its use. If you attempt to enter this command into Windows Server 2016 Technical Preview 5 however, then you will receive the error shown in Figure A.
Figure A: The command used in the previous article no longer works.
So what gives? Why did the command suddenly stop working? Well, there is a reason why Microsoft refers to the current Windows Server build as a technical preview. Windows Server 2016 is still a work in progress, and Microsoft is making changes as they refine the operating system in preparation for its eventual release. As a matter of fact, PowerShell even tells you that some changes are coming.
Another cmdlet that I demonstrated in Part 3 of this series was the Get-ContainerHost cmdlet. This cmdlet still works in the current technical preview release, but take a look at Figure B. Microsoft specifically says that it is updating the Containers PowerShell module to better align with Docker.
Figure B: Microsoft is making some changes.
Since Microsoft has changed some of the techniques used to deploy containers, I want to take a step back and show you the new way of doing things. Keep in mind however, that it is entirely possible that Microsoft could make more changes.
The first step in getting ready to use containers is to deploy the Containers feature. This process still works in the same way that it did in Part 3. You can deploy the required feature by entering these commands:
The next step in the process is to install Docker. The first step in doing so is to create a folder that can contain the Docker executables. You can do this by entering the following command:
New-Item –Type Directory –Path ‘C:\Program Files\Docker\’
After creating this folder, you will need to add it to the system path. You can do so by using this command:
[Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\Program Files\Docker", [EnvironmentVariableTarget]::Machine)
You can see what this looks like in Figure C.
Figure C: You must add the newly created Docker folder to the system path.
At this point, you will need to reboot the server. Otherwise, PowerShell isn’t going to recognize the changes that you have made to the system path. After the server reboots, enter the following command:
This command displays the system path. You will need to verify that C:\Program Files\Docker is listed in the system path, as shown in Figure D.
Figure D: C:\Program Files\Docker must be listed in the system path.
Now, you will need to download the Docker client and the Docker daemon. Both of these components will be placed in the C:\Program Files\Docker folder that you previously created. To download these components through PowerShell, enter the following commands:
Invoke-WebRequest https://aka.ms/tp5/b/docker -OutFile $env:ProgramFiles\docker\docker.exe
Invoke-WebRequest https://aka.ms/tp5/b/dockerd -OutFile $env:ProgramFiles\docker\dockerd.exe
Figure E shows what this process looks like. When the download completes, you can verify the existence of the files by typing the following command:
Get-ChildItem “C:\Program Files\Docker”
You can see the command’s output in Figure F.
Figure E: This is what the download process looks like.
Figure F: The files have been placed into the C:\Program Files\Docker container.
Now that the necessary components have been downloaded and verified, the next steps that must be completed are to register Docker as a Windows Server service, and to then start that service. You can accomplish these tasks by entering the following commands:
CD “Program Files\Docker”
It is worth noting that the command that registers the Docker service is case sensitive. It is also worth noting that there are two dashes in front of the word register. You can see these commands in action in Figure G. You will notice that the Get-Service Docker command is used to confirm that the service exists and that it is running.
Figure G: The Docker service is now running.
Now that the Docker service is up and running, we need to install the ContainerImage package provider, and then install our container images. This is a fairly simple, but somewhat time consuming process. Once again, this is something that I covered earlier in the series, but the process has changed a bit.
The actual commands that you will run will vary depending on whether you want to install a Nano Server image or a Windows Server Core image. For the sake of demonstration, I will install both. Here are the commands used for doing so:
Install-PackageProvider ContainerImage –Force
Install-ContainerImage –Name NanoServer
Install-ContainerImage –Name WindowsServerCore
You can see the output from these commands in Figure H. As you look at this figure, you will notice that there is an error message indicating that Images is not a Docker command. The reason why this error occurred was because of case sensitivity. Docker commands (commands that start with the word Docker) are case sensitive. PowerShell cmdlets are not.
Figure H: Here is the output from the image installation.
The last thing that we need to do is to tag our images with the word Latest. This keeps us from having to reference the images by version number each time we use them. There is nothing wrong with referencing the version numbers, but doing so can be tedious. Here is how you tag the images:
docker tag nanoserver:10.0.14300.1010 nanoserver:latest
docker tag windowsservercore:10.0.14300.1000 windowsservercore:latest
If you look at Figure I, you can see that the images have retained their original tags, so we aren’t deleting the version numbers. Instead, we are creating some additional tags.
Figure I: We have added tags to our images.
As you can see, Microsoft has made quite a few changes with regard to containers in Windows Server 2016. In all honesty, I wouldn’t be surprised to see Microsoft make some more changes before Windows Server 2016 is ultimately released. For right now though, the procedures described in this article will allow you to deploy Docker and some images. In Part 8, I will continue the discussion by showing you how to create a container.
If you would like to read the other parts in this article series please go to:
Staying focused at work in an always-connected world is hard! Here’s how to use tech — and some free tools…
Facial recognition technology has matured to the point of being reliable — for better or for worse. What does the…
Cipher suites are a set of algorithms you need to secure your environment, either by using SSL and TLS. Here’s…
Artificial intelligence has greatly improved modern life. But businesses must recognize that AI cyber risks exist and take appropriate measures.
CiraSync offers an enterprise solution for syncing global address list contacts and calendars to smartphones and other mobile devices. Here’s…
HIPAA is the mandatory health regulation that must be followed strictly. But if you’re an IT pro in the health-care…