Good day, Cloud Gurus,
and welcome back for this lesson where we're going to take
an introductory look at Windows containers.
First up, we'll briefly introduce the concept of containers,
and then we'll explore Docker in a little bit more detail.
We'll also take a look at container images,
and we'll cover off the Windows Server container
base images that are available to you
when you're running and deploying Windows containers.
And we'll also cover off the container isolation modes
that are available on Windows Server.
And we'll also take a look at
the container networking drivers
available on Windows Server.
And we'll wrap up with a demo where we'll configure
our Windows container host.
Let's get started.
One of the biggest challenges and often repeated challenges
that I faced as a systems administrator
has been the deployment of new applications.
Often, these applications were developed and tested
in environments that differ greatly
from the production environment that I was managing,
and, because of this, there were often deployment issues
related to security settings that were more relaxed
in the development environment or other configurations,
like the versions of Windows Server
or the required application dependencies
not being well defined.
Containers aim to solve this problem
and a number of other problems with application deployment.
Containers are an application package that includes
everything the application needs to run,
including all of the configuration and prerequisites,
which removes the dependency on the host operating system.
The process of creating a container
to run your application with all of its dependencies
is referred to as containerization.
And the end product of a containerized application
is referred to as a container image.
And one of the benefits of containers is that containers
have the ability to run anywhere,
including your local workstation,
using something like Docker Desktop, on your servers,
or they can be even deployed directly to the cloud.
Now regardless of where they are deployed,
they offer a consistent development
and deployment environment.
And containers provide an isolated environment
that cannot interfere with other workloads
or have other workloads interfere with them,
which means you can run more applications
without the risk of conflicts between those applications
when running them on the same server.
And containers only require minimal resources to run,
which results in increased efficiency
over things like virtual machines.
And containers also start and stop faster than VMs,
allowing you to more quickly scale to meet demand.
Now let's take a look at Docker.
Docker is a collection of tools used to package
and ship containerized applications.
Now it's not the only set of tools you can use to do this,
but it is considered the industry standard
and it is supported on Window Server.
Let's take a look at the components that make up Docker.
You'll spend most of your time, at least in the early days,
when you first start to use Docker
using the command-line interface or Docker CLI.
And the Docker CLI is what you use
to interface with the container engine.
And container images are stored in a registry.
Docker Hub is a really popular container registry,
and Azure also has the Azure Container Registry as well.
And the container engine pulls the image from the registry,
prepares it, and hands it off to the container runtime.
And the container runtime is responsible
for running the container on the server.
And when you need to save credentials, for example,
those that you use to access the registry,
Docker has a credential helper that you can use
to securely save those credentials.
And once you start to deploy
more complex containerized applications
and define how those containers will work together,
you will start to use an orchestrator.
An orchestrator interacts with the container engine
to orchestrate the deployment of containers.
Docker Compose and Kubernetes
are 2 popular container orchestration frameworks.
Now let's take a look at container images,
which are your containerized application.
The container image is made up of layers.
The first layer in a container image is the Base OS layer.
On Windows, this layer defines which Windows
operating system image your container should use
and which Windows API features your application
can leverage depends on your base container image.
And we'll take a look at the options you have
for your base image later on in this lesson.
The next layer in your container image are the dependencies
that your application needs to run.
This might be .NET or some other libraries
that your application depends on.
And the next layer up in your container image
is the application layer.
And this is the software that runs in the container.
And each of these layers,
when layered on top of the base image,
create your container image.
And when you're using Docker,
you define container images using a Dockerfile.
A Dockerfile contains the instructions
to create your container image
and which command to run when your container starts.
And you can also tag the images you create with a version.
And the most commonly seen version
of an image is the latest version,
which indicates it's the latest version
of the image that you've created.
Now when building container images that run Windows,
you have 4 base images to choose from,
and it's important to select the correct base image
to run your application.
The first of these is Windows Server Core,
and it has a subset of the Window Server APIs
and supports traditional .NET Framework apps.
The next option is Nano Server,
and it's designed to be used with .NET Core applications
and has the smallest footprint of all of the base images.
And then we have the Windows base image,
and it includes the full Windows API set
and is based on Windows Server up until Windows Server 2019.
And then finally, we have the Windows Server base image,
which also provides the full Windows API set
and is available starting with Windows Server 2022.
Now you're likely going to land on either
Windows Server Core or Nano Server for your base image,
as these are the most efficient images.
You'll pick Windows Server Core
for traditional .NET Framework apps,
and you'll choose Nano Server for .NET Core apps.
And only choose Windows Server or the Windows image
when you require additional compatibility
that's not available in the smaller base images.
Now we know from our previous lessons
on Hyper-V virtual machines,
that virtual machines run on top of a hypervisor.
And that hypervisor runs directly on top of the hardware.
And the host operating system runs in a separate partition
to the virtual machines, but also on top of the hypervisor,
but the host operating system
has more direct access to the hardware.
Containers, on the other hand, are very flexible.
When your containers share the same operating system image
or an image that is compatible
with your Windows container host,
you can run your containers directly
on the host operating system in an isolated process.
And this is referred to as running your container
in process isolation.
And this is the default isolation mode
on a Window Server container host.
But if you require a higher level of isolation
between your containers and the host operating system,
you can also choose to run your containers
inside a highly optimized virtual machine.
This allows your containers to run
a different operating system kernel.
For example, running a Linux container
on a Windows Server container host.
And this is referred to as Hyper-V isolation.
And as the default isolation mode on Windows clients,
like Windows 10 or Windows 11,
the virtual machine that the container runs on
isn't a traditional VM, and therefore,
isn't visible in Hyper-V Manager,
but you can view the running VM worker process
using something like PowerShell.
Choose process isolation for improved efficiency
when your containers share a compatible
operating system kernel with your Windows host,
and choose Hyper-V isolation when you need to run
a different operating system kernel
or you need to provide a higher-level
of security through isolation.
Containers on a Windows container host are provided
with network connectivity using a virtual network adapter.
And this is not too dissimilar
to the way Hyper-V VMs get their network connectivity.
And there are 5 different network drivers
that you can use with containers
on a Windows container host.
Let's take a high-level look at each of them.
The first of these is NAT, and it's equivalent
to a Hyper-V internal virtual switch with NAT enabled.
And it's created by default when Docker is installed.
The next is transparent, and it's equivalent
to a Hyper-V external virtual switch
and is connected to a network adapter on the container host.
And it's good for development and small deployments.
And then we have the overlay network driver,
and it's used to allow containers to communicate
with each other across container hosts
and it's good for large multi-node deployments.
And we also have the Layer 2 bridge network driver,
and it also uses a Hyper-V virtual switch,
but couples it with MAC address rewrite
to the host's MAC address.
And the reason for this is because containers
can be short-lived, the Layer 2 bridge is used
to ease the burden of learning multiple MAC addresses
on physical network switch.
And a Layer 2 bridge is good for use with Kubernetes.
And the last networking driver
to be aware of is the Layer-2 tunnel.
It's identical to the Layer-2 bridge,
but is designed to work in Azure Virtual Networks.
And it adds support for things like
network security groups in Azure.
All right, let's take a quick look at a demo
of configuring a Window Server container host.
In this demo, we will deploy Docker
to a Window Server using Package Management, and
that will install the container engine, runtime, and CLI.
And then we will confirm the Docker installation
using the Docker CLI.
And, finally, we'll view the default container networking
also using the Docker CLI.
Let's take a look.
All right, so here I am logged onto the server
that we're going to configure as our container host.
First, we need to go ahead and install
the Docker Microsoft Package Management provider
from the PowerShell Gallery.
To do that, we're going to use Install-Module,
we'll specify the name of the module that we want to
install, which is the DockerMsftProvider,
and then we want to download this module
from the PowerShell Gallery,
and then we'll specify to force the install.
We'll go ahead and press Enter to run that.
And we also need to upgrade NuGet,
so we'll go ahead and do that.
And we'll confirm that with Yes.
All right, now we can go ahead and install
the latest version of Docker using Package Management.
And to do that, we'll use the Install-Package
PowerShell cmdlet, we'll specify the name of Docker,
and we'll specify the provider name
as the DockerMsftProvider that we just installed.
We'll go ahead and press Enter to run that.
And this'll just take a moment to install,
so we'll come back when this is done.
All right, Docker's now successfully installed,
and we need to go ahead and restart the server
to complete the installation.
So we'll go ahead and restart the server
using the Restart-Computer PowerShell cmdlet,
and then we'll come back once this server has restarted.
All right, the server's finished restarting,
so let's go ahead and launch PowerShell again.
And now let's go ahead and run the docker version command
to confirm that Docker is installed.
All right, and we can see that Docker
is installed correctly.
Now let's go ahead and view the default networking
that is created when we install Docker.
So we'll go ahead and run the docker network ls command.
And we can see we have that default nat network
that is created when Docker is installed.
All right, we'll dive into the Docker commands
in more detail in upcoming lessons,
but, for now, that concludes this demo.
Let's go ahead and wrap up with a bit of a summary
of what we've covered in this lesson.
All right, so what have we covered?
A containerized application is stored in a container image,
and that container image is stored in a container registry.
And a Dockerfile contains the instructions to create
your container image and which command to run
when your container starts.
And running your containers directly on a container host
in an isolated process is referred to as process isolation,
whereas running your containers in a lightweight
virtual machine on the container host
is referred to as Hyper-V isolation.
And the five container networking drivers are NAT,
transparent, overlay,
Layer-2 bridge, and Layer-2 tunnel.
All right, thanks for being with me in this lesson.
I hope you found it useful,
and I look forward to seeing you in the next lesson.