Комментарии 32
Не забудьте настроить PHP_IDE_CONFIG в окружении. Тогда шторм автоматом будет подцеплять конфигурацию
Виртуалки сразу отбросил — ноут не очень радовался соседям внутри:) Докер поджирал заметно ресурсы
Я не пользуюсь windows при разработке, но кажется, что докер через WSL2 должен работать с минимальным оверхедом, и потреблять столько же, как обычный дистрибьютив? docs.docker.com/docker-for-windows/wsl
Не пробовали такой вариант?
Проблема разработки в докере в WSL2 в том что если маунтить проект из винды в WSL, то скорость падает настолько что работать невозможно, а наоборот в косяках работы в том же phpstorm (возможно решаемы, но пока решение не нашел, которое было бы таким же удобвным как просто win + docker)
- Проект держим в файловой системе WSL.
- Подключаем сетевой диск в винду. Например,
\\wsl$\Ubuntu. - Открываем проект с этого диска в любимой IDE.
Интересно. На маке у меня не возникает проблем с линкованием папок внутрь контейнера, но вот оверхед из-за виртуализации достигает 50-60% по CPU. Т.е. 100% загрузки ядра в докере превращаются в 160% в mac os. Ну и потребление памяти, конечно.
Еще из косяков докера — очень долгая работа операции COPY при сборке контейнера. Но видел похожее issue на гитхабе, может быть пофиксят.
Еще из косяков докера — очень долгая работа операции COPY при сборке контейнера. Но видел похожее issue на гитхабе, может быть пофиксят.
У 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 не получается достичь нормального рабочего окружения.
А где вариант просто WAMP?
Как вы разрабатываете на PHP?Ubuntu это такой алиас для всех Линукс дистрибутивов?
Ubuntu + LAMP
Ubuntu + Docker
Когда в линуксовом терминале набираешь
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.
Я бы проголосовал, но таких вариантов нет. Я использую и WSL и Ubuntu, но не с LAMP. А с LEMP.
Для гуглящих: сетевые диски, монтирование файловых систем WSL2 в windows и наоборот — это медленно и решения этого вопроса для wsl2 пока нет.
Есть еще один способ без тормозов монтируемых ФС: поставить X server на windows (X410 и пр.), проект и phpstorm/webstorm/[YOUR IDE] развернуть полностью в WSL2, пробросить дисплей. Таким образом будет использоваться только ФС linux, тормоза исключены.
Есть еще один способ без тормозов монтируемых ФС: поставить X server на windows (X410 и пр.), проект и phpstorm/webstorm/[YOUR IDE] развернуть полностью в WSL2, пробросить дисплей. Таким образом будет использоваться только ФС linux, тормоза исключены.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Xdebug через Windows Subsystem For Linux 2 (WSL2)