Comments 135
Отличный материал! Таких кастомных статей оч мало.
относительно недавно это обсуждалось в группе ror2ru: groups.google.com/group/ror2ru/browse_thread/thread/4b2ab0a1fdf42aec/32d18020230f3409?hl=ru&lnk=gst&q=unicorn#32d18020230f3409
А слабо установить это все чз dpkg с созданием deb пакетов? а то накидать софта в систему особого ума ненадо…
Чем вам rubygems, как менеджер пакетов, не угодил?
я думаю что предполагалась установка руби деб пакетом, что есть совсем необосновано, т.к. rvm более правилен (особенно когда нужно несколько версий руби). да и удаление занимает несколько секунд — rm -rf ~/.rvm (удаляем и рвм и все руби)
Могу предположить, что необходимостью держать (а главное использовать) два менеджера пакетов.
На гитхабе рассказывали как у них все работает — github.com/blog/517-unicorn
Конфиг юникорна — gist.github.com/206253
Конфиг юникорна — gist.github.com/206253
Самая популярная на данный момент связка, имхо, nginx+passenger. И ставится в разы проще.
По моим наблюдениям passenger на продакшн серверах начинает уходить, сменяясь на Unicorn.
Robot Unicorn Attack
А преимущества у Unicorn перед Passenger есть? Passenger автоматический стартует или убивает лишние инстансы и делает кучу еще всего. Как с этим у Unicorn?
unicorn.bogomips.org/ там по пунктам написано что может.
Это я читал, но там написана общие фичи архитектуры, мне больше интересны реальные преимущества (скорость обработки запросов, использованная память и т.д.) перед Passenger. Везде старые статьи 2009 года, за это время Passenger улетел вперед, хочется реальное сравнение.
Да и чисто по перечислению фич Passenger выглядит как-то более солидно.
Да и чисто по перечислению фич Passenger выглядит как-то более солидно.
github.com/blog/517-unicorn#comment-3142 — С 2009-го по моему в этом плане ничего не изменилось (или я что-то пропустил)
stackoverflow.com/questions/2201756/does-phusion-passenger-restart-gracefully-when-i-touch-restart-txt
Тут люди уверены, что Passenger нормально завершает все текущие запросы, 2010 год. В документации Passenger не понятно, как он обрабатывает перезапуск, прям интересно стало, это правда или нет.
Тут люди уверены, что Passenger нормально завершает все текущие запросы, 2010 год. В документации Passenger не понятно, как он обрабатывает перезапуск, прям интересно стало, это правда или нет.
Мое мнение, что passenger — это модуль для nginx/apache и он как бы «впаян» во frontend сервер и без него никуда. Используя Unicorn мы получаем четкое разделение на frontend/backend сервера — с точки зрения построения продакшн инфраструктуры такой подход, на мой взгляд, надежнее.
Пассажир подкупает простотой своей настройки, при этом не являясь чем-то плохим, и вполне имеет право на жизнь.
Пассажир подкупает простотой своей настройки, при этом не являясь чем-то плохим, и вполне имеет право на жизнь.
это тоже обсуждалось в группе ror2ru: groups.google.com/group/ror2ru/browse_thread/thread/e9562d1a4821e18e/e92f74e271d407b5?hl=ru&lnk=gst&q=unicorn
только из-за шаред-хостингов (в которых всегда по дефолту есть апач). все серьёзные приложения даже не смотрят на пассажира, ибо он 1) практически не масштабируется 2) течёт 3) вместе с апачем ест памяти больше, чем unicorn или thin.
Апач вообще фи, про него ни слова не было. Nginx+passenger дают вполне неплохую производительность, zero-time-restart начиная с версии 3 и в настройке/установке просто как три копейки.
zero-time-restart это только у nginx. сами по себе рельсы всё равно environment порой минуты по 3 поднимают. если б thin'у не надо было рельсы поднимать, он бы тоже за секунды стартовал :)
во всяком случае на мой взгляд всё равно frontend <-> backend намного отказоустойчивее, производительнее и масштабируемее. пассажир — это всё-таки решение больше для тех, кто хочет меньше париться с поддержкой приложения, и кому не нужна высокая нагрузка.
кто-то выше говорил про автостарт: не знаю как unicorn, но thin умеет в одну команду весь свой кластер сделать сервисом, и если кто-то умирает, он сразу перезапускается
во всяком случае на мой взгляд всё равно frontend <-> backend намного отказоустойчивее, производительнее и масштабируемее. пассажир — это всё-таки решение больше для тех, кто хочет меньше париться с поддержкой приложения, и кому не нужна высокая нагрузка.
кто-то выше говорил про автостарт: не знаю как unicorn, но thin умеет в одну команду весь свой кластер сделать сервисом, и если кто-то умирает, он сразу перезапускается
1) Масштабируется отлично. В третьей версии пассажира появился Passanger Standalone режим. Вообще, у пассажира гораздо более правильная очередь, имхо, + неплохие возможности подтюнить его поведение в нужную сторону.
2) Пассажир перестал течь после 1 версии, 3 версия вообще очень хороша в этом плане.
3) А по поводу пассажир+апач — похоже на проблемы апача, т.к. пассажир+nginx довольно таки неприхотлив в памяти. А вообще у вас странное стравнение — пассажир+апач vs unicorn. Надо сравнивать «пассажир+nginx vs unicorn+nginx», т.к. unicorn все равно без nginx использовать это самоубийство ))
2) Пассажир перестал течь после 1 версии, 3 версия вообще очень хороша в этом плане.
3) А по поводу пассажир+апач — похоже на проблемы апача, т.к. пассажир+nginx довольно таки неприхотлив в памяти. А вообще у вас странное стравнение — пассажир+апач vs unicorn. Надо сравнивать «пассажир+nginx vs unicorn+nginx», т.к. unicorn все равно без nginx использовать это самоубийство ))
Плюсую. Тем более, что Passenger заточен под REE (или REE под Passenger), что дает достаточный бонус производительности.
вот и возникает вопрос. производительность либо плюшки 1.9.2. я выбираю плюшки.
Когда пробовал 1.9.2, была туча гемов, которые на этой версии либо не заводились вообще, либо жутко баговали, поэтому как-то не впечатлился и вернулся на REE. А под REE лучше пассажира просто ничего нет.
Возможно, сейчас ситуация обстоит иначе, не спорю. Но пока продакшн-сервера будут сидеть на пассажире, а там посмотрим.
Возможно, сейчас ситуация обстоит иначе, не спорю. Но пока продакшн-сервера будут сидеть на пассажире, а там посмотрим.
Unicorn очень медленно стартует
Спасибо за статью.
Пока только не понял, может ли Unicorn запускать разные приложения под разными версиями Ruby, что иногда очень хочется иметь. В связи с этим два вопроса:
Зачем rvm?
Чем это по большому счёту лучше, чем nginx+passenger?
Пока только не понял, может ли Unicorn запускать разные приложения под разными версиями Ruby, что иногда очень хочется иметь. В связи с этим два вопроса:
Зачем rvm?
Чем это по большому счёту лучше, чем nginx+passenger?
два инстанса юникорна с разными конфигами и сокетами.
Да, может. Причем при подходе, описанном в статье, получается, что каждое приложение имеет собственный конфигурационный файл для unicorn и собственный бинарник unicorn (благодаря bundle exec). Пачек «один мастер — n воркеров» тоже будет несколько — одна на приложение. Сокеты юникорнов будут расположены в разных местах и для запуска нового приложения на сервере вам будет необходимо создать еще одну upstream секцию (лучше делать в отдельном файле в conf/vhosts) в nginx. Рестартуем nginx один раз — и больше этого не требуется при деплоях.
Rvm для легкой смены версий руби, если одному приложению требуется 1.8.7 или ree, а другому 1.9.2 — задавать их через rvm очень удобно.
Ответ на второй вопрос здесь: habrahabr.ru/blogs/ror/120368/#comment_3947007
Rvm для легкой смены версий руби, если одному приложению требуется 1.8.7 или ree, а другому 1.9.2 — задавать их через rvm очень удобно.
Ответ на второй вопрос здесь: habrahabr.ru/blogs/ror/120368/#comment_3947007
автор, а вам не кажется слишком смелым слово «правильно» в заголовке?
вот я к примеру деплою с помощью git, вместо unicorn'а у меня thin, вместо rvm я собираю ruby из сорцов (всегда пользую 1.9.2, ибо пора забывать об 1.8), и в общем-то не понимаю, почему мой подход менее правильный.
вот я к примеру деплою с помощью git, вместо unicorn'а у меня thin, вместо rvm я собираю ruby из сорцов (всегда пользую 1.9.2, ибо пора забывать об 1.8), и в общем-то не понимаю, почему мой подход менее правильный.
Здесь не как у Эдиссона — может быть и несколько правильных способов :)
Основная идея — прийти к разделению fronend/backend части при эксплуатации приложения.
А показал я на одном из многочисленных примеров — просто я использовал набор именно этих инструментов и мне они удобны. Более того, я уверен, что их набор
Основная идея — прийти к разделению fronend/backend части при эксплуатации приложения.
А показал я на одном из многочисленных примеров — просто я использовал набор именно этих инструментов и мне они удобны. Более того, я уверен, что их набор
должен меняться в соответствии с конкретной задачей.
то что вы используете thin это ваше право.
а вот то что вы собираете из сорцов — значит у вас очень много свободного времени. как вы обновляете руби? ручками? в наше то прогрессивное время…
в любом случае удачи вам
а вот то что вы собираете из сорцов — значит у вас очень много свободного времени. как вы обновляете руби? ручками? в наше то прогрессивное время…
в любом случае удачи вам
вы либо ни разу не пользовались rvm, либо у вас супер-сервера и вы не замечаете, что он их тоже собирает из сорцов.
мне во всяком случае проще написать
против трёх же команд по установке rvm, установке нужной версии руби и выбору её по дефолту.
и вам удачи
мне во всяком случае проще написать
wget что-то/ruby.tar.gz
tar -zxf ruby.tar.gz
./confidure && make && make installпротив трёх же команд по установке rvm, установке нужной версии руби и выбору её по дефолту.
и вам удачи
ну тут дело в том что параметров для ./configure намного больше нужно и запоминать их влом, да конечно можно написать скрипт и т.д. но как-то проще rvm install 1.9.2 (даже ссылку копировать не нужно откуда качать)
я ещё в своей практике ни разу не сталкивался с тем, что нужно писать дополнительные команды к configure при установке рубей. один раз нужно было что-то дополнительно из сорцов докомпилить (типа zlib'а, а может и не оно), но это было так давно, что я уже и не вспомню.
до сих пор нужно zlib, openssl. не?
кстати да. руби очень странно относиться к новым либам openssl.
я уже давно свежий дистр не ставил, поэтому не вспомню, память короткая.
по части этого вашего rvm'а оно конечно хорошо, что одной командой обновлять. только мне этого и не надо так часто. на днях было на одном из серверов, где rvm была: висело себе уже 2 месяца приложение, работало. обновил rvm'ом руби (1.9.2 аж с p0 до свежей стабильной), отказала половина вьюх, в которых использовалось самописное расширение Time чтоб расширить DateTime (для синтаксического сахара). Оказалось, что внезапно DateTime стал наследоваться от Date. и подобные баги не первые в моей практике, вплоть до того, что после обновления не загружается один-единственный файл из папки autoload'а (когда другие все загружаются).
лично для себя я давно уяснил по части MRI: если работает, то лучше не трогать.
по части этого вашего rvm'а оно конечно хорошо, что одной командой обновлять. только мне этого и не надо так часто. на днях было на одном из серверов, где rvm была: висело себе уже 2 месяца приложение, работало. обновил rvm'ом руби (1.9.2 аж с p0 до свежей стабильной), отказала половина вьюх, в которых использовалось самописное расширение Time чтоб расширить DateTime (для синтаксического сахара). Оказалось, что внезапно DateTime стал наследоваться от Date. и подобные баги не первые в моей практике, вплоть до того, что после обновления не загружается один-единственный файл из папки autoload'а (когда другие все загружаются).
лично для себя я давно уяснил по части MRI: если работает, то лучше не трогать.
Ну у меня привычка другая. Читаю постоянно фиды с руби и с рельсов и правлю код до того как все депрекейшн вылетит таким образом.
З.Ы. да — моя фанат )
З.Ы. да — моя фанат )
а спеков у вас нету? CI опять же.
да есть спеки. только в чём мне выгода постоянно свежую версию руби держать? приростов производительности не даёт, на моей памяти уже полгода не было ни одной серьёзной уязвимости. только чтобы лишних 10 часов рабочего времени на прогонку test::unit и отладку тратить?
а зачем тратить время на прогонку тестов?
есть teamcity с несколькими профилями сборки.
моно сделать еще один профиль с новым руби, благо тимсити поддерживает rvm.
и оно все автоматом прогонит еще и скажет где была ошибка
есть teamcity с несколькими профилями сборки.
моно сделать еще один профиль с новым руби, благо тимсити поддерживает rvm.
и оно все автоматом прогонит еще и скажет где была ошибка
вы сейчас сказали, как это можно упростить (и то сомнительно), а не в чём мне выгода от обновлений.
выгода в том что бы после года сиденья на старом релизе не прыгнуть на новый с тысячами косяков и геморроем.а на новый прийдется пересесть или изза безопасности или изза скорости или вы сервак новый купили. вы на новое железо будете ставить старый софт? это как на последний оптерон поставить Debian Woody.
в чём профит регулярных косяков и геморроя относительно таковых раз в полгода?
а зачем на них отвлекаться? у нас проект с постоянной разработкой. сидеть на старом нету смысла. тем более что мы не продали заказчику и забыли.
я имею в виду чем косяки и геморрой раз в месяц лучше косяков и геморроя раз в полгода?
тем что они незаметны. разработка и так идет постоянно, потому подправить один баг можно быстрее чем десяток. ИМХО конечно же.
исправить 10 багов за 1 раз, или 20 багов за 6 раз? логика подсказывает, что быстрее первое.
ну я думаю их будет меньше.
скорее всего 20 за 1 раз или 10 за 6.
скорее всего 20 за 1 раз или 10 за 6.
нет, почему же. смотрите: допустим в каждую версию вносится 2 бага, а 1 предыдущий исправляется. в этом случае я исправляю 6 багов, а вы 12. моё число багов по законам комбинаторики не может быть больше вашего.
но вы не исправляя свой код вовремя окажетесь в большой куче deprecation и removed functionality.
да, но суммарно мне исправлять один за полгода не больше, чем вам суммарно 6 раз за 6 месяцев.
но вы учтите, что я исправляю постоянно и знаю что где ломалось, а вы нет.
я потрачу 12 раз по 10 минут, а вы 6 раз по 30.
я потрачу 12 раз по 10 минут, а вы 6 раз по 30.
за месяц к следующему обновлению вы можете что-то забыть.
я за день, в который буду исправлять, вряд ли что-то забуду.
я за день, в который буду исправлять, вряд ли что-то забуду.
ну и что? мне зачем все помнить, я то уже все исправил :)
Честно говоря я никогда не понимал людей сидящих до сих пор на 8.04 с такими версиями руби что рельсы 3-й поднять невозможно. Эта гипотетическая безопасность убивает весь прогресс. Это то же самое что сидеть на ИЕ6 потому что в ИЕ9 больше дырок. Вы уж извините, но я считаю, что лучше потратить сутки в месяц на обновления, чем сидеть на каменных велосипедах.
при чём здесь 8.04 и ИЕ6, если я сижу на 1.9.2, который позволяет мне запустить третьи рельсы, и при критических уязвимостях раз в полгода я обновляюсь?
вернее будет аналогия не с 8.04 и ИЕ6, а с 10.04 LTS vs 11.04 и FireFox 3.6.15 vs FireFox 4.0.0. Кстати, я на 11.04 и FF4.
> Эта гипотетическая безопасность убивает весь прогресс.
мои старые рубя убивают ваш прогресс? или чей? лично мне они экономят нервы и время.
вернее будет аналогия не с 8.04 и ИЕ6, а с 10.04 LTS vs 11.04 и FireFox 3.6.15 vs FireFox 4.0.0. Кстати, я на 11.04 и FF4.
> Эта гипотетическая безопасность убивает весь прогресс.
мои старые рубя убивают ваш прогресс? или чей? лично мне они экономят нервы и время.
ну да. немного преувеличил. но лично для меня разница между p136 и p180 есть (даже в номере). так что считаю что обновления хотя бы раз в месяц необходимы. конечно если это не убъет проект (как mysql2 > 0.3.0 для rails 3.0.x)
кстати p180 — это багфикс релиз.
www.ruby-lang.org/en/news/2011/02/18/fileutils-is-vulnerable-to-symlink-race-attacks/ — читаем тут.
www.ruby-lang.org/en/news/2011/02/18/fileutils-is-vulnerable-to-symlink-race-attacks/ — читаем тут.
а прогресс убивает то что авторы гемов вынуждены делать совместимость с предыдущими версиями (что есть ересь на мой взгляд), и из-за этого код только пухнет. т.е. ничего полезного.
я как раз пользую rvm во всю.
у нас не супер-сервера а простой Amazon EC2 middle.
дело то не в том что собирает или нет из сорцов. дело в том что когда мне надо обновить руби я просто пишу
rvm upgrade 1.9.2-p136 192-p180 и всё.
rvm мне и жемсеты перенесет, и пересоберет что надо в жемах. не надо париться. и симлинку на дефолтный обновит.всего одна команда против трех.
у нас не супер-сервера а простой Amazon EC2 middle.
дело то не в том что собирает или нет из сорцов. дело в том что когда мне надо обновить руби я просто пишу
rvm upgrade 1.9.2-p136 192-p180 и всё.
rvm мне и жемсеты перенесет, и пересоберет что надо в жемах. не надо париться. и симлинку на дефолтный обновит.всего одна команда против трех.
>./confidure && make && make install
Я бы убивал за такое, с разжалованием в виндузятники, лишением всех наград и т.д.
serverfault.com/a/419211/190178
How do I install the latest stable version of Redis?
github.com/jordansissel/fpm/wiki
www.slideshare.net/fabiokung/ruby-and-rails-packaging-to-production
Я бы убивал за такое, с разжалованием в виндузятники, лишением всех наград и т.д.
serverfault.com/a/419211/190178
How do I install the latest stable version of Redis?
github.com/jordansissel/fpm/wiki
www.slideshare.net/fabiokung/ruby-and-rails-packaging-to-production
ах да, обновляю я повтором указанных выше команд с впереди стоящим make clean из папки сорцов старой версии.
кстати, сразу видно, что у вас очень много свободного времени, если вы на продакшне всегда держите свежую свежую руби. трудная, наверное, работа, дебажить приложение после каждого обновления.
кстати, сразу видно, что у вас очень много свободного времени, если вы на продакшне всегда держите свежую свежую руби. трудная, наверное, работа, дебажить приложение после каждого обновления.
RVM удобен тем, что работает по сути везде и одинаково, а в том же Debian вечно в пакетах что-то сломают или не обновят по полгода.
Ответ был вот в эту ветку.
Забыли одну весчь.
Если этой строчки не будет, то при обновлении Gemfile у вас после релоада уникорна не будет новых изменений бандла джемов.
before_exec do |server|
ENV["BUNDLE_GEMFILE"] = "#{rails_root}/Gemfile"
end
Если этой строчки не будет, то при обновлении Gemfile у вас после релоада уникорна не будет новых изменений бандла джемов.
Вот эту статью надо к Locum отправить, а то их «развертка» просто ни о чем. Тут ясно и понятно, что да как. Спасибо за статью.
Вот еще бы написали, для чего Capistrano, а то не понятно.
Вот еще бы написали, для чего Capistrano, а то не понятно.
Capistrano — это штука для автоматизации развертки новых версий приложения. Т.е. надо положить изменения на сервер — пишешь одну команду у себя на рабочей машине:
cap deploy — она автоматически производит деплой, если возникает ошибка — откатывается к предыдущей версии. Вещь очень удобная — сильно снижает человеческий фактор ошибки.Кстати, у нас используется установка RVM в режиме system-wide.
Хотя бы потому, что на одном сервере может быть размещено несколько ruby-сервисов.
Хотя бы потому, что на одном сервере может быть размещено несколько ruby-сервисов.
Каждый под своим user.
А в чем недостаток когда у каждого этого юзера будет свой рвм и свой руби?
а зачем плодить кучу сущностей? у каждого юзера своя версия rvm. вот кому это надо?
ну меня просто напрягает rvm установленный под рутом :) мне кажется что лучше пусть больше сущностей, но без рутового доступа (а еще желательно и с nologin)
а чем он вас напрягает?
сделать дефолтным другую версию руби не получиться — прав не хватит.
ну с капистрано не получиться nologin
сделать дефолтным другую версию руби не получиться — прав не хватит.
ну с капистрано не получиться nologin
Я и говорю чтобы рвм и руби у каждого свои.
Вот с капистрано у меня тоже проблемы ) точнее не люблю его. я лучше сделаю
ssh user_allowed_to_login@host
sudo su rvm_user
git pull
Вот с капистрано у меня тоже проблемы ) точнее не люблю его. я лучше сделаю
ssh user_allowed_to_login@host
sudo su rvm_user
git pull
в этом случае будут проблемы, например, с откатом назад (надо знать, на какое количество коммитов откатываться, к примеру), а также с тем, чтобы не забыть обновить конфиги, выполнить миграции и так далее.
У нас обычно это все зашивается в cap deploy или в chef recipes.
У нас обычно это все зашивается в cap deploy или в chef recipes.
теги сила. чекаутим по тегам, откат по тегам.
а базу вы тоже ручками обновляете? ;)
довольно редкая операция в продакшне если честно, да и rake db:migrate сделать не сложно на мой взгляд
а у вас сколько продакшенов? мне просто лень идти на все воркеры делать одни и теже операции. тем более что ошибиться не мудрено, а капистрано очень помогает.
4.
но обновляются они то не одновременно, проекты то разные.
но обновляются они то не одновременно, проекты то разные.
Очень может быть, что и одинаковые. Например, при развертывании одного приложения на нескольких серверах (масштабируемость, отказоустойчивость).
а у меня проект один, но воркеров много. да и лень это такая штука…
как говориться правильный админ — ленивый админ, потому что он один раз все настроил, а дальше уже все автоматом :)
как говориться правильный админ — ленивый админ, потому что он один раз все настроил, а дальше уже все автоматом :)
Надо разделять процессы bootstrapping и deploy.
На этапе bootstrapping сервер подготавливается, ставится операционная система и системные сервисы (например, snmp, collectd, rvm, ruby).
А на этапе deploy делаются service-specific tasks.
На этапе bootstrapping сервер подготавливается, ставится операционная система и системные сервисы (например, snmp, collectd, rvm, ruby).
А на этапе deploy делаются service-specific tasks.
Кстати для полноге zero-downtime нужно делать так:
after_fork do |server, worker|
begin
worker.user('deployer', 'deployer') if Process.euid == 0
defined?(ActiveRecord::Base) and
ActiveRecord::Base.establish_connection
old_pid = "#{server.config[:pid]}.oldbin"
if File.exists?(old_pid) && server.pid != old_pid
begin
# after this all request will be processed by new workers
Process.kill("WINCH", File.read(old_pid).to_i)
sleep 0.1
# send stop for the old master
Process.kill("QUIT", File.read(old_pid).to_i)
rescue Errno::ENOENT, Errno::ESRCH
end
end
rescue => e
puts "[#{Process}]: #{e.message}\n"
puts "[#{Process}]: #{e.backtrace.join("\n")}"
end
end
UFO just landed and posted this here
> чем собранный руками nginx лучше nginx из репозитория?
Если вы про репозиторий убунты, то ответ — цифрами в номере версии.
>Я использую mercurial. C репозиториями git работаю опять-таки из mercurial
если при это выполнив в консоли git clone git@url вы не получите ошибок, то переезжать не надо.
Если вы про репозиторий убунты, то ответ — цифрами в номере версии.
>Я использую mercurial. C репозиториями git работаю опять-таки из mercurial
если при это выполнив в консоли git clone git@url вы не получите ошибок, то переезжать не надо.
Мы давно перешли на сборку nginx руками по нескольким причинам:
1) полный контроль над списком собираемых модулей (часть модулей выкинута, часть добавлена, типа aio);
2) необходимость использования директив конфигурации nginx, которые появились только недавно;
3) Патчи на некоторые баги (например, патчи на AIO).
При этом, конечно, вместо сборки можно просто сделать сборку однократно и положить пакеты в локальный репозиторий пакетов.
1) полный контроль над списком собираемых модулей (часть модулей выкинута, часть добавлена, типа aio);
2) необходимость использования директив конфигурации nginx, которые появились только недавно;
3) Патчи на некоторые баги (например, патчи на AIO).
При этом, конечно, вместо сборки можно просто сделать сборку однократно и положить пакеты в локальный репозиторий пакетов.
установка rvm на debian и чтобы не system-wide — боль. постоянно хочет установить в /usr/local/rvm вместо ~/.rvm
как это лечить?
как это лечить?
Если он хочет установить в /usr/local/rmv — скорее всего вы делаете установку из-под root. Если нет, то вам сюда.
Скажите, а вы не придумали способ, как при деплое капистраной сделать, чтоб в случае ошибки в приложении происходил фейл и rollback? Просто в случае graceful restart с помощью USR2 иногда (когда какой-то косяк в коде) происходит следующее: unicorn стартует новый мастер, переименовывает pid в oldpid, фейлится, переименовывает обратно и продолжает работать со старой версией приложения. При этом, капистрана об этом ничего не знает и думает, что произошёл successful deploy. Со стороны это выглядит как ничего не изменилось после деплоя. Единственный способ узнать об ошибке – зайти на сервер и посмотреть в логи.
А разве компилировать Ruby — это правильно. Если найдут уязвимость в безопасности, то надо будет самому об этом узнать и обновить, а не написать просто
sudo apt-get updateДля оперативного обновления наверное компиляция более правильное решение, если следить. А версия в репах может не обновляться неизвестное время. Если обратили внимание, то и nginx здесь компилируется, видимо с аналогичными соображениями. Вроде и настроить можно более тонко при компиляции, но это к гентушникам :)
Если сервис некритичный, то, имхо, лучше из реп ставить действительно, может из нестабильных.
А если очень критичный, то компилировать на тестовом сервере с аналогичным конфигом, собирать пакет и ставить его на продакшен после всестороннего исследования. Как-то так.
Если сервис некритичный, то, имхо, лучше из реп ставить действительно, может из нестабильных.
А если очень критичный, то компилировать на тестовом сервере с аналогичным конфигом, собирать пакет и ставить его на продакшен после всестороннего исследования. Как-то так.
Блин, так и не понял, чем unicorn так хорош.
Для меня все это сильно похоже на mongrel_cluster, на который все благополучно забили, задолбавшись с ним. А тут заново история повторяется. Да еще и конфиг какой-то на ruby писать теперь придется.
Для меня все это сильно похоже на mongrel_cluster, на который все благополучно забили, задолбавшись с ним. А тут заново история повторяется. Да еще и конфиг какой-то на ruby писать теперь придется.
не очень понятно, как поднимать unicorn при старте системы (а также красиво опускать/перезапускать его) — неужели придётся писать свой кастомный скрипт в /etc/init.d/?
Мы используем runit: habrahabr.ru/blogs/sysadm/83775/
Вопрос такой тогда: как вы интегрируете runit с capistrano?
namespace :deploy do
task :start do
run "sudo /usr/bin/sv up #{application}"
end
task :stop do
run "sudo /usr/bin/sv down #{application}"
end
task :restart do
run "sudo /usr/bin/sv hup #{application}"
end
end
тут по идее должно быть
но взято из рабочего кода.
понятно, надо прописать sudoers для пользователя deploy.
namespace :deploy do
task :start do
sudo "/usr/bin/sv up #{application}"
end
task :stop do
sudo "/usr/bin/sv down #{application}"
end
task :restart do
sudo "/usr/bin/sv hup #{application}"
end
end
но взято из рабочего кода.
понятно, надо прописать sudoers для пользователя deploy.
Подскажите как запускать Unicorn под Runit?
У меня такой скрипт не работает
У меня такой скрипт не работает
#!/bin/sh
exec 2>&1
# Settings
APP_ROOT=/srv/vchemodan
APP_USER=deployer
APP_GROUP=deployer
APP_RAILS_ENV='production'
UNICORN_CONFIG=$APP_ROOT/current/config/unicorn.rb
CMD="bundle exec unicorn -E $APP_RAILS_ENV -c $UNICORN_CONFIG -E $APP_RAILS_ENV"
cd $APP_ROOT/current
exec chpst -u $APP_USER:APP_GROUP $CMD
остановите сервис, перейдите в его каталог </etc/sv/your_service>.
попробуйте запустить так:
Все ошибки станут сразу видны.
попробуйте запустить так:
./run
Все ошибки станут сразу видны.
Как минимум, APP_GROUP без $.
Да это случайно, на самом деле $ перед APP_GROUP есть.
Вот какую ошибку мне возвращает ранит:
chpst: fatal: unable to setgroups: permission denied
Вот какую ошибку мне возвращает ранит:
chpst: fatal: unable to setgroups: permission denied
У утилиты chpst нет прав на установку группы. Видимо, запускается runsvdir не из под рута или какие-то странные пермишены?
Попробуйте заменить chpst на sudo, или убрать строку chpst -u ..., оставить просто
Попробуйте заменить chpst на sudo, или убрать строку chpst -u ..., оставить просто
exec unicorn ...
После долгих дискуссий и поисков я пришел к выводу, что гарантии может дать только runit. Однако есть у меня один могильничек… В общем gem whenever (cron) + проверка на живость мастера (bash). Если с купюрами, то выглядит как-то так:
if environment == 'production'
every 1.minute do
command «if [! -f #{unicorn_pid} ] || [! -e /proc/$(cat #{unicorn_pid}) ]; then rvm #{ruby} && cd #{current} && bundle exec unicorn_rails -c #{unicorn_conf} -E #{rails_env} -D; fi»
end
end
UFO just landed and posted this here
Спасибо за статью!
У меня у двух сайтов почему-то конфликтовали директивы `listen 80 default deferred;` (duplicated listen ....) при том что голый `listen 80;` работает.
Мне кажется можно было бы описать еще подход с /etc/nginx/sites-available/ /etc/nginx/sites-enabled/ вместо /usr/local/nginx/conf/vhosts/*
соответственно, конфиги — в sites-available, симлинки на рабочие сайты — в sites-enabled, в nginx вместо `include /usr/local/nginx/conf/vhosts/*` стоит `include /etc/nginx/sites-enabled/*.conf`
Позвляет быстро отключать сайты, не ломая их конфиги.
У меня у двух сайтов почему-то конфликтовали директивы `listen 80 default deferred;` (duplicated listen ....) при том что голый `listen 80;` работает.
Мне кажется можно было бы описать еще подход с /etc/nginx/sites-available/ /etc/nginx/sites-enabled/ вместо /usr/local/nginx/conf/vhosts/*
соответственно, конфиги — в sites-available, симлинки на рабочие сайты — в sites-enabled, в nginx вместо `include /usr/local/nginx/conf/vhosts/*` стоит `include /etc/nginx/sites-enabled/*.conf`
Позвляет быстро отключать сайты, не ломая их конфиги.
Это вопрос принятых в определенном дистрибутиве соглашений и личных предпочтений.
Nginx'у всё равно откуда include делать, если прав хватает. В Debian и Ubuntu, насколько помню, используются
Nginx'у всё равно откуда include делать, если прав хватает. В Debian и Ubuntu, насколько помню, используются
/etc/nginx/sites-{available,enabled}, в RHEL/CentOS — /etc/nginx/conf.d, в ArchLinux это вообще на усмотрение админа, по умолчанию никаких директорий нет и include /etc/nginx/whatever/*.conf спокойно пишут руками, кому нужно. В подходе а-ля rhel отключать конфиги можно с помощью mv, всё равно потом SIGHUP кидать.Sign up to leave a comment.
Связка rvm + Rails + Nginx + Unicorn или деплоим рельсы правильно