Как правильно деплоить с помощью deployer?

Question

[Vladislav Altyncev]

Можете по структуре подсказать. Или помочь понять как правильно делать)

Я так понимаю из гита deployer всё тянет в `/releases/1/`, вернее всё то, чем можно управлять с помощью deployer.
В `/shared/` можно сложить всё, что не надо "релизить", в принципе у меня такого нет.

Дак вот, чтобы не создавать симлинки, я так понимаю, придётся, например, с помощью `rsync`, при успешном разворачивании копировать из `/releases/1/` в `/` корень сайта файлы?
Или есть проще вариант?

Comments

[zorca]

А кто мешает не использовать готовые рецепты, а самому все таски написать?

[Vladislav Altyncev]

zorca, никто не мешает. Чуть побольше информации/ документации/ примеров, а ещё круче, если на русском было бы)

[zorca]

Vladislav Altyncev, ну а почему не на корейском или иврите? Учите великий и могучий язык сообщества программистов. Примеров достаточно: https://deployer.org/recipes

[Vladislav Altyncev]

zorca, и на том спасибо

[zorca]

Vladislav Altyncev, ну вы же деплоите PHP-проект, а сам Deployer на нем написан, что тут сложного? Я понимаю, если бы еще код был скрыт, но это оупенсорс: https://github.com/deployphp/deployer/blob/master/... - вот файлик с таском релизов, читайте, вникайте. Я так вообще готовые таски не использую. Правда желательно знать команды Линуха конечно.

[Vladislav Altyncev]

zorca, если я деплою php проект, это же не значит, что я пишу этот проект, это даже не значит, что я знаю php)
Я пытаюсь суть понять. Сложно сразу во всё вникнуть.
И интересны мнения, как лучше поступать.
Т.е. если я добавляю шаблон сайта в deployer, то лучше симлинки делать или можно просто копировать с заменой файлы, ну или есть другие способы.
Если есть только фтп доступ до сервера, то тогда видимо только копирование, если оно вообще работает без ssh.

[zorca]

Vladislav Altyncev, Deployer вообще изначально предполагает, что у вас есть рут-доступ к серверу по ssh (в идеале), можно так же все делать под пользователем веб-сервера (www-data к примеру). Если даже вы работаете с виртуальным хостингом, то многие хсотеры предоставляют SFTP-доступ к серверу, чем тоже можно воспользоваться. Теоретически можно и просто FTP использовать, но у меня такого опыта не было. Вы можете пользоваться любыми локальными командами, которые будут работать у вас в консоли в обычном режиме. Я к примеру в первом проекте собирал все файлы сайт 7zip и отправлял их на сервер, после чего там распаковывал: https://gist.github.com/zorca/76f5dd09b73cdf6842ac...
Проблема в том, что rsync под Виндой требует для настройки недюжинных знаний и четко работать все это будет только под Linux или Mac. С деплоем с гита конечно же проблем не должно быть. Вот только остаются база и медиа. Как вариант, можно дамп базы хранить в гите, в приватной репе.

[Vladislav Altyncev]

zorca, База и медиа, мне не нужны.
У меня процесс такой, есть репозиторий, где хранится шаблон битрикса, есть dev сервер, где стоит гит и dev версия сайта, есть продакшн сервер, собственно там конечный сайт. При пуше в dev ветку, этот шаблон должен разворачиваться на этом же dev сервере, при пуше в мастер, естественно на конечный сайт.

Я так понимаю, можно на `post-receive` хук повесить выполнение deployer. При пуше в dev один таск, при пуше в master другой.
ssh в принципе есть, про фтп, это я рассматриваю все варианты, наихудший так сказать :-)

Какой бы таск не был, структура же всё равно всегда одна, последний билд лежит в
/releases/1/
Хотя, судя по вашему таску

>set('deploy_path', '/var/www/' . $config['site_name'] . '.' . $config['server_name']);

я не прав?

Опять остальные релизы тогда он где хранит?

У меня основной вопрос, как мне удобнее из
/releases/1/
переносить файлы в битриксовый
/loca/template/

Как мне кажется, проще всего rsync выполнять по завершению деплоя.

[zorca]

Vladislav Altyncev, в моем сетапе все локальыне файлы сразу перемещались в веб-директорию, для демонстрации клиенту. Вашем же случае самый простой вариант - убрать или переименовать папку /loca/template/ и заменить ее на симлинк на свежий релиз. Зачем же каждый раз тягать файлы туда-сюда? То есть вы просто копируете таск релизов к себе в основной сетап, переименовываете его и подключаете вместо обычно. Затем меняете симлинк в таске на нужный вам и собственно бинго.

[zorca]

Vladislav Altyncev, вот в подобных местах: https://github.com/deployphp/deployer/blob/master/... нужно подменить путь на нужный вам, то есть файл симлинка должен зваться template и быть выложен в директорию, где папка template лежит. Сама папка должна быть переименована. иначе вам не удастся там создать симлинк.

[Vladislav Altyncev]

Зачем же каждый раз тягать файлы туда-сюда?

ну rsync же умный, он вроде быстро все делает.
/local/template/ одна из папок... есть ещё несколько файлов в корне.

В общем, надо попробовать, прежде чем дальше рассуждать.
Спасибо.
Попробую что нибудь сделать. А там уже может новые вопросы возникнут.

Answer 1

[Вадим Степанов]

Deployer создает при каждом запуске новую папку с увеличивающимся номером в releases. Но при этом последний успешный релиз всегда доступен по символьной ссылке в current
Т.е. получается что-то типа
releases/1
releases/2
releases/3
current ---> releases/3
shared

Чем вас не устраивают символьные ссылки? Они достаточно удобны в данном случае.

Разве что надо после деплоя надо перезагружать php-fpm, т.к. иначе активные рабочие процессы будут пользоваться старым значением символьной ссылки (в смысле будут обращаться к предыдущему релизу).

Настройте ваш web-сервер, чтобы загружал проект из папки current.

Comments

[Vladislav Altyncev]

А на отдельные файлы тоже ведь можно символьные ссылки указывать?
Проблем в общем то нет, когда есть возможность настроить веб сервер, а вот когда надо отдать изменения на левый сервер, куда особо доступа нет, то тут я только вижу, перенос файлов через rsync или как нибудь так.
Выше в треде, мы вроде к этому и пришли.