Microsoft 30 июня показала публичную превью-функцию, которая может заметно упростить жизнь тем, кто пишет и тестирует софт на корпоративных Windows-машинах: WSL-контейнеры позволяют запускать Linux-контейнеры прямо внутри Windows Subsystem for Linux. Для русскоязычной IT-аудитории смысл предельно прикладной: меньше сторонних инструментов, меньше плясок с локальной средой и еще один аргумент в пользу Windows как допустимой машины для разработки, даже если стек у команды по факту Linux.
О новинке сообщает The Register. Microsoft добавила в WSL сразу два элемента: встроенный CLI для Linux-контейнеров и API, через который Windows-приложения смогут запускать такие контейнеры как часть собственной логики. Новый исполняемый файл называется wslc.exe, а для тех, кому лень печатать четыре буквы подряд, предусмотрен алиас container.exe. По синтаксису и поведению инструмент явно ориентирован на привычки людей, которые давно живут с Docker: Microsoft не изобретает новый язык жестов, а пытается встроиться в уже сформированный рабочий процесс.
Это важный поворот не потому, что Windows внезапно полюбила Linux, а потому что WSL из полезного компромисса постепенно превращается в полноценный слой для разработки и запуска контейнерных нагрузок. Раньше WSL был удобен прежде всего как способ открыть Linux-среду на ноутбуке, где по корпоративной политике нельзя просто снести Windows и поставить нормальную систему. Теперь Microsoft подталкивает WSL ближе к production-like сценарию для локальной разработки: собрать контейнер, прогнать тесты, отладить поведение приложения и дернуть это из Windows-инструмента без обязательной установки отдельной контейнерной платформы.
В Microsoft прямо говорят, что контейнеры давно стали базовым кирпичом современной разработки: от cloud-native-приложений и AI-нагрузок до CI/CD и тестирования. Собственно, на этом и строится аргументация компании: если контейнеры стали нормой, то Windows нужно не просто терпеть их присутствие через сторонние продукты, а предлагать встроенный, управляемый и понятный корпоративному ИТ-отделу механизм. Для бизнеса это звучит знакомо: безопасность, управляемость, интеграция с платформой. Для разработчика перевод на нормальный язык такой: если отдел инфраструктуры все равно заставляет сидеть на Windows, то теперь хотя бы часть Linux-контейнерного хозяйства можно получить «из коробки», а не через отдельный зоопарк утилит и согласований.
Самое интересное здесь даже не новый CLI, а окружающая экосистема. Microsoft обновила интеграцию Microsoft Defender for Endpoint для WSL: в приватной превью защита уже умеет видеть события, связанные с Linux-контейнерами. Появились и настройки в Intune для управления WSL-контейнерами. Проще говоря, компания не просто показала еще одну игрушку для девелоперов, а сразу подвязала ее к тем системам, которые любят службы безопасности и админы крупных организаций. Поддержка также появилась в предварительной версии Visual Studio Code: в настройках dev container можно переключить Docker path на wslc. Это уже похоже на попытку не конкурировать лоб в лоб с привычным стеком разработки, а аккуратно подменить его нижний слой так, чтобы пользователь заметил минимум боли.
Есть и технические доработки вокруг самих WSL-контейнеров. Microsoft говорит о новой файловой системе по умолчанию, которая должна ускорить доступ Windows к файлам контейнера в два раза. Формулировка звучит бодро, но здесь хочется сохранить профессиональный скепсис: двукратный рост на проблемном участке еще не означает, что стало быстро в абсолютных значениях. Кроме того, компания добавила новый сетевой режим для лучшей совместимости и улучшенные механизмы возврата памяти. Важная деталь: эти изменения пока не включаются глобально для всего WSL. Microsoft отдельно уточняет, что речь идет о критических путях вроде файлового доступа и сети, поэтому новшества активированы только внутри контейнерного сценария. Это разумная осторожность, а заодно честное признание, что в таких местах легко сломать половину чужих рабочих окружений.
Статус релиза тоже надо читать без розовых очков. Пока это public preview, то есть ранний доступ, а не функция, на которую стоит бездумно ставить важные внутренние процессы. The Register пишет, что протестированная версия выглядела достаточно стабильной, но использовать ее для серьезной работы издание считает слишком рискованным. И это справедливо: в контейнерном мире разработчики готовы терпеть много странностей, пока речь идет о локальных экспериментах, но терпимость быстро заканчивается там, где начинаются воспроизводимость сборок, интеграция с пайплайнами и ответственность за чужую команду. С другой стороны, именно такие превью обычно и определяют, куда Microsoft поведет Windows-разработку дальше: если инструмент не развалится по дороге к общедоступному релизу, он вполне может стать стандартным элементом среды для тех, кто пишет под Windows, но живет в Linux-контейнерной реальности.
Для рынка здесь, пожалуй, главный вопрос не в том, сможет ли Microsoft запускать контейнеры, а в том, насколько далеко она зайдет в сокращении зависимости от сторонних решений на разработческом десктопе. Если WSL-контейнеры действительно доведут до состояния, при котором они будут нормально дружить с VS Code, корпоративной безопасностью и типовым контейнерным workflow, Windows получит более убедительную позицию в командах, где выбор ОС давно считается решенным в пользу Linux или macOS. А вот станут ли разработчики добровольно менять устоявшийся инструментарий на встроенную альтернативу от Microsoft, будет зависеть уже не от пресс-релиза, а от скорости файловой системы, сетевых нюансов и того, как часто новый стек ломается в понедельник утром.