Ну тут все зависит от конкретного проекта и причин почему его нужно остановить. Так-то способов остановить конкретного вассала не мало)
Вообще по-хорошему так бд и файлопомойка должны быть вообще на другом сервере а проект который нужно именно остановить (а не перезапустить или еще что-то) бы вообще оттуда снести и потом когда надо снова задеплоить из репы и все.
Конфиги nginx.conf и uwsgi.ini касающиеся проекта лежат в репе с проектом конечно если проект изначально заточен под полное взаимодействие с nginx и uwsgi(например кеширование и многое другое там прописано и у каждого проекта могут быть нюансы к примеру какой-то проект может использовать что-то типа django-nginx-image)
Посмотрите на репозиторий проекта rtfd.org — там вообще вроде как немеряно конфигов nginx валяется, если что-то не изменилось.
а потому что по умолчанию uwsgi уже собирается с этими модулями и не нужно ничего прописывать.
если вы пробовали ту uwsgi которая ставится через apt — так там модульная сборка которая расчитана на легковесность(только в конфиге подключаются нужные модули и они уже отдельными файлами лежат например в папке plugins а не встроены в бинарнике uwsgi). я всегда ставлю uwsgi через pip, а если нужен какой-то особенный профиль сборки просто подставляю нужные параметры например: UWSGI_PROFILE=gevent pip install uwsgi тогда uwsgi установится сразу еще и с плагином gevent и его не надо прописывать как plugin а просто сразу в конфиге использовать. Если ставить uwsgi через pip там же после установки указано какие плагины скомпилились вместе с uwsgi.
Забыл упомянуть про emperor и свою структуру проектов.
например у меня в каждом django-проекте лежит nginx.conf и uwsgi.ini
в основном nginx.conf прописывается: include /server/apps/*/nginx.conf;
а при запуске uwsgi в режиме emperor: newrelic-admin run-program uwsgi --emperor="/server/apps/*/uwsgi.ini:production"
это упрощенно а так-то у меня и для emperor .ini файлик есть с настройками и для вассалов всякие по умолчанию настройки.
По сути nginx ищет свои конфиги в /server/apps/любое имя проекта/nginx.conf — конкретно ищет nginx.conf
и тоже-самое с uwsgi
Еще в плане сравнения uWSGI c Gunicorn — Gunicorn не умеет сервить Ruby, PHP, Perl и другие проекты, а uWSGI легко.
так как у вас в ini-конфиге уже прописана chdir chdir = /path/to/your/project
то ниже не стоит лишний раз прописывать пути, можно просто добавить %(chdir) вместо "/path/to/your/project": socket = %(chdir)/mysite.sock
так-же можно назвать uwsgi.ini с именем проекта project.ini и в конфиге %n будет означать имя файла конфига до расширения то есть project
я все-же чаще называю его uwsgi.ini, но имя проекта чтобы не писать постоянно просто берется из имени директории в которой лежит файл конфига — %c
Подробнее смотреть тут.
Например у меня в конфиге сокет так прописан: socket = %d%c.uwsgi.sock — %d полный путь до папки в которой лежит конфиг, %c имя директории проекта.
Тоже самое с module = %c.wsgi
часто у меня в конфиге uWSGI несколько секций, одна общая откуда другие при необходимости берут эти общие дефолтные настройки типа:
[uwsgi]
uid = server
gid = server
chmod-socket = 664
chown-socket = server:server
;тут типа настроено так что виртуальное окружение имеет такое-же имя как и имя проекта
venv = /server/.virtualenvs/%c
pp = %d
master
processes = %k
cheaper = 4
protocol = uwsgi
autoload
no-orphans
memory-report
die-on-term
harakiri = 60
harakiri-verbose
reload-mercy = %k
worker-reload-mercy = %k
max-requests = 5000
buffer-size = 65535
post-buffering = 1048576
reload-on-rss = 300
touch-reload = %p
vacuum
enable-threads
single-interpreter
lazy-apps
; читаем .env файлы которые совместимы с foreman/honcho например как для хероку, всякие настройки в переменных окружения.
for-readline = .env
env = %(_)
end-for
Тут сразу становится понятно как запускать нужную секцию, в которой вы сделали импорты других нужных вам секций.
Незнаю почему вообще сравнивают uWSGI и Gunicorn. uWSGI намного более функциональный — он может выступать и как замена celery/rq(я через uwsgi spooling и почту рассылаю пачками и другие фоновые задачи выполняются), он может мониторить файлы, папки, как крон работает и много чего еще… отлично ладит с nginx и с кэшем удобно работать. uWSGI и просто как wsgi сервер уже на голову выше Gunicorn, и делает много, надежно, быстро(ну явно быстрее чем Gunicorn), и при этом кушает не так много. А если вспомнить о всех вкусностях которые хранятся в закромах uWSGI то вообще даже и смотреть не хочется на Gunicorn
Я вот немного попиливаю github.com/unbit/django-uwsgi но все с временем проблемы, в планах много всего и многое под разные проекты делалось а выпилить и оформить с доками в ту репу все что-то никак. Еще по теме uwsgi есть django-uwsgi-mail и django-uwsgi-cache
Забыл еще упомянуть что можно вообще весь ваш проект скормить в uwsgi и запускать типа ./myapp --no-site --master --processes 4, там как-раз и понадобится TemplateLoader из django-uwsgi
Ubuntu для Mac как выпускали так и выпускают. Вы так говорите будто только в этом релизе возобновили выпуск спец образов под Mac.
Я всегда их использую чтобы на Macbook Pro ставить Ubuntu. Вот только плохо что не на всех зеркалах они встречаются…
Я мало имею дел с php, восновном с python. Но пару раз приходилось все-же связаться и с php, и запускал я его на Mavericks через uWSGI, как я делаю это и с python приложениями. uWSGI вообще всеяден, через него можно и perl запускать и ruby и многое другое. А так как я оч привык к uWSGI то мне проще было не лезть в дебри php-fpm и воспользоваться любимыми и привычными средствами. Вот насчет производительности uwsgi vs php-fpm ничего не могу сказать — может кто-то проводил тесты? Ну по крайней мере uWSGI помимо всего прочего несет в себе еще очень богатый функционал.
Это имеет смысл если вы еще по многим другим причинам используете jQuery в вашем проекте. А иначе лучше только средствами AngularJS обойтись и не подключать jQuery вообще.
Очень порадовала возможность посмотреть аттачи из всех писем как файлы.
Хорошо что музыкальные файлы можно прослушать, но плохо что не из всех папок(из папки «Mail attachments» мне не удалось послушать музыкальные треки, только скопировав эти-же самые треки в папку «Музыка», появилась возможность их воспроизвести) это можно сделать.
Хотелось бы иметь возможность открывать через этот интерфейс и файлики с расширениями .py, .conf, .ini и другие(ну можно же их открывать тупо как текстовые файлы)
Когда сидел на Ubuntu, тоже много пользовался notify-send из bash скриптов, но в питон скриптах я пользовался pynotify
В OS X сейчас шлю уведомления как-то так:
osascript -e 'display notification "Some message" with title "Some title" subtitle "Some subtitle" sound name "Bosso"'
Да дело не только в удобстве и дизайне а в том что GitHub позиционировался еще и как социальная сеть. Именно социальные фишки такие как фолловинг и всякие ленты, рейтинги итд повлияли на его популяризацию.
Вообще по-хорошему так бд и файлопомойка должны быть вообще на другом сервере а проект который нужно именно остановить (а не перезапустить или еще что-то) бы вообще оттуда снести и потом когда надо снова задеплоить из репы и все.
Посмотрите на репозиторий проекта rtfd.org — там вообще вроде как немеряно конфигов nginx валяется, если что-то не изменилось.
если вы пробовали ту uwsgi которая ставится через apt — так там модульная сборка которая расчитана на легковесность(только в конфиге подключаются нужные модули и они уже отдельными файлами лежат например в папке plugins а не встроены в бинарнике uwsgi). я всегда ставлю uwsgi через pip, а если нужен какой-то особенный профиль сборки просто подставляю нужные параметры например:
UWSGI_PROFILE=gevent pip install uwsgiтогда uwsgi установится сразу еще и с плагином gevent и его не надо прописывать как plugin а просто сразу в конфиге использовать. Если ставить uwsgi через pip там же после установки указано какие плагины скомпилились вместе с uwsgi.например у меня в каждом django-проекте лежит nginx.conf и uwsgi.ini
в основном nginx.conf прописывается:
include /server/apps/*/nginx.conf;а при запуске uwsgi в режиме emperor:
newrelic-admin run-program uwsgi --emperor="/server/apps/*/uwsgi.ini:production"это упрощенно а так-то у меня и для emperor .ini файлик есть с настройками и для вассалов всякие по умолчанию настройки.
По сути nginx ищет свои конфиги в /server/apps/любое имя проекта/nginx.conf — конкретно ищет nginx.conf
и тоже-самое с uwsgi
Еще в плане сравнения uWSGI c Gunicorn — Gunicorn не умеет сервить Ruby, PHP, Perl и другие проекты, а uWSGI легко.
chdir = /path/to/your/projectто ниже не стоит лишний раз прописывать пути, можно просто добавить %(chdir) вместо "/path/to/your/project":
socket = %(chdir)/mysite.sockтак-же можно назвать uwsgi.ini с именем проекта project.ini и в конфиге %n будет означать имя файла конфига до расширения то есть project
я все-же чаще называю его uwsgi.ini, но имя проекта чтобы не писать постоянно просто берется из имени директории в которой лежит файл конфига — %c
Подробнее смотреть тут.
Например у меня в конфиге сокет так прописан:
socket = %d%c.uwsgi.sock— %d полный путь до папки в которой лежит конфиг, %c имя директории проекта.Тоже самое с
module = %c.wsgiчасто у меня в конфиге uWSGI несколько секций, одна общая откуда другие при необходимости берут эти общие дефолтные настройки типа:
а ниже например могут быть секции типа таких:
или:
тут например видно что в местах
ini = :uwsgiini = :staticfilesподхватывается конфиг из других секций.
py-autoreload = 2— отличная штука — uWSGI автоматом перезагружается при разработке как и джанговский девелопмент сервер после изменения файлов.так-же при разработке или например на хероку можно использовать что-то типа:
Тут предполагается что папка public лежит в корне проекта, а в ней assets как static и uploads как media
а в settings.py например так:
тогда uWSGI вообще можно использовать без nginx(если есть необходимость) и он вообще вполне сносно раздает статические файлы.
вот например один из моих Procfile:
Тут сразу становится понятно как запускать нужную секцию, в которой вы сделали импорты других нужных вам секций.
Незнаю почему вообще сравнивают uWSGI и Gunicorn. uWSGI намного более функциональный — он может выступать и как замена celery/rq(я через uwsgi spooling и почту рассылаю пачками и другие фоновые задачи выполняются), он может мониторить файлы, папки, как крон работает и много чего еще… отлично ладит с nginx и с кэшем удобно работать. uWSGI и просто как wsgi сервер уже на голову выше Gunicorn, и делает много, надежно, быстро(ну явно быстрее чем Gunicorn), и при этом кушает не так много. А если вспомнить о всех вкусностях которые хранятся в закромах uWSGI то вообще даже и смотреть не хочется на Gunicorn
Я вот немного попиливаю github.com/unbit/django-uwsgi но все с временем проблемы, в планах много всего и многое под разные проекты делалось а выпилить и оформить с доками в ту репу все что-то никак. Еще по теме uwsgi есть django-uwsgi-mail и django-uwsgi-cache
Забыл еще упомянуть что можно вообще весь ваш проект скормить в uwsgi и запускать типа ./myapp --no-site --master --processes 4, там как-раз и понадобится TemplateLoader из django-uwsgi
Я всегда их использую чтобы на Macbook Pro ставить Ubuntu. Вот только плохо что не на всех зеркалах они встречаются…
А так-то есть еще MNPP помимо MAMP
Хорошо что музыкальные файлы можно прослушать, но плохо что не из всех папок(из папки «Mail attachments» мне не удалось послушать музыкальные треки, только скопировав эти-же самые треки в папку «Музыка», появилась возможность их воспроизвести) это можно сделать.
Хотелось бы иметь возможность открывать через этот интерфейс и файлики с расширениями .py, .conf, .ini и другие(ну можно же их открывать тупо как текстовые файлы)
В OS X сейчас шлю уведомления как-то так: