Comments 39
redmine нормально запускается под 1.9.2, нужно только mysql2 gem использовать
Возможно. Но в документации написано, что пока не поддерживается. Экспериментировать с некоторыми заказчиками чревато )) Мало ли что всплывет.
Спасибо, Иван, как раз по этой статье, но на вашем блоге недавно собирал. Были ряд сложностей, так как nginx у меня уже был настроенный с php-fpm, и ruby 1.8.7 почему-то не дособрал нормально коннектор к libxml, но в целом всё решилось.
Кстати с Unicorn очень даже производительное решение выходит и удобное.
Волнует вот какой вопрос, к примеру запустил я unicorn от пользователя vasya:host значит и Ruby будет работать от него.
А вот если я команду на запуск прописал в /etc/rc.local от кого будет запуск? Извините за невежество :)
Кстати с Unicorn очень даже производительное решение выходит и удобное.
Волнует вот какой вопрос, к примеру запустил я unicorn от пользователя vasya:host значит и Ruby будет работать от него.
А вот если я команду на запуск прописал в /etc/rc.local от кого будет запуск? Извините за невежество :)
Насколько я знаю, rc.local запускается от рута.
Я бы в вашей ситуации написал bash скрипт, который проверяет запущен ли демон и если нет, то переходил в нужную директорию и запускал unicorn. И поставил бы его в кронтаб от нужного пользователя.
Таким образом убилось бы 2 зайца: запуск от нужного пользователя и мониторинг.
Я бы в вашей ситуации написал bash скрипт, который проверяет запущен ли демон и если нет, то переходил в нужную директорию и запускал unicorn. И поставил бы его в кронтаб от нужного пользователя.
Таким образом убилось бы 2 зайца: запуск от нужного пользователя и мониторинг.
Мне кажется с кронтабом не очень кошерно. Вот пример как можно через init скрипт сделать. Они там создают не привилегированного юзера и используют su, что бы запустить под ним.
для запуска unicorn удобно использовать тулзу Runit. Запускать можно от любого юзера плюс Runit сам мониторит состояние процесса и перезапускает при необходимости
Насколько я знаю, rc.local запускается от рута.
Я бы в вашей ситуации написал bash скрипт, который проверяет запущен ли демон и если нет, то переходил в нужную директорию и запускал unicorn. И поставил бы его в кронтаб от нужного пользователя.
Таким образом убилось бы 2 зайца: запуск от нужного пользователя и мониторинг.
Я бы в вашей ситуации написал bash скрипт, который проверяет запущен ли демон и если нет, то переходил в нужную директорию и запускал unicorn. И поставил бы его в кронтаб от нужного пользователя.
Таким образом убилось бы 2 зайца: запуск от нужного пользователя и мониторинг.
Походу пора портировать virtualenv под Ruby.
К сожалению с virtualenv на практике не сталкивался. Чем он тут лучше RVM будет?
Пардон, виноват, не написал что virtualenv — это реализация идеи в топике + куча плюшек, но под python.
Эм и все равно не понятно. В топике представлено куча инструментов, и не думаю, что virtualenv их все реализует. Я всегда считал что virtualenv и RVM примерно равны по ф-ционалу.
Virtualenv (и virtualenvwrapper) реализовывает куда больше фич чем сабж :)
У нас есть ТАКИЕ приборы, но мы вам про них не расскажем! (с) Манго-Манго :) Поделились бы, особенно если есть практический опыт и с тем и с тем. А то иначе, это еще скатиться к холивару Pyhton vs ruby, чего бы мне не хотелось.
И как бы не спорю, мне и правда интересно, чем virtualenv. Может проникнусь и каким нить костылем такой же ф-уионал в RVM приделаю.
И как бы не спорю, мне и правда интересно, чем virtualenv. Может проникнусь и каким нить костылем такой же ф-уионал в RVM приделаю.
Главный плюс который я вижу в ruby — это мультиверсионность гемов и самого руби без костылей.
В Питоне по умолчанию много версий одного и того же модуля не поставить. И тут приходит в помощь virtualenv, который, по сути, создает изолированное от системы окружение, в которое можно установить любую версию питона/модуля, использовать pre/post workon/deactivate хуки. Плюс поддержка со стороны uWSGI/nginx делают задачу из сабжа тривиальной.
Основная задача virtualenv — отделение проекта от ОС, например для разработки какого-либо модуля/проекта. Однако для продакшена virtualenv тоже подходит.
С другой стороны такие энвы удобно использовать для работы над текущей и dev-версией проекта, так как зависимости в них могу различаться, в том числе и по версии модулей.
Ну и один из перков — 'make virtualenv portable', что можно использовать для презентации проекта «с флешки», а-ля Denwer (если конечно на клиенте *nix-подобная система).
В Питоне по умолчанию много версий одного и того же модуля не поставить. И тут приходит в помощь virtualenv, который, по сути, создает изолированное от системы окружение, в которое можно установить любую версию питона/модуля, использовать pre/post workon/deactivate хуки. Плюс поддержка со стороны uWSGI/nginx делают задачу из сабжа тривиальной.
Основная задача virtualenv — отделение проекта от ОС, например для разработки какого-либо модуля/проекта. Однако для продакшена virtualenv тоже подходит.
С другой стороны такие энвы удобно использовать для работы над текущей и dev-версией проекта, так как зависимости в них могу различаться, в том числе и по версии модулей.
Ну и один из перков — 'make virtualenv portable', что можно использовать для презентации проекта «с флешки», а-ля Denwer (если конечно на клиенте *nix-подобная система).
спасибо за развернутый ответ. Теперь понятна ваша точка зрения. Но кроме
1) использовать pre/post workon/deactivate хуки.
2) 'make virtualenv portable',
и по духу и по умениям оба инструмента выглядят очень похожими. Мне в целом ясно. Если про 1) еще подробней расскажете (когда и для чего это полезно), то буду совсем рад :)
1) использовать pre/post workon/deactivate хуки.
2) 'make virtualenv portable',
и по духу и по умениям оба инструмента выглядят очень похожими. Мне в целом ясно. Если про 1) еще подробней расскажете (когда и для чего это полезно), то буду совсем рад :)
Предположим у нас есть python, virtualenv, virtualenvwrapper и git/hg-репа с кодом.
Создаем энв:
Ключ --no-site-packages говорит чтобы энв не использовал системные site-packages, --python указывает на бинарник python нужной нам версии (если не указывать — берется системный).
Как видите создалось 5 скриптов, из которых там интересно 4.
В распоряжении разработчика есть команд:
workon (активирует энв)
deacticate (деактивирует энв)
mkvirtualenv (создает энв)
rmvirtualenv (удаляет энв)
Допустим наш энв используется для dev-версии проекта. Что мы хотим при запуске энва? Обновить код из репы! Для этого пишем в test_env/bin/preactivate (или postactivate, в данном случае разницы нет):
А при деактивации энва мы захотим все коммитнуть и пушнуть. Ну и по аналогии: можно творить что угодно.
Алерт, дальнейшие высказывания могут быть ошибочными.
Также хуки разделяются на глобальные и per-env, то есть если есть действия которые будут выполнятся для всех энвов без исключения — то вэлкам ту глобал хукс.
Создаем энв:
mktums@beta:~ $ mkvirtualenv --no-site-packages --python=/opt/local/bin/python2.6 test_env
Running virtualenv with interpreter /opt/local/bin/python2.6
New python executable in test_env/bin/python
Installing setuptools............................done.
Installing pip...............done.
virtualenvwrapper.user_scripts creating /Users/mktums/Envs/test_env/bin/predeactivate
virtualenvwrapper.user_scripts creating /Users/mktums/Envs/test_env/bin/postdeactivate
virtualenvwrapper.user_scripts creating /Users/mktums/Envs/test_env/bin/preactivate
virtualenvwrapper.user_scripts creating /Users/mktums/Envs/test_env/bin/postactivate
virtualenvwrapper.user_scripts creating /Users/mktums/Envs/test_env/bin/get_env_detailsКлюч --no-site-packages говорит чтобы энв не использовал системные site-packages, --python указывает на бинарник python нужной нам версии (если не указывать — берется системный).
Как видите создалось 5 скриптов, из которых там интересно 4.
Более того, на самом деле при установке virtualenvwrapper создаются еще 8 скриптов:
postactivate
postdeactivate
postmkvirtualenv
postrmvirtualenv
preactivate
predeactivate
premkvirtualenv
prermvirtualenv
В распоряжении разработчика есть команд:
workon (активирует энв)
deacticate (деактивирует энв)
mkvirtualenv (создает энв)
rmvirtualenv (удаляет энв)
Допустим наш энв используется для dev-версии проекта. Что мы хотим при запуске энва? Обновить код из репы! Для этого пишем в test_env/bin/preactivate (или postactivate, в данном случае разницы нет):
#!/bin/bash
# This hook is run before every virtualenv is activated.
cd project && hg pull -u http://mktums:pwd@repos/test_envА при деактивации энва мы захотим все коммитнуть и пушнуть. Ну и по аналогии: можно творить что угодно.
Алерт, дальнейшие высказывания могут быть ошибочными.
Также хуки разделяются на глобальные и per-env, то есть если есть действия которые будут выполнятся для всех энвов без исключения — то вэлкам ту глобал хукс.
Да, мы с вами, к слову, нашли о чем спорить, все равно virtualenv'а под Ruby нет, а жаль =(
Использую связку nginx+кластер из thin'ов Вполне доволен. Работает по этой схеме проект со средней нагрузкой. Производительность вполне устраивает.
Смотрел в сторону unicorn, но как-то не сложилось.
Смотрел в сторону unicorn, но как-то не сложилось.
а подскажите, если и порты, и location совпадают, то как nginx понимает, когда просят project, а когда redmine?
За это отвечают директивы server{}. Для каждого хоста свой обработчик location.
А через виртуализацию не проще ли такую задачу решить? Здесь достаточно виртуализации на уровне операционной системы (OpenVZ, jails, zones); «тяжелые» системы, подобные VMware, не потребуются.
«смерть пассажира и рождение единорога». Отличное название для рок-группы…
Sign up to leave a comment.
Поднимаем на одном сервере несколько Ruby on Rails проектов под разными версиями ruby (Nginx + Unicorn)