Create and manage Windows Server container images.
The Hello World type of question when we're
confronted with Docker containers is,
what's the difference between a Docker container and a virtual machine,
and why would you care?
After all, we're administrators, not developers.
Well, as an administrator,
you're probably creating environments that are consumed by your developers.
Virtual machines, as I'm sure you know by now,
are software‑based computer instances that run on top of a hypervisor platform.
So, in Microsoft land, we have Hyper‑V as our hypervisor,
and then in our virtual machine, we have a virtualized set of hardware,
CPU, RAM, network, storage.
Of course, the VMs are all sharing that hardware from the host.
But the point is we've got the full stack within each VM,
a full instance of the operating system,
all software binaries, dependencies, and then your applications.
It's a lot faster nowadays for your developers to do
their test and dev work and even present services in
production using Docker containers.
Now if we compare and contrast, by the way,
this diagram, you can see the attribution URL in the lower left corner,
just wanted to say that, we still have the underlying hardware infrastructure,
but instead of having each container enclosing a full operating system,
which is pretty heavy in terms of disk space and network
bandwidth allocation and just simple upkeep,
we have a single operating system and a single
container engine running on our host,
and each Docker container is simply the application and
its supporting binaries and libraries.
Now there's some underlying smoke and mirrors that are going on.
We can look at Docker containers running on a container host as basically
processes because those containers are all sharing the underlying
container engine operating system and host hardware.
However,
Microsoft put a little wrinkle on that with Hyper‑V
containers that we'll learn about momentarily.
Long story short,
containers represent a way to virtualize individual applications
in a way that's much faster and more portable,
generally speaking, than doing the same thing with big old virtual machines.
Now this notion of application virtualization is not specific to Docker.
In fact,
the underlying techniques in Linux that support containerization predate Docker.
Docker just presented a uniform API for working with those
application virtualization technologies.
And Microsoft and Docker have a really tight partnership.
They've been very close business partners for the last several years; therefore,
it is absolutely in scope for your AZ‑800 and AZ‑801
exams for you to know a bit about Docker,
okay?
So here in this blurry image, sorry, it was the highest res I could find,
it shows the Docker workflow.
To build a container involves first getting hold of an
image or creating your own image.
You create a Docker image by installing the Docker CLI,
Docker command‑line tools, the build tools on your system,
of course, these are available for Windows,
macOS, and Linux, and you create what's called a Dockerfile.
This is a set of instructions using a domain‑specific
syntax that Docker created that provides instructions on
what you want to be in your image,
and you'll always start with an existing image,
and then you can add and subtract from there.
We don't need to get too much deeper into the weeds there.
You do need to know just a little bit about the Dockerfile
syntax in case you see that on your exam,
and I'll show you how to do that in the demo,
so don't worry about that.
But bottom line is your Dockerfile is then built or compiled into an image.
Again, you do this all using the Docker client tools.
That image is a binary snapshot of the container contents,
and this is going to be what you use to run or spawn Docker containers.
That's the highest‑level view here.
Again, the image is the binary deployable unit,
and you'll want to keep your Docker images in a central repository to where
your developers and infrastructure people can get to them.
And because the Docker files are plain text files,
you'll want to keep those in Source Code Control.
In order to run Docker containers, you'll need the Docker server component,
and this is called a daemon, or in Windows,
it'd be a Windows service, the Docker service,
same idea, it's a background process,
and this on the Docker host supports that runtime
environment for your containers.
And of course, we've got support for Windows Server for Docker,
for Windows 10, Windows 11 client, and then Azure as well.
One of the value propositions among many of containerizing
your workloads is that they're universal,
they can run in any environment.
The bottom line is it doesn't matter whether your Docker host is in Amazon or
Google Cloud or Azure or on‑premises or in another provider.
As long as you've got the Docker daemon running,
you should be able to create containers based on those images.
It's a really universal way to develop and deliver software.
This is one of the big reasons why Docker has such a big foothold in the business and software development lifecycle market.