Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Всем привет!
Подозреваю, что у каждого третьего тут написал свой специфический деплой лары на продакшен. Но возможно кто-то сделал универсальное решение, которое можно адаптировать и использовать у себя.
Ищу такое решение для разворачивания сервера и последующего деплоя ларавел на Ubuntu 16.04. Все дополнительные необходимые вещи прикручу сам 
(ещё большим счастьем для меня будет то, если не нужно будет ставить дополнительных пакетов, чтобы оно было независимое и работало без установки чего-то через композер/в систему)
Про envoy знаю, но даже с ним всё сведется к тому, что нужно будет писать полностью деплой с нуля. И меня больше всего страшит работа с композером (признаюсь: я юзаю его первый раз сейчас с ларой, локально на макоси проблем не возникло, всё поставил по инструкции Valet).
Я не понимаю могу ли я просто взять директорию с ларой из локального окружения и залить её по ftp (есессно, поменяв .env). Не понимаю есть ли в композере такие вещи как "develop" и "production" окружение?
Когда ранее работал с Django (python) - было множество прекрасных готовых решений под Ansible, Chef, Puppet для неё. Надеюсь, что и в сообществе Laravel что-то такое присутствует
Изменено Lord_Alfred (09.04.2017 02:07:56)
Не в сети
Мастер 
git pull – наше всё
ну на самом деле конечно там ещё некоторые команды надо выполнить, всё-таки есть в ларавеле и продакшен-специфичные оптимизации, и в maintenance mode есть смысл приложение переводить при обновлении. плюс если ассеты собираются на сервере – запускать gulp или mix. плюс если используются очереди – рестартовать обработчики
у меня в одном из проектов скрипт-обновлятор выглядит так:
#!/bin/bash
php artisan down
git pull
composer install
composer dump-autoload -o
php artisan config:cache
php artisan route:cache
php artisan laroute:generate
gulp --production
php artisan queue:restart
php artisan upgulp – потому что проект на L5.2, laroute – пакет, который позволяет генерить маршруты в js-коде, аналогично route() на пхп-стороне. composer install включает в себя php artisan optimize, и в config/compile.php у меня добавлены некоторые из своих часто используемых классов
кроме «полного» обновлятора, есть ещё мини-обновлятор, который не пересобирает ассеты и работает намного быстрее
Не в сети
git pull – наше всё
ну на самом деле конечно там ещё некоторые команды надо выполнить, всё-таки есть в ларавеле и продакшен-специфичные оптимизации, и в maintenance mode есть смысл приложение переводить при обновлении. плюс если ассеты собираются на сервере – запускать gulp или mix. плюс если используются очереди – рестартовать обработчики
у меня в одном из проектов скрипт-обновлятор выглядит так:
#!/bin/bash php artisan down git pull composer install composer dump-autoload -o php artisan config:cache php artisan route:cache php artisan laroute:generate gulp --production php artisan queue:restart php artisan upgulp – потому что проект на L5.2, laroute – пакет, который позволяет генерить маршруты в js-коде, аналогично route() на пхп-стороне. composer install включает в себя php artisan optimize, и в config/compile.php у меня добавлены некоторые из своих часто используемых классов
кроме «полного» обновлятора, есть ещё мини-обновлятор, который не пересобирает ассеты и работает намного быстрее
Большое спасибо за ценный ответ, подчерпнул для себя кое что новое
Но остались некоторые вопросы:
1. Есть ли готовые решения для разворачивания всего необходимого на сервере (Ubuntu 16.04)? В питонячих пакетах это много где называлось bootstrap или provision.
2. Git - воистину самое полезное и необходимое в разработке, но если думать о том, что мою разработку будут запускать win-юзеры, которые привыкли к установке CMS аля "скопируйте все файлы по ftp": как мне лучше построить систему, чтобы потом у них не возникло проблем?
Перефомулирую вопрос для лучшего понимания: могу ли я копировать локальную папку vendor на сервер без запуска "composer install"? И нужно ли предварительно как-то сказать локальному композеру, что это продакшен окружение?
Не в сети
Мастер но если думать о том, что мою разработку будут запускать win-юзеры, которые привыкли к установке CMS аля "скопируйте все файлы по ftp": как мне лучше построить систему, чтобы потом у них не возникло проблем?
ох, сожрут такие пользователи тебе весь мозг. но если хочешь – видимо нужно что-то вроде https://github.com/RachidLaasri/LaravelInstaller взять за основу и сделать свой собственный веб-установщик. как потом решать задачу обновления на новые версии через веб-интерфейс, тут я не подскажу, скорее всего надо будет писать всё своё
Перефомулирую вопрос для лучшего понимания: могу ли я копировать локальную папку vendor на сервер без запуска "composer install"? И нужно ли предварительно как-то сказать локальному композеру, что это продакшен окружение?
можно, более того, если вместе с composer.json распространять composer.lock – он будет при composer install устанавливать только версии идентичные тем что в окружении разработки, а не обновлять их на последние доступные. это очень удобно, поскольку позволяет обновлять зависимости локально и хорошо тестировать перед деплоем
если ты включаешь vendor в пакет, то на целевой системе композер вообще не нужен. просто перед заворачиванием пакета достаточно сгенерить оптимизированный автолоадер (composer dump-autoload -o) и всё. то же самое с ассетами – можно миксом сразу собрать продакшен-сборку стилей и скриптов, сразу версионировать их (mix.version()) и вместе с манифестом положить в распространяемый пакет – на целевой системе уже не нужны будут node.js, npm, webpack и пр. то же самое с кэшированием маршрутов и конфига. фактически ты исполняешь что-то аналогичное моему скрипту-деплоеру в своей системе и получаешь готовую продакшен-сборку, которую остаётся упаковать и выложить
но имей в виду – если твои пользователи умеют только залить что-то по фтп, скорее всего твой код будет крутиться на обычном дешманском шареде, а это значит – кэш либо файловый либо база, очередей – нет и не будет, сессии либо на файлах либо в базе и так далее
но наверное самая большая засада будет с тем что 99 из 100 будут лить твой код в корень веб-сервера и ругаться что ничего не работает. о том что корнем должен быть public – они сначала не прочитают, а потом если ты будешь это объяснять – не поймут что ты им объясняешь. я смотрю с CMS-ками на ларавеле в этом плане ситуация такая, что они поголовно «перемещают» паблик в корень проекта, что само по себе создаёт больше проблем чем решает – в ларавеле не предусмотрена защита кода и файлов от любопытного юзера при такой установке, а .htaccess работает не у всех хостеров и не всегда
в итоге, например, можно попалить все зависимости конкретной установки – http://www.atlantis-cms.com/composer.json или раскрыть локальные пути – http://www.atlantis-cms.com/server.php – в общем непонятно как лучше – сделать хорошо или лечить всех чайников
Не в сети
@constb, огромное вселенское СПАСИБО за такое подробное описание, всё наконец-то сошлось в голове
нужно что-то вроде https://github.com/RachidLaasri/LaravelInstaller взять за основу и сделать свой собственный веб-установщик. как потом решать задачу обновления на новые версии через веб-интерфейс, тут я не подскажу, скорее всего надо будет писать всё своё
Визуально выглядит очень круто, я как раз что-то такое хотел себе сделать, но более в человечном виде (не задавать .env плейн-текстом, а разбить это на шаги). Обновления на новые версии пока не предусматриваю, т.к. не ясно "выстрелит" ли вообще данная идея. Делаю хорошо и качественно пока для себя, но с возможностью расширения и для использования другими, поэтому по опыту стараюсь сразу же закрывать все такие огрехи, чтобы потом не переписывать всё с нуля.
но имей в виду – если твои пользователи умеют только залить что-то по фтп, скорее всего твой код будет крутиться на обычном дешманском шареде, а это значит – кэш либо файловый либо база, очередей – нет и не будет, сессии либо на файлах либо в базе и так далее
Тут проблем не возникнет, изначально всё будет сводиться к установке VestaCP + настройке чистого сервера под требуемое окружение (установка memcached (скорее всего), supervisord, monit и т.д.), поэтому априори они не смогут на шареде всё это добро развернуть
но наверное самая большая засада будет с тем что 99 из 100 будут лить твой код в корень веб-сервера и ругаться что ничего не работает. о том что корнем должен быть public – они сначала не прочитают, а потом если ты будешь это объяснять – не поймут что ты им объясняешь.
Да, думал над этим, пока первичным решением вижу разместить index.html в корень пакета (не в public), где написать о том, что они не поменяли DOCUMENT_ROOT. Потом, возможно, переделаю инсталлер, чтобы он менял эту настройку и ребутил веб-сервер, но это может оказаться сомнительной затеей, если они будут складывать конфиги апача/nginx куда-то в другие места
Не в сети
Вот стандартный скрипт с Laravel Forge, может пригодится:
Писарьcd /home/forge/website.com
git fetch --all
git reset --hard origin/master
git pull
composer install --no-interaction --prefer-dist
composer dumpauto
php artisan migrate --forceНе в сети
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)