Summary
In this article we will learn about Namespace and Control Groups. We will also learn about process behind Containers creation on Windows and Linux Server
Container Big Picture
Namespace and Control Groups
- Containers are Isolated area (Namespace) of the OS with resource uses limits (Control Groups)
- We use 2 building blocks while creating Container: Namespaces and Control Groups
- Namespaces are about isolations and Control group are about grouping objects and setting limits
- Namespace carves Operating Systems into multiple, isolated virtual operation systems. Creates additional isolated user spaces, Containers Image
Isolation with Window Containers:
- Process
- File System
- Environment Variables
- Local User and Groups
Follow the steps below to validate and verify Isolation: ‘Process’, ‘File System’, ‘Environment Variables’ and ‘Local User and Groups’ between Container and Host
- Create container :
- Run following command to open PowerShell in Container:
docker exec -it ISSServer powershell
- Run following command to list scvhost.exe and processes running inside container
tasklist /svc /fi "imagename eq svchost.exe" | Get-process
- In ‘Process Isolation’, all the process running with Job object ID: 776 are Container Process
Once the Container stops, all the process with Job Object ID:776 will stop on the Host
- File System: File System in the Containers are isolate from the File System on Container Host
Eg: File Structure on Container Host
ls c:\
Directory: C:\
Mode LastWriteTime Length Name
—- ————- —— —-
d—– 5/5/2020 8:13 AM Packages
d—– 9/15/2018 7:19 AM PerfLogs
d-r— 5/7/2020 5:17 AM Program Files
d—– 5/5/2020 8:33 AM Program Files (x86)
d-r— 5/5/2020 8:27 AM Users
d-r— 5/5/2020 8:06 AM Windows
d—– 5/6/2020 4:17 AM WindowsAzure
File Structure on Container
docker exec -it ISSServer powershell
ls C:\
Directory: C:\
Mode LastWriteTime Length Name
—- ————- —— —-
d—– 4/14/2020 7:46 PM inetpub
d-r— 4/13/2020 3:39 AM Program Files
d—– 4/13/2020 3:38 AM Program Files (x86)
d-r— 4/13/2020 3:40 AM Users
d—– 4/14/2020 7:46 PM Windows
-a—- 9/15/2018 9:42 AM 5510 License.txt
-a—- 4/14/2020 7:46 PM 168344 ServiceMonitor.exe
File System of the container is provided by Base OS in the Docker Image
Example: When the Container is not running:
When we start the Container, an additional Disk is added in the Disk Management: Disk 03
Disk 03 is removed from the Disk Management (Host OS), when the container is stopped.
- Windows Registry: Windows Registry on Compare are different from Host Registry (Refer HostFile and ContainerFile text file)
- Environment variables : Environment variables of Container are independent of Host Environment variables (Refer HostFile and ContainerFile text file)
Eg: Container Host and Containers have different sets on Environment variables respectively
- Local User and Groups: Local User and Groups on the Container are different from Host Local User and Groups
Eg: New user account created on Container will have access restricted to respective Container. User account created on the Container Host will not have explicit access on Containers
Reference
HostFile and ContainerFiles attached with email for detailed results of Process, FileSystem, Environment Variables and Local Users & Groups
Docker.exe is Client and Dockerd.exe is Daemon Service
smss service runs in every container and make sure that all required system services and process to running before the applications starts
Comparison between Container and Hypervisor
Hypervisor:
- We install Hypervisor on hardware and use it resources (CPU, Memory, Storage and Network) to create one or more virtual machines.
- These VM gets their own slice of virtual memory, CPU, Storage and Network
Container:
- We use Namespace to take host operating system with all its resources (Hostname, Filesystem, Local Users & Groups, Registry, Network and Process Tress) to create multiple virtual operating systems called Containers
- Each containers has its own virtualized Filesystem, Registry, Process Tree, Network and Local User & Groups
Each VM feels like a Physical Server and Each Container feels like Operating System
Each Container share same Kernel with Host Operating Systems (more like virtualized Kernel Space)
Control Groups: Job Objects
- Grouping processes and impose resource limits (CPU, Memory and Disk IO). Control Groups assign compute resource to the Containers and monitor utilization
Docker Engine:
- Docker Client: Run commands like ‘docker run <Container Images>‘. Client take this command and post it as API request to containers Endpoint in the Docker Daemon
- Docker Daemon (Docker API): Implements REST API
- Containerd (Execution and Lifecycle): Container supervisor that handles execution and lifecycle operation (Start, start and pause)
- OCI Layer (Runtime): Interfacing to Kernel
- Client ask Daemon for new container. The Daemon gets Container D to start and manage new container.
- Run C at the OCI layer actually builds the container
Example:
- When we run commands, ‘docker run <Container Images>‘ in the Client, it take this command and post it as API request to containers Endpoint in the Docker Daemon
- So to create the container, Daemon calls Container D over GRPC API on local UNIX socket
- Container D starts a shim process for every container and Run C creates the Container. Once the Container is created, Run C exits leaving container with its shim process connecting it back to Container D
- Run C gets called for every new container
- Container D manages multiple Shims and Run C
In Windows, we have Host Compute Service for building Containers
Docker Architecture: Windows Server & Docker – The Internals Behind Bringing Docker & Containers to Windows – Black Belt
