#php #laravel #docker #laravel-8 #laravel-sail
Вопрос:
Я создал новый проект Laravel 8, который поставляется с Laravel Sail, предварительно настроенной средой докеров. Это хорошо работает, пока мне не понадобится использовать расширение PHP.
В документации Laravel Sail, похоже, ничего не говорится о расширениях PHP, что является серьезной проблемой. Любой нетривиальный PHP-сайт должен использовать несколько расширений PHP. Без возможности добавлять расширения PHP Laravel Sail (или любая другая среда PHP) более или менее бесполезна.
Там Dockerfile есть и вход, и php.ini вход vendor/laravel/sail/runtimes/8.0/ . Я мог бы скопировать эти файлы из vendor и в код моего собственного проекта и взломать docker-compose.yml , чтобы указать на мои версии этих файлов. Однако, если я это сделаю, я потеряю любые будущие исправления или улучшения, которые люди Laravel Sail внесут в эти файлы.
Я знаю о sail artisan sail:publish команде, которую они упоминают в конце документации по парусу Ларавеля (https://laravel.com/docs/8.x/sail#sail-customization). Похоже, он просто делает то, о чем я упоминал выше: копирует сторонний код в мой проект, и теперь внезапно этот веб-сайт конечного пользователя отвечает за поддержание своей собственной копии Laravel Sail.
Наверняка есть идиоматический способ добавить расширения PHP в Laravel Sail без повторной реализации развилки Laravel Sail в коде моего сайта?
Комментарии:
1. Каково ожидаемое поведение после перезапуска контейнера? Предполагается ли, что расширение «переживет» перезапуск контейнера? И как именно вы хотели бы получить возможность установить расширение PHP в свой контейнер docker и сохранить его без локальной перестройки контейнера? Я задал этот вопрос, потому что считаю, что единственный способ-позаботиться о вашем файле Docker и делать с ним то, что вам нужно, поэтому создайте образ самостоятельно, и если он вам нужен, вы должны загрузить его в реестр docker.
2. Расширение переживает перезапуск контейнера. Так и должно быть. Если это не так, то контейнер бесполезен для разработки сайта, использующего эти расширения. Неразумно ожидать, что разработчик будет подключаться к машине и вручную устанавливать расширения каждый раз, когда они перезапускают контейнер, потому что весь смысл Docker заключается в том, чтобы избежать такого рода ручной настройки машины. С моим текущим, хакерским решением, описанным выше, это работает.
3. В настоящее время я сам создаю этот образ. Я понимаю, что использование образа Docker требует, чтобы вы сначала его создали. Это не то, чего я пытаюсь избежать. Чего я пытаюсь избежать, так это включения файла Dockerfile Laravel Sail в мой проект и, следовательно, возложение ответственности на разработчика моего веб-сайта для конечных пользователей за поддержание этой ветви Laravel Sail. Это сторонний код, поэтому он должен быть в
vendorкаталоге.sail artisan sail:publishРешение, которое я использую, работает, но оно загрязняет код этого веб-сайта сторонним кодом, который должен быть вvendorнем .4. Да, я понимаю твою точку зрения. У меня есть файлы Dockerfiles в отдельном репозитории, перестраивайте их при добавлении расширения и отправляйте в реестр docker (либо Docker hub, частное репозиторий gitlab или что вам нравится).
sail artisan sail:publishесть ли там просто для того, чтобы дать вам файлы, делайте с ними все, что хотите. Если кто-то решит оставить их с приложением, это их выбор, но лучше разделить их, как вы указали.5. Я написал: «Предполагается ли, что расширение «переживет» перезапуск контейнера?» Но это был неправильный вопрос, лучше было бы: «Должно ли расширение «пережить» удаление контейнера?» потому что это то, что решает либо при использовании образа docker для развертывания, либо при использовании образа для локальной разработки. Это должно иметь значение даже для одинокого разработчика, потому что смена рабочей станции приведет к потере такого расширения, которое не было установлено во время сборки образа.