最近在 Windows 上折腾容器环境发现不少朋友还在为 Docker 的选择纠结。装 Docker Desktop 吧软件体量大、启动慢、吃内存每年还要关注商用授权条款不装吧本地开发又离不开 Linux 容器。我的方案很直接在 WSL2 里装一份 Ubuntu然后在 Ubuntu 发行版内部直接安装原生 Docker Engine完全不依赖 Docker Desktop。这套方案既能用上 WSL2 和 Windows 深度集成的优势又能拿到和 Linux 服务器完全一致的 dockerd 环境本地开发、CI 演练、GPU 容器都覆盖得到。这篇文章就把完整过程写下来顺便把那些文档不会写、但实际操作中一定会踩的坑一并说清楚。适合想在 Windows 10/11 上低成本跑 Linux 容器的开发者也适合需要把 WSL2 当开发主力环境的人参考。1. 为什么是 WSL2 原生 Docker Engine而不是 Docker Desktop1.1 这套组合到底是什么很多人容易把“WSL2 里的 Docker”和“Docker Desktop 的 WSL2 后端”混为一谈。Docker Desktop 也有 WSL2 集成模式它会在 Windows 上跑一个虚拟机作为后端实际上还是把 Linux 容器装进某个发行版里执行。但用户接触到的还是 Docker Desktop 的图形界面和控制进程。我们这里说的原生 Docker Engine 是另一条路直接在 WSL2 的 Ubuntu 发行版里面安装 docker-ce 系列软件包让 dockerd 直接跑在这个发行版上。这跟在一台 Linux 服务器上装 Docker 没有本质区别。你平时怎么在 Ubuntu 服务器上配 Docker在 WSL2 里就怎么配。从使用体验来说原生方案的特点是没有额外一层守护进程不用启动 Docker Desktop 的 GUI内存占用比 Docker Desktop 明显低对只有 16G 内存的机器很友好和公司生产环境的 Linux Docker 完全一致不依赖任何图形化封装配置方式就是改 /etc/docker/daemon.json 和 systemd 服务和服务器运维经验平滑复用1.2 Docker Desktop 的痛点在哪里我最早也用 Docker Desktop而且是开了 WSL2 后端的那种。用一段时间之后发现几个问题比较难以接受。首先是资源占用。Docker Desktop 默认会给虚拟机分配不少资源哪怕你没在跑容器后端进程也常驻风扇时不时就转起来。在 16G 内存的轻薄本上这个开销很明显。其次是网络和端口映射Docker Desktop 出现异地解析、端口冲突时排查起来绕来绕去。第三个是许可问题对于个人开发、学习来说免费版本足够但如果公司规模或场景触发商用条件就得认真考虑授权成本。原生 Docker Engine 就没有这些包袱。docker 命令直接调本地 socket没有中间商。资源占用就是容器本身和 containerd 那点儿开销。想停就停想清理就清理非常直接。1.3 什么场景还是建议用 Docker Desktop原生方案虽然好但也不是万能。如果遇到下面几种场景Docker Desktop 仍可能是更省事的选择需要在 Windows 侧跑 Windows 容器需要 Docker Desktop 自带的 Kubernetes 集成界面其实原生也能装 k3s 或 kind但需要自己配置你需要一个图形界面来管理容器而不是愿意用命令行公司统一要求使用 Docker Desktop 及对应合规工具链除了这些情况对于以 Linux 容器为主要开发目标的个人开发者、运维和 AI 方向的同学原生方案往往更干净。2. 环境准备WSL2 和 Ubuntu 的安装与避坑2.1 先解决“虚拟化未启用”的问题WSL2 依赖 Windows 的虚拟化能力。如果之前没有开过虚拟机平台执行 wsl --install 时很容易遇到标题里那个经典报错请确保计算机固件设置中“虚拟机平台”已启用。开启该功能后需要重启计算机。这个问题的完整排查链路我按顺序讲首先在 BIOS/UEFI 里确认 CPU 虚拟化技术是开启的Intel 对应 VT-xAMD 对应 SVM。开机时按 Del 或 F2 进固件设置找到相关选项并启用这个因主板而异不同品牌位置不一样但一般都在 Advanced / CPU Configuration 里。然后确认 Windows 功能已经开启。以管理员身份打开 PowerShell执行以下命令dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart执行完重启电脑再确认 WSL2 可用。还有一种情况是电脑里装了虚拟机监控程序冲突。比如用了老的 VMware、Hyper-V 没关干净或者其他沙盒类工具都会干扰 WSL2 启动。如果 BIOS 虚拟化确实开了功能也开了还是报错就查一下 Windows 的“虚拟机监控程序”是否被正确加载命令行执行systeminfo | findstr Hyper-V正常情况下能看到“Hyper-V 要求: 已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。”如果显示“未检测到虚拟机监控程序”说明 Hyper-V 层没起来重点检查 Windows 功能里的 Hyper-V 和虚拟机平台。2.2 一步到位装 WSL2 和 Ubuntu 22.04Windows 11 和较新的 Windows 10 版本WSL 已经支持一个命令搞定wsl --install -d Ubuntu-22.04如果之前没装过 WSL这个命令会默认启用所需功能下载 WSL 内核然后拉取 Ubuntu 22.04 发行版并初始化。初始化过程中会让你设置 Linux 用户名和密码注意这个用户默认在 sudo 组里后面很多命令都要靠它。如果你希望用其他发行版先看有哪些选择wsl --list --online装完以后可以确认默认版本是不是 WSL2wsl --set-default-version 2 wsl --list --verbose看到 Ubuntu-22.04 那一行的 VERSION 列是 2 就对了。如果是 1说明内核版本太旧或者虚拟化没生效先执行 wsl --update 升级内核。2.3 顺手把 WSL 更新到最新版WSL2 的内核和用户态组件是微软持续更新的。旧版 WSL 有些功能支持不完整比如 systemd、mirrored 网络模式、wsl --manage 命令都依赖较新的版本。我装完第一件事就是更新wsl --update更新完执行 wsl --shutdown 再重新打开终端让新内核生效。这个动作经常被忽略后面遇到一些莫名其妙的问题先想想是不是 WSL 版本太老。2.4 把 Ubuntu 的 apt 源换成国内源进入 WSL2 的 Ubuntu 后第一步我建议换源。默认源指向国外服务器下载慢不说apt update 还容易间歇性失败。很多同学吐槽“wsl2 update 慢”八成不是 WSL 自己的 update 卡而是 Ubuntu 的 apt update 卡了。Ubuntu 22.04 和更早版本配置文件在 /etc/apt/sources.list。Ubuntu 24.04 开始改成了 DEB822 格式文件位置在 /etc/apt/sources.list.d/ubuntu.sources。先确认自己系统是哪个版本cat /etc/os-release | grep VERSION_CODENAME如果是 22.04jammy或更早这样操作sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i s//.*archive.ubuntu.com//mirrors.aliyun.comg; s//security.ubuntu.com//mirrors.aliyun.comg /etc/apt/sources.list sudo apt update如果是 24.04noble直接编辑 ubuntu.sources把其中的 URL 里的 archive.ubuntu.com 和 security.ubuntu.com 替换成 mirrors.aliyun.com 即可。替换的时候注意保持 URIs 段落格式不要动 Components 那几行。换源之后 apt update 的速度会立刻改善后面装 Docker 依赖也顺畅得多。2.5 开启 systemd让服务管理走上正轨新版 WSL 支持在发行版内启用 systemd。启用之后docker、ssh、cron 这些服务都可以用 systemctl 管理和真实 Linux 服务器一致。不用 systemd 的话很多服务只能手动起重启之后要么丢失要么自己写启动脚本非常别扭。配置方法是在 /etc/wsl.conf 里加一段[boot] systemdtrue保存后回到 Windows执行 wsl --shutdown再重新进入 Ubuntu。验证systemctl is-system-running输出 running 说明 systemd 正常。这步做对了后面 docker 就可以用 systemctl enable docker 开机自启省掉很多麻烦。3. 安装原生 Docker Engine完整命令与实践3.1 为什么不用 apt install docker.ioUbuntu 官方源里有一个 docker.io 包直接用 sudo apt install docker.io 也能装上 Docker。但我不推荐理由非常实际官方源的 Docker 版本通常落后 docker-ce 仓库好几代缺少 docker-buildx 和 docker-compose-plugin 这种现在很常用的插件版本滞后会导致和 Docker Hub 上新镜像的兼容性问题也可能和某些需要新 API 的工具不匹配所以正路是从 Docker 官方 apt 源安装 docker-ce。在 WSL2 里这么做和在普通 Ubuntu 服务器上几乎一样只是内核相关模块由 WSL2 自己搞定Docker 只需要用 overlay2 存储驱动即可WSL2 默认就支持。3.2 走官方源的分步安装命令先安装前置依赖sudo apt update sudo apt install ca-certificates curl gnupg lsb-release添加 Docker 官方 GPG keysudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg添加 apt 源echo deb [archamd64 signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null如果 lsb_release -cs 输出的代号比如 noble在 Docker 仓库里还没有对应目录可以手动替换成 jammy通常也能兼容。但最稳妥的还是用官方支持的代号。更新索引并安装sudo apt update sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin安装完之后检查一下版本docker --version docker compose version到这里安装部分就结束了。是不是比想象中简单核心逻辑就是加源、装包没有特殊操作。3.3 启动、验证和用户组配置如果之前已经开启了 systemd直接sudo systemctl enable --now docker sudo systemctl status docker如果没开 systemd就用 servicesudo service docker start sudo service docker statusdocker 正常启动后建议把当前用户加入 docker 用户组免去每次敲 sudo dockersudo usermod -aG docker $USER newgrp dockernewgrp 是让当前终端会话立即生效如果不想开新终端也可以注销重进。这一步不要省不然后面 docker info、docker run 到处都是权限错误。3.4 用 hello-world 验证全链路启动成功后跑第一个容器docker run hello-world正常情况下会输出一段文字说明 Docker 安装成功。如果这一步就卡住或者拉取超时大概率是镜像拉取的问题不用慌看下一节配置镜像加速。另外提一句如果 docker run 报错 containerd 相关的问题多半是之前装过旧版 Docker 留下的残留。稳妥做法是先卸载干净sudo apt purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin sudo rm -rf /var/lib/docker然后再从头装一遍。WSL2 里的环境比较干净重来成本很低别舍不得。4. 镜像拉取加速与 Docker 其他实用配置4.1 拉镜像超时的问题到底出在哪Docker 默认从 Docker Hub 拉取镜像但在国内直连 Docker Hub 经常超时或速度极慢。这不是 Docker 本身的问题而是网络链路的问题。遇到 docker pull 卡住不动、进度条半天不走、连接被重置基本就是这个原因。解决办法是给 dockerd 配置 registry mirror。它的原理是让 docker pull 优先从配置的镜像站拉取而不是直接访问 Docker Hub。镜像站会在后台帮你缓存和转发速度通常好很多。4.2 daemon.json 配置 registry-mirrorsDocker 的守护进程配置文件在 /etc/docker/daemon.json。有就编辑没有就新建sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json EOF { registry-mirrors: [ https://docker.m.daocloud.io ] } EOF改完一定要重启 dockersudo systemctl restart docker验证配置是否生效docker info | grep -A 4 Registry Mirrors看到列表里有你填的地址说明 dockerd 已经接受这个配置。这里要特别说明registry mirror 只对 Docker Hub 官方镜像路径生效比如 nginx、ubuntu、python 这种。对于第三方私有仓库地址它不会接管。另外镜像加速服务并不保证永远稳定各家站点的可用性随时可能变化建议定期检查一下。阿里云容器镜像服务也提供每个用户专属的加速地址登录阿里云控制台后可以获得形如 https://xxx.mirror.aliyuncs.com 的个人地址在自己环境里填上那个地址也可以而且因为是个人专属通常更稳定一点。4.3 配好加速之后再顺便规划数据目录Docker 默认把所有镜像、容器层、卷都放在 /var/lib/docker 下。WSL2 的虚拟磁盘文件默认在 C 盘的用户目录里跑一段时间之后会越来越大甚至膨胀到几十 GB。如果你的 C 盘比较紧张有两个方向可以处理。方向一把 Docker 数据目录改到 WSL2 发行版内的其他位置。编辑 daemon.json加一行{ data-root: /home/yourname/docker-data }改完重启 docker。这样数据从系统盘目录挪出来但依然在 WSL2 的虚拟磁盘内。方向二把整个 WSL2 发行版的虚拟磁盘迁移到 D 盘或者 E 盘。这个方案更彻底后面专门讲。我个人的建议是对于只有一块系统盘、空间紧张的用户至少先把 Docker 数据目录挪到一个你自己清楚的路径方便后面查看占用。4.4 镜像站的“可用性”问题要留个心眼镜像加速器的时效性是个现实问题。可能今天还好好的明天就失效了。所以配置多个候选地址是比较稳妥的做法{ registry-mirrors: [ https://docker.m.daocloud.io, https://hub-mirror.c.163.com, https://mirror.baidubce.com ] }Docker 会依次尝试这些地址哪个通了用哪个。不过不建议填太多无效地址否则 dockerd 启动时探测会拖慢启动速度。两到三个足够。给一个小技巧每次配置完 daemon.json都执行 docker info 看一眼 Registry Mirrors 那一节是否显示了所有地址还有没报错。如果某一天 docker pull 突然变慢优先排查是不是第一个 mirror 挂了把顺序调一调或者临时去掉比反复猜测原因高效得多。5. 这台 WSL2 Docker 的隐藏坑网络、存储与性能5.1 systemd 和 service 两种启动方式选一个就好新版本 WSL2 启用 systemd 后docker 可以用 systemctl 管理。但并不是所有环境都默认开启 systemd这时候约束就从 service docker start。两种方式理论上结果一样但混用容易出问题。我在一次迁移中遇到过之前用 service docker start 启动了 docker后来在 /etc/wsl.conf 里开了 systemd重启之后两个 init 系统都想接管 docker导致出现重复的 socket 或者 dockerd 进程异常。遇到这种问题处理方式很简单。如果决定用 systemd就彻底禁用老的 service 表达方式打开 WSL 后先确认 systemctl is-system-running 状态正常然后sudo systemctl enable --now docker sudo systemctl restart docker之后千万不要再用 service docker stop 去停保持一种管理方式。毕竟 systemd 是正规军服务启动顺序、依赖、日志都会更规范。排查问题时也方便用 journalctl -u docker 看日志。另外如果没开 systemd 的旧环境service docker start 也能用只是在 wsl --shutdown 重启后docker 不会自动启动每次需要手动敲。想要自启又不想上 systemd可以在 ~/.profile 或 /etc/profile.d 里加启动检测但这是治标不治本还是开 systemd 稳妥。5.2 NAT 网络、mirrored 模式和跨系统访问WSL2 的默认网络模式是 NATWSL2 里有一套独立的虚拟网络。这带来几个常见问题第一Windows 侧访问 WSL2 里的服务。比如在 Ubuntu 里启动了一个监听 9090 的容器Windows 浏览器访问 http://localhost:9090 一般能通因为 WSL2 做了 localhost 转发。但也有坑如果服务监听的端口和 Windows 本机端口冲突转发规则会混乱。这时候处理办法是 wsl --shutdown 重启 WSL2基本能恢复。第二WSL2 里访问 Windows 侧的服务。比如 Windows 上跑了一个 MySQL 3306在 WSL2 里不能直接用 localhost 访问因为 localhost 指向的是 WSL2 自己的网络栈。需要拿到 Windows 主机的 IPip route show | grep default | awk {print $3}得到的地址就是网关也就是 Windows 主机在 WSL2 NAT 网络里的 IP。连接时用这个地址就行。第三如果你觉得 NAT 模式的端口转发太绕可以考虑用 mirrored 模式。在 Windows 用户目录下创建 .wslconfig 文件[wsl2] networkingModemirrored保存后 wsl --shutdown 重启。这样 WSL2 和 Windows 共享同一个网络接口IP 地址一致访问服务时端口规则和本机一致省去很多绕弯。不过我实测 mirrored 模式在部分旧版 WSL 上有兼容问题如果遇到网络异常再改回默认 NAT 就好。5.3 /mnt/c 的性能陷阱直接影响 Docker 构建WSL2 访问 Windows 文件系统是通过 9P 协议速度比访问 Linux 原生文件系统慢不少。很多人习惯把代码仓库放在 D 盘或 C 盘然后让 Docker 构建时使用这些目录结果发现镜像构建极慢那些 IO 密集的步骤比如 npm install、go build、编译大型 C 项目在 /mnt/c 路径下跑速度可能只有原生性能的十分之一。这不是 Docker 的问题而是 WSL2 跨文件系统访问的本质限制。解决思路很简单把项目目录放到 WSL2 的 Linux 文件系统下比如 $HOME/code然后通过 \wsl$\Ubuntu-22.04\home\用户名\code 这样的路径在 Windows 资源管理器里访问。IDE 用 VS Code 的话配合 Remote-WSL 插件直接访问 Linux 文件系统里的项目体验和本地编辑没区别。如果你非要项目在 Windows 盘又要求 Docker 构建快也不是没法绕但步骤比较繁琐比如用启动容器时挂载卷的方式或者在项目根目录里配置 .dockerignore 减少 context 体积。但从根源上把项目放进 Linux 文件系统比什么优化都有效。5.4 vhdx 只涨不缩磁盘膨胀与迁移方案WSL2 虚拟磁盘文件ext4.vhdx默认放在 C 盘这个文件的特点是只增不减。你在 WSL2 里删掉了几十个 GB 的镜像宿主机上的 vhdx 文件不会自动变小需要手动压缩。压缩步骤先在 WSL2 里清理 dockerdocker system prune -a退出 WSL2在 PowerShell 里执行wsl --shutdown找到发行版的 vhdx 路径。一般在C:\Users\用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04*\LocalState\ext4.vhdx用 diskpart 压缩diskpart select vdisk fileC:\Users\用户名\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu22.04...\LocalState\ext4.vhdx attach vdisk readonly compact vdisk detach vdisk exit如果想把整个发行版迁移到 D 盘推荐用新版 WSL 自带的 move 命令wsl --shutdown wsl --manage Ubuntu-22.04 --move D:\WSL\Ubuntu-22.04这个命令把发行版的虚拟磁盘整体移动过去不会丢用户配置和数据。如果你的 WSL 版本比较老没这个命令就只能用 export unregister import 的老办法但那样默认会重置为 root 用户需要自己再调整默认用户麻烦一些。6. 进阶玩法把 GPU 塞给 Docker跑 AI 训练6.1 WSL2 的 GPU 透传到底是怎么工作的如果只是跑普通容器前面几步就够了。但很多同学折腾 WSL2 是为了本地跑 AI 训练、推理或 CUDA 相关的开发。WSL2 支持 GPU 透传Linux 侧可以通过 DirectML 或 NVIDIA CUDA 调用 Windows 宿主上的 GPU。透传链路大概是这样的Windows 宿主上安装 NVIDIA 显卡驱动驱动通过 WSL2 的虚拟化层把 GPU 能力映射到 Linux 侧。Linux 侧不需要也不应该再安装 NVIDIA 的 Linux 驱动只需要安装 CUDA 相关的用户态库。这意味着在 WSL2 的 Ubuntu 里直接运行 nvidia-smi 就能看到 GPU 信息而且驱动版本显示的是 Windows 侧的驱动版本。如果这一步都不通后面 Docker 里用 GPU 就不用想了。6.2 Windows 宿主准备只装驱动别装 Linux 驱动Windows 上安装 NVIDIA 驱动时选择 Game Ready 驱动或 Studio 驱动都可以只要是较新版本都内置了对 WSL 的支持。装好之后不需要额外安装 Linux 驱动。千万别在 WSL2 的 Ubuntu 里按照网上普通 Linux 教程去装 NVIDIA Linux 驱动那会把整个 WSL 环境搞坏。WSL2 不是独立物理机它共享 Windows 的内核驱动栈额外装驱动只会冲突。装完驱动后在 Windows PowerShell 里执行 nvidia-smi能看到 GPU 信息就说明宿主准备完成。然后再进入 WSL2同样执行 nvidia-smi确认能看到 GPU。6.3 在 WSL2 里给 Docker Engine 装 nvidia-container-toolkitDocker 本身并不知道 GPU 是什么需要借助 nvidia-container-toolkit 来把宿主机的 GPU 设备挂载到容器里。步骤如下先添加 NVIDIA 容器工具包的仓库curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update安装并配置sudo apt install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker如果用的是非 systemd 方式启动restart 就改成sudo service docker restart验证 runtime 是否注册成功docker info | grep -i runtime如果能看到 nvidia说明配置生效。6.4 用 nvidia/cuda 镜像验证全链路拉一个带 CUDA 的镜像来验证docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi如果一切正常容器内会输出和宿主机一致的 GPU 信息。如果报错提到 could not select device driver with capabilities: [[gpu]]说明 nvidia-container-toolkit 没配好或者 docker 重启后 runtime 没生效。先执行 nvidia-ctk runtime configure --runtimedocker 再重启基本能解决。跑这个验证的时候第一次拉 nvidia/cuda 镜像可能要等一会儿因为这个镜像体积不小。建议找个网速不错的时候操作。6.5 给 PyTorch 这类 AI 镜像的实用建议很多 AI 开发者的误区是每次都直接拉超大镜像比如 pytorch/pytorch:latest几个 GB 起步拉取和启动都痛苦。实际上更合理的做法是在本地用一个基础镜像比如 nvidia/cuda:12.4.1-runtime-ubuntu22.04然后在这个基础上安装 PyTorch 或 TensorFlow最后提交成一个自定义镜像。这样以后每次启动只需要把它作为本地镜像跑起来避免反复从远程拉大包。当然如果你需要快速跑通实验直接用官方 PyTorch 镜像也完全可以。加 --gpus all 参数就行docker run --rm --gpus all -it pytorch/pytorch:2.3.0-cuda12.1-cudnn8-runtime python -c import torch; print(torch.cuda.is_available())输出 True 就是 GPU 可用。这里有个细节--gpus all 是把所有 GPU 给容器如果你只想用某一块可以改成 --gpus device0这在多卡机器上有用WSL2 下一般就一块显卡全给就好。按我自己的实测Win11 RTX 40 系显卡下这套 WSL2 原生 Docker Engine GPU 透传跑训练脚本性能基本接近原生 Linux差距在个位数百分比日常开发完全够用。唯一要注意的是 Windows 显卡驱动别乱升级有些新驱动在 WSL2 透传上反而会有小问题如果发现 GPU 容器突然起不来先回忆一下最近是不是动过驱动。保留一套稳定驱动别追新这是我在这个环境里踩过几次坑之后的真实体会。
