[Autogenerated] there are basically two types of silos that are supported.
One type is called an application silos,
This is the less interesting silo for our purposes,
this provides some kind of file system redirection for
desktop applications that have been converted UWP using a
technology called the Stockbridge.
So you might recall, we were using wind,
debug preview with debug preview can be downloaded from the Microsoft store.
It might presume that this is a UWP application,
but in fact it is not, it is actually a normal win 32 application based on w Pf,
the Windows presentation foundation technology from .NET which is a
normal application that doesn't adhere to the UWP model.
In fact, however,
it has been converted using the death of bridge technology to UWP in terms
of the way it is deployed and provided to the store.
And this provides an easy way to update the debugger whenever
new updates are available and you may have noticed and of
course we use that multiple times.
We ran the debugger will mean privilege is something that you
normally cannot do for UWP applications.
So the debugger is running in application silo which provides some very
simple file system redirection for temporary files,
but other than that it has no kind of continual
ization capabilities or properties.
So if the debugger goes to something like c temp,
it is the real c temp on the host.
So this is not what we care about here.
The true containers are server silos.
Several silos are the one used ones used to implement Windows containers
by providing isolation for five system registering object namespace and
and that allows us to create true containers.
So we have this virtualization or redirection in the file system.
We have registered virtualization.
So essentially when we go to a certain location in the registry,
it's now private to a container and being redirected to
somewhere on the host and there's also a private object and
namespace And this is the real silo.
This is the thing that allows us to create windows based containers.
So here's the general server silo architecture.
This is what that looks like when you want to actually build
containers and we typically use Docker to do that or other
technologies built on Docker.
Docker started its life in the Linux world but then they
wanted to also move to Windows and Windows can use Docker
to host containers using silos.
And this is what I want to show you here in general and
then we'll see a demo showing exactly what that looks like
and how that works in practice.
So here's an example of host operating system that has
its own executed and colonel of course.
And we want to create a container which doesn't have its
own kernel It only has the applications and user mode parts
of Windows that it requires.
So first we have this thing called container manager,
you can think of that as the API or some kind of application
that is used to create containers destroy containers manage
containers in various ways.
So you can think of that if you compare that to Docker this is
like the command line interface and the engine of Docker that
talks to the Windows kernel to make the appropriate changes to
configure these containers.
So these are not this is not something which is too interesting.
But of course we'll use that in the day.
So now we have a container container has to be built using
something called the based Windows Image as a basis.
So the idea here is that you can get from the Docker hub or from
Microsoft basic Windows images that contain certain aspects of Windows
could be a Windows client or Windows server could have these or those
components you want to start with something in order to have something
which is closest to what you want to use for your applications when
you do that.
Using Docker typically use a Docker file which is like a
script that builds your container images.
A blueprint for creating actual containers.
So you always start with the base Windows Image and then use the script in the
Docker file to add more stuff such as installed applications,
change values in the registry, add users and whatever else you need to do.
And once once you have this image built,
you can create as many containers as you want based on that blueprint image.
So here's one container managed by a silo that's the silo object.
The job object upgraded to being Asylum.
And of course, that image has its own services in its own SMS s its own anti DLL,
its own other processes that we're familiar with like sys rSS and so on.
So everything is being used from the container image.
Except for two things.
One of them is the host anti Dll and that makes sense because it's better
to use the real anti Dll coming from the host instead of the one coming
from the container image because it is perfectly suited to work with the
Real Colonel and has a more wide view than whatever anti DLL is provided by
the container image itself.
Secondly,
SMS S the session manager is also used from the host
rather than from the container image.
And that's because as we'll see, every container is running its own session.
So we need to have the system wide view of sessions and only the
host S M S S S S s coming from the host platform.
Can see that entire view All other services applications are provided by the
container imaging used from the container image itself.
So, here's an example for a process running in the container image.
And so it is part of this particular container and wants to perform
registry operations and file system operations.
And of course,
a process within the container shouldn't really be aware of
the fact that it is part of the container.
This is part of the idea of having that kind of abstraction and illusion
that you're running on a full blown Windows system.
So when the process performs these kinds of operations,
we have to have that kind of redirections as we described.
So, in the case of a fire system,
there's a file system mini filter provided by the kernel
called W C I F S and W C is short for Windows,
containers install about file system and this is the one that's performing a
redirection to a different location in the file system before handing over
the new path to the N T F s file system driver.
So from the container itself, it doesn't really know.
It thinks it's accessing C temp for instance,
but in fact it's accessing completely different location in the file system.
Same goals for the registry.
Here's another container as an example and we have processes here
again using the file system and the registry.
So in terms of the registry,
the kernel contains a registry filter called V rage for
registry virtualization that performs redirection.
If you're coming from a container to the configuration manager
which is the one handling the registry in the Windows candle and
only then the real registry is access.
So again, this is completely transparent to the container.
It has no idea.
It is actually being redirected.
So container is using less resources because it doesn't use a
separate kernel is the same kernel that is on the host,
which is in contrast to a virtual machine which always
has its own kernel and user mode.
So let's see what that looks like when we're using Docker.