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 система под малонагруженный/личный проект, то управлять ей какой-то автоматизированной утилитой это стрельба из пушек по воробьям — проще руками все настраивать. С другой стороны, когда у тебя куча серверов — БД, бекенд(ы), фронтенд(ы), каждый как-то связан с другими (сбор статистики, включение в балансировку и т.д.) — то придет время посмотреть на подобные инструменты.

Не в сети

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