Comments 27
Хотя, я считаю, что вместо deployer вполне можно использовать capistrano, так как у него сообщество все равно больше развито, чем у deployer и капистрано есть плагины для разворачивания проектов как на руби, так и на пхп и так на ноде.
github.com/capistrano/laravel
Вот плагин для ларавел
Да и об идеологии такой я не слышал. Есть инструмент, есть его варианты использования. Какая разница, как ты его будешь использовать, если от него в любом случае есть польза, и в том, и в другом случае?
И чем конкретно капистрано лучше деплоера? Вот сижу я сейчас на деплоере, вроде счастливый и довольный. Зачем мне капистрано?
И чем конкретно капистрано лучше деплоера?
Тем что написан раньше, отлажен лучше, больше готовых плагинов. Основан на rake (ruby's make) и в-принципе делает всё, что надо.
Для капистраны не надо ставить на удалённой ноде ничего — только нужен ssh-доступ.
Написан всего на пол года раньше. Да и вообще — не очень это сильный довод, смотреть, кто когда был написан.
Насчёт готовых плагинов — возможно, хотя хотелось бы увидеть конкретные юз-кейсы с этими плагинами, показывающие превосходство капистрано над другими подобными системами деплоя.
Основан на rake — ну это вообще не довод и не повод. Каждый инструмент на чём-то там основан.
Для деплоера тоже, при желании, не надо ставить на удалённой ноде ничего — он точно также может работать по ssh, это просто я лично люблю сам заходить на сервер и делать деплой руками, мне так спокойнее.
По суди, разница по функциям между инструментами совсем небольшая. Деплоер ещё попроще будет: для его работы достаточно всего одного файла-конфига. Но, при желании, можно и "расширить" конфигурацию, разбив её несколько файлов.
Лаконично и очень даже удобно, как по мне.
Что насчет капистрано — то это обязательная установка руби, бандлера, и так далее. А разницы как минимум никакой, как я вижу на данный момент.
Но, например, я работаю с symfony и мне не очень нравится, что тянуться ненужные зависимости.
deployer в этом плане мне понрвавился больше. хоть мы и пользовались capifony до этого.
+ в том, что не нужно ставить руби, чтобы деплоить.
Надо попробовать.
Мы билдим готовый собранный проект с разогретым кешем и статикой и просто раскатываем его на сервера, где остается только выполнить миграции и переключить симлинки.
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)
Здравствуйте) Но ведь всё это делается только через судо, т.е. нужно пароль ввести для выполнения подобной операции? И как ещё такие вещи давать ему выполнять? Или как вы это делаете у себя, чтобы было реально безопасно?
Для себя я пока не нашел красивого решения, завел отдельного пользователя (от которого не запускаются приложения), разрешил ему в sudoers запускать service. Тогда конфиг deployer'а можно исправить на
runLocally("ssh specialuser@server service php5-fpm restart");
P.S. не разобрался как тег source использовать, в превью все хорошо, а в самом сообщении — нет. А нет, это видимо из-за предмодерации было.
Deployer — удобный и гибкий деплой приложений