[Autogenerated] Here's a summary of what we've seen when looking
at containers when we're working with Docker,
we have a session that is used to host all the
processes that are part of the container.
And there are part of the job of course because the container is managed
by a service silo and the silo is first and foremost a job which has been
upgraded to being silo for the fire system.
We can see there's a mutual drive or virtual volume being created for that.
And we've seen that by mapping to our own dR.
But in general this is not a necessity is just a way to see things from
the host perspective for at least learning purposes.
Then we've seen that the registry is being redirected to a W.
C.
Sub key that you can see in the real registry.
So we have to use the tool that allows you to see the real
registry such as my own total registry and you won't find
it in the normal edit tool.
And we've seen that the container good is kind of the player there
to be able to identify the various parts of the registry that
belong to a particular particular asylum.
So Good is used for that as well.
In terms of object namespace every silo has its own job object I.
D.
And this idea is used as a way to differentiate between different
silos and holding on to their various named objects.
So we've seen there's a silos directory in window B.
J.
That's the most common tool to see the object manager.
namespace can also use my own Object Explorer system,
explore to see exactly the same thing and you see that there's the
subdirectory or sub key which has the job idea and then there's a list of
uh other directories which we'll discuss in the future course and one of
them holds onto this named objects so that there's no collision when you
create a named object called A B.
C.
It's actually going to be called.
From the container perspective what it's going to be
called just a base named object Bc.
But in fact from the host perspective is going to
be called silos the job object.
IDE base named objects and then abc this is what we get when we use Windows
containers which is a very nice technology and wish it would extend to using
graphical applications but currently doesn't support it.
So containers can only run Windows containers at least can only
Orion applications that have no user interface.
So you can run the various servers, they're like web servers,
database servers, any kind of application really.
And you can communicate with the outside world using
normal networking which is also something you can
containerize and configure using Docker.
APIs which also provided uh properly support is provided by the Windows kernel