The docker container run command creates a container from an image and starts the application inside the container. It's actually equivalent to running two separate commands, docker container create and docker container start, which shows that containers can have different states. You can create a container without starting it, and you can pause, stop, and restart running containers. Containers can be in different states, and you can use them in different ways.

The dockeronwindows/ch02-powershell-env image is an example of a packaged application that is meant to run in a container and perform a single task. The image is based on Microsoft Nano Server...

Docker images are layered. The bottom layer is the operating system, which can be a full OS like Windows Server Core, or a minimal OS like Microsoft Nano Server. On top of that are layers for each change you make to the base OS when you build an image - by installing software, copying files, and running commands. Logically, Docker treats the image as a single unit, but physically, each layer is stored as a separate file in Docker's cache, so images with a lot of common features can share layers from the cache.

Images are built using a text file with the Dockerfile language - specifying the base OS image to start with, and all the steps to add on top. The language is very simple, and there are only a few commands you need to master in order to build production-grade images. I'll start by looking at the basic PowerShell image I've been using...

The goal of building an image is to package your application in a portable, self-contained unit. The image should be as small as possible, so it's easy to move around when you want to run the application, and it should have as few OS features as possible, so it has a fast startup time and a small attack vector.

Docker doesn't impose restrictions on the image size. Your long-term goal may be to build minimal images that run lightweight .NET Core applications on Linux or Nano Server. But you can start by packaging your existing ASP.NET apps in their entirety as Docker images to run on Windows Server Core. Docker also doesn't impose restrictions on how to package your app, so you can choose from different approaches.

Applications running in a Docker container see a single filesystem that they can read from and write to in the usual way for the operating system. The container sees a single filesystem drive but it's actually a virtual filesystem, and the underlying data can be in many different physical locations.

Files that a container can access on its C drive could actually be stored in an image layer, in the container's own storage layer, or in a volume that is mapped to a location on the host. Docker merges all these locations into a single virtual filesystem.

The virtual filesystem is how Docker can take a set of physical image layers...

Microsoft has made the Windows Server Core base image available on Docker Hub, and that's a version of Windows Server 2016 which has much of the functionality of the full server edition but without the UI. As base images go, it's very large - 5 GB compressed on Docker Hub, compared to 380 MB for Nano Server, and 2 MB for the tiny Alpine Linux image. But it means you can Dockerize pretty much any existing Windows app, and that's a great way to start migrating your systems to Docker.

Remember NerdDinner? It was an open source ASP.NET MVC showcase app, originally written by Scott Hanselman and Scott Guthrie - among others at Microsoft. You can still get the code at CodePlex, but there hasn't been a change committed since 2013, so it's an ideal candidate for proving that old ASP.NET apps can be migrated...