Microsoft объявила об общедоступном выпуске контейнеров WSL (WSL containers, WSLC). Они позволяют запускать Linux-контейнеры в Windows с помощью встроенной команды wslc.exe. К выпуску инженеры компании подготовили разбор архитектуры платформы: рассказали об отдельных сессиях с собственными виртуальными дисками, изоляции процессов и сетевой модели Consomme, которая отличается от сетевой модели обычной Подсистемы Windows для Linux.
Публичная предварительная версия WSLC вышла в составе WSL 2.9.3. Функцию представили на конференции Build 2026, а общедоступный выпуск запланировали на осень. О возможностях предварительной версии, синтаксисе wslc.exe и API для приложений Windows мы рассказывали в отдельном материале. Об общедоступном выпуске Microsoft сообщила в блоге для разработчиков Windows, а инженер Пьер Буле в блоге Windows Command Line подробно объяснил, как устроена контейнерная платформа и чем она отличается от привычного WSL.
WSLC – встроенная в WSL платформа для работы с Linux-контейнерами. Команда wslc.exe позволяет управлять контейнерами, образами, томами и сетью. WSLC работает поверх существующей подсистемы и не является новой версией WSL вроде «WSL 3».
Как устроены сессии и их изоляция
Как и в обычном WSL, клиент обращается к службе wslservice.exe, которая работает с повышенными привилегиями. Она создаёт виртуальные машины через HCS и запускает в них процессы Linux.
В обычном WSL виртуальная машина остаётся под управлением этой службы. В WSLC служба создаёт дочерний процесс wslcsession.exe и передаёт ему работу с сессией. Этот процесс выполняется от имени пользователя, который его запустил, и отвечает за создание контейнеров, подключение каталогов и привязку сетевых портов.
Как создаётся сессия WSLC. Приложение Windows может обращаться к платформе не через wslc.exe, а через библиотеку wslcsdk.dll. Схема Microsoft
Каждая сессия работает в отдельном процессе, что усиливает изоляцию по сравнению с общей виртуальной машиной WSL. При этом процесс сессии имеет меньше привилегий, чем wslservice.exe. Такой подход позволяет чётче разграничить работу системной службы Windows и пользовательских процессов.
Внутри виртуальной машины контейнерами управляет moby, а wslcsession.exe обращается к нему по REST API поверх hvsocket. Приложения Windows могут работать с платформой не через wslc.exe, а через библиотеку wslcsdk.dll.
Собственный диск для каждой сессии и два типа томов
У каждой сессии WSLC есть собственный виртуальный диск. На нём хранятся её образы, контейнеры, сети и тома. При работе через wslc.exe эти VHD-файлы размещаются в каталоге %AppData%\Local\wslc\sessions.
Тома позволяют сохранять данные после удаления контейнера: содержимое его временного хранилища при удалении теряется. Самый простой вариант – подключить к контейнеру каталог Windows:
wslc container run -v C:\Windows\System32\drivers\etc:/volume -it debian:latest ls /volume
В этом примере содержимое C:\Windows\System32\drivers\etc доступно контейнеру debian:latest в каталоге /volume. Сначала каталог Windows подключается к виртуальной машине через virtiofs в /mnt, а затем монтируется в контейнер с помощью bind-mount.
Проверили на общедоступном выпуске: wslc 3.0.1.0 в Windows 11, сборка 26300.9550. Последняя команда – тот самый пример с подключением каталога Windows, контейнер видит содержимое C:\Windows\System32\drivers\etc
Путь каталога Windows в контейнер: сначала virtiofs в /mnt виртуальной машины, затем bind-mount в /volume. Схема Microsoft
virtiofs – файловая система для совместного доступа к файлам из основной системы и виртуальной машины. По оценке Microsoft, доступ к файлам Windows через virtiofs примерно вдвое быстрее, чем через протокол plan9, на котором работают обычные дистрибутивы WSL.
Второй тип томов использует отдельный VHD-файл вместо каталога Windows. Такой том предоставляет контейнеру обычную файловую систему Linux и позволяет задать ограничение по размеру. Например, том на 200 000 000 байт создаётся следующей командой:
wslc volume create --driver vhd -o SizeBytes=200000000 my-volume
В блоге Microsoft эта команда приведена с ошибкой: имя тома в ней указано дважды. wslc такой вызов не принимает и отвечает, что найден лишний позиционный аргумент, – имя нужно одно.
После этого том можно подключить по имени к одному или нескольким контейнерам:
wslc container run -v my-volume:/volume -it debian:latest findmnt /volume
В примере Microsoft подключённый том отображается как устройство /dev/sdf с файловой системой ext4.
Как работает сеть Consomme
Для доступа контейнеров к сети используется модель Consomme. Весь трафик виртуальной машины Linux передаётся в виде кадров Ethernet через очередь virtio. Их обрабатывает процесс Windows, запущенный от имени владельца сессии WSLC.
Этот процесс отвечает на DNS-запросы, маршрутизирует UDP- и TCP-трафик и обеспечивает проброс портов. Для Windows исходящие соединения выглядят как соединения обычного приложения того же пользователя. По словам Microsoft, благодаря этому контейнеры широко совместимы с VPN и брандмауэрами.
Consomme – сетевая модель WSLC, в которой трафик виртуальной машины Linux обрабатывает пользовательский процесс Windows. Она обеспечивает проброс портов и доступ к loopback-адресам основной системы, используя сетевой стек Windows.
В приведённом Microsoft примере nginx внутри контейнера принимает подключения на порту 80, а из Windows к нему можно обратиться через порт 8000.
Проброс порта 8000 на порт 80 контейнера. Внутри виртуальной машины трафик до контейнера всё так же проходит через NAT. Схема Microsoft
Том VHD отдаётся контейнеру отдельным устройством /dev/sde с файловой системой ext4. Ниже – nginx с пробросом порта: контейнер слушает 80-й, а curl в Windows обращается к 127.0.0.1:8000 и получает страницу
Ещё при выпуске предварительной версии Microsoft уточняла: virtiofs и Consomme по умолчанию включены только для контейнеров WSL. В обычных дистрибутивах подсистемы прежние механизмы работы с файлами и сетью сохранились – компания решила не менять их сразу для всего WSL. В статье об архитектуре общедоступной версии об изменении этого подхода не сообщается.
Исходный код и доступность WSLC
Исходный код WSLC доступен в открытом репозитории microsoft/WSL. Microsoft открыла код самой подсистемы в мае 2025 года, и контейнерная платформа развивается в рамках того же проекта.
В самой статье об архитектуре не сказано, какая версия пакета WSL нужна для общедоступного выпуска. Ответ есть в документации Microsoft Learn, обновлённой в день релиза: контейнеры требуют WSL 2.9.3 или новее, а обновиться можно обычной командой wsl --update. Переходить на предварительный канал, как это было в июне, больше не нужно. Установленную версию показывает wsl --version: на нашей машине обычное обновление принесло WSL 3.0.1.0, и wslc.exe появился в C:\Program Files\WSL.