Skip to main content

Development

Docker Bootcamp – Container Isolation Modes

Todd Trapani Mdjxgabn Xe Unsplash

Welcome back to Docker Bootcamp.  In the previous post, we learned about performance and how to tune our containers.  In this post we’ll look at another way to improve the performance of your containers by using process isolation mode.  By default, windows containers run in hyper-v mode.  When we run our containers in hyper-v mode they actually run inside a specialized hyper-v virtual machine. This increases compatibility of images that we can run and keeps containers segregated from the host and other containers. When we run our containers in process isolation mode they run as a process directly on the host.  Process isolation mode increases performance, but is more strict about the host os version and the images that can run.  You can run containers in both modes at the same time on the same host.

Commands

  • pull – Pull an image from a repository
  • run – Create and start a new container
  • stats – Display a live stream of container resource usage statistics

Command Details

You can find a full list of commands and all available flags at https://docs.docker.com/engine/reference/commandline/docker/.

pull

docker pull [options] [registryhost/][username/]name[:tag]

–all-tags -a O Download all tagged images in the named repository

 

run

docker run [options] image [command] [args…]

–isolation O Set isolation mode for container

  • hyperv – Runs the container in hyper-v isolation mode (default)
  • process – Runs the container in process isolation mode

 

stats

docker stats [container]

Examples

My local machine is running Windows 10 20H2.  You can find you windows version by right clicking on the start menu and clicking system.  To run these examples, you can find a version of the windows server core image that matches your local machine https://mcr.microsoft.com/v2/windows/servercore/tags/list.

Docker Bootcamp 17 Windows Version

    • Run a container in hyper-v isolation mode
      • docker run -it –isolation=hyperv –name sc20h2H mcr.microsoft.com/windows/servercore:20H2 powershell.exe
    • Run a container in process isolation mode
      • docker run -it –isolation=process –name sc20h2P mcr.microsoft.com/windows/servercore:20h2 powershell.exe
    • View container stats to compare details
      • docker stats
    • Run a command inside the container
      • ping google.com -n 100

If the version of the container you are trying to run in process isolation mode does not match your host, you will get an error “The container operating system does not match the host operating system”.

Docker Bootcamp 17 Process Isolation Unsupported Version

If the version of the container you are trying to run in either mode is newer than your host, you will get an error “No matching manifest for XXX in the manifest list entries”.

Docker Bootcamp 17 Cannot Pull Later Versions Of Windows

On my local, you can see the difference in the amount of CPU and memory the containers in each configuration.  The process isolation mode container uses less resources since it runs as a process on the host instead of running inside a hyper-v virtual machine.  The process isolation container uses 81% less memory an the hyper-v isolation container!

Docker Bootcamp 17 Server Core Hyperv Vs Process

I tested three other versions of windows containers and found similar memory savings.

Image Memory Usage (Hyper-V) Memory Usage (Process Isolation) Percent Difference
Nanoserver:ltsc2022 246 MB 29 MB 88%
Server:ltsc2022 536 MB 71 MB 86%
Servercore:ltsc2022 400 MB 45 MB 88%

It is important to note that a container running in process isolation mode exposes it’s running process to the host.  When you run the ping command on the process isolation container, you will see PING.EXE listed in the resource manager of the host.  This means containers running in process isolation mode are potentially less secure.

Docker Bootcamp 17 Process Command Visible To Host

Hyper-v containers are more secure as they are isolated from other containers as well as the host.

Real World Usage

I tested the difference between hyper-v isolation and process isolation in a real world example.  The results were even more noticeable in the performance of my machine and my containers.  I created two identical virtual machines (with the exception of the windows version).  They both had 1 logical processor with 4 cores and 32GB of ram assigned.  At the time of the test, only one virtual machine was running on my host.  I used a real Sitecore 10 project that runs several containers at a time.  The results were massively different!

Hyper-V Isolation

Docker Bootcamp 17 Isolation Hyperv A
Docker Bootcamp 17 Isolation Hyperv B

The CPU usage remained at nearly 100% usage.  The vmmem process that manages the memory of the hyper-v virtual machines is off the charts!  27% of the cpu to run the Sitecore CM container.  The overall memory usage was 20.3 GB.  It was so difficult to use my machine.  Let’s not even talk about what happened when I opened Visual Studio or built the solution!

Process Isolation

Docker Bootcamp 17 Isolation Process A

Docker Bootcamp 17 Isolation Process B

The CPU usage spiked as a I navigated the site, but the average usage was much lower and was stable around 30% when the site was idol.  The Sitecore CM container ran at a much more reasonable 8% of the cpu.  The overall memory usage was 9.7 GB.  The machine was much better to use, more responsive, and was able to run Visual Studio with ease.

Final Thoughts

You can dramatically increate the performance of your containers by running in process isolation mode.  Make sure there aren’t any security concerns before doing so and there is an image that matches your host operating system version. If there isn’t an image for the most recent version of windows, you might have to postpone upgrading your host machine (which has its own security risks).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Eric Sanner, Solutions Architect

More from this Author

Categories
Follow Us