In part 2 of 2 blog posts, Premier Developer Consultant Julien Oudot continues his networking tips about Azure Virtual Machine Scale Set (VMSS) and Windows Containers. Building on the first post about VMSS set-up, Julien walks through how to communicate with containers running on nodes deployed as part of VMSS.

If you haven’t read it yet, do not hesitate to look at the part 1 of the article which describe the 2-node VM Scale Set (VMSS) set up in Azure as well as some tips to make sure the two nodes are up. In this second part, we are going to talk about how to communicate with containers running on the nodes deployed as part as the VMSS (NAT networking mode only):

• When running a Windows Container in one of your node, test the connectivity to this container from the node hosting it.
• When running Windows containers in your nodes of the VMSS, test the connectivity to another container running on another node.

Network connectivity between the host and the running container

Another configuration where we might want to test the communication would be between a container and the host of this container.

To try that, we can just run the container and attach it to a particular port of the host with the command docker run -d -p 8081:80 microsoft/iis:nanoserver-sac2016

Then using docker ps, we can see the container image id and use it in docker inspect <image_id> to find the internal IP of the running container.

Relevant result of docker inspect:

Because we are in NAT networking mode, this IP is only accessible from the host where the container is running. So, we can just use ping <ip> to check that the container is up and running or Test-NetConnection <ip> -Port <container_port> would help.

Note that Test-NetConnection needs to target the container port 80 and not the host port 8081. Otherwise, we see the following error telling us that also we can ping the IP, we cannot open the TCP connection on port 8081 of the container.

Our current example being IIS, we could just open a browser and call the URL http://<internal_ip>:80/ but I have been working on containerizing a networking daemon for one of my customers. And in this scenario, I did not have such a way to test it. The tools described above have the advantage of working on different type of containerized workload instead of relying on the browser.

Network connectivity between containers running on different nodes (NAT only)

In this configuration, we want to check from another node that we have the container running on a particular port of another host and that we have network connectivity with the container.

Again, our current example being IIS, we could just open a browser and call the URL http://<hostname>:8081/ but what we want is a method that would work for any kind of workload running in this container.

In a NAT networking mode, we are going to use the host hostname and the exposed port as an entry point. With the command Test-NetConnection <hostname> -Port <exposed_port>, we can see the TCP test succeeding.

On the other hand, when trying the same command on a port where nothing is running, the result is different. We can see that ping succeeded but we were not able to open a TCP connection on the port.

To go one step further, we might want to test that we are still able to reach the container running in vmssblogv000002 from a container running in vmssblogv000001 (we have just tested the connectivity from the vmssblogv000001 host so far).

From vmssblogv00001, let starts a Windows Server Core container in interactive mode with the command docker run -it microsoft/windowsservercore powershell.

First, it is worth mentioning that we can ping both hostnames from the container.

And since we can access the remote host vmssblogv000002, we can also use Test-NetConnection on the port we want to check. This is using the host as an entry point. If your workloads need direct container-to-container communication, the NAT networking mode is probably not the best solution.

These configuration and commands are the basics to start playing around with networking communications when running Windows Containers in a VMSS in Azure. If you want to go deeper, here are more advanced networking configuration to explore here.