Комментарии 18
К сожалению, редактировать статьи старше 30 суток нельзя, поэтому добавлю информацию в виде комментария.
Плюсы Sail
Быстрое разворачивание окружения в рамках проекта.
Минусы Sail
Жёсткая привязка к одному проекту;
Запуск команды
php artisan serveвнутри контейнера, что добавит 3-4 секунды ожидания загрузки страницы из-за конвертации файловой системы из GPT/MBR в EXT4, ибо внутри докера линукс со своей файловой системой.Жёсткая привязка запускаемой базы данных к проекту. При запуске соседнего проекта будет создана новая база данных. Из-за этого не удастся работать двум проектам с одной базой.
Несмотря на то, что Laravel Sail содержит в себе конфигурацию для запуска под PHP 7.4, 8.0 и 8.1, сам пакет laravel/sail устанавливается в качестве зависимости в проект и имеет ограничения по ним, а именно поддерживает Laravel версий 8.х и 9.х, что делает абсолютно бесполезным конфигурации для PHP 7.4 и 8.0, так как лучше такие проекты запускать на 8.1.
Так как он устанавливается через зависимости, то требует обязательного предустановленного PHP и Composer на компьютере;
Необходимость прописывать алиас при первоначальной настройки, иначе придётся вызывать слишком длинные команды запуска. Например,
vendor/bin/sail artisan migrate.
Заключение
Сама идея организации проекта Laravel Sail имеет огромный потенциал в разработке, но реализация с жёсткой привязкой зависимостям делают его крайне неудобным в использовании.
Исправить эту ситуацию можно взяв файлы проекта Laravel Sail с запуском вне данной системы. Таким образом на свет появился проект-помощник Docker Environment - просто запускаем и всё. Нужен лишь докер. Ну а проект стартуем через php artisan serve из консоли и никаких задержек конвертации файловой системы.
ЗЫ: также легко менять версии PHP на лету при помощи хелпера Windows PHP.
TL;DR: Что бы запустить Laravel под Windows, надо установить Linux для Windows :)
А вот у меня получилось, что Laravel на Docker без WSL2 работает гораздо быстрее, чем с ним.
Проект на файловой системе Windows.
Стоит отметить, что многие вещи в экосистеме laravel делаются в точном соответствии с их слоганом - framework for web artisans.
Это не плохо, но иногда приходится объяснять молодым разработчикам, что если что-то заложено во фреймворк, это ещё не значит что это оптимальное решение во всех ситуациях.
Некоторые вещи, бесспорно удобные, могут успешно применяться, когда вы делаете бложик или магазин рассчитанный на 100 заказов в год, но при этом они же могут ставить палки в колёса, когда ваш магазин должен обрабатывать тысячи заказов в день.
Подобный подход прослеживается и в Laravel sail. Это решение, которое позволяет организовать разработку одного веб-сервиса, при этом вам всё ещё нужен php определённой версии на хосте.
Есть аналогичный инструмент, который используя тот же принцип действия, решает более существенные проблемы. Например, позволяет не иметь на хосте php вообще. Это важно, когда вы работаете над разными проектами, и у них разные требования к версиям и модулям php. Генерирует git хуки чтобы они выполнялись в контейнере. Позволяет запускать несколько разрабатываемых веб-сервисов и определять зависимости между ними.
Тогда уж Laradock. Но, в целом, да. Что-то удобно, а что-то нет. В случае с Sail неудобно то что необходимо целый линух ставить чтобы он работал при том, что докер и без него спокойно контейнеры собирает. Но статья не про удобство, а про сам факт запуска. Удобство каждый для себя сам выбирает
Laradock, мне кажется, наследует идеи таких решений как OpenServer, однако "фича" ларадока относительно опенсервера одновременно и мешает ему быть логичным.
Ценность OpenServer, Xampp, Wamp, Mamp в том, что вам не надо знать как оно работает и не надо ничего настраивать. Вы просто устанавливаете одну программу, и в ней мышкой накликиваете какие компоненты вам нужны. В этом есть ценность, т.к. это сильно проще чем скачивать компоненты по отдельности и править их конфиги. Ценность есть ещё и в том, что эти решения позволяют менять версии ПО. Это было очень важно десять лет назад, когда установка каждого компонента системы была квестом - скачай архив или установщик, он тебе гвоздями к системе прибьётся, потом иди ищи где его конфиги и т.д.
С распространением докера эти проблемы, для тех кто освоил докер и хоть немного научился работать с используемыми компонентами, отошли на второй план.
Сейчас очень просто получить работающий nginx, fpm, mysql, etc просто набрав команду в терминале. Добавляем сюда docker-compose и ещё упрощаем себе жизнь - количество вводимых команд стремится к минимуму, а запустив новый проект можно просто скопировав в него пару файлов.
Ларадок по сути является таким хитрым большим docker-compose файлом. Ну да, там есть пара скриптов чтобы настроить какие компоненты использовать, ведь самих компонентов там едва ли не сотня. Но ничего нового по сравнению с самописным файлом ларадок не даёт. Только экономит время на старт, но раз-другой написав свой конфиг, вы в дальнейшем можете его копировать едва ли не быстрее чем стартует ларадок.
Sail в этом отношении делает шаг вперёд. Он не просто является docker-compose файлом. Он даёт разработчику новую возможность - позволяет выполнить команду в контейнере в контексте текущего проекта. Это почти как docker exec, только короче, и не требует указывать имя контейнера. Это важно, ведь разработчику часто приходится вызывать composer и artisan, и выполняться они строго в том же окружении, в котором работает разрабатываемое приложение.
У ларадока да, нужно знать как работает докер чтобы его использовать.
Что касается его конфигурирования, всё настраивается через файл .env. В сами образы не надо лазить.
Также многие считают ларадок тяжёлым лишь потому, что не умеют работать с докер-контейнерами - разработчики просто выполняют команду docker-compose up -d и жалуются что ларадок много жрёт, и совсем не догадываются что нужно явно передавать какие контейнеры собирать, например, docker-compose up -d mysql php-fpm mailhog redis.
Что касается выполнения кода в контейнере то Sail работает как все контейнеры за тем исключением, что Тейлор трепетно относится к документации и, в том числе, поэтому его продукты притягивают такое внимание. Ну и его любовь к хелперам и упрощению также играет немаловажную роль.
laradock хорош, но очень огромен и громоздкий, они попытались все и вся запихать в один контейнер - это плохо, а в sail контейнер весьма чистый и вполне можно за малыми изменениями использовать даже для образа в кубер, а вот ларадок - точно нет (хотя видел приколы, где его используют за базовый образ)
Только у меня при запуске "всего этого" сжирается минимум 4Gb RAM?
К сожалению, редактировать статьи старше 30 суток нельзя, поэтому добавлю информацию в виде комментария.
Плюсы Sail
Быстрое разворачивание окружения в рамках проекта.
Минусы Sail
Жёсткая привязка к одному проекту;
Запуск команды
php artisan serveвнутри контейнера, что добавит 3-4 секунды ожидания загрузки страницы из-за конвертации файловой системы из GPT/MBR в EXT4, ибо внутри докера линукс со своей файловой системой.Жёсткая привязка запускаемой базы данных к проекту. При запуске соседнего проекта будет создана новая база данных. Из-за этого не удастся работать двум проектам с одной базой.
Несмотря на то, что Laravel Sail содержит в себе конфигурацию для запуска под PHP 7.4, 8.0 и 8.1, сам пакет laravel/sail устанавливается в качестве зависимости в проект и имеет ограничения по ним, а именно поддерживает Laravel версий 8.х и 9.х, что делает абсолютно бесполезным конфигурации для PHP 7.4 и 8.0, так как лучше такие проекты запускать на 8.1.
Так как он устанавливается через зависимости, то требует обязательного предустановленного PHP и Composer на компьютере;
Необходимость прописывать алиас при первоначальной настройки, иначе придётся вызывать слишком длинные команды запуска. Например,
vendor/bin/sail artisan migrate.
Заключение
Сама идея организации проекта Laravel Sail имеет огромный потенциал в разработке, но реализация с жёсткой привязкой зависимостям делают его крайне неудобным в использовании.
Исправить эту ситуацию можно взяв файлы проекта Laravel Sail с запуском вне данной системы. Таким образом на свет появился проект-помощник Docker Environment - просто запускаем и всё. Нужен лишь докер. Ну а проект стартуем через php artisan serve из консоли и никаких задержек конвертации файловой системы.
ЗЫ: также легко менять версии PHP на лету при помощи хелпера Windows PHP.
если честно не совсем понял в чем жесткая зависимость? ты без проблем можешь подвязаться к БД которая у тебя работает в чистом Windows/Linux/MacOS, не использую ту что развернул в sail, также никто не мешает сделать одну общую сеть через докер между несколькими оркестрами, вариантов масса. конфигурации с 7.4 и 8.0 нужны не для новых проектов, а для внедрения в старые на основе 7.4 (я делал даже для 5.6) - это совсем не проблема. Также например при использовании octane ты сможешь сделать такое же окружение как и на прод сервере (с одной лишь разницей - без вотчера). Да и насчет что такое GPT, MBR, EXT3/4 и NTFS стоило бы тоже почитать и как оно работает с ОС
В том, что нельзя использовать подключение из одного проекта к другим без плясок. Да, технически это возможно, но нужно пару кувырков сделать для реализации. Лишние телодвижения ни к чему.
Что касается конфигов, в том и нюанс, что установить Sail можно хоть на PHP 7.3 и выше, конфиги у него для 7.4 и выше, а сам он работает с Laravel 8.0, который хоть и работает на PHP 7.3+, но лучше сразу запускать на 8.2. Хотя, в случае старых проектов, возможно, и будет полезным.
Да и насчет что такое GPT, MBR, EXT3/4 и NTFS стоило бы тоже почитать и как оно работает с ОС
Я знаю как работает файловая система
насчет файловой ты путаешь системы адресации (разметки) и файловые системы.
насчет конфигов - тебе абсолютно никто не машет поправить и поставить хоть от какой версии (руки на что даны). Это всего лишь красивая обертка над docker-compose
Также никаких проблем с сетью там нет пропиши extra_hosts в docker-compose и все + сеть также назови - никаких танцев - один профит.
Всем мира!
Публикации
Laravel Sail под Windows