How To Run Multiple Linux Commands in Linux Terminal

Alright, let’s talk Docker and Windows. You’ve probably heard the buzz about containers revolutionizing how we build, ship, and run applications. Docker is usually synonymous with Linux, but what if your world revolves around Windows applications, .NET Framework, IIS, or other Microsoft technologies? Can you leverage the power of Docker in a Windows environment? The answer is a resounding yes, but with some important nuances.

The phrase “Run Windows in Docker” can mean a couple of different things, and it’s crucial to understand the distinction right from the start. This guide will walk you through the official and supported way – using Windows Containers – explaining what they are, why you’d use them, how to get started, and what limitations to keep in mind. We’ll cover everything from setting up your environment to running pre-built images and even crafting your own. Forget Voodoo magic; this is about practical containerization for Windows workloads. Let’s dive in!

Table of Contents

Clearing the Air: What Does “Running Windows in Docker” Really Mean?

Before we jump into the “how,” let’s clarify the “what.” When people search for running Windows in Docker, they often have slightly different ideas in mind.

Understanding Docker: Containers vs. Virtual Machines (A Quick Analogy)

Think of traditional Virtual Machines (VMs) like building separate houses on a plot of land. Each house (VM) has its own foundation, walls, plumbing, electricity, and a full operating system. They are well-isolated but resource-heavy.

Containers, on the other hand, are more like apartments in a building. They share the building’s foundation and core infrastructure (the host operating system’s kernel) but have their own isolated living spaces (processes, filesystem, network stack). This makes them much lighter, faster to start, and more efficient in resource usage compared to VMs.

Docker is the most popular tool for building, managing, and running these “apartments” or containers. It started in the Linux world, sharing the Linux kernel between the host and containers.

Introducing Windows Containers: The Native Approach

Because Docker containers share the host OS kernel, you couldn’t traditionally run a Windows application (which needs the Windows kernel and APIs) directly inside a Docker container on a Linux host. Microsoft saw the container revolution happening and worked with Docker to create Windows Containers.

Windows Containers allow you to package and run Windows applications and their dependencies in isolated environments on a Windows host. Crucially, these containers share the Windows kernel with the host OS or use a lightweight Hyper-V virtualized kernel. This is the official, supported, and most common way to “run Windows in Docker.” You’re not running the entire Windows OS in the traditional sense; you’re running Windows applications containerized on a Windows host.

Why Not Just Run Full Windows 10/11 in a Container? (The Big Caveat)

This is a common question. Can you spin up a full graphical Windows 10 or 11 desktop inside a Docker container like you might a Linux distribution? Technically, yes, but practically, it’s not the intended use case and comes with major hurdles:

Not Native Docker: It involves running a full VM inside the container using tools like QEMU. This negates many Docker benefits (lightweight, speed).
Resource Intensive: You’re essentially running an OS within an OS, demanding significant RAM and CPU.
Licensing Issues: Windows desktop licenses generally don’t permit running within a containerized or virtualized environment in this manner without specific, often expensive, volume licensing or VDA licenses. Running an unlicensed Windows copy, even temporarily, violates the EULA.
Complexity: Setting this up is far more complex than standard Docker workflows.

So, when we talk about “Running Windows in Docker” in this guide, we’re focusing on the official Windows Containers feature for running applications and services, not emulating a full desktop OS.

Why Bother? The Benefits of Using Windows Containers

Okay, so we’re containerizing Windows applications, not the whole desktop OS. Why is this useful? The advantages mirror many of the reasons developers love Docker on Linux:

Streamlining Development Environments

Imagine onboarding a new developer for your .NET Framework project. Instead of a multi-page setup guide involving installing specific SDK versions, configuring IIS, setting up databases, etc., you can provide a Dockerfile or a Docker Compose file. They run one or two commands (docker build and docker run or docker-compose up), and voilà! A consistent, isolated development environment matching production is up and running in minutes. No more “it works on my machine” headaches.

Modernizing Legacy .NET Framework Apps

Got older ASP.NET or WCF applications running on aging Windows Servers? Containerizing them is a powerful first step towards modernization. You can package the application and its specific dependencies (like .NET Framework 4.x) into a container image without touching the underlying application code significantly. This allows you to deploy these legacy apps onto modern infrastructure (like newer Windows Server versions or even cloud container orchestration platforms like Azure Kubernetes Service with Windows nodes) more easily and consistently. It buys you time and flexibility for eventual refactoring or rewriting.

Enhancing CI/CD Pipelines for Windows Workloads

Continuous Integration and Continuous Delivery (CI/CD) pipelines thrive on consistency and speed. Windows Containers provide a predictable artifact – the container image – that can be built, tested, and deployed across different stages automatically. Tools like Jenkins, Azure DevOps, or GitHub Actions have excellent support for building and pushing Windows container images, making your Windows application delivery pipeline much more robust and efficient. Testing becomes faster as you can spin up clean environments for each test run.

Deploying Windows Services (IIS, SQL Server Express, etc.) Efficiently

Need to run specific Windows services like Internet Information Services (IIS) to host a website, or maybe a SQL Server Express instance for development or testing? Microsoft provides official container images for many common Windows workloads. Pulling and running these images is often much faster and cleaner than performing manual installations on a host or VM. You can configure them via environment variables or configuration files mounted into the container.

Setting the Stage: Prerequisites for Windows Containers

Ready to get started? First, you need to ensure your system is prepared. Running Windows Containers requires a Windows host machine.

Host System Requirements (Windows Version Matters!)

This is crucial. You need a compatible version of Windows:

Windows 10/11 Pro, Enterprise, or Education (64-bit): Version 1607 (Anniversary Update) or later is technically required, but using a recent version (like Windows 10 21H2+ or Windows 11) is highly recommended for better features, performance, and compatibility. Windows Home edition is not directly supported for native Windows containers, though Docker Desktop can use the WSL 2 backend on Home which involves a Linux VM layer (more on this below).
Windows Server 2016, 2019, or 2022 (Standard or Datacenter): These server editions are built for hosting containers.

You’ll also need sufficient RAM (8GB+ recommended, 16GB+ is better, especially if using Hyper-V isolation) and CPU virtualization features enabled in your system’s BIOS/UEFI (often called Intel VT-x or AMD-V).

Installing Docker Desktop for Windows (The Easy Button)

The simplest way to get Docker running on your Windows 10/11 machine is by installing Docker Desktop for Windows.

Download it from the official Docker website.
Run the installer and follow the prompts. It usually handles enabling the necessary Windows features for you.
A restart is typically required.
After restarting, Docker Desktop should start automatically. You’ll see the whale icon in your system tray.

Note: Docker Desktop has licensing terms that changed in 2021. It’s free for personal use, small businesses (under 250 employees AND less than $10 million annual revenue), education, and open-source projects. Larger enterprises require a paid subscription. On Windows Server, you typically install the Docker Engine (Moby) directly using PowerShell commands, not Docker Desktop.

Configuring Docker Desktop: WSL 2 vs. Hyper-V Backend

Docker Desktop on Windows can use two different backends to run containers:

WSL 2 (Windows Subsystem for Linux 2): This is the default on modern Windows versions. It uses a lightweight Linux VM running under WSL 2 to host the Docker daemon. This provides excellent performance for Linux containers. To run Windows containers, you still need the Windows Containers feature enabled on your host, and Docker Desktop seamlessly switches context when needed. Even if WSL 2 is the backend, you can still run Windows containers!
Hyper-V Backend: This older method uses a more traditional Hyper-V VM (MobyLinuxVM). It’s generally less performant than WSL 2 for Linux containers.

You can usually stick with the default (WSL 2). Docker Desktop includes a toggle in its settings (under General) to “Use the WSL 2 based engine.” Crucially, you also need to ensure the “Enable integration with my default WSL distro” is checked (under Resources > WSL Integration) if you want to run Docker commands from within your WSL 2 Linux environments. However, for running Windows containers, the key is enabling the Windows feature itself. Right-click the Docker tray icon and ensure “Switch to Windows containers…” is selected if you’re currently in Linux container mode.

Enabling Necessary Windows Features (Containers / Hyper-V)

Docker Desktop often handles this during installation, but you can verify or do it manually:

Search for “Turn Windows features on or off” in the Windows search bar.
Ensure that “Containers” is checked.
Ensure that “Hyper-V” is checked (specifically the “Hyper-V Platform”). Even if using process isolation, some components might be needed, and it’s required for Hyper-V isolation mode and often for Docker Desktop’s underlying mechanisms.
If you’re using the WSL 2 backend, ensure “Virtual Machine Platform” and “Windows Subsystem for Linux” are also checked.
Click OK and restart your computer if prompted.

With your system prepped and Docker Desktop installed and configured, you’re ready for action!

Getting Hands-On: Running Your First Windows Container

Let’s get to the fun part – actually running a Windows container.

Choosing Your Windows Base Image: The Foundation

Unlike Linux where alpine, ubuntu, or debian are common base images, Windows containers use specific images provided by Microsoft, hosted on the Microsoft Container Registry (MCR). The main choices are:

Windows Server Core: The Workhorse

Image Name Prefix: mcr.microsoft.com/windows/servercore
Description: This is the most common base image. It includes a subset of Windows Server components, supporting traditional applications like .NET Framework apps, IIS, and other Windows Server roles. It has no GUI but provides PowerShell and Command Prompt access. It offers good compatibility but is larger than Nano Server.
Example Tag: ltsc2022 (Long-Term Servicing Channel for Windows Server 2022 compatibility)

Nano Server: Lean and Mean

Image Name Prefix: mcr.microsoft.com/windows/nanoserver
Description: An extremely stripped-down, optimized image for modern applications (.NET Core/.NET 5+). It’s much smaller and has a reduced attack surface. However, it lacks compatibility for many older applications and APIs (including full .NET Framework and many GUI-related DLLs). It’s primarily command-line/PowerShell driven.
Example Tag: ltsc2022

Windows Image: For More Compatibility (But Larger)

Image Name Prefix: mcr.microsoft.com/windows
Description: This image builds upon Server Core and includes additional components like DirectX, providing broader compatibility for certain types of applications (e.g., some automation tasks needing graphics APIs), but it’s the largest of the three. It’s generally less common unless specific dependencies require it.
Example Tag: ltsc2022

Choosing the right image: Start with Server Core if you need .NET Framework support or standard Windows Server features. Use Nano Server for modern .NET (Core/5/6/7+) applications where size and security are paramount. Only use the Windows image if Server Core proves insufficient due to missing libraries. Always try to use specific version tags (like ltsc2022, 1809) rather than latest for predictable builds.

Pulling an Image from Docker Hub (e.g., `mcr.microsoft.com/windows/servercore:ltsc2022`)

Let’s pull the Server Core image compatible with Windows Server 2022 / Windows 11. Open PowerShell or Command Prompt (as Administrator is often recommended for Docker operations on Windows):

docker pull mcr.microsoft.com/windows/servercore:ltsc2022

This command contacts the Microsoft Container Registry and downloads the specified image layers. Be patient – Windows images are significantly larger than typical Linux images (Server Core can be several gigabytes!). You’ll see download progress bars.

Running a Simple Interactive Container (`docker run -it ... cmd`)

Once the image is pulled, you can run a container from it. Let’s start an interactive command prompt session inside a new Server Core container:

docker run -it --rm mcr.microsoft.com/windows/servercore:ltsc2022 cmd.exe

Let’s break down this command:

docker run: The command to create and start a new container.
-it: Short for -i (interactive, keep STDIN open) and -t (allocate a pseudo-TTY). This lets you interact with the container’s shell.
--rm: Automatically remove the container when you exit it. Useful for temporary sessions.
mcr.microsoft.com/windows/servercore:ltsc2022: The image to base the container on.
cmd.exe: The command to execute inside the container once it starts.

You should now see a command prompt that looks something like C:\>. You are inside the container! Try running commands like dir, ipconfig, ver, or hostname. You’ll see you’re in an isolated Windows environment based on Server Core. Type exit to leave the container (it will be removed because of --rm).

Congratulations! You’ve successfully run your first Windows container.

Building Your Own Windows Container Images with Dockerfile

Running pre-built images is great, but the real power comes from packaging your own applications. This is done using a Dockerfile.

Understanding the Dockerfile for Windows

A Dockerfile is a text file containing instructions on how to build a Docker image. The syntax is largely the same for Windows and Linux containers, but the base images and commands you run inside will differ. Key instructions include:

FROM: Specifies the base image (e.g., mcr.microsoft.com/windows/servercore:ltsc2022).
WORKDIR: Sets the working directory for subsequent instructions.
COPY: Copies files from your host machine into the container image.
RUN: Executes commands inside the container during the build process (often used for installing software, e.g., using PowerShell).
EXPOSE: Informs Docker that the container listens on specified network ports.
CMD or ENTRYPOINT: Specifies the command to run when a container is started from the image.

Example: Creating a Simple IIS Web Server Image

Let’s build an image that sets up IIS and copies a simple HTML file to serve.

Create a directory: Make a new folder for your project, e.g., C:\DockerIIS.

Create an HTML file: Inside C:\DockerIIS, create a file named index.html with simple content like:

<!DOCTYPE html>
<html>
<head>
    <title>Hello from Windows Container!</title>
</head>
<body>
    <h1>IIS is running inside a Windows Docker Container!</h1>
</body>
</html>

Create the Dockerfile: Inside C:\DockerIIS, create a text file named Dockerfile (no extension) with the following content:

# Use Windows Server Core as the base image
FROM mcr.microsoft.com/windows/servercore:ltsc2022

# Set the working directory
WORKDIR /inetpub/wwwroot

# Install IIS using PowerShell
RUN powershell -Command Add-WindowsFeature Web-Server;

# Copy the sample HTML file into the default IIS site directory
COPY index.html .

# Expose port 80
EXPOSE 80

# Command to keep IIS running (ServiceMonitor handles monitoring IIS)
CMD ["C:\\ServiceMonitor.exe", "w3svc"]

Building the Image (`docker build ...`)

Navigate to your project directory (C:\DockerIIS) in PowerShell or Command Prompt and run the build command:

docker build -t my-iis-app .

docker build: The command to build an image from a Dockerfile.
-t my-iis-app: Tags the resulting image with the name my-iis-app.
.: Specifies that the build context (where Docker looks for the Dockerfile and files to COPY) is the current directory.

Docker will execute the instructions in your Dockerfile step-by-step. The RUN command installing IIS might take a minute or two.

Running the Custom IIS Container

Once the build completes successfully, you can run your custom IIS container:

docker run -d -p 8080:80 --name my-web-server my-iis-app

-d: Run the container in detached mode (in the background).
-p 8080:80: Map port 8080 on your host machine to port 80 inside the container (where IIS is listening).
--name my-web-server: Give the running container a convenient name.
my-iis-app: The name of the image you just built.

Now, open your web browser and navigate to http://localhost:8080. You should see your “Hello from Windows Container!” message served by IIS running inside the Docker container!

To stop and remove the container:

docker stop my-web-server
docker rm my-web-server

Key Considerations and Potential Gotchas

While powerful, Windows containers have specific considerations you need to be aware of:

Host & Container Version Compatibility (The Matching Game)

This is arguably the most common tripping point. The Windows container image version must be compatible with the Windows host OS version. You generally cannot run a newer container OS version on an older host OS.

Windows Server 2022 / Windows 11 hosts can typically run ltsc2022, ltsc2019, 1809 images.
Windows Server 2019 / Windows 10 (1809+) hosts can typically run ltsc2019, 1809 images, but not ltsc2022.

Always check the Microsoft documentation for the specific compatibility matrix if you encounter errors like “Operating system mismatch.” Using LTSC (Long-Term Servicing Channel) tags like ltsc2022 or ltsc2019 generally provides the most stable compatibility within their respective generations.

Licensing: The Elephant in the Room

Container OS: The Windows base image OS (Server Core, Nano Server) itself is typically covered by the license of your host Windows OS (Windows 10/11 Pro/Enterprise or Windows Server Standard/Datacenter). You don’t usually need a separate Windows license for the container’s OS layer if you are properly licensed for the host. Microsoft’s EULA for Windows Server, for instance, includes rights for container usage.
Application Licensing: You are still responsible for licensing any software you install inside the container (e.g., SQL Server Standard edition, third-party applications) according to their specific terms. Free editions like SQL Server Express are often used in containers without extra licensing cost.
Full Windows GUI (Revisited): As mentioned earlier, running a full Windows 10/11 desktop GUI within a container via emulation typically falls outside standard licensing and requires specific, often costly, VDI/VDA licensing.

Disclaimer: Licensing is complex. Always consult the official Microsoft licensing documentation and your organization’s licensing agreements. This information is for general guidance only.

Performance: Isolation Modes (Process vs. Hyper-V)

Windows Containers offer two isolation modes:

Process Isolation: (Default on Windows Server) Containers share the kernel with the host OS. This is faster, more efficient, and results in smaller image sizes, similar to Linux containers. However, it requires strict host/container version compatibility.
Hyper-V Isolation: (Default on Windows 10/11, can be specified on Server) Each container runs inside a highly optimized, lightweight utility VM. This provides better security isolation and relaxes the strict version compatibility requirement (you can often run older or newer container versions relative to the host, within limits). The trade-off is slightly slower startup times and higher resource consumption compared to process isolation.

You can specify Hyper-V isolation when running a container using the --isolation=hyperv flag:

docker run -it --rm --isolation=hyperv mcr.microsoft.com/windows/servercore:ltsc2022 cmd.exe

Docker Desktop on Windows 10/11 often defaults to Hyper-V isolation for Windows containers because process isolation has stricter compatibility requirements with client OS versions.

Storage and Networking in Windows Containers

Storage: Similar to Linux containers, you can use volumes (-v host-path:container-path) to persist data outside the container’s ephemeral filesystem or share data between the host and container. Named volumes are also supported.
Networking: Windows containers use various network drivers (NAT, Transparent, L2Bridge, Overlay). Docker Desktop typically sets up a default NAT network, making it easy to map ports (-p) for accessing container services from the host. More complex networking scenarios might require specific driver configurations, especially on Windows Server.

**Limitations: What Windows Containers Can’t Do Easily (e.g., GUI Apps)**

Direct GUI Application Support: Windows Containers are primarily designed for server applications, background services, and command-line tools. Running traditional graphical Windows applications directly within a standard Windows container is generally not supported or practical. Workarounds involving RDP servers inside containers exist but are complex and often clunky.
Hardware Access: Direct access to host hardware (like GPUs, specific USB devices) from within a Windows container is limited compared to VMs or running directly on the host. There’s ongoing work (e.g., GPU support in specific scenarios with WSL/DirectML), but it’s not as straightforward as on Linux.
Kernel-Level Features: Applications requiring deep kernel-level access or specific drivers that cannot be installed within the container environment might not work.

Exploring Alternatives: When Windows Containers Aren’t the Right Fit

Windows Containers are powerful, but they aren’t the solution for every problem. Consider these alternatives:

Traditional Virtual Machines (Hyper-V, VMware, VirtualBox)

If you need to run a full, isolated Windows desktop environment (including GUI), need guaranteed hardware access, or have strict isolation requirements beyond what Hyper-V isolation offers, a traditional VM is still the best choice. They provide complete OS virtualization but come with higher resource overhead.

Windows Subsystem for Linux (WSL)

If your goal is primarily to run Linux tools and applications on your Windows machine, WSL (especially WSL 2) is fantastic. It provides a near-native Linux environment directly integrated with Windows, without needing a separate Docker container for the Linux OS itself (though Docker Desktop leverages WSL 2). It’s not for running Windows apps, but for bringing Linux dev tools to Windows.

**Wine on Linux (For running some Windows apps on Linux hosts)**

If you are on a Linux host and want to run a Windows application, Wine (or commercial versions like CrossOver) attempts to translate Windows API calls into Linux equivalents. It doesn’t involve containers or Windows itself. Compatibility varies greatly depending on the application; it’s often hit-or-miss, especially for complex apps or games. It’s entirely different from Windows Containers.

Frequently Asked Questions (FAQs)

FAQ 1: Can I truly run a full Windows 10 desktop inside a Docker container?

A: Not in the way Docker containers are typically used. Standard Windows Containers run Windows applications and services using shared or lightweight virtualized kernels (Process or Hyper-V isolation). While technically possible to run a full Windows OS using QEMU inside a Docker container, it’s highly inefficient, complex to set up, performs poorly, and has significant licensing implications that usually make it impractical and non-compliant for typical desktop use. For a full Windows desktop experience, use a traditional Virtual Machine (VM).

FAQ 2: What’s the main difference between Windows Server Core and Nano Server images?

A: Server Core is larger but offers broader compatibility, including support for the full .NET Framework and many traditional Windows Server APIs and roles (like IIS). Nano Server is significantly smaller and more secure, optimized for modern .NET (Core/5+) applications and infrastructure roles, but lacks compatibility with older frameworks and many APIs found in Server Core. Choose Server Core for legacy app compatibility or standard server roles; choose Nano Server for new .NET applications where size and attack surface are priorities.

FAQ 3: Do I need an extra Windows license for the OS inside the container?

A: Generally, no. When running Windows Containers on a properly licensed Windows 10/11 Pro/Enterprise host or a Windows Server host, the license for the host OS typically covers the Windows base container OS layer (e.g., Server Core, Nano Server). Microsoft’s EULAs for these host operating systems include rights for using Windows Containers. However, you do need to ensure any additional software you install inside the container (like SQL Server Standard, third-party apps) is properly licensed according to its own terms. Always refer to official Microsoft licensing documentation for specifics.

FAQ 4: Can I run Windows containers on my Mac or Linux machine?

A: No. Windows Containers require a Windows kernel. Because Docker containers share the host OS kernel (or use host virtualization features tied to the host OS), you need a Windows host machine (Windows 10/11 Pro/Ent/Edu or Windows Server) to run Windows Containers. You can run Linux containers on Mac, Windows (via WSL 2 or Hyper-V), and Linux hosts.

FAQ 5: How big are Windows container images typically?

A: Significantly larger than typical Linux images.

Nano Server: Often the smallest, starting around 100-300MB (compressed download size), expanding somewhat on disk.
Server Core: Much larger, typically 1.5GB+ (compressed download size), expanding to 3-5GB+ on disk.
Windows Image: The largest, often exceeding Server Core’s size.

These sizes are just for the base image; adding applications and dependencies will increase the final image size. This is a key reason why optimizing layers and using multi-stage builds is important for Windows containers too.