Now let's turn our attention to configuring container networking.
Now I'm assuming you're coming out of the previous module
in which we learned about virtual switches and how
networking works in Microsoft Hyper‑V.
Well,
what we have with Docker is a completely separate networking ecosystem, so
I'm going to constrain our discussion only to the overlay between Docker
container networking and Hyper‑V networking.
And I'm just going to call it as the slide says, Windows Container Networking.
So we can see here that on the Windows Hyper‑V host,
we've got VMs or Hyper‑V containers on one side,
and then we have just standard process isolation
Windows containers on the right side.
But notice that both of those containers have a virtual network
interface that interacts with the Hyper‑V virtual switch,
and then, ultimately, especially if you're using the external switch type,
the hardware network interface card on the Hyper‑V host.
So the good news is for our AZ‑800,
we don't have to get into the weeds with the complexities of
Linux networking and Docker networking.
We can look at it this way.
The internal Hyper‑V vSwitch is directly mapped to the Docker NAT network mode,
network address translation.
The external vSwitch,
which in my experience is by far the most popular type of switch
because its surface is your Hyper‑V VMs to your network,
this is mapped to the Docker transparent network mode.
So just think of that in your mind, NAT mode to internal vSwitch,
transparent mode to external vSwitch.
Lastly, let's manage container instances.
I'd mentioned that there's going to be, or likely to be,
some Docker command line interface syntax on your exam,
so don't be surprised.
I mean,
it is surprising in the sense that these certification exams
are vendor specific and they're Microsoft,
not Docker certifications.
On the other hand,
it should not be surprising that we'll see some Docker on our exams because
Microsoft and Docker have formed such a deep relationship.
So here I just have some sample Docker CLI code just to give you some feel.
You've seen, we've come out of a demo, so this is basically just review.
Let's go over it again.
So to build an image from a Dockerfile,
docker build, and then t is to tag the image with,
normally you'll give the image a descriptive label,
colon, and then a version number.
We can do docker image ls to list images on our host. To delete an image,
docker image rm.
To run a Windows container image, this is really the exam alert for your exam,
the fact that you can access those isolation modes when you start the container.
So when you do docker run,
you'll do isolation=hyperv if you want a Hyper‑V Windows Server container,
isolation=process if you want to run the Windows Server container in a
lower security or just a standard Docker container way.
And just to review, docker run means to start the container.
It means to bind to a terminal session,
so instead of starting the container detached with ‑d,
‑it will put you at the command prompt into the container.
And then lastly, after the image name and label,
that's going to be your entry point if it's not already defined in the image.
Here, these docker run commands will put you in a cmd​.exe session.
To manage containers, docker container stop.
There's a number of different ways to do that.
So what I want you to see from the Docker CLI high‑level view is
that Docker CLI behaves quite a bit like the Azure CLI where
you've got the keyword, instead of az for Azure CLI it's Docker,
then you've got your context, build, image,
container, etc, and then you have your command and parameters.
So it's a consistent syntax really.
And I believe that the Azure CLI was definitely designed with the Docker CLI in mind.