WSL Container 初体验：Windows 原生容器

前言

Microsoft 最近给 WSL 加了一个很有意思的新能力：WSL Container。

简单说，它让 Windows 用户可以通过 WSL 自带的命令行工具来运行 Linux 容器。这个工具叫：

复制代码

wslc

同时也提供了一个更直观的别名：

复制代码

container

如果你熟悉 Docker，那么 wslc 的很多概念会非常眼熟：镜像、容器、run、pull、build、exec、volume、network 等，都能在它的命令里看到。

不过要先说明：WSL Container 目前还是 public preview 。它已经可以体验，但并不代表已经完全成熟。尤其是在代理环境下，wslc pull 目前还有比较明显的问题。

这篇文章会分成两部分：

WSL Container 怎么用，有什么优势
遇到代理无法拉镜像时，如何用 Docker 或本地 tar 绕过

版本确认

首先确认 WSL 版本：

复制代码

wsl --version

我的演示环境是：

复制代码

WSL version: 2.9.3.0Kernel version: 6.18.35.2-1

确认 wslc 可用：

复制代码

wslc --versioncontainer --version

输出类似：

复制代码

wslc 2.9.3.0

WSL Container 是什么

可以把 WSL Container 理解为：WSL 自带的容器运行和管理能力。

它不是 Docker Desktop 的图形界面替代品，也不是把 Docker Desktop 原样塞进 WSL。它更像是一个 Windows / WSL 原生的容器 CLI。

查看帮助：

复制代码

wslc --help

你会看到很多熟悉的命令：

cs 复制代码

image Manage images.
container Manage containers.
network Manage networks.
volume Manage volumes.
pull Pull images.
run Run a container.
build Build an image from a Dockerfile.
exec Execute a command in a running container.

复制代码

没错就类似 docker cli, 用命令管理容器。

第一个成功演示

如果本地已经有 alpine 镜像，可以直接运行：

cs 复制代码

wslc images
wslc run --rm alpine echo "hello from WSL Container"

输出：

复制代码

hello from WSL Container

也可以查看容器里的系统信息：

复制代码

wslc run --rm alpine cat /etc/os-release

这个命令没有进入 Ubuntu 发行版，也不需要手动打开 Docker Desktop。它是由 wslc 直接启动容器。

问题来了：如果本地没有镜像，wslc run 会自动尝试 pull。

例如：

复制代码

wslc run --rm busybox echo "hello"

在网络不稳定或需要代理的环境里，可能会失败：

复制代码

Image 'busybox' not found, pullingGet "https://registry-1.docker.io/v2/": context deadline exceededError code: E_FAIL

很自然的想法是给 PowerShell 设置代理：

cs 复制代码

$env:HTTP_PROXY="http://127.0.0.1:7897"
$env:HTTPS_PROXY="http://127.0.0.1:7897"
$env:http_proxy="http://127.0.0.1:7897"
$env:https_proxy="http://127.0.0.1:7897"

然后再试：

复制代码

wslc pull busybox

但在我的测试中，仍然会超时。

原因是：WSL Container 2.9.3 preview 的拉镜像后端没有继承当前 PowerShell 的代理环境变量。

可以通过下面命令观察 wslc session 里的环境变量：

复制代码

wslc system session run printenv

我这里看到的只有：

复制代码

PATH=/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/sbin

也就是说，PowerShell 里设置的 HTTP_PROXY / HTTPS_PROXY 没有进入 wslc pull 的实际拉取路径。

当前最稳妥的办法是：不要让 wslc 现场 pull，而是提前准备镜像 tar，再用 wslc load 导入。（测试用）

用 Docker Desktop 准备镜像

如果你已经安装并启动了 Docker Desktop，可以用 Docker 先拉镜像：

复制代码

docker pull alpine

然后保存成 tar：

复制代码

docker save alpine:latest -o C:\tmp\alpine.tar

再导入到 WSL Container：

复制代码

wslc load -i C:\tmp\alpine.tar

查看镜像：

复制代码

wslc images

运行：

复制代码

wslc run --rm alpine echo "hello from WSL Container"

这不是最优雅的方案，但在 public preview 阶段非常实用。

WSL Container 的优势

虽然当前 preview 版本有代理问题，但 wslc 仍然很值得关注。

1. 更轻量

Docker Desktop 是一个完整产品，有 GUI、后台服务、设置面板、扩展、Kubernetes 等。它很强，但如果只是临时跑一个容器，就显得有些重。

wslc 更像一个系统级命令行工具：

复制代码

wslc run --rm alpine echo ok

简单、直接、适合轻量任务。

2. 更贴近 WSL 原生体验

很多 Windows 开发者已经把 WSL 当成 Linux 开发环境。

WSL Container 的方向是把容器能力也放进 WSL 体系里：

复制代码

Windows + WSL + Container

3. 有一定 Docker 工作流兼容性

很多命令和 Docker 的使用习惯相似：

cs 复制代码

wslc run --rm alpine echo hello
wslc build -t demo:latest .
wslc images

但要注意：这不等于 100% 替代 Docker Desktop。

复杂 Compose 项目、依赖 Docker Engine API 的 IDE 插件、Docker Desktop 扩展、Kubernetes 集成等，都需要单独测试。

总结

WSL Container 是一个很值得关注的新方向。

它的优点是：

更轻量
更贴近 WSL 原生体验
和 Docker 镜像 / Dockerfile 工作流有一定兼容思路

但当前 public preview 版本也有明显限制：

wslc pull

在代理环境下可能无法使用
PowerShell 的 HTTP_PROXY / HTTPS_PROXY 不一定会被拉镜像后端继承
wsl.conf

/ .wslconfig autoProxy 对 wslc pull 不一定有效
复杂 Docker Desktop 工作流还不能直接假设兼容

【微软玩具系列】WSL Container 初体验：Windows 原生容器_哔哩哔哩_bilibilihttps://www.bilibili.com/video/BV1XxT16qEts/?spm_id_from=333.1387.homepage.video_card.click

学会了吗？学会了

CSDN: @scixing

Bilibili: @无聊的年

参考链接

Microsoft DevBlogs: WSL container is now available for public preview

https://devblogs.microsoft.com/commandline/wsl-container-is-now-available-for-public-preview/
Microsoft Learn: WSL Container

https://learn.microsoft.com/en-us/windows/wsl/wsl-container
Microsoft WSL GitHub releases

https://github.com/microsoft/WSL/releases