Microsoft переводит WSL Containers в статус общего доступа
Корпорация Microsoft официально перевела проект WSL Containers из стадии публичного тестирования в статус общедоступного релиза (General Availability). Теперь функциональность доступна любому пользователю, выполнившему команду wsl —update. Как подтвердил 29 сентября Логан Айер, вице-президент Windows Platform + Developer, актуальный выпуск WSL включает в себя исполняемый файл wslc.exe и программный интерфейс WSL Containers API.
Ранее разработчикам под Windows, нуждавшимся в Linux-контейнерах, приходилось устанавливать Docker Desktop или самостоятельно настраивать Docker Engine внутри дистрибутива WSL. Теперь же Microsoft интегрирует собственный рабочий процесс для контейнеров непосредственно в WSL. Несмотря на то что текущая сборка в репозитории GitHub имеет номер 3.0.1, в компании подчеркивают: это не релиз WSL 3. Microsoft официально опровергла слухи о разработке WSL 3 ранее в этом году, пояснив, что WSL Containers — это отдельный инструмент командной строки и API, а не новая версия самой подсистемы WSL.
Инструментарий и архитектурные особенности
Первый компонент системы — wslc.exe — представляет собой утилиту командной строки для создания, запуска, управления и развертывания Linux-контейнеров из среды Windows. Для удобства пользователей, привыкших к Docker, предусмотрен алиас container.exe. Система поддерживает стандартные операции, например: wslc run —rm -it ubuntu:latest или wslc image ls.
Второй компонент, WSL Containers API, позволяет нативным приложениям Windows программно создавать Linux-контейнеры и управлять ими. Пакет Microsoft.WSL.Containers (доступен в NuGet) включает проекции для C# и C++/WinRT, поддерживает стандартные потоки ввода-вывода (stdin/stdout), монтирование файлов, сетевое взаимодействие и доступ к GPU.
Крейг Лоуэн, главный менеджер по продукту WSL, отметил, что статус GA означает полную готовность технологии к использованию в разработке и производственных средах. При этом важно понимать: «нативные» контейнеры не работают на ядре Windows, они функционируют на ядре Linux внутри инфраструктуры виртуальных машин WSL.
Архитектура WSL Containers существенно отличается от обычного WSL. По словам старшего инженера Microsoft Пьера Буле, в обычном WSL приложения взаимодействуют со службой wslservice.exe, которая создает виртуальную машину. В WSL Containers эта служба не удерживает права владения ВМ, а создает дочерний процесс wslcsession.exe. Он работает от имени пользователя, отвечая за создание контейнеров, монтирование директорий и привязку сетевых портов. Это обеспечивает более строгую изоляцию (сессии живут в отдельных процессах) и повышенную безопасность, так как сессионные операции выполняются с меньшими привилегиями, чем wslservice.exe. Каждая сессия получает собственный VHD-файл, хранящийся в %AppData%\Local\wslc\sessions.
Сетевые возможности и работа с томами
Для монтирования папок Windows в контейнеры используется технология virtiofs. Согласно данным Буле, она примерно в два раза быстрее, чем протокол plan9, который используется в стандартных дистрибутивах WSL для доступа к диску C:. Контейнеры, которым требуется нативная файловая система Linux или жесткие лимиты размера, могут использовать тома на базе VHD.
Релиз GA привносит новые команды: wslc container restart, копирование файлов через cp, управление сетью (connect, disconnect) и расширенные опции для wslc network create, включая поддержку проверок работоспособности контейнеров и аргумента —mount.
Значительные изменения коснулись сети благодаря модели Consommé. Весь трафик из виртуальной машины Linux передается в виде Ethernet-кадров в очередь virtio, а Windows-процесс, запущенный от имени пользователя, обрабатывает DNS-запросы, маршрутизацию TCP/UDP и маппинг портов. Поскольку трафик выглядит так, будто он отправлен обычным Windows-процессом, это устраняет типичные конфликты с VPN и брандмауэрами. Тесты показывают, что Flask-сервис внутри контейнера доступен по адресу 127.0.0.1:5000 без дополнительных настроек сети.
Корпоративное использование и интеграция
Microsoft подготовила решение для полноценного корпоративного применения:
- Microsoft Intune: позволяет ИТ-администраторам включать или отключать WSL Containers, а также ограничивать загрузку образов списком одобренных реестров.
- Microsoft Defender for Endpoint: теперь интегрирован с контейнерами, отслеживая активность процессов, файлов и сетевых соединений внутри контейнера с привязкой к хостовой системе Windows.
- Групповые политики: подтверждена полная совместимость с существующими механизмами управления и списками разрешенных реестров.
Также заявлено, что расширение VS Code Dev Containers теперь может использовать wslc в качестве драйвера контейнеров, обеспечивая поддержку для VS Code Containers и платформы Aspire.
Настройка WSLc и текущие ограничения
Когда пользователь Нил Эннс обратился к Лоуэну за руководством по настройке VS Code, тот ответил, что процедура «должна быть такой же простой, как установка wslc в качестве выбранного бинарного файла в настройках». Однако Эннс сообщил, что расширение Dev Containers по-прежнему выдает ошибку о том, что команда «docker» не найдена, даже после перехода с предварительной версии расширения на релизную. Таким образом, несмотря на полноценный запуск интеграции, настройка редактора все еще может требовать дополнительного устранения неполадок.
Microsoft работает над поддержкой Compose
В Microsoft заявили: «Наш главный запрос на внедрение функции для WSLc — это добавление поддержки Compose, и это станет нашим приоритетом в следующих итерациях». Инструмент Compose позволяет разработчикам описывать несколько связанных контейнеров (например, веб-фронтенд, бэкенд API, базу данных и кэш) в одном файле compose.yaml и запускать весь стек одной командой. В ходе июльского тестирования именно отсутствие Compose вынуждало запускать каждый контейнер в проектах с несколькими контейнерами по отдельности.
Цель Microsoft заключается в том, чтобы команда wsl compose up работала с существующими файлами compose.yaml без необходимости внесения изменений. Лоуэн подтвердил в социальной сети X, что эта возможность находится в дорожной карте, а статус задачи также отслеживается в соответствующем GitHub issue.
Обходные пути сообщества и отсутствие поддержки –privileged
На вопрос разработчика о том, может ли wslc собирать и отправлять образы изнутри дистрибутива WSL, Лоуэн упомянул wslc-remote — репозиторий, созданный сообществом под его авторством. Хотя Microsoft стремится к нативной поддержке этой функции, Лоуэн отметил, что существует «множество неприятных пограничных случаев», поэтому проект остается в ведении сообщества с неоднозначными ожиданиями.
Другой пользователь отметил, что отсутствие поддержки флага –privileged вынудило его вернуться к Docker для работы с кластерами Kubernetes kind и k3d. Лоуэн ответил, что эта поддержка скоро появится и в ближайшее время перейдет в стадию превью, так как она уже добавлена в основную ветку разработки. Стоит учитывать, что статус GA (общедоступный релиз) не означает, что wslc может сравниться по функциональности с любой зрелой платформой контейнеризации.
Поддержка Windows 10, Windows Server и интеграция Linux
Лоуэн подтвердил, что WSL Containers «работает везде, где поддерживается WSL». В ходе тестов wslc был успешно запущен на Windows 10 для сборки и развертывания дашборда Flask. Отвечая на вопрос в X о поддержке WSL Containers в производственной среде на Windows Server, Лоуэн подтвердил: «Да, это поддерживается в продакшене!»
Linux как ключевой элемент Windows
Ирония ситуации заключается в том, что много лет назад Стив Балмер называл Linux «раком», а теперь Microsoft фактически превращает Windows 11 в первоклассный хост для Linux-контейнеров. Выпуск собственного бесплатного дистрибутива Linux и добавление инструментов контейнеризации в WSL лишь укрепляют этот статус. В Редмонде осознали, что Windows не сможет существовать без Linux.
WSL теперь имеет открытый исходный код, Microsoft продолжает улучшать сетевое взаимодействие и доступ к файлам между Windows и Linux, а благодаря API WSL Containers приложение Windows может запускать Linux-контейнер, даже если пользователь не задумывается об участии Linux. В анонсе статуса GA Microsoft отмечает, что Linux на Windows выходит за рамки среды разработки, становясь платформой для запуска ИИ и облачных рабочих нагрузок.
Google внедряет нативную поддержку Windows 11 и WSL в свои новые ИИ-инструменты, а Ubuntu растет на Windows 11 быстрее, чем на нативных Linux-ПК, поэтому WSL все чаще связывает разработчиков Windows с инструментами Linux. Команда wsl –update предоставляет разработчикам нативный CLI и API для контейнеров Linux, а администраторы получают инструменты управления через Intune и Defender.
Тем не менее, маловероятно, что большинство пользователей смогут так быстро отказаться от Docker Desktop. Поддержка Compose все еще находится в дорожной карте, некоторые продвинутые сценарии требуют использования Docker, а сторонние инструменты по-прежнему важны. Наибольший интерес вызывает будущее команды wsl compose up: день, когда она сможет запускать существующие файлы Compose без изменений, станет моментом, когда многие разработчики наконец смогут удалить Docker Desktop.
