1. Docker Desktop On Windows Server 2017
2. Docker Desktop On Windows Server 2012
3. Docker Desktop Windows Server 2008

Estimated reading time: 15 minutes

Welcome to Docker Desktop! The Docker Desktop for Windows user manual provides information on how to configure and manage your Docker Desktop settings.

For information about Docker Desktop download, system requirements, and installation instructions, see Install Docker Desktop.

Settings

The Docker Desktop menu allows you to configure your Docker settings such as installation, updates, version channels, Docker Hub login,and more.

Host operating system: Windows Server or Windows 10. Hypervisor: Windows 10 must run Hyper-V to support containers; Windows Server, as shown in the table, has more flexibility. Docker engine: Docker is a third-party application for managing containers. Docker Enterprise runs on Windows Server; Docker Desktop for Windows runs in Windows 10. Docker official doc gives instruments to configure a DNS server for use by Docker. Open the /etc/default/docker file for editing: sudo nano /etc/default/docker Add a setting for Docker: DOCKEROPTS='-dns 8.8.8.8' Replace 8.8.8.8 with a local DNS server such as 192.168.1.1. You can also specify multiple DNS servers.

This section explains the configuration options accessible from the Settings dialog.

1. Open the Docker Desktop menu by clicking the Docker icon in the Notifications area (or System tray):

2. Select Settings to open the Settings dialog:

General

On the General tab of the Settings dialog, you can configure when to start and update Docker.

• Start Docker when you log in - Automatically start Docker Desktop upon Windows system login.

• Expose daemon on tcp://localhost:2375 without TLS - Click this option to enable legacy clients to connect to the Docker daemon. You must use this option with caution as exposing the daemon without TLS can result in remote code execution attacks.

• Send usage statistics - By default, Docker Desktop sends diagnostics,crash reports, and usage data. This information helps Docker improve andtroubleshoot the application. Clear the check box to opt out. Docker may periodically prompt you for more information.

Resources

The Resources tab allows you to configure CPU, memory, disk, proxies, network, and other resources. Different settings are available for configuration depending on whether you are using Linux containers in WSL 2 mode, Linux containers in Hyper-V mode, or Windows containers.

Advanced

Note

The Advanced tab is only available in Hyper-V mode, because in WSL 2 mode and Windows container mode these resources are managed by Windows. In WSL 2 mode, you can configure limits on the memory, CPU, and swap size allocatedto the WSL 2 utility VM.

Use the Advanced tab to limit resources available to Docker.

CPUs: By default, Docker Desktop is set to use half the number of processorsavailable on the host machine. To increase processing power, set this to ahigher number; to decrease, lower the number.

Memory: By default, Docker Desktop is set to use 2 GB runtime memory,allocated from the total available memory on your machine. To increase the RAM, set this to a higher number. To decrease it, lower the number.

Swap: Configure swap file size as needed. The default is 1 GB.

Disk image size: Specify the size of the disk image.

Disk image location: Specify the location of the Linux volume where containers and images are stored.

You can also move the disk image to a different location. If you attempt to move a disk image to a location that already has one, you get a prompt asking if you want to use the existing image or replace it.

File sharing

Note

The File sharing tab is only available in Hyper-V mode, because in WSL 2 mode and Windows container mode all files are automatically shared by Windows.

Use File sharing to allow local directories on Windows to be shared with Linux containers.This is especially useful forediting source code in an IDE on the host while running and testing the code in a container.Note that configuring file sharing is not necessary for Windows containers, only Linux containers. If a directory is not shared with a Linux container you may get file not found or cannot start service errors at runtime. See Volume mounting requires shared folders for Linux containers.

File share settings are:

• Add a Directory: Click + and navigate to the directory you want to add.

• Apply & Restart makes the directory available to containers using Docker’sbind mount (-v) feature.

Tips on shared folders, permissions, and volume mounts

• Share only the directories that you need with the container. File sharing introduces overhead as any changes to the files on the host need to be notified to the Linux VM. Sharing too many files can lead to high CPU load and slow filesystem performance.

• Shared folders are designed to allow application code to be edited on the host while being executed in containers. For non-code items such as cache directories or databases, the performance will be much better if they are stored in the Linux VM, using a data volume (named volume) or data container.

• Docker Desktop sets permissions to read/write/execute for users, groups and others 0777 or a+rwx.This is not configurable. See Permissions errors on data directories for shared volumes.

• Windows presents a case-insensitive view of the filesystem to applications while Linux is case-sensitive. On Linux it is possible to create 2 separate files: test and Test, while on Windows these filenames would actually refer to the same underlying file. This can lead to problems where an app works correctly on a developer Windows machine (where the file contents are shared) but fails when run in Linux in production (where the file contents are distinct). To avoid this, Docker Desktop insists that all shared files are accessed as their original case. Therefore if a file is created called test, it must be opened as test. Attempts to open Test will fail with “No such file or directory”. Similarly once a file called test is created, attempts to create a second file called Test will fail.

Shared folders on demand

You can share a folder “on demand” the first time a particular folder is used by a container.

If you run a Docker command from a shell with a volume mount (as shown in theexample below) or kick off a Compose file that includes volume mounts, you get apopup asking if you want to share the specified folder.

You can select to Share it, in which case it is added your Docker Desktop Shared Folders list and available tocontainers. Alternatively, you can opt not to share it by selecting Cancel.

Proxies

Docker Desktop lets you configure HTTP/HTTPS Proxy Settings andautomatically propagates these to Docker. For example, if you set your proxysettings to http://proxy.example.com, Docker uses this proxy when pulling containers.

Your proxy settings, however, will not be propagated into the containers you start.If you wish to set the proxy settings for your containers, you need to defineenvironment variables for them, just like you would do on Linux, for example:

For more information on setting environment variables for running containers,see Set environment variables.

Network

Note

The Network tab is not available in Windows container mode because networking is managed by Windows.

You can configure Docker Desktop networking to work on a virtual private network (VPN). Specify a network address translation (NAT) prefix and subnet mask to enable Internet connectivity.

DNS Server: You can configure the DNS server to use dynamic or static IP addressing.

Note

Some users reported problems connecting to Docker Hub on Docker Desktop. This would manifest as an error when trying to rundocker commands that pull images from Docker Hub that are not alreadydownloaded, such as a first time run of docker run hello-world. If youencounter this, reset the DNS server to use the Google DNS fixed address:8.8.8.8. For more information, seeNetworking issues in Troubleshooting.

Updating these settings requires a reconfiguration and reboot of the Linux VM.

WSL Integration

In WSL 2 mode, you can configure which WSL 2 distributions will have the Docker WSL integration.

By default, the integration will be enabled on your default WSL distribution. To change your default WSL distro, run wsl --set-default <distro name>. (For example, to set Ubuntu as your default WSL distro, run wsl --set-default ubuntu).

You can also select any additional distributions you would like to enable the WSL 2 integration on.

For more details on configuring Docker Desktop to use WSL 2, see Docker Desktop WSL 2 backend.

Docker Engine

The Docker Engine page allows you to configure the Docker daemon to determine how your containers run.

Type a JSON configuration file in the box to configure the daemon settings. For a full list of options, see the Docker Enginedockerd commandline reference.

Click Apply & Restart to save your settings and restart Docker Desktop.

Command Line

On the Command Line page, you can specify whether or not to enable experimental features.

You can toggle the experimental features on and off in Docker Desktop. If you toggle the experimental features off, Docker Desktop uses the current generally available release of Docker Engine.

Experimental features

Experimental features provide early access to future product functionality.These features are intended for testing and feedback only as they may changebetween releases without warning or can be removed entirely from a futurerelease. Experimental features must not be used in production environments.Docker does not offer support for experimental features.

For a list of current experimental features in the Docker CLI, see Docker CLI Experimental features.

Run docker version to verify whether you have enabled experimental features. Experimental modeis listed under Server data. If Experimental is true, then Docker isrunning in experimental mode, as shown here:

Kubernetes

Note

The Kubernetes tab is not available in Windows container mode.

Docker Desktop includes a standalone Kubernetes server that runs on your Windows machince, sothat you can test deploying your Docker workloads on Kubernetes. To enable Kubernetes support and install a standalone instance of Kubernetes running as a Docker container, select Enable Kubernetes.

For more information about using the Kubernetes integration with Docker Desktop, see Deploy on Kubernetes.

Reset

The Restart Docker Desktop and Reset to factory defaults options are now available on the Troubleshoot menu. For information, see Logs and Troubleshooting.

Troubleshoot

Visit our Logs and Troubleshooting guide for more details.

Log on to our Docker Desktop for Windows forum to get help from the community, review current user topics, or join a discussion.

Log on to Docker Desktop for Windows issues on GitHub to report bugs or problems and review community reported issues.

For information about providing feedback on the documentation or update it yourself, see Contribute to documentation.

Switch between Windows and Linux containers

From the Docker Desktop menu, you can toggle which daemon (Linux or Windows)the Docker CLI talks to. Select Switch to Windows containers to use Windowscontainers, or select Switch to Linux containers to use Linux containers(the default).

For more information on Windows containers, refer to the following documentation:

• Microsoft documentation on Windows containers.

• Build and Run Your First Windows Server Container (Blog Post)gives a quick tour of how to build and run native Docker Windows containers on Windows 10 and Windows Server 2016 evaluation releases.

• Getting Started with Windows Containers (Lab)shows you how to use the MusicStoreapplication with Windows containers. The MusicStore is a standard .NET application and,forked here to use containers, is a good example of a multi-container application.

• To understand how to connect to Windows containers from the local host, seeLimitations of Windows containers for localhost and published ports

Settings dialog changes with Windows containers

When you switch to Windows containers, the Settings dialog only shows those tabs that are active and apply to your Windows containers:

If you set proxies or daemon configuration in Windows containers mode, theseapply only on Windows containers. If you switch back to Linux containers,proxies and daemon configurations return to what you had set for Linuxcontainers. Your Windows container settings are retained and become availableagain when you switch back.

Dashboard

The Docker Desktop Dashboard enables you to interact with containers and applications and manage the lifecycle of your applications directly from your machine. The Dashboard UI shows all running, stopped, and started containers with their state. It provides an intuitive interface to perform common actions to inspect and manage containers and Docker Compose applications. For more information, see Docker Desktop Dashboard.

Docker Hub

Select Sign in /Create Docker ID from the Docker Desktop menu to access your Docker Hub account. Once logged in, you can access your Docker Hub repositories directly from the Docker Desktop menu.

For more information, refer to the following Docker Hub topics:

Two-factor authentication

Docker Desktop enables you to sign into Docker Hub using two-factor authentication. Two-factor authentication provides an extra layer of security when accessing your Docker Hub account.

You must enable two-factor authentication in Docker Hub before signing into your Docker Hub account through Docker Desktop. For instructions, see Enable two-factor authentication for Docker Hub.

After you have enabled two-factor authentication:

1. Go to the Docker Desktop menu and then select Sign in / Create Docker ID.

2. Enter your Docker ID and password and click Sign in.

3. After you have successfully signed in, Docker Desktop prompts you to enter the authentication code. Enter the six-digit code from your phone and then click Verify.

After you have successfully authenticated, you can access your organizations and repositories directly from the Docker Desktop menu.

Adding TLS certificates

You can add trusted Certificate Authorities (CAs) to your Docker daemon to verify registry server certificates, and client certificates, to authenticate to registries.

How do I add custom CA certificates?

Docker Desktop supports all trusted Certificate Authorities (CAs) (root orintermediate). Docker recognizes certs stored under Trust RootCertification Authorities or Intermediate Certification Authorities.

Docker Desktop creates a certificate bundle of all user-trusted CAs based onthe Windows certificate store, and appends it to Moby trusted certificates. Therefore, if an enterprise SSL certificate is trusted by the user on the host, it is trusted by Docker Desktop.

To learn more about how to install a CA root certificate for the registry, seeVerify repository client with certificatesin the Docker Engine topics.

How do I add client certificates?

You can add your client certificatesin ~/.docker/certs.d/<MyRegistry>:<Port>/client.cert and~/.docker/certs.d/<MyRegistry>:<Port>/client.key. You do not need to push your certificates with git commands.

When the Docker Desktop application starts, it copies the~/.docker/certs.d folder on your Windows system to the /etc/docker/certs.ddirectory on Moby (the Docker Desktop virtual machine running on Hyper-V).

You need to restart Docker Desktop after making any changes to the keychainor to the ~/.docker/certs.d directory in order for the changes to take effect.

The registry cannot be listed as an insecure registry (seeDocker Daemon). Docker Desktop ignorescertificates listed under insecure registries, and does not send clientcertificates. Commands like docker run that attempt to pull from the registryproduce error messages on the command line, as well as on the registry.

To learn more about how to set the client TLS certificate for verification, seeVerify repository client with certificatesin the Docker Engine topics.

Where to go next

• Try out the walkthrough at Get Started.

• Dig in deeper with Docker Labs example walkthroughs and source code.

• Refer to the Docker CLI Reference Guide.

This article outlines Microsoft's support policy concerning Windows containers and Docker for on-premises deployments.

Original product version: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10 - all editions
Original KB number: 4489234

Note

When customers experience issues with or have questions about Windows containers and related Docker functionality, Microsoft is their first point of contact. For similar information about Microsoft's support policy for containers in Azure, see Support policy for containers and related services on Azure.

Supported configurations for container hosts

Microsoft defines the supported host configurations in the following terms:

• Host operating system: Windows Server or Windows 10.

• Hypervisor: Windows 10 must run Hyper-V to support containers; Windows Server, as shown in the table, has more flexibility.

• Docker engine: Docker is a third-party application for managing containers. Docker Enterprise runs on Windows Server; Docker Desktop for Windows runs in Windows 10. For more information about Docker, see Docker on Windows.

• Container type: Microsoft supports Windows Server containers, Hyper-V containers, and Linux containers. However, not all host configurations can support all of the container types. For general information about Windows containers and container types, see Containers on Windows.

Note

The Linux Containers on Windows (LCOW) feature is under active development. For more information, see Linux Containers on Windows. You can track ongoing progress in the Moby project on GitHub.

Host component support

Customers that deploy Windows Server containers on supported Windows Server versions running on physical hardware or virtual machine on Hyper-V will receive full support for issues that are related to the operating system and/or container engine.

Supported configurations for Windows Server container hosts

Microsoft supports Windows containers on the following versions and releases of Windows Server:

• Windows Server 2019 (1809) Standard or Datacenter editions
• Windows Server 2016 (1803) Standard or Datacenter editions
• Windows Server 2016 (1709) Standard or Datacenter editions
• Windows Server 2016 (1607) Standard, Datacenter, or Nano Server editions
• Windows IoT core (only available to Windows Insider members)

Note

You cannot host containers on Windows Server, Nano Server edition, on any Windows Server release later than 1607.

Microsoft supports Windows containers on both LTSC and Semi-annual Channel (SAC) releases. For information about the support lifecycles for Windows versions and releases, see Windows Server Semi-Annual Channel overview.

To deploy containers in Windows Server, you must install Docker Enterprise (see Install Docker Engine - Enterprise on Windows Servers). Docker provides full support for Docker Enterprise at Docker support.

On these versions of Windows, the types of containers that Microsoft supports depends on whether your host is a physical computer or a virtual machine, and whether Windows is running with Hyper-V enabled.

Supported container types on a physical container host

Supported container types on a virtual machine container host

Supported configurations for Windows 10 container hosts

Microsoft supports containers on Windows 10 Professional or Enterprise with Anniversary Update (version 1607) or later, with the following requirements:

• Hyper-V must be enabled

• Docker Desktop for Windows must be installed (see Install Docker Desktop for Windows). Docker Desktop for Windows is the Community Edition (Docker CE) and is ideal for developers and small teams looking to get started with Docker and experimenting with container-based apps.

  Microsoft does not provide support for Docker Desktop for Windows. Support is only provided through the Docker Community Forums. For more information, see 'What if I have problems or questions?' in the Docker for Windows FAQ at Docker FAQ.

You can use Hyper-V containers or Linux containers on Windows 10. You cannot use Windows Server containers.

Microsoft does not support containers on virtual machines that are hosted on a Windows 10 computer. To use containers on a virtual machine, use Windows Server as the virtual machine host.

Requirements for container hosts

For information about requirements for container hosts, see:

For information about requirements and compatibility issues for virtualization, see Windows Server Catalog: Server Virtualization Validation Program.

To run Hyper-V containers, the container host must meet the requirements for running Hyper-V itself. To summarize, Hyper-V requires:

• 64-bit processor, with the following capabilities:

  • Second-level address translation (SLAT): The Windows hypervisor functionality requires SLAT (the Hyper-V management tools do not.

  • Hardware-assisted virtualization: This is available in processors that include a virtualization option - specifically processors with Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) technology.

  • Hardware-enforced Data Execution Prevention (DEP) must be available and enabled. For Intel systems, this is the XD bit (execute disable bit). For AMD systems, this is the NX bit (no execute bit).

• VM Monitor Mode extensions.

• At least 4 GB of RAM. More memory is better. You'll need enough memory for the host and all virtual machines that you want to run at the same time.

• Virtualization support turned on in the BIOS or UEFI.

For more information, see System requirements for Hyper-V on Windows Server.

Supported container orchestrators

The Azure Service Fabric is not available to orchestrate on-premises containers. Windows does support Docker swarm, Kubernetes, and Red Hat orchestrators.

• Docker swarm: Docker swarm is a feature of the Docker engine. Docker swarm is fully supported by Docker. For more information about using Docker swarm with Windows containers, see Getting started with swarm mode.

• Kubernetes: Kubernetes for on-premises Windows Server deployments is still in preview (Beta). Microsoft will not provide any support until the official announcement of general availability. Until then, use the following resources:

  • For the latest information about functionality with Windows Server 2016 and Windows Server 2019, see Kubernetes on Windows.

  • To track development and participate in community preview efforts, follow the Kubernetes #SIG-Windows community.

• Red Hat OpenShift (Windows Server 2019 only): Red Hat OpenShift on Windows Server 2019 is still in private preview. Microsoft will not provide support until the announcement of general availability.

Docker Desktop On Windows Server 2017

Supported container images

Microsoft offers four container base images for Windows:

• Windows Server core: If your application needs the full .NET framework, this is the best image to use.
• Nano Server: For applications that only require .NET Core, Nano Server will provide a much slimmer image.
• Windows: You may find your application depends on a component or .dll that is missing in Server Core or Nano Server images, such as GDI libraries. This image carries the full dependency set of Windows.
• Windows IoT core: This image is purpose-built for IoT applications. You should use this container image when targeting an IoT Core host.

Note

The IoT Core base image is only available to members of the Windows Insider program.

As outlined in Supported container hosts, not all host operating systems support both Windows Server containers and Hyper-V containers. Similarly, not all of the base images support both container types. The following table outlines which container types you can create using each base image on each of the host operating systems.

Container base OS images that are supported on Windows container hosts

If you plan to work with container hosts that run different versions and releases of Windows, you will also need to consider the versions and releases of the container images. Some container features are not backward-compatible, so some newer base OS images may not run on container hosts with older OS versions. For more detailed information about compatibility issues between base OS image versions and host OS versions, see Windows Container Version Compatibility.

Support for container workloads

Microsoft fully supports its container base OS images, as described in this section. For support of Microsoft applications in containers, see GitHub, the Microsoft forums, or the Microsoft repository on DockerHub for the custom container image in question.

When running third-party applications in Windows containers, refer to the application vendor for support. In particular, confirm with the application vendor that they support running the application in a Windows container.

Supported networking configurations

Microsoft fully supports Windows container networking functionality. This functionality includes the Host Networking Service (HNS) and Host Compute Service (HCS). HNS and HCS work together to create containers (HCS) and attach endpoints to a network (HNS). Additionally, it includes the following container network drivers (for full descriptions of these drivers, see Windows Container Network Drivers):

• Network Address Translation (NAT): This is the default driver for container networks. NAT networks support port forwarding and mapping from container hosts to container endpoints. Microsoft supports multiple NAT networks on Windows 10 container hosts that have Windows 10, version 1703 (also known as the Creators Update) installed.

• Transparent: When configured with a user-specified subnet, transparent networks support static IP addresses from the physical network or dynamic IP addresses assigned by an external DHCP server. When using a transparent network for containers on a virtual container host, you must configure MAC address spoofing.

• Overlay: Microsoft supports overlay networks for use with Docker swarm or Kubernetes orchestration. To use overlay networks, your configuration must meet the following requirements:

  • Your container hosts run Windows Server 2019, Windows Server 2016, or Windows 10 Creators Update.

  • Your deployment meets the requirements listed in Using overlay networks.

  • When using Kubernetes, you are using Flannel or OVN control panes.

    Note

    Kubernetes for on-premises Windows Server deployments is still in preview (Beta). For information about Kubernetes support, see Supported container orchestrators.

• L2Bridge: Microsoft supports L2Bridge networks to assign containers to the same IP subnet as the container host. To use L2Bridge networks, your configuration must meet the following requirements:

  • Your container hosts run Windows Server 2019, Windows Server 2016, or Windows 10 Creators Update.

  • IP addresses must be assigned statically from the same prefix as the container host.

  • You configure MAC address spoofing.

• L2Tunnel: Microsoft primarily supports L2Tunnel networks for use in a Microsoft Cloud Stack. Otherwise, requirements for L2Tunnel networks resemble the requirements for L2Bridge networks.

Advanced network options - supported and unsupported

Microsoft supports switch-embedded teaming for container host networks used by Docker. Microsoft does not support any other NIC teaming configuration for container networking. For more information, see Advanced Network Options in Windows.

Microsoft does not support the following features for container networking:

• IPSec encryption for container communication

• HTTP proxy configuration for containers. You can track a preliminary PR for this feature at Changes to support registry modification in containers.

• Attaching endpoints to running Hyper-V containers (hot-add)

Microsoft does not support the following commands and options for Docker:

Supported service accounts for containers

Microsoft supports Active Directory group Managed Service Accounts (gMSAs) for containers.

Docker Desktop On Windows Server 2012

Containers cannot be domain-joined. By using Group Managed Service Accounts (gMSAs), Windows containers themselves and the services they host can be configured to use a specific gMSA as their domain identity. Any service running as Local System or Network Service will use the Windows container's identity just like they use the domain-joined host's identity. For information about using gMSAs, see:

Supported endpoint security options for containers and container hosts

Microsoft supports Windows Defender to protect container hosts. However, it does not support Windows Defender to run within containers.

Docker Desktop Windows Server 2008

Docker provides information about third-party providers and their endpoint protection products at Endpoint security for Windows containers. When using a third-party product, verify that the provider supports the product for containers. Be aware of any issues and limitations related to running the product within a container. Additionally, for recommendations about how to configure anti-virus protection to work with containers, see Anti-virus optimization for Windows Containers.