Комментарии
29
Не забудьте настроить PHP_IDE_CONFIG в окружении. Тогда шторм автоматом будет подцеплять конфигурацию
Удивительно, но у меня заработало без этой настройки. Пытаюсь теперь понять почему оно работает и что можно сделать лучше:)
Виртуалки сразу отбросил — ноут не очень радовался соседям внутри:) Докер поджирал заметно ресурсы
Я не пользуюсь windows при разработке, но кажется, что докер через WSL2 должен работать с минимальным оверхедом, и потреблять столько же, как обычный дистрибьютив? docs.docker.com/docker-for-windows/wsl
Не пробовали такой вариант?
Проблема разработки в докере в WSL2 в том что если маунтить проект из винды в WSL, то скорость падает настолько что работать невозможно, а наоборот в косяках работы в том же phpstorm (возможно решаемы, но пока решение не нашел, которое было бы таким же удобвным как просто win + docker)
- Проект держим в файловой системе WSL.
- Подключаем сетевой диск в винду. Например,
\\wsl$\Ubuntu. - Открываем проект с этого диска в любимой IDE.
IDE не тормозит при индексации на сетевом диске?
Смотря с чем сравнивать.
Пробовал. phpstorm сильно ругался т.к. не мог толком индексиовать
Интересно. На маке у меня не возникает проблем с линкованием папок внутрь контейнера, но вот оверхед из-за виртуализации достигает 50-60% по CPU. Т.е. 100% загрузки ядра в докере превращаются в 160% в mac os. Ну и потребление памяти, конечно.
Еще из косяков докера — очень долгая работа операции COPY при сборке контейнера. Но видел похожее issue на гитхабе, может быть пофиксят.
Еще из косяков докера — очень долгая работа операции COPY при сборке контейнера. Но видел похожее issue на гитхабе, может быть пофиксят.
Ну вот у меня тоже Docker Desktop на винде выжигает. Причем сначала вроде все ок — тишь да гладь, а потом как словит чего-то и начнет выжигать по 80-100ЦП)
WSL пока живет, крутит несколько проектов и все хорошо
WSL пока живет, крутит несколько проектов и все хорошо
Юзали Docker + Mutagen?
У PhpStorm есть такая малоизвестная фича, которая полностью решает эту проблему.
www.jetbrains.com/help/phpstorm/deployment-in-PhpStorm.html
Суть в том, что можно вообще не монтировать файловые системы, а использовать синхронизацию через FTP/SFTP. В этом случае и IDE и приложение работают в своих «родных» файловых системах, и соответсвенно издержки производительности равны нулю. При этом не важно, где именно запущено приложение. Это может быть WSL с Докером или без, Virtual Box, удалённый Линукс сервер в облаке и т.д. Синхронизация может происходить автоматически при сохранении локального файла. В случае локальной сети, деплой изменённого файла занимает 20 — 100 мс. Этого достаточно, чтобы приложение обновилось пока вы переключаетесь между окном IDE и браузера. Единственное не удобство это первоначальный деплой большого проекта. Загружать тысячи файлов через SFTP это долго. Поэтому, лучше файлы проекта выкачать прямо на удалённом сервере, например через Гит.
Помимо проблем с Windows, есть много других поводов использовать удалённый серевер для локальной разработки. Например, «тяжелые» проекты, которым требуется несколько сотен ГБ на локальном диске, или проекты со сложной инфраструктурой. Вместо того, чтобы объяснять верстальщику как поднять проект в Docker на WSL, можно просто дать ему SSH доступ к удалённому dev серверу. По сути локальная машина превращается в тонкий клиент. Все что нужно иметь в ней это браузер, терминал, IDE и Гит. Даже PHP не нужен. Все инструменты типа Composer и npm запускаются на удалённой машине. Xdebug настраивается примерно так же как описано в этой статье.
www.jetbrains.com/help/phpstorm/deployment-in-PhpStorm.html
Суть в том, что можно вообще не монтировать файловые системы, а использовать синхронизацию через FTP/SFTP. В этом случае и IDE и приложение работают в своих «родных» файловых системах, и соответсвенно издержки производительности равны нулю. При этом не важно, где именно запущено приложение. Это может быть WSL с Докером или без, Virtual Box, удалённый Линукс сервер в облаке и т.д. Синхронизация может происходить автоматически при сохранении локального файла. В случае локальной сети, деплой изменённого файла занимает 20 — 100 мс. Этого достаточно, чтобы приложение обновилось пока вы переключаетесь между окном IDE и браузера. Единственное не удобство это первоначальный деплой большого проекта. Загружать тысячи файлов через SFTP это долго. Поэтому, лучше файлы проекта выкачать прямо на удалённом сервере, например через Гит.
Помимо проблем с Windows, есть много других поводов использовать удалённый серевер для локальной разработки. Например, «тяжелые» проекты, которым требуется несколько сотен ГБ на локальном диске, или проекты со сложной инфраструктурой. Вместо того, чтобы объяснять верстальщику как поднять проект в Docker на WSL, можно просто дать ему SSH доступ к удалённому dev серверу. По сути локальная машина превращается в тонкий клиент. Все что нужно иметь в ней это браузер, терминал, IDE и Гит. Даже PHP не нужен. Все инструменты типа Composer и npm запускаются на удалённой машине. Xdebug настраивается примерно так же как описано в этой статье.
Мы примерно так и работаем когда речь идёт о "поправить вёрстку". Я стараюсь придерживаться идеи, что настройка окружения разработчику не должна затрагивать (или затрагивать по минимуму) другие сферы ответственности. То есть верстальщик не должен поднимать у себя php, бекендер не должен поднимать vue dev сервер и тд.
В таком случае можно максимально быстро онбордить в проекты людей. Описанный вами способ нами достаточно часто используется.
Этот вопрос я оставил себе на следующие выходные:) В будни надо разруливать рабочие задачи:) Но спасибо за наводку — если докер заведется без оверхеда, то это вообще будет большая победа:) а то со времен работы на Ubuntu не получается достичь нормального рабочего окружения.
Дайте, пожалуйста, знать, что получится. Еще интересно по поводу сети. Как я понимаю, проблемы сети между wsl и виндой помножатся на проблемы сети между wsl и докером. На данный момент проблемы с сетью отпугивают от wsl больше всего :)
Да, отпишу по результату, если дойду до этого:) Но, чует мое сердце, мне быстро надоест делать эти apt-get регулярные и я настрою докер)
А где вариант просто WAMP?
Windows + LAMP разве не тоже самое?)
Linux Apahce MySQL PHP !== Windows Apache MySQL PHP. У меня LAMP только на проде и я не использую виртуализации
Согласен. Сейчас добавлю пункт, но уже конечно врядли кто проголосует:)
Спасибо. 5 человек, однако уже.
Как вы разрабатываете на PHP?Ubuntu это такой алиас для всех Линукс дистрибутивов?
Ubuntu + LAMP
Ubuntu + Docker
И правда. По привычке написал Ubuntu. Поменял на Linux. Спасибо за замечание:)
Когда в линуксовом терминале набираешь
explorer.exe создаётся ощущение что этот мир где то свернул не туда. Линукс запущенный через WSL, это не тот Линукс к которому вы могли привыкнуть. Например, в нём нет systemd и Docker нужно ставить через десктопное Windows приложение. У WSL есть только два приемущества по сравнению с Virtual Box / VMware, экономия памяти и быстрый запуск. Если для вас это не критично, то намного проще и удобней использовать виртульные машины.В WSL2 в дистрибутивы linux можно установить нативно Docker и при желании systemd. У меня на Windows 10 на данный момент установлено 16 разных дистрибутивов linux в которых Docker прокидывается с хостовой машины, 2 дистрибутива linux имеют установленый Docker внутрь дистрибутива. Плюс установлены ещё 4 машины WSL2 со своими дистрибутивами linux с нативным докером и systemd.
И как производительность в разных вариантах?
Если вся рабочая среда развернута внутри WSL2 без прокидок на хостовую Windows, то на глаз, различий незаметно, будь-то Docker прокинут с хостовой машины или установленный нативно в дистрибутив linux
Я бы проголосовал, но таких вариантов нет. Я использую и WSL и Ubuntu, но не с LAMP. А с LEMP.
Добавил вариант
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Xdebug через Windows Subsystem For Linux 2 (WSL2)