Разработка с Docker на Windows Subsystem for Linux (WSL)




Для полноценной работы с проектом на docker'е в WSL необходима установка WSL 2. На момент написания заметки ее использование возможно только в рамках участия в программе предварительной оценки Windows (WSL 2 доступна в сборках 18932 и выше). Так же отдельно стоит упомянуть, что необходима версия Windows 10 Pro для установки и настройки Docker Desktop.


Важно! В WSL 2 пропала острая необходимость в Docker Desktop для Windows 10. Как обходиться без него описано в пункте Про Docker в Ubuntu.



Первые шаги


После вступления в программу предварительной оценки и установки обновлений необходимо установить дистрибутив Linux (в данном примере используется Ubuntu 18.04) и Docker Desktop с WSL 2 Tech Preview:


  1. Docker Desktop WSL 2 Tech Preview
  2. Ubuntu 18.04 из Windows Store

В обоих пунктах следуем всем инструкциям по установке и настройке.


Установка дистрибутива Ubuntu 18.04


Перед запуском Ubuntu 18.04 необходимо включить Windows WSL и Windows Virtual Machine Platform посредством выполнения двух команд в PowerShell:


  1. Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux (потребует перезагрузку компьютера)
  2. Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

После необходимо удостовериться, что мы будем использовать WSL v2. Для этого в терминале WSL или PowerShell последовательно выполняем команды:


  • wsl -l -v — смотрим, какая версия установлена в данный момент. Если 1, то движемся далее по списку
  • wsl --set-version ubuntu 18.04 2 — для обновления до версии 2
  • wsl -s ubuntu 18.04 — устанавливаем Ubuntu 18.04 в качестве дистрибутива по-умолчанию

Теперь можно запустить Ubuntu 18.04, провести настройку (указать имя пользователя и пароль).


Установка Docker Desktop


Важно! В WSL 2 пропала острая необходимость в Docker Desktop для Windows 10. Как обходиться без него описано в пункте Про Docker в Ubuntu.


В процессе установки следуем указаниям. Компьютер потребует перезапуск после установки и при первом запуске для включения Hyper-V (из-за поддержки которого и требуется версия Windows 10 Pro).


Важно! Если Docker Desktop сообщит о блокировке со стороны firewall'а, идем в настройки антивируса и вносим следующие изменения в правила сетевого экрана (в данном примере в качестве антивируса используется Kaspersky Total Security):


  • Проходим в Настройки -> Защита -> Сетевой экран -> Настроить пакетные правила -> Local Service (TCP) -> Изменить
  • Из списка локальных портов удаляем порт 445
  • Сохранить

После запуска Docker Desktop в его контекстном меню выбираем пункт WSL 2 Tech Preview.




В открывшемся окне нажимаем кнопку Start.




Теперь docker и docker-compose доступны внутри дистрибутива WSL.


Важно! В обновленном Docker Desktop теперь вкладка с WSL внутри окна настроек. Там включается поддержка WSL.




Важно! Помимо галочки активации WSL также необходимо в вкладке Resources->WSL Integration активировать Ваш WSL дистрибутив.




Запуск


Неожиданностью стали те многие проблемы, которые возникли при попытке поднять контейнеры проектов, расположенных в директории пользователя Windows.


Ошибки различного рода, связанные с запуском bash-скриптов (которые как правило стартуют при сборке контейнеров для установки необходимых библиотек и дистрибутивов) и прочих, обычных для разработки на Linux, вещей, заставили задуматься о размещении проектов непосредственно в директории пользователя Ubuntu 18.04.

.

Из решения предыдущей проблемы вытекает следующая: как работать с файлами проекта через IDE, установленную на Windows. В качестве «best practice» я нашел для себя только один вариант — работа посредством VSCode (хотя являюсь поклонником PhpStorm).


После скачивания и установки VSCode обязательно устанавливаем в расширение Remote Development extension pack.


После установки выше упомянутого расширения достаточно просто выполнить команду code . в директории проекта при запущенной VSCode.


В данном примере для обращения к контейнерам через браузер необходим nginx. Установить его через sudo apt-get install nginx оказалось не так просто. Для начала потребовалось обновить дистрибутив WSL посредством выполнения sudo apt update && sudo apt dist-upgrade, и только после этого запустить установку nginx.


Важно! Все локальные домены прописываются не в файле /etc/hosts дистрибутива Linux (его там даже нет), а в файле hosts (обычно расположенном C:\Windows\System32\drivers\etc\hosts) Windows 10.


Про Docker в Ubuntu


Как подсказали знающие пользователи в комментариях к заметке, docker внутри дистрибутива WSL 2 абсолютно работоспособен. Это позволяет не устанавливать Docker Desktop на Windows 10 и решает проблему с наличием версии Windows 10 Pro (необходимость в Pro возникает именно в связи с использованием Docker Desktop). Устанавливается согласно инструкциям с родного сайта:



Если при выполнении команды docker начнет ругаться на демона, проверьте статус сервиса — в моем случае как и nginx он не запускается автоматически. Запустите его командой sudo service docker start.


Если в момент сборки вывалится ошибка «Service failed to build: cgroups: cannot find cgroup mount destination: unknown» попробуйте следующее решение (не мое, найдено мною, ссылка в источниках): sudo mkdir /sys/fs/cgroup/systemd; sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd.


Работа с проектом через PhpStorm


Чтобы обеспечить возможность работы с проектом в WSL через PhpStorm, необходимо сделать следующее:


  • Запускаем командную строку Windows 10 от имени администратора;
  • В командной строке Windows 10 выполняем команду mklink /D C:\project_directory \\wsl$\Ubuntu\home\user\project_directory, которая создаст символьную ссылку на папку проекта.

После этого в IDE можно открыть проект по пути C:\project_directory


P.S. Дмитрий Симагин, спасибо за решение.


Источники


Более подробное описание каждого шага можно найти тут:


Комментарии 76

    +1
    В WSL2 докер можно нативно установить прямо в WSL-контейнере (без установки докера на хост систему)
      –1
      В попытках запустить тоже самое на WSL v1 я делал так (с localhost:2375 без TLS), но там все заходило в тупик с маршрутизацией. Nginx в Ubuntu не отрабатывал обращения к контейнерам (они все работают на localhost, но с разными портами). Как раз в попытках найти решение данной проблемы я и наткнулся на историю с WSL v2.
      0
      Интересно, а возможно ли запустить Asterisk через WSL?
        0
        да, я запускал.
          0
          Стоит ли шкурка вычинки? Или лучше поднять Linux на виртуальной машине?
            0
            Однозначно не стоит. WSL, это больше поиграться.
        0
        Ну и как победили case-insensitive файловую систему Windows?
          0
          А что её побеждать-то? Какие странные манипуляции надо делать, чтобы это стало проблемой?
            +1
            Закоммитить index.png и index.PNG.
            Или в конфигах писать пути без учёта регистра.
            Но на практике у меня с этим проблемы бывают раз в пятилетку. Хуже переводы строк виндовые: поменяешь entrypoint.sh, не проверишь переводы строк и всё ломается, причём ошибки довольно безумные порой.
            Но всё это тоже решаемо.
            На самом деле у меня с WSL большие надежды, работать через Hyper-V сильно медленно.
              +2
              Первая ситуация уже представляется мне ошибкой — не могу представить, когда может реально потребоваться коммитить два таких файла (с одним расположением). Разработчик выстрелил себе в ногу, ФС её доотстреливала, 1-1 :)
              Пути без учёта регистра — в смысле, они выстрелят уже в case-sensitive окружении? Тут ещё можно поспорить, кто в этой ситуации «плохой» :)

              А вот переводы строк да, больно, регулярно натыкаюсь.
                +1

                Частая ситуация — поменяли регистр у файла и закоммтили. Теперь у всех на windows сломался репозиторий.

                  0
                  да, вот это у меня было, закомитил с ошибкой, потом поменял, локально все работает, деплой падает. Часа 4 искал ошибку
                0
                На чем основываются ваши надежды, учитывая что WSL2 работает опять таки поверх Hyper-V?
                0

                Названия веток в гите, отличающиеся только регистров, сводят гит с ума.

                0
                В итоге получается не победил. Прошу прощения, опыта мало, но если я правильно понял, то как раз я не победил, а нашел обходной путь, разместив проект именно в директории пользователя Ubuntu. Недостаток огромен — тот же PhpStorm не может работать с проектом.
                  0

                  А через симлинк не работает?

                    0

                    Через симлинк работает, но только напрямую в папку проекта. Забиндить папку ~/projects целиком не выйдет.
                    При этом есть минус: шторм может переписать права на файлы в папке и из wsl работать с ними будет тяжко.
                    Пока не завезут поддержку лучше настраивать локально и через ssh лить в wsl. Ну или использовать VS Code.

                  +1

                  Его можно включить в конкретной директории. И для этого wsl не нужен.

                    0

                    wsl 2 это виртуалуа с линуксом, так что да, победили.

                    0

                    PhpStorm тоже умеет работать с проектами на удаленных машинах. Например, в данном случае можно попробовать открыть проект через ssh.

                      0
                      Я думал об этом. Но будет это так же удобно (в плане использования тех же плагинов для Symfony или React), как с локальным проектом?
                        0

                        Насколько я помню, он будет работать так как будто проект расположен локально, но при сохранении файла закачивать его.

                        0

                        WSL предоставляет ssh или надо самому поднимать?

                          0

                          Самому. Но в случае WSL 2 с этим нет никаких проблем, по скольку это полноценный Linux.

                        0
                        Опять же, с учетом моего скудного опыта в этом деле, я предлагаю всем, кто имеет опыт по теме, владеет best practice по данной теме — напиши, подскажите. Мне самому очень хочется найти более грамотное решение
                          +2

                          Не поленитесь и зайдите в youtrack к @jetbrains и проголосуйте за плагин к WSL 2. Они судя по всему не понимают что это киллер фича разработки на Windows. Я сам пока сижу на vscode, если привыкну — откажусь от jetbrains ideшек.

                          +2
                          TL;DR: После долгих актов любви с phpStorm, WSL2 и docker в итоге победила обычная виртуальная машина.

                          Камнем преткновения оказался именно шаринг кода между системами.
                          Вариант 1 — запускать все в файловом пространстве винды. Необходимый твик — указание юниксовых LE у git. Все работает, но ЧЕРТОВСКИ медленно. Зато IDE спокойно отрабатывает.
                          Вариант 2 — запускать все в файловом пространстве WSL. Для шаринга кода лучше всего использовать встроенный механизм WSL сетевого маунта. Все работает быстро, но IDE становится плохо. Никакой синхронизации файлов, проблемы с правами + сетевой маунт раз в 15 минут отваливается и PHPStorm в этот момент начинает паниковать, так как его настроечные файлы тоже исчезли без предупреждения.

                          Переходить на VSCode не вариант.

                          Так что после месяца бесплодных попыток завести все это одновременно лучшим вариантом оказалось разворачивание отдельной копии сервиса в винде для редактирования + поднятие всех остальных сервисов проекта в WSL в таком случае тормозит только один сервис >.< Но дополнительно получаем МОРЕ проблем с связями между сервисами и постоянное ручное редактирование docker-compose.yml. + Это работает если надо работать только над одним сервисом одновременно. Если надо одновременно в 2+ покопаться сложность возрастает экспоненциально.

                          Так что в итоге — старый добрый virtualbox. Да, он отъедает у меня 16ГБ и 8 ядер процессора только для того чтобы запуститься. Ну да и хрен с ним — у меня ещё столько же остается для хост-системы.
                            0
                            А Вы пробовали установить PhpStorm в WSL?
                            Мне как-то понадобилось подебажить tarantul-скрипты. Tarantul установил в WSL и рядом поставил линукс-версию идеи. На винде запустил X-сервер.
                              +1
                              Скажем так — я очень люблю линукс. Он гибкий, быстрый, менее требовательный к ресурсам. Не было бы линукса — не было бы современного IT в то виде в котором мы его имеем. Но это отличный серверный инструмент.
                              Да простят меня продвинутые пользователи линукса, как рабочая станция он — говно.
                              Да — макось далеко не безупречна. Да — винда тоже имеет очень много косяков. Но ни мак ни видна не приводили меня в состояние, когда я хотел бы выкинуть ноут в окно.

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

                              В последний раз когда я пытался работать на убунте у меня абсолютно внезапно отключились ctrl+c и ctrl+v в русской раскладке. В английской работали. ctrl+insert и shift+insert работали. В русской — не работали. В попытке вернуть работоспособность я попытался установить полную поддержку русского языка в систему, в результате чего у меня перестали работать внешние мониторы. WTF?

                              Может я — рукожоп. Я не исключаю такую возможность. Но ни на винде ни на маке у меня таких ситуаций никогда не возникало за последние 20 лет.
                                0
                                Как админ чаще сталкиваюсь с обратным вариантом. Устройства с iOS/MacOS работают вполне стабильно, но если какой-то возможности нет или ты не знаешь, где конкретно искать эту настройку — можно убить кучу времени, пытаясь это победить. И понять, что какая-то проблема решение не имеет совсем (например — посмотреть список сохранённых wifi сетей в iPhone).
                                С windows — если оно зависло, или если что-то не работает, то зачастую логов нет нигде. Ни в одном из разумных мест. А если есть — это несколько мегабайт текстовых файлов за один короткий раз (обновления и их cbs логи, например).
                                А линукс системы если зависают, либо если какой-то софт не работает, идеологически стараются вести разумные логи. И по ним проблема почти всегда решается. При этом всегда понятно, в каких местах этот лог искать.
                                При этом из глобальных проблем при обновлениях для линукса я помню только сломанный драйвер для gma950 (что решалось просто загрузкой прошлого ядра до момента следующего обновления). Винда же при этом иногда умудряется при обновлении себя убить (с десяткой в этом плане стало чуть лучше, она чаще молча откатывается обратно, тратя кучу времени и не выдавая разумного сообщения в конце). И это всё на разнообразных системах (и десктопах, и серверах).
                                  +1
                                  Фиг его знает. Но для меня разработка на Windows — не удобно.
                                  Linux — норм.
                                  При этом выполнять «стандартные офисные задачи» на Windows наоборот удобнее, чем на Linux.
                                  Причем и на windows, и на Linux работаю в IDEA.

                                    0
                                    А я, и не пытаюсь никого убедить, что на винде удобнее. Более того — мне самому очень неудобно так как почти все инструменты приходится так или иначе допиливать под себя.
                                    Я говорил о том, что исходя из моего опыта риск того, что операционная система и/или приложения необходимые для работы внезапно встанут колом прямо посередине рабочего процесса (желательно в дедлайн) несколько меньше чем у линукса.

                                    Для работы я, на самом деле, предпочитаю мак, но прямо сейчас меня задушила жаба и вместо последнего MBP я купил себе MSI с RTX2060 на борту и очень этому рад 0=)
                                      +1
                                      Странно. У меня наоборот риск того, что что-то не заработает в Windows выше, чем в Linux. Т.к. использую только LTS сборки KUbuntu, то там практически ничего не ломают с обновлением.
                                      А вот в Windows с очередным обновлением может прилететь какая-то бяка.
                                      Это я про Windows 10.
                          • НЛО прилетело и опубликовало эту надпись здесь
                              –1
                              Демон в WSL сам по себе не работает. Только через docker для Windows
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  –2
                                  В смысле прям в нормальную Ubuntu? Понятно, это вариант всех вариантов. :) Эта история не про то. Это история про ноутбук с hiDpi и прочими фичами, с которыми Ubuntu не дружит. Про компьютер, который на Windows 10 летает, а на Ubuntu умирает. Вот отсюда интерес к WSL.
                                    0
                                    Расскажите, пожалуйста, как именно Ubuntu, и видимо конкретно Gnome, не дружит с высоким dpi?
                                      0
                                      Например, scale 1.25 или 1.5 до сих пор предоставляется как экспериментальная настройка. Активируется все это дело через терминал, во время работы сильно напрягает процессор (дискретной карты нет). KDE решает проблему, но не дружит с несколькими мониторами с разным scale.
                                  0
                                  А вот и нет. Читайте внимательнее мануалы. Докер прекрасно разворачивается внутри WSL прямо с нативным containerd
                                    0
                                    И при этом требует docker host и работу docker windows 10 с localhost:2375 без TLS, если говорим про WSL 1.
                                      0
                                      В WSL1 — да.
                                      Но я был уверен, что мы разговариваем про WSL2 в этой статье.
                                0
                                Для полноценной работы с проектом на docker'е хватит и WSL v1. Ставишь Docker for Windows, открываешь доступ по tcp без tls в настройках, в WSL также устанавливаешь docker и docker-compose, указываешь DOCKER_HOST в .bashrc и монтируешь диски windows в корень. Все работает без проблем
                                  0
                                  Возникали проблемы с обращениями к контейнерам через браузер, так как все они отзываются на localhost с разными портами. Почему и что было именно не так — не знаю пока что точно. Если дело было не в таком подключении — расскажите как быть. Ибо в данный момент получить возможность использовать WSL 2 — боль.
                                    0
                                    С маппингом портов проблем не возникало. Еще в докере запускаю nginx который проксирует запросы к контейнерам и слушает 80 и 443 порты локальной машины
                                    0

                                    Если работать только с существующими контейнерами, то да, все замечательно работает. А вот сборка образов в такой конфигурации работает крайне криво.

                                      0
                                      Что значит работает сборка работает крайне криво? За сборку в такой схеме отвечает Docker for Windows. Никаких проблем со сборкой образов замечено не было
                                        0

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

                                          0
                                          Да, не помешает для полноты картины. Просто впервые слышу о такой проблеме
                                        0
                                        Я на протяжении уже более чем года на постоянной основе использую Docker for Windows (+WSL1 с докер-клиентом, когда это нужно или просто удобно) для разработки, сборки и деплоя образов. Никаких проблем с билдами нет.
                                      0
                                      Существующий Docker desktop for Windows (тот, который работает через служебную виртуалку Hyper-V) внезапно невозможно использовать

                                      Из-за того, что Hyper-V внезапно захватывает порты
                                      github.com/docker/for-win/issues/3171

                                      Нашёл это после того, как у меня отказался стартовать рабочий compose из-за того, что 8080 порт оказался захвачен после перезагрузки хоста.
                                        +2
                                        Сколько же проблем отпадает при нативном использовании Линукса для разработки :)
                                          0
                                          И столько же возникает. Начиная от мучений от использования местного интерфейса, заканчивая невозможностью запускать игры.
                                          0
                                          Вообще вроде обещали что для wsl2 версия pro не будет нужна и что будет docker устанавливаться внутри самой wsl2, а также что новый docker for windows будет использовать wsl2 как «вирталку» вместо непосредственно hyper-v.
                                            +2
                                            Для WSL 2 версия pro не нужна, сижу под home. Для WSL 1 она тоже не нужна.

                                            В статье говорится про докер, но для него в WSL 2 она не нужна. Докер отлично ставится в WSL 2 как и в обычном дистрибутиве линукса. Собственно этим статья вводит в заблуждение.
                                              0
                                              Из моего опыта все как раз наоборот — с WSL 2 теперь можно обойтись только докером для Windows 10, без установки в саму WSL. То есть, если отключить докер для windows, демон докера не будет работать, как и в WSL 1.
                                                0
                                                Pro версия нужно для Docker Desktop, так как в домашней версии недоступна Hyper-V
                                                  0

                                                  Проверил — все верно.

                                                    0
                                                    WSL 1 и не исполнялась в виртуалке, поэтому-то что для неё PRO не была нужна ещё не означает технически что для WSL 2 работающей на Hyper-V всё должно быть также.

                                                    Это действительно не очевидно и эта статься на Хабре вносила некоторую путаницу в этой области, так как использовала Docker for Windows которому как раз всегда был нужен полноценный Hyper V который требует Windows PRO

                                                    docs.microsoft.com/en-us/windows/wsl/wsl2-faq
                                                    Does WSL 2 use Hyper-V? Will it be available on Windows 10 Home?
                                                    WSL 2 will be available on all SKUs where WSL is currently available, including Windows 10 Home.
                                                    The newest version of WSL uses Hyper-V architecture to enable its virtualization. This architecture will be available in the 'Virtual Machine Platform' optional component. This optional component will be available on all SKUs. You can expect to see more details about this experience soon as we get closer to the WSL 2 release.
                                                      0
                                                      Интересно. Означает ли это что теперь на Windows Home/Single можно будет разворачивать виртуальные машины?
                                                    0
                                                    Возможно так и есть. Надо удостовериться будет. Но по-моему Docker Desktop все-равно не установится на домашней версии. WSL на домашней доступна была с самого начала. А вот докер для Windows нет. Только старые версии, работавшие в связке с VirtualBox
                                                    +1
                                                    Вот совсем не понял, зачем на одной машине селить Docker и WSL. Точнее, не понял зачем это надо в разрезе статьи. Текущий докер десктоп поднимается как виртуальная машина в hyper-v, где и создаются контейнеры. В них можно подмонтировать любые папаки с родной машины, не обязательно для этого поднимать ubuntu. Сам разрабатываюсь в связке Win10 + Docker + *all jetbrains давненько. При этом необходимость в linux-машине возникает только для быстрой проверки каких-то догадок, типа «команда работает вот так или вот эдак», когда лень докер для этого запускать. В общем, кажется автор сделал что-то лишнее.
                                                      0
                                                      Вот совсем не понял, зачем на одной машине селить Docker и WSL
                                                      Чтобы получить нормально работающий docker (и другие линуксовые утилиты/приложения, если не брать докер)

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

                                                      необходимость в linux-машине возникает только для быстрой проверки каких-то догадок
                                                      зависит от языка, в том же руби нужен bundle install
                                                        0
                                                        Чтобы получить нормально работающий docker (и другие линуксовые утилиты/приложения, если не брать докер)

                                                        А что в винде в докере работает ненормально? Если не секрет, конечно.
                                                        с этим точно не всё так радужно, проблемы есть, у меня возникали даже с обычным постгресом

                                                        Пример покажите, пожалуйста
                                                        зависит от языка, в том же руби нужен bundle install

                                                        И что мешает сделать его в контейнере?

                                                        Я не утверждаю, что WSL не нужен. Я утверждаю, что в разрезе данной статьи он абсолютно бесполезен и бессмысленен. Что б разрабатываться в докер-контейнере достаточно Docker Desktop. При этом тот же PhpStorm работает с папкой на локальной машине, она подмонтирована в докер-контейнер на VOLUME. При необходимости — отлаживаемся при помощи xdebug. При чем тут WSL?

                                                        Вот живой пример: image
                                                          0
                                                          При этом тот же PhpStorm работает с папкой на локальной машине, она подмонтирована в докер-контейнер на VOLUME

                                                          Даже под Линуксом при такой схеме проблемы бывают с правами на каталоги и файлы, например. Как мне помнится года два назад, когда был вынужден работать под Виндой проблем с ними было гораздо больше.

                                                            0
                                                            Не буду спорить. Вот только WSL эту проблему никак не решает ) Проблему решает грамотная настройка прав в секции RUN докерфайла )
                                                              0

                                                              WSL по идее должен её частично решать за счёт того, что система управления правами одна, а не две, которые могут конфликтовать.

                                                      0
                                                      Проект будет быстро работать только если его поместить в домашнюю директорию ubuntu \\wsl$\Ubuntu\home\user\project. Для того чтобы использовать эту папку в IDE можно создать символьную ссылку. Это пока единственный рабочий способ который я нашел
                                                        0
                                                        Я пробовал создать символьную ссылку. Но Windows как-то не разделила мое устремление. Можете описать подробнее. Simlink на директорию проекта?
                                                          0

                                                          Заходим в wsl в нужную директорию 'cd /home/user/project', открываем проводник 'explorer.exe .', копируем из адресной строки путь к директории и в windows делаем символьную ссылку 'mklink /D C:\project \\wsl$\Ubuntu\home\user\project'. После этого в IDE можно открыть проект по пути C:\project

                                                            0

                                                            А проблемы с доступом к файлам из wsl из-за переписывания прав вы решили? У меня после такого сценария docker-контейнеры не видят файлы, расположенные в примонтированных папках в wsl.

                                                              0
                                                              Нет, не решил. Как описано в статье, директории проекта у меня в пользователе Ubuntu. Потому и нет возможности работать через IDE на Windows 10 полноценно (с тем же PhpStorm). Только VSCode
                                                                +1

                                                                Как выяснилось, PhpStorm 2019.3 EAP#7 и позже научили работать с путями вида \\wsl$\..., можете попробовать. Медленнее, чем нативно, но работает.

                                                        0
                                                        Возможно в меня полетят камни, но wsl -l -v выдает ошибки аргументов? Параметр -v смущает
                                                          0
                                                          Проверьте сборку Windows. Эти команды, как и сама WSL v2 доступна только в сборках выше 18932, которые в свою очередь доступны только в рамках программы предварительной оценки Windows.

                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                        Самое читаемое