|
1 | 1 | --- |
2 | | -title: Best practices |
| 2 | +linkTitle: Best practices |
| 3 | +title: WSL 2 best practices for Docker Desktop on Windows |
3 | 4 | description: Best practices for using Docker Desktop with WSL 2 |
4 | | -keywords: wsl, docker desktop, best practices |
| 5 | +keywords: wsl 2, docker desktop, best practices, Windows Subsystem for Linux, Docker Desktop Windows performance |
5 | 6 | tags: [Best practices] |
6 | 7 | aliases: |
7 | 8 | - /desktop/wsl/best-practices/ |
8 | 9 | --- |
9 | 10 |
|
10 | | -- Always use the latest version of WSL. At a minimum you must use WSL version 2.1.5, otherwise Docker Desktop may not work as expected. Testing, development, and documentation is based on the newest kernel versions. Older versions of WSL can cause: |
11 | | - - Docker Desktop to hang periodically or when upgrading |
12 | | - - Deployment via SCCM to fail |
13 | | - - The `vmmem.exe` to consume all memory |
14 | | - - Network filter policies to be applied globally, not to specific objects |
15 | | - - GPU failures with containers |
| 11 | +This page covers recommendations when running Docker Desktop on Windows using WSL 2, including version requirements and file system performance. |
16 | 12 |
|
17 | | -- To get the best out of the file system performance when bind-mounting files, it's recommended that you store source code and other data that is bind-mounted into Linux containers. For instance, use `docker run -v <host-path>:<container-path>` in the Linux file system, rather than the Windows file system. You can also refer to the [recommendation](https://learn.microsoft.com/en-us/windows/wsl/compare-versions) from Microsoft. |
18 | | - - Linux containers only receive file change events, “inotify events”, if the original files are stored in the Linux filesystem. For example, some web development workflows rely on inotify events for automatic reloading when files have changed. |
19 | | - - Performance is much higher when files are bind-mounted from the Linux filesystem, rather than remoted from the Windows host. Therefore avoid `docker run -v /mnt/c/users:/users,` where `/mnt/c` is mounted from Windows. |
20 | | - - Instead, from a Linux shell use a command like `docker run -v ~/my-project:/sources <my-image>` where `~` is expanded by the Linux shell to `$HOME`. |
| 13 | +## Keep WSL up to date |
21 | 14 |
|
22 | | -- If you have concerns about the size of the `docker-desktop-data` distribution, take a look at the [WSL tooling built into Windows](https://learn.microsoft.com/en-us/windows/wsl/disk-space). |
23 | | - - Installations of Docker Desktop version 4.30 and later no longer rely on the `docker-desktop-data` distribution; instead Docker Desktop creates and manages its own virtual hard disk (VHDX) for storage. (note, however, that Docker Desktop keeps using the `docker-desktop-data` distribution if it was already created by an earlier version of the software). |
24 | | - - Starting from version 4.34 and later, Docker Desktop automatically manages the size of the managed VHDX and returns unused space to the operating system. |
| 15 | +Always use the latest version of WSL. |
25 | 16 |
|
26 | | -- If you have concerns about CPU or memory usage, you can configure limits on the memory, CPU, and swap size allocated to the [WSL 2 utility VM](https://learn.microsoft.com/en-us/windows/wsl/wsl-config#global-configuration-options-with-wslconfig). |
| 17 | +At a minimum you must use WSL version 2.1.5, otherwise Docker Desktop may not work as expected. Testing, development, and documentation is based on the newest kernel versions. Older versions of WSL can cause: |
| 18 | +- Docker Desktop to hang periodically or when upgrading |
| 19 | +- Deployment via SCCM to fail |
| 20 | +- The `vmmem.exe` to consume all memory |
| 21 | +- Network filter policies to be applied globally, not to specific objects |
| 22 | +- GPU failures with containers |
| 23 | + |
| 24 | +## Optimise file system performance with bind mounts |
| 25 | + |
| 26 | +To get the best out of the file system performance when bind-mounting files, store source code and other data that is bind-mounted into Linux containers. For instance, use `docker run -v <host-path>:<container-path>` in the Linux file system, rather than the Windows file system. You can also refer to [Microsoft's recommendation](https://learn.microsoft.com/en-us/windows/wsl/compare-versions). |
| 27 | + |
| 28 | +Linux containers only receive file change events, “inotify events”, if the original files are stored in the Linux filesystem. For example, some web development workflows rely on inotify events for automatic reloading when files have changed. |
| 29 | + |
| 30 | +Performance is much higher when files are bind-mounted from the Linux filesystem, rather than accessed from the Windows host filesystem. Therefore avoid `docker run -v /mnt/c/users:/users` where `/mnt/c` is mounted from Windows. |
| 31 | + |
| 32 | +Instead, from a Linux shell use a command like `docker run -v ~/my-project:/sources <my-image>` where `~` is expanded by the Linux shell to `$HOME`. |
| 33 | + |
| 34 | +## Limit CPU and memory usage |
| 35 | + |
| 36 | +If you have concerns about CPU or memory usage, configure limits on the memory, CPU, and swap size allocated to the [WSL 2 utility VM](https://learn.microsoft.com/en-us/windows/wsl/wsl-config#global-configuration-options-with-wslconfig). |
0 commit comments