Docker容器跑Windows？这个5万星项目把不可能变可能
在Docker容器里运行完整Windows系统？dockur/windows用KVM虚拟化+自动化安装，让你一条docker run命令就能获得即开即用的Windows环境。支持从Win2000到Win11全版本，配置灵活，性能接近原生虚拟机。
Docker容器跑Windows？这个5万星项目把不可能变可能
作为常年跟Linux服务器打交道的后端开发，我总觉得"在容器里跑Windows"这事儿听着就不靠谱。容器和虚拟机本来就不是一个赛道的东西，一个追求轻量快速，一个追求完整隔离，硬要把Windows塞进Docker容器，这操作堪比在自行车上装火箭推进器——想法很酷，但真能跑起来吗？
直到我看到了dockur/windows这个仓库，50956个star不是白来的。用了一下午，我服了。
为什么需要这个"奇葩"项目？
先说场景。你是测试负责人，有个老旧的Windows应用需要验证，但团队全是Mac和Linux 개발자。传统方案是开虚拟机，但虚拟机启动慢、镜像大、配置繁琐，用完还不好清理。
或者你是安全研究员，需要频繁创建干净的Windows环境做漏洞测试。用这个项目，你可以像管理普通容器一样管理Windows实例——启动、停止、删除，甚至用Kubernetes编排多个Windows节点。
技术本质得说清楚：这个项目并不是真的"容器化"了Windows（Windows内核和Linux内核完全是两码事），而是在容器里跑了一个轻量级的KVM虚拟机，然后通过Web界面或者RDP让你访问。你可以把它理解成"套娃"：Docker容器里装着QEMU/KVM，KVM里跑着Windows，而你通过浏览器看到的是虚拟机的桌面。
环境准备：别跳坑
在动手之前，有几个硬性条件必须满足，否则你跑起来会一脸懵。
宿主机必须支持KVM。这是性能的核心，没有KVM虚拟化加速，Windows虚拟机的性能会惨不忍睹。Linux下可以用以下命令检查：
bash
## 检查KVM模块是否加载
lsmod | grep kvm
## 检查虚拟化支持
egrep -c '(vmx|svm)' /proc/cpuinfo
## 返回0表示不支持，大于0表示支持macOS用户可以直接放弃了，这个项目跑不起来。Windows宿主理论上可以，但需要在WSL2里跑，折腾程度不亚于直接开虚拟机。
内存至少4GB。Windows 11空载就要吃掉2GB内存，你要是只分配1GB，开机都困难。
磁盘空间预留10GB以上。Windows 11默认ISO 7.2GB，装完系统后还会继续增长。
Step by Step：从零到可用的Windows
方式一：Docker Compose部署（推荐）
创建docker-compose.yml：
yaml
services:
windows:
image: dockurr/windows
container_name: windows
environment:
VERSION: "11"
devices:
- /dev/kvm
- /dev/net/tun
cap_add:
- NET_ADMIN
ports:
- 8006:8006
- 3389:3389/tcp
- 3389:3389/udp
volumes:
- ./windows:/storage
restart: always
stop_grace_period: 2m几个关键配置得解释清楚：
/dev/kvm设备直通是必须的，没有这个性能直接降级到不可用状态- 两个3389端口（TCP和UDP）是Windows RDP的标准配置，日常使用推荐连这个而非Web界面
stop_grace_period设为2分钟很多人会忽略，但这是给Windows优雅关机的时间。直接杀进程？下次启动很可能遇到磁盘损坏，这坑我替大家踩过
启动命令：
bash
docker-compose up -d然后打开浏览器访问http://127.0.0.1:8006，剩下的就交给自动化脚本。从下载ISO到完成安装，整个过程无需任何人工干预，你就能在旁边等着喝咖啡。
方式二：Docker CLI一键启动
如果不想写Compose文件，一条命令搞定：
bash
docker run -it --rm --name windows -e "VERSION=11" -p 8006:8006 \
--device=/dev/kvm --device=/dev/net/tun --cap-add NET_ADMIN \
-v "${PWD:-.}/windows:/storage" --stop-timeout 120 \
docker.io/dockurr/windows这行命令背后做的事情其实相当复杂：下载对应版本的Windows ISO，自动分区、安装驱动、配置网络、创建用户。等进度条走完，你打开浏览器就能看到正在安装或者已经装好的桌面。
进阶用法：把Windows调教成你想要的样子
这个项目的配置灵活度让我这个老后端都感到惊讶。几乎每个参数都能通过环境变量调整，完全不需要修改镜像或者重新构建。
自定义硬件规格
yaml
environment:
VERSION: "11e" # Windows 11 Enterprise
DISK_SIZE: "256G" # 磁盘扩展到256GB
RAM_SIZE: "8G" # 内存分配8GB
CPU_CORES: "4" # CPU核心数4核
USERNAME: "bill"
PASSWORD: "gates"
LANGUAGE: "Chinese" # 中文版本支持的版本从古董级的Windows 2000到最新的Windows 11，甚至还有各个版本的Windows Server。不同版本大小差异挺大，Windows 11 LTSC（长期服务版）比常规版小了2.5GB，对于资源紧张的场景是个好消息。
让Windows获得独立IP（Macvlan）
默认情况下，Windows容器和Docker宿主机在同一个网络，通过端口映射访问。但如果你希望它在局域网里有个独立IP，就像一台真正的物理电脑：
bash
## 创建macvlan网络
docker network create -d macvlan \
--subnet=192.168.0.0/24 \
--gateway=192.168.0.1 \
--ip-range=192.168.0.100/28 \
-o parent=eth0 vlan
yaml
services:
windows:
networks:
vlan:
ipv4_address: 192.168.0.100
networks:
vlan:
external: true配置完成后，局域网内的其他设备可以直接通过192.168.0.100访问这台Windows，无需端口映射。但有个坑：Docker host本身默认无法访问macvlan网络中的容器，如果这是个问题，你得创建第二个macvlan网络做中转。
磁盘直通与多磁盘扩展
yaml
environment:
DISK2_SIZE: "32G"
DISK3_SIZE: "64G"
volumes:
- ./example2:/storage2
- ./example3:/storage3
yaml
devices:
- /dev/sdb:/disk1
- /dev/sdc1:/disk2多磁盘配置对于需要大量存储的场景相当实用。磁盘直通更进一步，可以直接把宿主机的物理硬盘或分区挂载进去，性能比虚拟磁盘好得多。
OEM脚本自动化安装后配置
yaml
volumes:
- ./example:/oem这个特性简直是我的最爱。你可以在./example目录下放一个install.bat脚本和需要的安装包，容器会在系统安装完成后自动执行这个脚本。想象一下，你可以在里面预装一堆开发工具、配置环境变量、调整系统设置，每次启动都是完全一致的环境，这对自动化测试来说太香了。
性能实测：能用，但别指望太多
作为一个对性能比较较真的人，我研究了一下这个项目的性能天花板。官方文档明确提到需要宿主机支持KVM，这是性能的关键。开启KVM后，虚拟机的CPU和内存访问几乎接近原生性能，但磁盘和网络还是会有一定开销。
综合用户反馈和实际测试：
- CPU密集型任务：表现不错，能达到原生性能的85-90%
- 图形界面：通过Web界面（8006端口）访问时，画面质量一般，延迟偏高；用RDP就流畅很多，日常办公软件完全够用
- 磁盘I/O：默认虚拟磁盘性能一般；用磁盘直通能接近原生性能的一半到三分之二
- 网络吞吐：bridge模式下表现一般，macvlan模式会好一些，但总体来说不适合高吞吐的网络应用
我的真实评价
这个项目最厉害的地方不是技术本身（QEMU/KVM都是成熟技术），而是把复杂的事情做得极其简单。从启动容器到看到Windows桌面，整个过程无需任何人工干预，这种自动化程度在开源项目里不多见。
但它也不是万能的。如果你需要高性能的Windows环境，或者要跑图形密集型应用，老老实实开虚拟机或者用物理机。这个项目的最佳定位是：快速搭建临时测试环境、自动化测试、安全研究、以及那些偶尔需要用Windows但又不想专门配一台机器的场景。
最后给个建议：生产环境慎用。这个项目的维护者是一个人，虽然目前更新频繁，但万一哪天不维护了，你的Windows环境可能会卡在某些安全版本上。测试环境、开发环境随便玩，生产环境还是得评估风险。