Глава 5. Изучение WSL2

Содержание

Глава 5. Изучение WSL2
Новая функциональность WSL2
Архитектура WSL2
Инсталляция и установка
Включение Подсистем Windows для Linux 1
Включение "Платформы Виртуальных Машин"
Включение Подсистем Windows для Linux 2
Проверка Платформы подсистем дистрибуции Linux и откат обратно к WSL1
Запуск WSL2 в Виртуальной Машине
Как меняется практика пользователя от WSL1 к WSL2
Более быстрая производительность файлов
WSL2 теперь пользуется VHD
Изменения сетевой среды и общие соображения
Доступ к приложениям Windows из Linux
Доступ к приложениям Linux из Windows
Выводы

В этой главе мы намерены изучить подсистему Windows для Linux версии 2 (WSL2), те новые функциональные возможности, которые она привносит в общую таблицу и основные различия между версиями 1 и 2. Мы также изучим как устанавливать WSL2 на вашей машине и разрешать дистрибутивы Linux для их применения в WSL2. Наконец, мы разберёмся с её архитектурой и функциональными возможностями. Основная мысль данной главы состоит в том, чтобы снабдить читателя кратким обзором архитектурных изменений в WSL2 и затем построить остальные главы с этим пониманием, которое сделает для читателя более простым осознание тех целей, которые стоят за данной версией. Итак, приступим.

Новая функциональность WSL2

WSL2 это самый последний и величайший выпуск подсистемы Windows для Linux. Эта новая версия была собрана, имея в виду два основных обстоятельства и наиболее частых запросов сообщества:

  1. Лучшая производительность файлового ввода/ вывода - Увеличение в производительности ввода/ вывода означает более быстрые операции чтения и записи в файлах, а их скорость в целом зависит от того, насколько интенсивны операции доступа к файлам. Такие задачи как “git clone”, “npm install”, “apt update” или “apt upgrade” могут показывать в 2 - 3 раза более быстрые действия, в то время как распаковка некого упакованного файла tarball в WSL2 может иметь в 20 раз большую производительнсоть по сравнению с WSL1.

  2. Полная поддержка системных вызовов - Все вырабатываемые в подсистеме Windows для Linux версии 1 для выполнения функций, таких как доступ к файлам, запрос памяти, порождение процессов и тому подобное, которые вырабатывались из Linux, транслировались в соответствующие системные вызовы Windows для лежащей в основе операционной системы. Это стало возможным благодаря разработанному командой WSL уровню трансляции, однако у него имеются свои проблемы,к тому же невозможно было транслировать все системные вызовы Linux в Windows. Более того, команде WSL в Microsoft приходилось реализовывать этот уровень и приспосабливать его для любых изменений в ядре Linux.

    По этой причине Microsoft принял решение, что WSL2 будет содержать своё собственное ядро Linux для совместимости полной поддержки системных вызовов и более простого выполнения доставки обновлений ядра. Это открыло окна для бесшовного запуска внутри WSL2 дополнительных приложений, таких как Docker и прочие системы. Кроме того, Microsoft поддерживает fork ядра Linux; это означает, что любым обновлениям самого ядра Linux не приходится дожидаться длительного времени своего прихода в Windows и они могут быстро обновляться, публиковаться и распространяться более расторопно для своих пользователей. Все улучшения ядра и исправления его безопасности доступны через обновления Windows.

Имея ввиду все эти обстоятельства, важно также поддерживать тот же самый уровень практики без изменения большого чила моментов, которые уже применяются пользователями WSL1.

WSL1 сделал возможным для пользователей запуск исполняемых файлов ELF64 Linux в их подсистеме Windows для Linux, однако существуют изменения в версии 2 относительно того как такие исполняемый файлы Linux взаимодействуют с операционной системой Windows и самим системным оборудованием, в основном по той причине, что теперь начиная с WSL2 Microsoft снабжает Windows ядром Linux с более совершенной технологией виртуализации. Поскольку теперь доступно полное ядро, WSL также добавляет поддержку исполняемых файлов ELF32 или иных прочих функциональных возможностей, которые поддерживаются собственным ядром Linux.

Прежде чем мы приступим к применению WSL2, имеются два важных предварительных требования, которые необходимо соблюсти; прежде всего, WSL2 доступна лишь начиная с Windows 10 build 18917 и более поздних версий. Во- вторых, присоединитесь, пожалуйста, к программе “Windows Insider Program”, что отражено на Рисунок 5-1 и выберите быстрое (Fast) или медленное (Slow) кольцо (которое предлагает более стабильные обновления) для получения выпусков предварительного просмотра тех сборок Windows, которые поставляются с WSL2. Если вы уже работаете с Windows 10 версией 2004, пожалуйста, игнорируйте вторичную установку.

 

Рисунок 5-1


Возможность для Windows Insider Program

WSL2 вскорости (или уже в момент прочтения вами этих строк) выступает частью Windows 10 версии 2004, когда она станет доступной для всех. Именно это является шагом Microsoft в сторону улучшения их модели обслуживания ядра Linux через придание большей обтекаемости практики установок через Windows Update вместо снабжения их неким собственным образом ОС. Это подразумевает, что все ваши обновления ядра Linux будут бесшовно добавляться в вашу систему через Windows Update, в точности как любое программное обеспечение, исправления и драйверы. Всё что вам требуется, это просто кликнуть по кнопке “Check for updates” в настройках обновления Windows и установить эти обновления подобно Рисунку 5-2.

 

Рисунок 5-2


Обновление до Windows 10 версии 2004

На этом этапе данной главы вы, должно быть, думаете: что произойдёт с WSL1 и дистрибутивами Linux, которые я настраивал для него? Будет ли Microsoft прекращать поддержку WSL1 или отказываться от неё? Чтобы ответить на этот вопрос, скажем, не о чем беспокоиться, поскольку Microsoft не намерена и не планирует отказываться от WSL1, и эти две версии предназначены для параллельной работы. Это означает, что среды WSL1 и WSL2 Linux могут работать бок о бок, и вы можете обновлять и понижать версию любого дистрибутива, когда это необходимо. Позже в этой главе мы рассмотрим, как это делается.

Архитектура WSL2

Ядро Linux, которое поставляется с подсистемой Windows для Linux 2, запускается на облегчённой служебной виртуальной машине, которая изначально была разработана для сценариев сервера по запуску большого числа изолированных контейнеров на основе Hyper-V на одной машине хостинга и для поддержки более быстрого времени запуска.

Это не обычная виртуальная машина, новейшая и наилучшая технология виртуализации (на основе Hyper-V), разработанная для уменьшения объёма ресурсов, времени запуска, а также времени, затрачиваемого на создание, настройку и управление обычных виртуальных машин. Таблица 5-1 предоставляет некоторые отличия, чтобы сделать такое разграничение более отчётливым.

Таблица 5-1. Сопоставление обычных ВМ и и облегчённых служебных ВМ, применяемых WSL
Обычная ВМ Облегчённая служебная ВМ WSL2

Гостевая операционная система ВМ изолировнно от операционной системы своего хоста.

Гостевая операционная система ВМ очень сильно интегрирована с операционной системой своего хоста.

WslGetDistributionConfiguration( )

Выполняет выборку текущих настроек зарегистрированного в WSL дистрибутива.

Более медленное время запуска.

Более быстрое время запуска, то есть, менее 1 секунды.

Большее потребление памяти.

Меньшее потребление памяти.

Создание этих ВМ и управление ими.

Автоматические настройка и запуск только в случае необходимости.

Давайте окунёмся чуть глубже и разберёмся что происходит под капотом, когда запускается некий дистрибутив Linux WSL2. Прежде всего убедимся, что все экземпляры WSL прекращены:


> wsl --shutdown

Затем мы попытаемся выполнить некую команду в своём дистрибутиве WSL2 по умолчанию, который изменит своё состояние в “Running” после запуска команды. Теперь, чтобы убедиться в этом, запустим консоль PowerShell с полномочиями администратора и перечислим все запущенные контейнеры Hyper-V при помощи команды hcsdiag.exe list, которая выступает диагностическим инструментом для проверки контейнеров, управляемых Host Compute Service (Службой вычислений хоста), а затем это покажет нам все облегчёные контейнеры ВМ, которые были созданы незамедлительно за менее чем одну секунду, как это отражено на Рисунке 5-3.

 

Рисунок 5-3


Служба вычислений хоста создала облегчённую ВМ

Два других контейнера ничто иное как виртуальные машины Hyper-V, которые уже созданы в моей машине хоста и пребывают в состоянии исполнения. Как показано на Рисунке 5-4, вы можете увидеть их GUID из hcsdiag.exe list и установить соответствие результатов из cmdlet Get-VM.

 

Рисунок 5-4


Прочие виртуальные машины Hyper-V

Однако если мы погасим все экземпляры WSL2 снова и повторно выполним некую команду в моём дистрибутиве Linux WSL2, тогда это запустит некий новый контейнер для облегчённой вспомогательной ВМ с новым GUID, что видно на Рисунке 5-5.

 

Рисунок 5-5


Новая облегчённая ВМ стартует при каждом запуске команды

Теперь, когда мы понимаем, что наше ядро Linux запускается в такой облегчённой ВМ, тавайте рассмотрим дополнительно реальную архитектуру WSL, которая продемонстрирована на Рисунке 5-6 и те шаги, которые вовлекаются в общий процесс при запуске приложения Linux из операционной системы Windows и то, как это интегрировано с той ВМ Linux, которая снабжает нас бесшовной и наилучшей из обеих вселенных практикой.

 

Рисунок 5-6


Схема архитектуры и рабочий поток WSL2

Ниже приводятся все компоненты, которые продемонстрированы в этом рабочем потоке, которым вы можете последовать при представлении вами всего представленного:

  1. “wsl.exe” применяется для перечисления дистрибутивов, как запущенных, так и взаимодействующих со своей подсистемой, которая включена через службу LxssManager.

  2. LxssManager

    удерживает перечень того, какие дистрибутивы установлены и какие запущены, а затем вызывает HCS (Службу вычислений хоста).

  3. Сама Служба вычислений хоста является частью технологии виртуализации Hyper-V, которая делает возможной собственно WSL2; она будет запускать облегчённые служебные ВМ, использующие соответствующее ядро Linux.

  4. Этой ВМ далее ставится в соответствие файловая система вашего дистрибутива Linux и вызывается некий процесс init для инициализации и запуска вашего приложения.

  5. После этого настраивается некий ретранслятор из стандартного ввода со стороны Windows в ваше приложение, в нашем случае bash, поэтому устанавливается взаимосвязь между сторонами Linux и Windows с тем, чтобы мы могли наблюдать что происходит внутри нашего приложения Linux, когда на стороне Windows запускается некая команда.

    Обычно, стандартный ввод Windows отправляет команды в надлежащий сокет, затем эти команды считываются из этого сокета в облегчённую гостевую операционную систему и, наконец, этот скет служит стандартным вводом для такого приложения Linux, как “bash”.

Эта виртуальная машина запускается только когда вы запускаете своё приложение Linux и если вы уничтожаете своё приложение Linux или прекращаете wsl.exe, эта облегчённая виртуальная машина уходит прочь. Когда вы повторно запускаете некое приложение Linux, эта ВМ запускается новой и стартует опять.

Обратите, пожалуйста, внимание на то, что вне зависимости от того сколько дистрибутивов WSL2 запускаются на вашей машине, все они будут запускаться внутри отдельной облегчённой служебной ВМ. Это означает, что для каждого пользователя будет создаваться только одна вспомогательная ВМ Linux для обеспечения запуска множества дистрибутивов с применением WSL2. Каждый дистрибутив запускается в неком изолированном контейнере с тем чтобы не возникало каких- то проблем. Это достигается при помощи API пространства имён Linux с целью снижения общего объёма памяти и ресурсов создавая запуски всех дистрибутивов в некой отдельной ВМ.

С другой стороны, для доступа к файлам в WSL2, такие точки монтирования, как /mnt/c для обработки подобных запросов применяют файл сервер протокола 9P. Само ядро Linux выступает в качестве клиента этого протокола 9P, запущенного в своей облегчённой виртуальной машине, то есть, в собственной гостевой операционной системе, которая затем выполняет некий запрос в сервер 9P, запущенный в операционной системе её хоста (Windows 10) для доступа к файлам Linux из Windows.

Инсталляция и установка

Подсистема Windows для Linux поставляется в качестве функциональной возможности в Windows 10, однако имеется ряд шагов, вовлечённых во включение этой функциональности для WSL1, которое мы уже обсуждали в одной из предыдущих глав; отдельно от этого также уже обсуждалось требование включения функциональной возможности “Virtual Machine Platform”. Только после того как оба эти два предварительных требования соблюдены, можно далее продолжить преобразование наших дистрибутивов Linux WSL1 в WSL2 или выбрать WSL2 в качестве установленного по умолчанию для всех функциональных возможностей установленных дистрибутивов Linux.

Давайте сделаем это пошагово за раз.

Включение Подсистем Windows для Linux 1

Если вы ещё не применяли Linux в Windows 10, сейчас самое время заняться этим. Вы можете вначале стартовать с включения подсистемы Windows для Linux из Windows Features, как это уже упоминалось, следующими этапами:

  1. В линейке задач Windows снизу слева на вашем экране кликните по кнопке “Start” (“Пуск”).

  2. Теперь найдите “Turn Windows Features” (Включение или отключение компонентов Windows), а затем кликните по полученному результату вверху, как это показано на Рисунке 5-7.

     

    Рисунок 5-7


    Поиск “Включение или отключение компонентов Windows”

  3. Это откроет блок диалога “Включение или отключение компонентов Windows”. Отмотайте вниз и убедитесь что блок функциональности “Windows Subsystem for Linux” (Подсистема Windows для Linux) отмечен. Кликните OK и выйдите из этого блока диалога.

  4. Сохраните все открытые работы, ибо у вас может быть запрошено разрешение на перезгрузку вашей системы. Следуйте необходимым приглашениям на закрытие исполняемых приложений.

{Прим. пер.: Аналог через приглашение командной строки/ PowerShell:}


> dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

После того как WSL1 включён и ваша система перезапущена нам теперь необходимо включить “Virtual Machine Platform”. Чтобы сделать это выполните приводимые далее шаги. Обратите внимание, что эти шаги можно выполнять только если ваш компьютер поддерживает аппаратную виртуализацию и она включена в вашем BIOS или UEFI.

Включение "Платформы Виртуальных Машин"

  1. Запустите сеанс PowerShell с полномочиями администратора.

  2. Выполните в PowerShell приводимую ниже команду и, если вы наблюдаете отображаемые на Рисунке 5-8 результаты, тогда требуемая вами функциональность успешно включена.

    
PS> Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
     

    Рисунок 5-8


    Включение платформы Виртуальной Машины

  3. Если будет такой запрос, перезагрузите свою машину.

После выполнения этих шагов мы теперь можем преобразовать свои дистрибутивы Linux в подсистему Windows для Linux 2 или выбрать WSL2 в качестве архитектуры по умолчанию для запуска этих дистрибутивов.

Включение Подсистем Windows для Linux 2

Прежде чем включать WSL2, имеются некоторые временные меры, которые нам следует выполнить установку ядра Linux вручную. В ближайшем будущем, когда обновления WSL начнут доставляться через Центр обновления Windows, выполнение таких действий вручную не потребуется.

  1. Выгрузите обновление ядра Linux WSL2 со следующего URL.

  2. После завершения выгрузки кликните дважды по выгруженному вами файлу “wsl_update_x64.msi” в его местоположении для его запуска и примените это обновление.

  3. После применения данного обновления Пройдите в меню Start и запустите PowerShell.exe с полномочиями администратора.

  4. Теперь выполните приводимую ниже команду, как это отображено на Рисунке 5-9 чтобы сделать WSL2 архитектурой по умолчанию для всех новых дистрибутивов которые вы будете устанавливать в своей системе далее. Это не изменит уже имеющиеся дистрибутивы, запускаемые в WSL1, причём они обе будут сосуществовать совместно.

    
PS > wsl --set-default-version 2
     

    Рисунок 5-9


    Установка WSL2 в качестве архитектуры по умолчанию для новых дистрибутивов Linux

  5. Для настройки всех имеющихся дистрибутивов Linux на применение архитектуры WSL2, вы можете достичь этого выполнив wsl --set-version и название соответствующего дистрибутива Linux со следующей за ним “2”, как это отражено на Рисунке 5-10.

    
PS > wsl --set-version kali-linux 2
     

    Рисунок 5-10


    Преобразование дистрибутива Linux WSL1 в WSL2

Проверка Платформы подсистем дистрибуции Linux и откат обратно к WSL1

Очень просто проверить ту архитектуру, которую применяют ваши дистрибутивы Linux с помощью такой команды:


PS > wsl --list --verbose

Это приведёт список всех дистрибутивов Linux с их версиями и, как мы можем видеть на Рисунке 5-11, здесь также отражено и наше преобразование дистрибутива kali-linux с нашего предыдущего этапа.

 

Рисунок 5-11


Проверка версий дистрибутивов Linux WSL

Если мы желаем применять старую архитектуру WSL1, мы запросто можем преобразовать свой дистрибутив на использование WSL1, как это показано на Рисунке 5-12 и в нашем следующем примере:


wsl --set-version kali-linux 1
 

Рисунок 5-12


Откат обратно платформу дистрибутивов Linux к WSL1

Если вы полагаете что WSL2 это всё ещё экспериментальное программное обеспечение, вы можете не захотеть запускать его на своей первичной вычислительной системе и вместо этого провести оценку этого программного обеспечения в некой виртуальной машине. Однако прежде чем вы сможете применять WSL в некой виртуальной машине, имеется несколько моментов, в которых вы захотите разобраться и несколько требующихся нам конфигураций.

Запуск WSL2 в Виртуальной Машине

Вы также можете запускать свою подсистему Windows для Linux в виртуальных машинах Hyper-V. Всё что вам требуется, это убедиться что ваша виртуальная машина обладает включённой встраиваемой виртуализацией в ней, как это показано на Рисунке 5-13.

Для включения этой настройки мы можем воспользоваться PowerShell. Для этого выполните приводимую ниже команду в консоли PowerShell с правами администратора. Убедитесь только что вы предоставили верное название своей целевой Виртуальной машины. Эта настройка может быть применена только когда такая машина пребывает в остановленном состоянии, поскольку вы не можете изменять конфигурацию процессора при его работе.


PS > Get-VM 'Name' | Set-VMProcessor -ExposeVirtualizationExtensions $true
 

Рисунок 5-13


Включение WSL в виртуальных машинах Hyper-V

Некоторые из основных приложений виртуализации сторонних разработчиков могут не работать при применении в вашей системе Hyper-V. Это означает, что вы можете быть не способны запускать WSL совместно с VMware и VirtulBox. Тем не менее, поставщики этих основных технологий виртуализации в последнее время выпустили своё собственное программное обеспечение, которое поддерживает WSL2 и Hyper-V. Вот вам для справки некоторые ссылки на страницы этих выпусков:

Как меняется практика пользователя от WSL1 к WSL2

Microsoft изо всех сил старалась сохранить согласованность взаимодействия с пользователем в обеих архитектурах, но, несмотря на это, пользователи WSL2 заметят три основных изменения в общей пользовательской практике при переходе с WSL1 на WSL2.

Более быстрая производительность файлов

Испробуйте более высокую производительность файлового обмена, но для этого рекомендуется хранить все ваши файлы в корневой файловой системе дистрибутива Linux, ибо теперь у нас в подсистеме Windows для Linux 2 имеется полное ядро Linux, которое может легко обрабатывать эти операции с большим объёмом файлов и, по сравнению с WSL1, в несколько раз быстрее.

Для проведения эталонного тестирования мы проверим установку программного обеспечения при помощи диспетчера пакетов и протестируем веб сокеты при помощи запросов curl и в WSL1, и в WSL2.


> time sudo apt install ruby –y
> time curl google.com

Рисунок 5-14 демонстрирует, что установка “ruby” требует до завершения около 30 секунд в WSL1, а веб запрос к google.com выполняет выборку результата примерно за 5 секунд. Теперь давайте проверим то де самое в WSL2, однако убедитесь, что вы выполняете это в том же самом дистрибутиве Linux. Данная проверка выполнялась в дистрибутиве Linux Ubuntu 18.04 LTS, а потому я обязан изменить версию архитектуры с WSL1 на WSL2 и удалить уже установленное программное обеспечение “ruby” из своего дистрибутива для проведения проверки заново.

 

Рисунок 5-14


Производительность файлового обмена и веб сокета в WSL1

Наша проверка в WSL2 демонстрирует, что общая установка выполнилась менее чем за 5 секунд (в 6 раз быстрее чем в WSL1), а веб запрос занял 1/10ю секунды (в 50 раз быстрее чем в WSL1) для своего завершения и получения результатов как это выделено на Рисунке 5-15. Это существенное увеличение производительности по сравнению с подсистемой Windows для Linux с архитектурой версии 1.

 

Рисунок 5-15


Производительность файлового обмена и веб сокета в WSL2

WSL2 теперь пользуется VHD

Поскольку WSL2 применяет облегчённую вспомогательную ВМ, как и прочие виртуальные машины, она хранит все свои файлы Linux внутри некого виртуального жёсткого диска (VHD, virtual hardware disk), который пользуется файловой системой ext4. Этот VHD изначально устанавливается с размером 256 ГБ и, в зависимости от вашей нагрузки, этот VHD автоматически увеличивается и сжимается для удовлетворения ваших требований в хранении пока он не ударяется в этот установленный предел. Как только этот предел достигнут, вы начинаете получать сообщения об ошибках “out of disk space” (исчерпано дисковое пространство). Для исправления этих ошибок вам придётся расширить размер VHD выполнив такие шаги:

  1. Уничтожьте все запущенные экземпляры WSL при помощи следующей команды:

    
> wsl --shutdown

  2. Воспользуйтесь PowerShell для поиска своего названия пакета установки дистрибутива Linux PackageFamilyName и значения полного пути к его файлу ext4.vhdx:

    
PS > $pkgFamilyName = (Get-AppxPackage -Name "*ubuntu*").PackageFamilyName
PS > $Path = "$env:LOCALAPPDATA\Packages\$pkgFamilyName\LocalState\*.vhdx"
PS > $vhd = Get-ChildItem $Path

    Наконец, воспользуйтесь cmdlet Resize-VHD из модуля Hyper-V для расширения этого виртуального жёсткого диска до желаемого вами результата, как это показано на Рисунке 5-16.

    
PS > Resize-VHD -Path $VHD.FullName -SizeBytes <size>
     

    Рисунок 5-16


    Изменение размера виртуальных жёстких дисков WSL2

  3. После того как вы осуществили изменение размера и не получили никаких ошибок, как на нашем предыдцщем изображении, перезапустите свой дистрибутив WSL2.

  4. Теперь вы имеете расширенную в размере файловую систему изнутри WSL и вам надлежит уведомить её о произведённых на предыдущем шаге изменениях. Для этого вам придётся выполнить приводимую ниже команду в своём дистрибутиве WSL чтобы проверить что эта файловая система смонтирована:

    
> sudo mount -t devtmpfs none /dev

    После выполнения этого, далее нам придётся отыскать свою используемую корневую файловую систему путём фильтрации своих файловых систем по типу ext4, воспользовавшись приводимой далее командой, которая выделит точку монтирования, которую мы желаем иметь целевой, как это показано на Рисунке 5-17.

    
mount | grep ext4

  5. Скопируйте полученное здесь значение записи, например, /dev/sdb, из следующего примера и запустите такую команду:

    
sudo resize2fs /dev/sd**

    Убедитесь, что вы заменили наши звёздочки (**) в предыдущей команде правильными символами в своей команде и, когда она успешно завершится без ошибок, тогда завершится и расширение вашего VHD. Может быть запрошена установка resize2fs, если он ещё не установлен в вашем дистрибутиве Linux.

     

    Рисунок 5-17


    Расширение VHD внутри WSL2

Изменения сетевой среды и общие соображения

При использовании дистрибутива Linux WSL1, все системные вызовы Linux транслировались в системные вызовы Windows и если ваша система применяет LAN, тогда любое запущенное в WSL приложение также будет напрямую пользоваться этой LAN. Однако это поведение изменилось в WSL2 поскольку WSL2 запускает облегчённую служебную ВМ, и имеет виртуальный сетевой адаптер со своим собственным IP адресом, предназначенным именно ей, как это показано на Рисунке 5-18.

 

Рисунок 5-18


WSL2 обладает выделенным адаптером Ethernet

Дополнительно к этому, поскольку WSL2 всё ещё новый продукт и работа над ним продолжается, вы обнаружите, что в ранних выпусках WSL2 вам придётся получать доступ к операционной системе Windows из Linux при помощи IP адреса вашей хост машины, однако эта практика сгладится в последующих выпусках.

Доступ к приложениям Windows из Linux

К примеру, мой компьютер работает под Windows 10 версии 2004 (сборка ОС 19041.172), и у меня имеется простой сервер Node.js, запущенный на стороне Windows 10 и я запросто могу получить доступ к этому серверу при помощи адреса обратной связи (loopback) изнутри WSL2 при помощи простой команды “curl”, как это отражено на Рисунке 5-19.

 

Рисунок 5-19


Доступ к серверу Node.js в Windows из WSL2

Доступ к приложениям Linux из Windows

В точности также как я получал доступ к некому приложению Windows из Linux в своём предыдущем примере, аналогично, мы также можем получать доступ к приложению Linux, Node.js, запущенном в дистрибутиве Linux WSL по http://localhost со стороны Windows 10. Рисунке 5-20 демонстрирует команду PowerShell Invoke-WebRequest для доступа к терминальному пункту, запущенному в WSL.

 

Рисунок 5-20


Доступ к серверу Node.js в WSL2 из Windows

Выводы

В этой главе мы изучили новые функциональные возможности WSL2 и улучшения в ней, а также основную цель, стоящую за поставкой полного ядра Linux в Windows 10 для поддержки новой версии нашей подсистемы Windows для Linux. Мы включили поддержку и выполнили установку WSL2 и изучили как запускать параллельно платформы подсистем WSL1 и WSL2. Далее мы также взглянули на преобразование дистрибутива Linux WSL1 в совместимый с WSL2 дистрибутив и потом провели эталонное тестирование улучшения производительности файловой системы и сетевой среды в WSL2. Ближе к концу главы мы выполнили операцию изменения размера в виртуальном жёстком диске WSL2 и завершили главу сетевыми изменениями в WSL2. В своей следующей главе мы намерены изучить файловую систему подсистемы Windows для Linux, её архитектуру и то как эта файловая система делает возможным взаимодействие между Linux и Windows.