Laravel по-русски

Русское сообщество разработки на PHP-фреймворке Laravel.

Ты не вошёл. Вход тут.

#1 30.08.2017 09:04:45

Развертывание "боевого"

Доброго времени суток!

Требуется развернуть ресурс в сети, с учетом дальнейшей доработки/поддержки, контроля версий и т. п.
Кто-нибудь может подсказать примерную структуру? Ну там, тестовый-боевой-локальный..?
Не хотелось бы наступать на грабли, а чтобы сразу более-менее оптимально, по-опыту.

С уважением.

Не в сети

#2 31.08.2017 18:28:55

Re: Развертывание "боевого"

Ну там, тестовый-боевой-локальный..?

Где-то этот вопрос уже точно обсуждали. Зависит от ресурса - если он крупный, над ним работают несколько человек - тогда тестовый сервер нужен. В остальных случаях проще иметь локальный сервер и "боевой" сервер, и накатывать изменения прямо с локального. Метод "накатывания" по усмотрению - от простой загрузки файлов до более изощренных.

контроля версий

Контроль версий нужен всегда, благо усилий это почти не требует, если использовать git (даже сервер для хранилищ не нужен).

Не в сети

#3 01.09.2017 09:02:38

Re: Развертывание "боевого"

Большое спасибо!
Пока что работаю один, но в одиночку я это хозяйство вряд-ли потяну, помощника думаю искать в ближайшее время, поэтому, наверное, тестовый сервер нужен наверное, сразу :-).
Мне виделось что-то вроде автодеплоя master-а на "бой"... Читал, что есть такие схемы.
Другой вопрос, в этом случае, придется каждый раз апдейтить composer...
Когда Вы говорили про накат с локального на боевой, Вы подразумевали накат vendor, или апдейт composer-а лучше выполнять на боевом?
Или версия целиком собирается на локальном и накатывается?
Миграции-то, я так понимаю, все равно запускать "на бою" придется?
Извините за такой "поток сознания", реально, опыта развертывания чего-то подобного не имею, в голове каша пока.
Хотелось бы, конечно, отладить более-менее оптимальную схему...

Не в сети

#4 02.09.2017 16:45:06

Re: Развертывание "боевого"

помощника думаю искать в ближайшее время, поэтому, наверное, тестовый сервер нужен наверное, сразу :-).

С одной стороны, да. С другой стороны, если не хочется заморачиваться именно отдельным сервером - всегда можно организовать такой "тестовый" сервер у себя же локально. У вас же задача только увидеть версию, которую вы совместно накодили, до обновления в production. Вот и пусть у каждого будет еще один локальный поддомен с ней.

Отдельный настроенный сервер обычно используется, когда есть команда тестировщиков, чтобы не настраивать им каждому окружение - делается один общий сервер, закрывается HTTP-авторизацией и все на него ходят.

Когда Вы говорили про накат с локального на боевой, Вы подразумевали накат vendor, или апдейт composer-а лучше выполнять на боевом?

Я сейчас, наверное, скажу крамольную вещь, но да: лично я не использую git pull, composer update или другие способы накатывания изменений, так как они иногда вызывают конфликты, а последняя вещь - это получить неразрешимые зависимости на живом сервере (или в случае с git - конфликт версий, когда кто-то когда-то поменял файл на самом сервере и git не может слить изменения), когда не можешь ни откатиться назад, ни обновиться, и все встает.

Мой метод - банальная загрузка архива с тестового сервера и распаковка с заменой. Архив содержит абсолютно весь код, включая vendor и статику (стили, картинки и т.д.). Собственно, загрузку архива легко автоматизировать - если ты на Linux, то через tar cz /local/www | ssh my@host | tar xz -C /home/www. Естественно, некоторые файлы (конфиги) нужно единожды загрузить на сервер и в архив не включать, дабы этот сервер продолжал работать с production-базой, а не с тестовой.

Вот на тестовом уже можно использовать какие-то изощренные схемы обновлений. Иногда я делаю отдельный git, где держу код, и по хуку в нем обновляются миграции и т.д.

Тестовый - это, фактически, production-сервер, который не жалко поломать. Поэтому его код точно такой же "производственный", за вычетом конфигов.

Миграции-то, я так понимаю, все равно запускать "на бою" придется?

Миграции накатываются через команду после распаковки, с этим обычно проблем нет, плюс всегда можно восстановить БД из бекапа.

Извините за такой "поток сознания", реально, опыта развертывания чего-то подобного не имею, в голове каша пока.

Приятно видеть стремление к системному подходу smile

Не в сети

#5 04.09.2017 08:06:56

Re: Развертывание "боевого"

Большое спасибо!
Информации для размышления достаточно. Как выработаю решение, опубликую.

Не в сети

#6 12.09.2017 14:14:31

Re: Развертывание "боевого"

tar cz /local/www | ssh my@host | tar xz -C /home/www

зачем так сложно? smile есть же scp, есть rsync…

Не в сети

#7 12.09.2017 18:18:09

Re: Развертывание "боевого"

  1. зачем так сложно? ☺ есть же scp, есть rsync…

rsync нужно устанавливать и он сложнее (например, чтобы зашифровать и/или зажать соединение, нужно использовать --rsh="ssh -C"). scp довольно «тупая» утилита, ей хорошо копировать отдельные файлы, но папки — не всегда (нельзя исключить файлы, нельзя передать дополнительные атрибуты ФС и т.д.) — то, что можно сделать с tar.

А ssh (как способ передать поток данных с/на другой хост) вообще полезный универсальный инструмент, о нем полезно знать и использовать.

Не в сети

#8 18.09.2017 13:46:47

Re: Развертывание "боевого"

Смотрел в сторону таких штуковин, как Deployer и Capistrano.

Не в сети

#9 19.09.2017 22:47:56

Re: Развертывание "боевого"

Любые инструменты для автоматизации будут забирать у тебя степень свободы и контроля. Чтобы от них был толк, проекту нужна критическая масса. Если у тебя 1 система под малонагруженный/личный проект, то управлять ей какой-то автоматизированной утилитой это стрельба из пушек по воробьям — проще руками все настраивать. С другой стороны, когда у тебя куча серверов — БД, бекенд(ы), фронтенд(ы), каждый как-то связан с другими (сбор статистики, включение в балансировку и т.д.) — то придет время посмотреть на подобные инструменты.

Не в сети

#10 15.10.2017 13:45:53

Re: Развертывание "боевого"

Любые инструменты для автоматизации будут забирать у тебя степень свободы и контроля. Чтобы от них был толк, проекту нужна критическая масса. ...это стрельба из пушек по воробьям...

Ну не знаю, тут я с вами не соглашусь. Перешел на deployer и очень доволен. Да, отнял время на чтение документации и тесты во время настройки. Но это окупилось с лихвой. Если нужно исправление или запуск миграции или выполнить еще что-либо, создать кастомную команду и тд. Разработка локально, есть тестовая среда, есть продакшн. Выкатка кода на них всего в одну команду. Возможность откатиться на предыдущую версию тоже одной командой. К слову во время деплоя, если была ошибка подмена в проде не произойдет.

Другой вопрос, если разработчик все еще новичок в ларе, стоит повременить.

Не в сети

#11 15.10.2017 16:35:29

Re: Развертывание "боевого"

Другой вопрос, если разработчик все еще новичок в ларе, стоит повременить.

На мой взгляд, у фреймворков и, в целом, у любых инструментов, которые призваны облегчать разработку (не исключая IDE, кстати), есть кривая использования: в первую очередь они полезны начинающим, а с ростом опыта разработчик склонен от них отказываться.

Начинающего они привлекают тем, что реальная сложность скрыта за парой-тройкой простых команд (характерный пример - iptables vs ufw), но цена за это - гибкость (нельзя сделать надстройку более гибкой, чем базовый инструмент, иначе это будет тот же базовый инструмент, и тогда зачем использовать надстройку?) и вера, что то что сделано под капотом сделано хорошо.

С ростом опыта уменьшается потребность в простых командах (т.к. уже и так досконально знаешь, что там происходит внутри, и можешь это легко сделать сам) и одновременно увеличивается желание контролировать все части проекта, так как чем больше сложности скрыто, тем больше риск наткнуться на неожиданные проблемы. У меня последнее происходит с завидной регулярностью - вроде берешь крупную библиотеку (речь не только о PHP и JS), бывает что даже платную, начинаешь тестировать - вылазят баги и думаешь "лучше б я эту неделю потратил на написание своего компонента, чем на отлов багов, которые никак нельзя исправить, а потом еще неделю на переписывание".

Короче, уровень паранойи в отношении сторонних инструментов растёт вместе с опытом, так как ладно там использовать IDE или "блокнот" - это дело вкуса, но когда речь идёт о боевом сервере - если твой инструмент по ошибке закинет на него тестовый доступ (как уже было с каким-то сайтом, где боевой переключили на тестовую БД), или если в общедоступной папке внезапно окажутся закрытые данные, для которых почему-то™ не сработал .gitignore - то пинать будут не автора этого инструмента, а тебя.

Не в сети

#12 15.10.2017 17:02:01

Re: Развертывание "боевого"

В большинстве случаев вы правы, однако с таким подходом нужно писать все с нуля. И как показывает мой опыт, в вашем собственном велосипеде ошибки будут, хотя бы потому что вы используете язык написанный не вами, среду созданную не вами и еще куча факторов где другие могут накосячить. Так как по моему уже опыту, программирование - это написание кода, с минимальными затратами времени по-возможности и попыткой избежать (пофиксить) багов, оставленных не мною. И потом, как вы сказали, с ростом опыта возникает способность мыслить и создать что-то свое. До тех пор пока работает все относительно хорошо, я бы предпочел потратить время на отдых и в дали от работы.

Тема бесконечна для холивара, все учатся на ошибках. Моя самая дорогая ошибка мне обошлась в 3 млн. руб, поэтому я параноидально отношусь только к критически важным частям процесса. В остальном, если могу время сэкономить - то почему нет?

Не в сети

Подвал раздела