Комментарии 76
В WSL2 докер можно нативно установить прямо в WSL-контейнере (без установки докера на хост систему)
В попытках запустить тоже самое на WSL v1 я делал так (с localhost:2375 без TLS), но там все заходило в тупик с маршрутизацией. Nginx в Ubuntu не отрабатывал обращения к контейнерам (они все работают на localhost, но с разными портами). Как раз в попытках найти решение данной проблемы я и наткнулся на историю с WSL v2.
Интересно, а возможно ли запустить Asterisk через WSL?
Ну и как победили case-insensitive файловую систему Windows?
А что её побеждать-то? Какие странные манипуляции надо делать, чтобы это стало проблемой?
Закоммитить index.png и index.PNG.
Или в конфигах писать пути без учёта регистра.
Но на практике у меня с этим проблемы бывают раз в пятилетку. Хуже переводы строк виндовые: поменяешь entrypoint.sh, не проверишь переводы строк и всё ломается, причём ошибки довольно безумные порой.
Но всё это тоже решаемо.
На самом деле у меня с WSL большие надежды, работать через Hyper-V сильно медленно.
Или в конфигах писать пути без учёта регистра.
Но на практике у меня с этим проблемы бывают раз в пятилетку. Хуже переводы строк виндовые: поменяешь entrypoint.sh, не проверишь переводы строк и всё ломается, причём ошибки довольно безумные порой.
Но всё это тоже решаемо.
На самом деле у меня с WSL большие надежды, работать через Hyper-V сильно медленно.
Первая ситуация уже представляется мне ошибкой — не могу представить, когда может реально потребоваться коммитить два таких файла (с одним расположением). Разработчик выстрелил себе в ногу, ФС её доотстреливала, 1-1 :)
Пути без учёта регистра — в смысле, они выстрелят уже в case-sensitive окружении? Тут ещё можно поспорить, кто в этой ситуации «плохой» :)
А вот переводы строк да, больно, регулярно натыкаюсь.
Пути без учёта регистра — в смысле, они выстрелят уже в case-sensitive окружении? Тут ещё можно поспорить, кто в этой ситуации «плохой» :)
А вот переводы строк да, больно, регулярно натыкаюсь.
На чем основываются ваши надежды, учитывая что WSL2 работает опять таки поверх Hyper-V?
Названия веток в гите, отличающиеся только регистров, сводят гит с ума.
В итоге получается не победил. Прошу прощения, опыта мало, но если я правильно понял, то как раз я не победил, а нашел обходной путь, разместив проект именно в директории пользователя Ubuntu. Недостаток огромен — тот же PhpStorm не может работать с проектом.
А через симлинк не работает?
Через симлинк работает, но только напрямую в папку проекта. Забиндить папку ~/projects целиком не выйдет.
При этом есть минус: шторм может переписать права на файлы в папке и из wsl работать с ними будет тяжко.
Пока не завезут поддержку лучше настраивать локально и через ssh лить в wsl. Ну или использовать VS Code.
Его можно включить в конкретной директории. И для этого wsl не нужен.
wsl 2 это виртуалуа с линуксом, так что да, победили.
PhpStorm тоже умеет работать с проектами на удаленных машинах. Например, в данном случае можно попробовать открыть проект через ssh.
Опять же, с учетом моего скудного опыта в этом деле, я предлагаю всем, кто имеет опыт по теме, владеет best practice по данной теме — напиши, подскажите. Мне самому очень хочется найти более грамотное решение
Не поленитесь и зайдите в youtrack к @jetbrains и проголосуйте за плагин к WSL 2. Они судя по всему не понимают что это киллер фича разработки на Windows. Я сам пока сижу на vscode, если привыкну — откажусь от jetbrains ideшек.
Да, так и сделал. Это дело нужное. Кто еще за, прошу сюда:
https://youtrack.jetbrains.com/issue/IDEABKL-7908
https://youtrack.jetbrains.com/issue/IDEA-171510
https://youtrack.jetbrains.com/issue/IDEABKL-7908
https://youtrack.jetbrains.com/issue/IDEA-171510
TL;DR: После долгих актов любви с phpStorm, WSL2 и docker в итоге победила обычная виртуальная машина.
Камнем преткновения оказался именно шаринг кода между системами.
Вариант 1 — запускать все в файловом пространстве винды. Необходимый твик — указание юниксовых LE у git. Все работает, но ЧЕРТОВСКИ медленно. Зато IDE спокойно отрабатывает.
Вариант 2 — запускать все в файловом пространстве WSL. Для шаринга кода лучше всего использовать встроенный механизм WSL сетевого маунта. Все работает быстро, но IDE становится плохо. Никакой синхронизации файлов, проблемы с правами + сетевой маунт раз в 15 минут отваливается и PHPStorm в этот момент начинает паниковать, так как его настроечные файлы тоже исчезли без предупреждения.
Переходить на VSCode не вариант.
Так что после месяца бесплодных попыток завести все это одновременно лучшим вариантом оказалось разворачивание отдельной копии сервиса в винде для редактирования + поднятие всех остальных сервисов проекта в WSL в таком случае тормозит только один сервис >.< Но дополнительно получаем МОРЕ проблем с связями между сервисами и постоянное ручное редактирование docker-compose.yml. + Это работает если надо работать только над одним сервисом одновременно. Если надо одновременно в 2+ покопаться сложность возрастает экспоненциально.
Так что в итоге — старый добрый virtualbox. Да, он отъедает у меня 16ГБ и 8 ядер процессора только для того чтобы запуститься. Ну да и хрен с ним — у меня ещё столько же остается для хост-системы.
Камнем преткновения оказался именно шаринг кода между системами.
Вариант 1 — запускать все в файловом пространстве винды. Необходимый твик — указание юниксовых LE у git. Все работает, но ЧЕРТОВСКИ медленно. Зато IDE спокойно отрабатывает.
Вариант 2 — запускать все в файловом пространстве WSL. Для шаринга кода лучше всего использовать встроенный механизм WSL сетевого маунта. Все работает быстро, но IDE становится плохо. Никакой синхронизации файлов, проблемы с правами + сетевой маунт раз в 15 минут отваливается и PHPStorm в этот момент начинает паниковать, так как его настроечные файлы тоже исчезли без предупреждения.
Переходить на VSCode не вариант.
Так что после месяца бесплодных попыток завести все это одновременно лучшим вариантом оказалось разворачивание отдельной копии сервиса в винде для редактирования + поднятие всех остальных сервисов проекта в WSL в таком случае тормозит только один сервис >.< Но дополнительно получаем МОРЕ проблем с связями между сервисами и постоянное ручное редактирование docker-compose.yml. + Это работает если надо работать только над одним сервисом одновременно. Если надо одновременно в 2+ покопаться сложность возрастает экспоненциально.
Так что в итоге — старый добрый virtualbox. Да, он отъедает у меня 16ГБ и 8 ядер процессора только для того чтобы запуститься. Ну да и хрен с ним — у меня ещё столько же остается для хост-системы.
А Вы пробовали установить PhpStorm в WSL?
Мне как-то понадобилось подебажить tarantul-скрипты. Tarantul установил в WSL и рядом поставил линукс-версию идеи. На винде запустил X-сервер.
Мне как-то понадобилось подебажить tarantul-скрипты. Tarantul установил в WSL и рядом поставил линукс-версию идеи. На винде запустил X-сервер.
Скажем так — я очень люблю линукс. Он гибкий, быстрый, менее требовательный к ресурсам. Не было бы линукса — не было бы современного IT в то виде в котором мы его имеем. Но это отличный серверный инструмент.
Да простят меня продвинутые пользователи линукса, как рабочая станция он — говно.
Да — макось далеко не безупречна. Да — винда тоже имеет очень много косяков. Но ни мак ни видна не приводили меня в состояние, когда я хотел бы выкинуть ноут в окно.
По этому я предпочитаю запускать приложения с которыми я непосредственно работаю как можно дальше от никсов. Почему-то даже один и тот-же mysql workbench прекрасно работет и в винде и в маке, но в убунте он крашится с завидной регулярностью без каких-либо внешних предпосылок.
В последний раз когда я пытался работать на убунте у меня абсолютно внезапно отключились ctrl+c и ctrl+v в русской раскладке. В английской работали. ctrl+insert и shift+insert работали. В русской — не работали. В попытке вернуть работоспособность я попытался установить полную поддержку русского языка в систему, в результате чего у меня перестали работать внешние мониторы. WTF?
Может я — рукожоп. Я не исключаю такую возможность. Но ни на винде ни на маке у меня таких ситуаций никогда не возникало за последние 20 лет.
Да простят меня продвинутые пользователи линукса, как рабочая станция он — говно.
Да — макось далеко не безупречна. Да — винда тоже имеет очень много косяков. Но ни мак ни видна не приводили меня в состояние, когда я хотел бы выкинуть ноут в окно.
По этому я предпочитаю запускать приложения с которыми я непосредственно работаю как можно дальше от никсов. Почему-то даже один и тот-же mysql workbench прекрасно работет и в винде и в маке, но в убунте он крашится с завидной регулярностью без каких-либо внешних предпосылок.
В последний раз когда я пытался работать на убунте у меня абсолютно внезапно отключились ctrl+c и ctrl+v в русской раскладке. В английской работали. ctrl+insert и shift+insert работали. В русской — не работали. В попытке вернуть работоспособность я попытался установить полную поддержку русского языка в систему, в результате чего у меня перестали работать внешние мониторы. WTF?
Может я — рукожоп. Я не исключаю такую возможность. Но ни на винде ни на маке у меня таких ситуаций никогда не возникало за последние 20 лет.
Как админ чаще сталкиваюсь с обратным вариантом. Устройства с iOS/MacOS работают вполне стабильно, но если какой-то возможности нет или ты не знаешь, где конкретно искать эту настройку — можно убить кучу времени, пытаясь это победить. И понять, что какая-то проблема решение не имеет совсем (например — посмотреть список сохранённых wifi сетей в iPhone).
С windows — если оно зависло, или если что-то не работает, то зачастую логов нет нигде. Ни в одном из разумных мест. А если есть — это несколько мегабайт текстовых файлов за один короткий раз (обновления и их cbs логи, например).
А линукс системы если зависают, либо если какой-то софт не работает, идеологически стараются вести разумные логи. И по ним проблема почти всегда решается. При этом всегда понятно, в каких местах этот лог искать.
При этом из глобальных проблем при обновлениях для линукса я помню только сломанный драйвер для gma950 (что решалось просто загрузкой прошлого ядра до момента следующего обновления). Винда же при этом иногда умудряется при обновлении себя убить (с десяткой в этом плане стало чуть лучше, она чаще молча откатывается обратно, тратя кучу времени и не выдавая разумного сообщения в конце). И это всё на разнообразных системах (и десктопах, и серверах).
С windows — если оно зависло, или если что-то не работает, то зачастую логов нет нигде. Ни в одном из разумных мест. А если есть — это несколько мегабайт текстовых файлов за один короткий раз (обновления и их cbs логи, например).
А линукс системы если зависают, либо если какой-то софт не работает, идеологически стараются вести разумные логи. И по ним проблема почти всегда решается. При этом всегда понятно, в каких местах этот лог искать.
При этом из глобальных проблем при обновлениях для линукса я помню только сломанный драйвер для gma950 (что решалось просто загрузкой прошлого ядра до момента следующего обновления). Винда же при этом иногда умудряется при обновлении себя убить (с десяткой в этом плане стало чуть лучше, она чаще молча откатывается обратно, тратя кучу времени и не выдавая разумного сообщения в конце). И это всё на разнообразных системах (и десктопах, и серверах).
Фиг его знает. Но для меня разработка на Windows — не удобно.
Linux — норм.
При этом выполнять «стандартные офисные задачи» на Windows наоборот удобнее, чем на Linux.
Причем и на windows, и на Linux работаю в IDEA.
Linux — норм.
При этом выполнять «стандартные офисные задачи» на Windows наоборот удобнее, чем на Linux.
Причем и на windows, и на Linux работаю в IDEA.
А я, и не пытаюсь никого убедить, что на винде удобнее. Более того — мне самому очень неудобно так как почти все инструменты приходится так или иначе допиливать под себя.
Я говорил о том, что исходя из моего опыта риск того, что операционная система и/или приложения необходимые для работы внезапно встанут колом прямо посередине рабочего процесса (желательно в дедлайн) несколько меньше чем у линукса.
Для работы я, на самом деле, предпочитаю мак, но прямо сейчас меня задушила жаба и вместо последнего MBP я купил себе MSI с RTX2060 на борту и очень этому рад 0=)
Я говорил о том, что исходя из моего опыта риск того, что операционная система и/или приложения необходимые для работы внезапно встанут колом прямо посередине рабочего процесса (желательно в дедлайн) несколько меньше чем у линукса.
Для работы я, на самом деле, предпочитаю мак, но прямо сейчас меня задушила жаба и вместо последнего MBP я купил себе MSI с RTX2060 на борту и очень этому рад 0=)
НЛО прилетело и опубликовало эту надпись здесь
Демон в WSL сам по себе не работает. Только через docker для Windows
НЛО прилетело и опубликовало эту надпись здесь
В смысле прям в нормальную Ubuntu? Понятно, это вариант всех вариантов. :) Эта история не про то. Это история про ноутбук с hiDpi и прочими фичами, с которыми Ubuntu не дружит. Про компьютер, который на Windows 10 летает, а на Ubuntu умирает. Вот отсюда интерес к WSL.
А вот и нет. Читайте внимательнее мануалы. Докер прекрасно разворачивается внутри WSL прямо с нативным containerd
Для полноценной работы с проектом на docker'е хватит и WSL v1. Ставишь Docker for Windows, открываешь доступ по tcp без tls в настройках, в WSL также устанавливаешь docker и docker-compose, указываешь DOCKER_HOST в .bashrc и монтируешь диски windows в корень. Все работает без проблем
Возникали проблемы с обращениями к контейнерам через браузер, так как все они отзываются на localhost с разными портами. Почему и что было именно не так — не знаю пока что точно. Если дело было не в таком подключении — расскажите как быть. Ибо в данный момент получить возможность использовать WSL 2 — боль.
Если работать только с существующими контейнерами, то да, все замечательно работает. А вот сборка образов в такой конфигурации работает крайне криво.
Что значит работает сборка работает крайне криво? За сборку в такой схеме отвечает Docker for Windows. Никаких проблем со сборкой образов замечено не было
Я на протяжении уже более чем года на постоянной основе использую Docker for Windows (+WSL1 с докер-клиентом, когда это нужно или просто удобно) для разработки, сборки и деплоя образов. Никаких проблем с билдами нет.
Существующий Docker desktop for Windows (тот, который работает через служебную виртуалку Hyper-V) внезапно невозможно использовать
Из-за того, что Hyper-V внезапно захватывает порты
github.com/docker/for-win/issues/3171
Нашёл это после того, как у меня отказался стартовать рабочий compose из-за того, что 8080 порт оказался захвачен после перезагрузки хоста.
Из-за того, что Hyper-V внезапно захватывает порты
github.com/docker/for-win/issues/3171
Нашёл это после того, как у меня отказался стартовать рабочий compose из-за того, что 8080 порт оказался захвачен после перезагрузки хоста.
Сколько же проблем отпадает при нативном использовании Линукса для разработки :)
Вообще вроде обещали что для wsl2 версия pro не будет нужна и что будет docker устанавливаться внутри самой wsl2, а также что новый docker for windows будет использовать wsl2 как «вирталку» вместо непосредственно hyper-v.
Для WSL 2 версия pro не нужна, сижу под home. Для WSL 1 она тоже не нужна.
В статье говорится про докер, но для него в WSL 2 она не нужна. Докер отлично ставится в WSL 2 как и в обычном дистрибутиве линукса. Собственно этим статья вводит в заблуждение.
В статье говорится про докер, но для него в WSL 2 она не нужна. Докер отлично ставится в WSL 2 как и в обычном дистрибутиве линукса. Собственно этим статья вводит в заблуждение.
Из моего опыта все как раз наоборот — с WSL 2 теперь можно обойтись только докером для Windows 10, без установки в саму WSL. То есть, если отключить докер для windows, демон докера не будет работать, как и в WSL 1.
Pro версия нужно для Docker Desktop, так как в домашней версии недоступна Hyper-V
Проверил — все верно.
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.
Это действительно не очевидно и эта статься на Хабре вносила некоторую путаницу в этой области, так как использовала 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.
Возможно так и есть. Надо удостовериться будет. Но по-моему Docker Desktop все-равно не установится на домашней версии. WSL на домашней доступна была с самого начала. А вот докер для Windows нет. Только старые версии, работавшие в связке с VirtualBox
Вот совсем не понял, зачем на одной машине селить Docker и WSL. Точнее, не понял зачем это надо в разрезе статьи. Текущий докер десктоп поднимается как виртуальная машина в hyper-v, где и создаются контейнеры. В них можно подмонтировать любые папаки с родной машины, не обязательно для этого поднимать ubuntu. Сам разрабатываюсь в связке Win10 + Docker + *all jetbrains давненько. При этом необходимость в linux-машине возникает только для быстрой проверки каких-то догадок, типа «команда работает вот так или вот эдак», когда лень докер для этого запускать. В общем, кажется автор сделал что-то лишнее.
Вот совсем не понял, зачем на одной машине селить Docker и WSLЧтобы получить нормально работающий docker (и другие линуксовые утилиты/приложения, если не брать докер)
В них можно подмонтировать любые папаки с родной машиныс этим точно не всё так радужно, проблемы есть, у меня возникали даже с обычным постгресом
необходимость в linux-машине возникает только для быстрой проверки каких-то догадокзависит от языка, в том же руби нужен bundle install
Чтобы получить нормально работающий docker (и другие линуксовые утилиты/приложения, если не брать докер)
А что в винде в докере работает ненормально? Если не секрет, конечно.
с этим точно не всё так радужно, проблемы есть, у меня возникали даже с обычным постгресом
Пример покажите, пожалуйста
зависит от языка, в том же руби нужен bundle install
И что мешает сделать его в контейнере?
Я не утверждаю, что WSL не нужен. Я утверждаю, что в разрезе данной статьи он абсолютно бесполезен и бессмысленен. Что б разрабатываться в докер-контейнере достаточно Docker Desktop. При этом тот же PhpStorm работает с папкой на локальной машине, она подмонтирована в докер-контейнер на VOLUME. При необходимости — отлаживаемся при помощи xdebug. При чем тут WSL?
Вот живой пример:
При этом тот же PhpStorm работает с папкой на локальной машине, она подмонтирована в докер-контейнер на VOLUME
Даже под Линуксом при такой схеме проблемы бывают с правами на каталоги и файлы, например. Как мне помнится года два назад, когда был вынужден работать под Виндой проблем с ними было гораздо больше.
Проект будет быстро работать только если его поместить в домашнюю директорию ubuntu \\wsl$\Ubuntu\home\user\project. Для того чтобы использовать эту папку в IDE можно создать символьную ссылку. Это пока единственный рабочий способ который я нашел
Я пробовал создать символьную ссылку. Но Windows как-то не разделила мое устремление. Можете описать подробнее. Simlink на директорию проекта?
Заходим в wsl в нужную директорию 'cd /home/user/project', открываем проводник 'explorer.exe .', копируем из адресной строки путь к директории и в windows делаем символьную ссылку 'mklink /D C:\project \\wsl$\Ubuntu\home\user\project'. После этого в IDE можно открыть проект по пути C:\project
А проблемы с доступом к файлам из wsl из-за переписывания прав вы решили? У меня после такого сценария docker-контейнеры не видят файлы, расположенные в примонтированных папках в wsl.
Возможно в меня полетят камни, но
wsl -l -v выдает ошибки аргументов? Параметр -v смущаетЗарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка с Docker на Windows Subsystem for Linux (WSL)