Как стать автором
Обновить

Комментарии 27

Если развертывать локально на серваке, то деплойер так то особо и не нужен. Его идеология предполагает, что он используется для удаленного деплоя на различных сервера, включая staging и production серверы.

Хотя, я считаю, что вместо deployer вполне можно использовать capistrano, так как у него сообщество все равно больше развито, чем у deployer и капистрано есть плагины для разворачивания проектов как на руби, так и на пхп и так на ноде.

github.com/capistrano/laravel
Вот плагин для ларавел
Как бы сказать, «особо и не нужен». Одно дело вбить одну команду; другое дело — ворох этих команд, и в правильном порядке, и ничего не забыв.

Да и об идеологии такой я не слышал. Есть инструмент, есть его варианты использования. Какая разница, как ты его будешь использовать, если от него в любом случае есть польза, и в том, и в другом случае?

И чем конкретно капистрано лучше деплоера? Вот сижу я сейчас на деплоере, вроде счастливый и довольный. Зачем мне капистрано?
И чем конкретно капистрано лучше деплоера?

Тем что написан раньше, отлажен лучше, больше готовых плагинов. Основан на rake (ruby's make) и в-принципе делает всё, что надо.


Для капистраны не надо ставить на удалённой ноде ничего — только нужен ssh-доступ.

Написан всего на пол года раньше. Да и вообще — не очень это сильный довод, смотреть, кто когда был написан.


Насчёт готовых плагинов — возможно, хотя хотелось бы увидеть конкретные юз-кейсы с этими плагинами, показывающие превосходство капистрано над другими подобными системами деплоя.


Основан на rake — ну это вообще не довод и не повод. Каждый инструмент на чём-то там основан.


Для деплоера тоже, при желании, не надо ставить на удалённой ноде ничего — он точно также может работать по ssh, это просто я лично люблю сам заходить на сервер и делать деплой руками, мне так спокойнее.


По суди, разница по функциям между инструментами совсем небольшая. Деплоер ещё попроще будет: для его работы достаточно всего одного файла-конфига. Но, при желании, можно и "расширить" конфигурацию, разбив её несколько файлов.

Использовал и тот, и другой. Деплоер неплохо решает свои задачи на большинстве проектов, ничем не хуже капистрано. Но, на мой взгляд, если проект написан на PHP — лучше использовать деплоер. Чем меньше разных технологий — тем проще поддерживать проект.
И Деплоер точно также подходит и для любых других проектов. Причем, что удобно — можно его бинарник прямо в корень проекта положить и запускать без проблем на любой машине: он ведь ничего не требует для своей работы, даже пхп.

Лаконично и очень даже удобно, как по мне.

Что насчет капистрано — то это обязательная установка руби, бандлера, и так далее. А разницы как минимум никакой, как я вижу на данный момент.
А вот по поводу этого, сэр, хочу поспорить. Deployer написан на PHP и успакован в исполняемый Phar. А чтобы запустить Phar обязательно нужен PHP. Даже на официальном сайте написано:

«Deployer is a deployment tool written in PHP»
Я полагал, что phar архив становится исполняемым приложением :) Да, я ошибся. PHP для работы Deployer'а нужен.
Разве phar архивы не требуют php?
Как долго проходил коммент модерацию) Уже успели даже ответить
Когда последний раз пользовался, то столкнулся с тем, что например для dev'а нельзя выбрать другую ветку, или не внимательно читал доки, или нет такой возможности.
Есть параметр --tag=branch|tag

И тогда будет брать из нужно ветки. По умолчанию master.

Но опять же, значение по умолчанию можно задать в конфиге
Рекомендую еще попробовать Rocketeer
Лично, мне не нравится в rocketeer, то, что он тянет вендоры laravel, для laravel проекта — никаких проблем.
Но, например, я работаю с symfony и мне не очень нравится, что тянуться ненужные зависимости.

deployer в этом плане мне понрвавился больше. хоть мы и пользовались capifony до этого.
+ в том, что не нужно ставить руби, чтобы деплоить.
Ставьте rocketeer глобально и тогда в vendor проекта ничего не попадет.
Да, это гораздо лаконичнее того, что я когда-то писал xml-ем под phing :) Правда под ним был еще dbdeploy, позволявший управлять миграциями в БД.
Надо попробовать.
В более менее крупном проекте билдить проект на боевых серверах – не очень хорошая затея. Допустим, у нас 10 серверов. Во-первых, билдиться будет 10 раз на каждом из серверов. Во-вторых при билде проекта выполняются ресурсоемкие операции. Например, разогрев кеша крупного symfony-проекта нормально так догружает сервер. Т.е. у нас все сервера, которые под боевой нагрузкой, одновременно начинают параллельно нагружаются деплой-процессом, а это может привести к печальному результату, например к просадке времени отдачи страниц у пользователей.

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

Здравствуйте) Очень интересно. А каким образом вы еще и кеш разогретый умудряетесь положить прямо в билд?

Я про кеш Symfony, тот набор сгенерированных php-файлов, лежащих в папке app/cache/.

Я думал про opcache и apc :) Спасибо, теперь понятно.

Давать пользователю выполнять /usr/bin/service это очень плохая идея.
task('reload:php-fpm', function() {
run('sudo /usr/sbin/service php7.0-fpm restart');
});

Потому что помимо upstart/systemd сервисов, /usr/bin/service может стартовать и обычные SysV инит скрипты:
# Otherwise, use the traditional sysvinit
if [ -x "${SERVICEDIR}/${SERVICE}" ]; then
exec env -i LANG="$LANG" PATH="$PATH" TERM="$TERM" "$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
else
echo "${SERVICE}: unrecognized service" >&2
exit 1
fi

и единственная проверка для таких файлов — это проверка на существование!

Как следствие можно легко и непринужденно можно поднять права до рута, имея ограниченный доступ к серверу:
$ cd /tmp; echo «id» > awesome_service.sh; chmod +x awesome_service.sh
$ sudo /usr/bin/service ../../tmp/awesome_service.sh
uid=0(root) gid=0(root) группы=0(root)

Здравствуйте) Но ведь всё это делается только через судо, т.е. нужно пароль ввести для выполнения подобной операции? И как ещё такие вещи давать ему выполнять? Или как вы это делаете у себя, чтобы было реально безопасно?

То есть при деплое на десяток серверов вы будете каждый раз вводить пароль? А если серверов больше десяти и пароли разные? Я предполагал что у вас в /etc/sudoers разрешен запуск service без пароля (что как раз таки не безопасно).

Для себя я пока не нашел красивого решения, завел отдельного пользователя (от которого не запускаются приложения), разрешил ему в sudoers запускать service. Тогда конфиг deployer'а можно исправить на
runLocally("ssh specialuser@server service php5-fpm restart");


P.S. не разобрался как тег source использовать, в превью все хорошо, а в самом сообщении — нет. А нет, это видимо из-за предмодерации было.

У нас пока нет десятка серверов :) Поэтому это пока не стоит проблемой. Спасибо за разъяснения.

Для себя я пока не нашел красивого решения

Запускать php-fpm не от рута не вариант?
в /etc/sudoers можно разрешить запуск service только с конкретным аргументом (php7.0-fpm restart')
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории