Comments 34
Ничего себе, самый простой! А, согласно этой идеологии chef или ansible считается монструозным и сложным, что ли?
Или в данном случае «простотой» выступает количество различных инструментов? Тогда почему же не переписать все на bash?
В общем, развертывание серверов через капистрано имеет место на жизнь, но никак не может называться «самым простым способом».
Или в данном случае «простотой» выступает количество различных инструментов? Тогда почему же не переписать все на bash?
В общем, развертывание серверов через капистрано имеет место на жизнь, но никак не может называться «самым простым способом».
Вы мою предыдущую статью еще не видели, вот там было намного сложнее.
Да и на самом деле, если убрать весь текст, то весь способ заключается в добавлении нескольких строчек в Gemfile, нескольких в Capfile, немного кода в deploy.rb и запуском трех команд. Не так уж и страшно вроде.
Да и на самом деле, если убрать весь текст, то весь способ заключается в добавлении нескольких строчек в Gemfile, нескольких в Capfile, немного кода в deploy.rb и запуском трех команд. Не так уж и страшно вроде.
Я вот чем больше смотрю — тем больше понимаю, что технология скорее мертвая, чем живая. Насколько я вижу — сейчас по сути два полюса сражаются: один — generic deploy (через сборку пакетов ОС, как правило каким-то generic configuration management tool — типа того же chef / puppet / ansible), другой — абстрагирование по максимуму от инфраструктуры и задач ее поддержки и deploy полным автоматом через git push (всякие heroku, dokku и т.д.).
Даже несмотря на вашу громадную работу (ни разу не шучу, я вполне представляю, чего стоит автоматизация создания такой здоровой инфраструктуры — и, судя по всему, у вас эту задачу получилось решить), я боюсь, что Capistrano с «несколько строчек сюда, потом несколько туда, тут подкрутить, там поставить» все равно будет проигрывать по простоте «развернул контейнер(ы) через веб-интерфейс + git push => все работает».
Даже несмотря на вашу громадную работу (ни разу не шучу, я вполне представляю, чего стоит автоматизация создания такой здоровой инфраструктуры — и, судя по всему, у вас эту задачу получилось решить), я боюсь, что Capistrano с «несколько строчек сюда, потом несколько туда, тут подкрутить, там поставить» все равно будет проигрывать по простоте «развернул контейнер(ы) через веб-интерфейс + git push => все работает».
То есть вы считает, что пилить и гонять новые контейнеры по нескольку раз на день будет проще?
Сомневаюсь.
Все зависит от того, как построен цикл разработки и какие требования к деплою.
Сомневаюсь.
Все зависит от того, как построен цикл разработки и какие требования к деплою.
В смысле «пилить и гонять»? Контейнер один раз на приложение создается. Вы создаете несколько приложений в день? Я вот лично что-то типа 2-3 в год в лучшем случае.
Я о том, что деплой — это не только апдейт кода.
Простой сценарий деплоя:
— переводим приложение в сервисный режим
— делаем бекап БД
— обновляем код
— заливаем необходимые конфиги (надеюсь вы конфиги не храните в vcs)
— запускаем билд/миграции
— переводим приложение в рабочий режим или откатываем предыдущую версию если что-то пошло не так
Вот чем и как здесь помогут контейнеры?
Простой сценарий деплоя:
— переводим приложение в сервисный режим
— делаем бекап БД
— обновляем код
— заливаем необходимые конфиги (надеюсь вы конфиги не храните в vcs)
— запускаем билд/миграции
— переводим приложение в рабочий режим или откатываем предыдущую версию если что-то пошло не так
Вот чем и как здесь помогут контейнеры?
Вы привели не «простой», а скорее «умеренно средний» сценарий. Простой (который вполне годится для stage как есть) скорее выглядит как-то так:
— остановить приложение
— сделать бэкап БД
— обновить и собрать код, подсунув конфигурацию
— запустить миграции
— запустить приложение обратно или откатить
Такой минимальный сценарий реализуется как раз системами типа heroku одной командой без каких-либо особенных дополнительных телодвижений. Конфигурация, опять же, тривиальна — один контейнер с приложением, одна база данных, одно к другому присоединяется либо кликом в веб-интерфейсе либо еще одной командой.
По мере усложнения схемы деплоймента и перехода в production, разумеется, что-то придется доделывать вручную и что-то будет изменяться. Тривиальный вариант «сервисного режима» — показывать заглушку-статику — тоже получится более-менее автоматически на heroku-подобных системах. Введение полноценного режима read-only потребует уже кое-каких усилий по модификации собственно самого приложения, и, да, придется вписать в соответствующие строчки а ля «heroku features:enable -a myapp readonly» и «heroku features:disable -a myapp readonly» в процедуру деплоймента.
Я совершенно верю, что по мере роста через какое-то время процедура станет весьма сложной — серверов станет несколько тысяч, захочется zero downtime deployment, БД станет такой, что забэкапить ее нереально — в итоге потребуются выделенные deployment engineers, которые будут ее проводить. Да, в конечном счете уже станет по сути без разницы, чем именно деплоить, т.к. 90-95% всего, относящегося к деплойменту все равно будет самописное, с учетом специфики приложения, типа и характера данных, ролей в кластерах и т.д. и т.п. Кроме того, скорее всего в какой-то момент облачные PaaS / IaaS сервисы типа heroku или даже amazon станут слишком дороги и целесообразно будет завести свои сервера / свой датацентр и штат обслуживающих все это людей.
— остановить приложение
— сделать бэкап БД
— обновить и собрать код, подсунув конфигурацию
— запустить миграции
— запустить приложение обратно или откатить
Такой минимальный сценарий реализуется как раз системами типа heroku одной командой без каких-либо особенных дополнительных телодвижений. Конфигурация, опять же, тривиальна — один контейнер с приложением, одна база данных, одно к другому присоединяется либо кликом в веб-интерфейсе либо еще одной командой.
По мере усложнения схемы деплоймента и перехода в production, разумеется, что-то придется доделывать вручную и что-то будет изменяться. Тривиальный вариант «сервисного режима» — показывать заглушку-статику — тоже получится более-менее автоматически на heroku-подобных системах. Введение полноценного режима read-only потребует уже кое-каких усилий по модификации собственно самого приложения, и, да, придется вписать в соответствующие строчки а ля «heroku features:enable -a myapp readonly» и «heroku features:disable -a myapp readonly» в процедуру деплоймента.
Я совершенно верю, что по мере роста через какое-то время процедура станет весьма сложной — серверов станет несколько тысяч, захочется zero downtime deployment, БД станет такой, что забэкапить ее нереально — в итоге потребуются выделенные deployment engineers, которые будут ее проводить. Да, в конечном счете уже станет по сути без разницы, чем именно деплоить, т.к. 90-95% всего, относящегося к деплойменту все равно будет самописное, с учетом специфики приложения, типа и характера данных, ролей в кластерах и т.д. и т.п. Кроме того, скорее всего в какой-то момент облачные PaaS / IaaS сервисы типа heroku или даже amazon станут слишком дороги и целесообразно будет завести свои сервера / свой датацентр и штат обслуживающих все это людей.
Я примерно об этом и говорю.
Ситуации разные бывают, поэтому нельзя однозначно сказать, что вот это проще или лучше этого.
А судя по коментам, для многих деплой — это только апдейт кода.
Ситуации разные бывают, поэтому нельзя однозначно сказать, что вот это проще или лучше этого.
А судя по коментам, для многих деплой — это только апдейт кода.
Да я, собственно, о том, что есть «простые» сценарии и есть «сложные» сценарии.
Для простых — нишу потихоньку занимают инструменты типа heroku.
Для сложные — очевидно, команда devops-инженеров, которые будут использовать либо ту же существующую инфраструктуру, какие-то более общие configuration management инструменты типа chef / ansible / puppet / cfengine и т.п.
И Rails-специфичные инструменты типа Capistrano (равно как и любые другие инструменты, сурово привязанные к фреймворку — Mina, Moonshine, Rocketeer, Grunt, Fabric / Fabistrano и т.д.), в свете того, что попали между этих двух полюсов, стабильно теряют свою долю.
Для простых — нишу потихоньку занимают инструменты типа heroku.
Для сложные — очевидно, команда devops-инженеров, которые будут использовать либо ту же существующую инфраструктуру, какие-то более общие configuration management инструменты типа chef / ansible / puppet / cfengine и т.п.
И Rails-специфичные инструменты типа Capistrano (равно как и любые другие инструменты, сурово привязанные к фреймворку — Mina, Moonshine, Rocketeer, Grunt, Fabric / Fabistrano и т.д.), в свете того, что попали между этих двух полюсов, стабильно теряют свою долю.
Эмм, а в чем выражается Rails-специфика или суровая привязанность к фреймворку Capistrano/Mina?
Мне и колегам, тот факт, что они написаны на руби, совсем не мешает деплоить кроме рельсов и ноду с пхп. И уверен, что с любым другим стеком сложностей бы также не возникло.
Честно, не спора ради, а интереса для.
Мне и колегам, тот факт, что они написаны на руби, совсем не мешает деплоить кроме рельсов и ноду с пхп. И уверен, что с любым другим стеком сложностей бы также не возникло.
Честно, не спора ради, а интереса для.
Да ситуация там примерно такая же самое, что и Puppet / Chef. Аргументация из серии «not invented here», «нам неудобно писать конфиги на этом вашем ruby», «зачем мне в системе еще один лишний язык и занятые 10-20-50-100 мегабайт места» и т.д.
Рациональных отличий никаких, на самом деле — примерно как и в любом подобном же споре Capistrano vs все остальные. Ну, всяких рецептов для Capistrano / Rails будет априори больше, чем Capistrano / Django. А в свою очередь, у Grunt, наверное, готовых рецептов по деплою node.js будет больше, чем у Capistrano / node.js. Но при этом если речь о том, что надо относительно небольшой командой поддерживать дикий зоопарк разнообразных инсталляций на разных фреймворках — все равно будет тенденция к унификации — и в этом месте, опять же, ангажированность Capistrano с одним из фреймворков будет скорее играть против признания его «золотым стандартом».
Реально — посмотрите просто на альтернативы Capistrano — до смешного же доходит. Я пока ни одной не видел, которая бы давала четкий ответ на вопрос «чем оно лучше», у всех детский лепет на тему «а мы переписали это на нашем языке» или «мы сделали больше magic / меньше писать руками» или, наоборот «меньше magic / больше писать руками».
Рациональных отличий никаких, на самом деле — примерно как и в любом подобном же споре Capistrano vs все остальные. Ну, всяких рецептов для Capistrano / Rails будет априори больше, чем Capistrano / Django. А в свою очередь, у Grunt, наверное, готовых рецептов по деплою node.js будет больше, чем у Capistrano / node.js. Но при этом если речь о том, что надо относительно небольшой командой поддерживать дикий зоопарк разнообразных инсталляций на разных фреймворках — все равно будет тенденция к унификации — и в этом месте, опять же, ангажированность Capistrano с одним из фреймворков будет скорее играть против признания его «золотым стандартом».
Реально — посмотрите просто на альтернативы Capistrano — до смешного же доходит. Я пока ни одной не видел, которая бы давала четкий ответ на вопрос «чем оно лучше», у всех детский лепет на тему «а мы переписали это на нашем языке» или «мы сделали больше magic / меньше писать руками» или, наоборот «меньше magic / больше писать руками».
Ну вы всё это сделаете на своём компе разработчика, а потом замените контейнер и на продакшне всё заработает как часы без простоя
Люди, приготовьтесь к тому что это очень очень простой конфиг и если у вас приложение сложнее, чем уроки с блогом из рельсовых гайдов, то ваш deploy.rb и тп будет сильно больше. С добавлением в проект delayed_job, resque, faye и прочих сервисов, что надо запускать и мониторить.
А chef это уже потом, когда серверов станет много и появится необходимость поднимать много машин автоматом с готовыми nginx/postgres/etc, его нет смысла особенного использовать только для деплоя приложений. И он не проще в этом смысле.
Ну а кому надо проще «как php» — есть heroku, но это не для бедных развлечение, особенно сейчас, так что лучше учиться самим и понимать, как все устроено.
А chef это уже потом, когда серверов станет много и появится необходимость поднимать много машин автоматом с готовыми nginx/postgres/etc, его нет смысла особенного использовать только для деплоя приложений. И он не проще в этом смысле.
Ну а кому надо проще «как php» — есть heroku, но это не для бедных развлечение, особенно сейчас, так что лучше учиться самим и понимать, как все устроено.
Mina все ж лучше чем capistrano, деплои более быстрые получаются.
Вот сейчас прямо засек. У меня, если нет новых gem'ов в Gemfile, деплоится за 26 секунд. Вроде не так уж и медленно. Хотя Mina в чем-то выглядит интересней.
Mina выигрывает, если у вас деплой сложнее «один раз подключился и залил файлы».
Mina хороша только в случае если у вас только один сервер, на который деплоится приложение. Чуть больше 1 машины — всё, Mina уже непригодна, либо требует слишком много плясок. С капой же будь у тебя 1, 2, 10, N серверов — добавил IP в массив и счастье. Именно поэтому большинство и пользуется капой — не потому что у всех подряд по 2 и более серверов для деплоя, а потому что если у тебя вдруг появится ещё один сервер, или проект с несколькими серверами — не придется менять deploy tool.
А так да, я mina тоже люблю и уважаю. :)
А так да, я mina тоже люблю и уважаю. :)
К сожалению, mina менее популярна, и как следствие, под неё нет того же обилия готовых recipes как под capistrano.
Самый простой способ — это, когда код писать не надо. Ruby и RVM можно через Deploy4Me установить, вообще без кода (https://deploy4me.com/en/deployments/ruby.html). 2 минуты в визуальном редакторе и готово.
Сервис сам настроит SSH, безопасность и Nginx по желанию.
Сервис сам настроит SSH, безопасность и Nginx по желанию.
Все варианты деплоя приложений на руби такие монструозные?
Я объясню: если даже не рассматривать php (слишком просто), то можно рассмотреть такие варианты деплоя проектов на чистый сервер:
1. Django. Установка питона (если его внезапно нет), дальше pip: поставить фреймворк, поставить uwsgi. Осталось сочинить конфиг nginx (или спереть из гугла) и все.
2. Perl. Perl, как правило, уже есть. Нужно установить, например, Mojo, у которого внутри уже есть веб-сервер. Осталось его запустить одной командой и сочинить конфиг nginx.
Затем можно просто чекаутить репозиторий на продакшен-сервере. Ити я чего-то не понимаю в руби и все на самом деле просто?
Я объясню: если даже не рассматривать php (слишком просто), то можно рассмотреть такие варианты деплоя проектов на чистый сервер:
1. Django. Установка питона (если его внезапно нет), дальше pip: поставить фреймворк, поставить uwsgi. Осталось сочинить конфиг nginx (или спереть из гугла) и все.
2. Perl. Perl, как правило, уже есть. Нужно установить, например, Mojo, у которого внутри уже есть веб-сервер. Осталось его запустить одной командой и сочинить конфиг nginx.
Затем можно просто чекаутить репозиторий на продакшен-сервере. Ити я чего-то не понимаю в руби и все на самом деле просто?
Мы написали в свое время pushapp gem, пользуемся до сих пор и рады, хотя есть мысли перейти на docker.
А почему в заголовке RoR? Я успешно использую capistrano 3 для деплоя и сборки symfony 2 приложения. Также пытался использовать огрызок capifony, но с ней оказалось много проблем.
День добрый.
Сервер настроен, благодарю. Приложение задеплойжено.
Но возникла проблема «We're sorry, but something went wrong.»
Ассеты прекп-л, с дб сконектился.
Никак не могу понять в чем проблема, уже несколько дней бьюсь.
Сервер настроен, благодарю. Приложение задеплойжено.
Но возникла проблема «We're sorry, but something went wrong.»
Ассеты прекп-л, с дб сконектился.
Никак не могу понять в чем проблема, уже несколько дней бьюсь.
вот чего откопал в var/www/log/nginx.error.log, содержимое следующее (повторяется)
2015/03/04 07:35:59 [crit] 279#0: *12 connect() to unix:/var/www/application/current/tmp/sockets/.unicorn.sock failed (2: No such file or directory) while connecting to upstream, client: 94.230.122.71, server: _, request: «GET / HTTP/1.1», upstream: «unix:/var/www/application/current/tmp/socke...», host: "...."
2015/03/04 07:35:59 [crit] 279#0: *12 connect() to unix:/var/www/application/current/tmp/sockets/.unicorn.sock failed (2: No such file or directory) while connecting to upstream, client: 94.230.122.71, server: _, request: «GET / HTTP/1.1», upstream: «unix:/var/www/application/current/tmp/socke...», host: "...."
Проблема в том, что nginx не может найти .sock файл unicorn'a.
Проверьте, что:
— приложение присутсвует по адресу /var/www/application/current/
— unicorn запущен (ps aux | grep unicorn)
P.S. рекомендую этот gem для запуска unicorn при каждом деплое
Проверьте, что:
— приложение присутсвует по адресу /var/www/application/current/
— unicorn запущен (ps aux | grep unicorn)
P.S. рекомендую этот gem для запуска unicorn при каждом деплое
Sign up to leave a comment.
Самый простой deploy приложения на Ruby on Rails