Comments 11
Зря вы все из исходников компилите, как потом обновлять планируете? ручками?
И подумайте о структуре проектов, если вы захотите перенести хотя бы один из них на другой сервер вам придется вытаскивать конфиги и окружение сразу с нескольких папок. У себя использую такой подход:
после переноса папки проекта на другой сервер обычно достаточно создать симлинки на конфиги nginx и uwsgi, ну и если нужно то добавить пользователя.
Но у меня не получилось собрать uwsgi-плагин для питона, поэтому пришлось сделать по-другому.apt-get install uwsgi-plugin-python3 uwsgi-plugin-python
И подумайте о структуре проектов, если вы захотите перенести хотя бы один из них на другой сервер вам придется вытаскивать конфиги и окружение сразу с нескольких папок. У себя использую такой подход:
www
--example_proj1
----conf(конфиги nginx,uwsgi)
----logs(логи nginx,uwsgi,django)
----pids(сокет и пидфайл)
----project(файлы джанго проекта)
----static(статика проекта собираемая через collectstatic)
----venv(переносимое виртуальное окружение)
--example_proj2
после переноса папки проекта на другой сервер обычно достаточно создать симлинки на конфиги nginx и uwsgi, ну и если нужно то добавить пользователя.
зачем тащить за собой venv, если есть pip и requirements.txt?
Можно( и нужно) так конечно:) У меня просто руки еще не дошли добавить скрипт который при запуске будет создавать симлинки для конфигов, создавать бд и импортить в нее данные с бекапа, и настраивать venv.
Я тоже не вижу смысла в переносном виртуальном окружении, но бывает такое что на pypi какие-то глюки или еще где-то поэтому для особо приоритетных проектов делаю pybundle(на всякий случай), а некоторые вообще свои собственные pypi поднимают))
Зря вы все из исходников компилите, как потом обновлять планируете? ручками?
Ну, допустим мне надо сразу версию 2.6, 2.7 и 3.3 на одном сервере, насколько я понял проще это собрать из исходников чем поставить из репозиториев. Может я не прав.
> apt-get install uwsgi-plugin-python3 uwsgi-plugin-python
А если нужен плагин для 2.6, 2.7, и 3.3, как их поставить? Похоже, тут не обойтись двумя плагинами: projects.unbit.it/uwsgi/wiki/MultiPython
Структура проектов годная, спасибо.
Для 2,7 и 3,3 ставить прям так:
apt-get install uwsgi-plugin-python3 uwsgi-plugin-python
для 2,6 придется или компилить или распаковать из uwsgi-plugin-python только старой версии(до 12.04 если не ошибаюсь)
Ну а сам питон 2,6 в систему можно добавить из ппа
sudo add-apt-repository ppa:fkrull/deadsnakes
sudo apt-get update
sudo apt-get install python2.6 python2.6-dev
apt-get install uwsgi-plugin-python3 uwsgi-plugin-python
для 2,6 придется или компилить или распаковать из uwsgi-plugin-python только старой версии(до 12.04 если не ошибаюсь)
Ну а сам питон 2,6 в систему можно добавить из ппа
sudo add-apt-repository ppa:fkrull/deadsnakes
sudo apt-get update
sudo apt-get install python2.6 python2.6-dev
Лучше сразу ставить версию из официального репозитория: nginx.org/en/linux_packages.html — uwsgi модуль там есть.Почему nginx-full, а не nginx? В nginx-full уже входит модуль для работы с uwsgi.apt-get install nginx-full
Как-то странно режим Emperor используется))
Можно было иметь всего 1 экземпляр uwsgi а для python2/python3 просто разные виртуальные окружения и у приложений в конфигах прописать например «plugin = python3» а вообще какой питон в вирт окружении стоит такой и подхватится, так что не надо делать разные uwsgi.
А еще у uwsgi конфиг получился слишком длинный и не DRY. Можно было упрощать как-то так:
Насчет сокращений в конфиге итд читайте тут
Я деплою тоже через uWSGI и подключаю еще мониторинг newrelic, и что-то еще…
чтобы работало с uWSGI нужно добавить:
А еще uWSGI умеет брать конфиги не только из .ini файлов а и из json, xml, yaml и других а так-же из базы данных, например:
Тут доки по «считывальщикам конфигов вассалов»
так что раз уж речь зашла о хостинге, то такой вариант с конфигами в бд одним из лучших будет, причем uwsgi следит за изменениями, как только в бд данные вассала меняются он перегружает этого вассала, как из бд вассал удаляется — его процесс тоже убивается ну и как новая запись в бд появляется — стартует новый вассал.
Ну и странно что не воспользовались режимом Tyrant(emperor-tyrant) — который как-раз для таких случаев и предусмотрен, разные пользователи итд)
Можно было иметь всего 1 экземпляр uwsgi а для python2/python3 просто разные виртуальные окружения и у приложений в конфигах прописать например «plugin = python3» а вообще какой питон в вирт окружении стоит такой и подхватится, так что не надо делать разные uwsgi.
А еще у uwsgi конфиг получился слишком длинный и не DRY. Можно было упрощать как-то так:
[uwsgi]
protocol = uwsgi # (protocol = wsgi кстати, а почему не uwsgi?)
socket = /tmp/%n.sock # где %n - имя файла без расширения
chdir = /home/hosting/%n
venv = /home/hosting/.virtualenvs/%n
# не замечал чтобы что-то не подхватывало, ну ладно
pythonpath = %(venv)/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg
# далее по аналогии раз уж такое понадобилось, понятно что %(venv) короче и удобнее чем прописывать сто раз путь.
# с django 1.4 не надо env = DJANGO_SETTINGS_MODULE=settings
module = %n.wsgi # начиная с джанго 1.4 можно так а не django.core.handlers.wsgi:WSGIHandler()
Насчет сокращений в конфиге итд читайте тут
Я деплою тоже через uWSGI и подключаю еще мониторинг newrelic, и что-то еще…
чтобы работало с uWSGI нужно добавить:
enable-threads = true
single-interpreter = true
lazy-apps = true
memory-report = true
А еще uWSGI умеет брать конфиги не только из .ini файлов а и из json, xml, yaml и других а так-же из базы данных, например:
uwsgi --plugin emperor_mongodb --emperor "mongodb://127.0.0.1:27107,emperor.vassals,{enabled:1}"
или
uwsgi --plugin emperor_pg --emperor "pg://host=127.0.0.1 user=foobar dbname=emperor;SELECT name,config,ts FROM vassals"
Тут доки по «считывальщикам конфигов вассалов»
так что раз уж речь зашла о хостинге, то такой вариант с конфигами в бд одним из лучших будет, причем uwsgi следит за изменениями, как только в бд данные вассала меняются он перегружает этого вассала, как из бд вассал удаляется — его процесс тоже убивается ну и как новая запись в бд появляется — стартует новый вассал.
Ну и странно что не воспользовались режимом Tyrant(emperor-tyrant) — который как-раз для таких случаев и предусмотрен, разные пользователи итд)
Не забываем что через uWSGI можно запускать и Ruby и PHP итд, и он по производительности очень хороший.
Умеет мониторить файлы и директории, система сигналов имеется(мне uwsgi самостоятельно без всяких скриптов шлет в джаббер всякие тревоги), так-же умеет запускать сам различные программы «attach-daemon», может выступать в роли обработчика аналога celery и cron итд итп)) куча функционала.
uwsgi даже может скомпилиться с джангой и вашим приложением внутри в бинарнике))) Очень много всего покрывает.
Для хостинга uwsgi очень неплохой вариант))
Умеет мониторить файлы и директории, система сигналов имеется(мне uwsgi самостоятельно без всяких скриптов шлет в джаббер всякие тревоги), так-же умеет запускать сам различные программы «attach-daemon», может выступать в роли обработчика аналога celery и cron итд итп)) куча функционала.
uwsgi даже может скомпилиться с джангой и вашим приложением внутри в бинарнике))) Очень много всего покрывает.
Для хостинга uwsgi очень неплохой вариант))
Можно было иметь всего 1 экземпляр uwsgi а для python2/python3 просто разные виртуальные окружения и у приложений в конфигах прописать например «plugin = python3» а вообще какой питон в вирт окружении стоит такой и подхватится, так что не надо делать разные uwsgi.
Согласен. Тут я просто смалодушничал, не получилось у меня собрать плагины для uwsgi (ошибки компиляции были), поэтому сделал как сделал. Собственно, в P.S. про это написал.
Вот что получаю при попытке собрать плагин:
Скрытый текст
root@192756:~/uwsgi-1.9.10# /opt/python2.7/bin/python uwsgiconfig.py --plugin plugins/python/ core python27
using profile: buildconf/core.ini
detected include path: ['/usr/lib/gcc/x86_64-linux-gnu/4.6/include', '/usr/local/include', '/usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed', '/usr/include/x86_64-linux-gnu', '/usr/include']
*** uWSGI building and linking plugin plugins/python/ ***
[gcc -pthread] /usr/lib/uwsgi/python27_plugin.so
/usr/bin/ld: /opt/python2.7/lib/python2.7/config/libpython2.7.a(abstract.o): relocation R_X86_64_32S against `_Py_NotImplementedStruct' can not be used when making a shared object; recompile with -fPIC
/opt/python2.7/lib/python2.7/config/libpython2.7.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
*** unable to build python27 plugin ***
Если знаете что с этим делать, буду признателен, мое гугл-фу меня подвело в этой ситуации.
Вариант с конфигами в БД я рассматривал, но отказался: лишняя точка отказа получается: если какая-то беда с постгресом, то и хостинг не поднимется. (Представим что лежит pg и перезапускаем uwsgi). Файлики с конфигами надежнее, на мой взгляд + бекапировать проще, да и поправить если что конфиг руками проще, чем залезть в БД.
Ну и странно что не воспользовались режимом Tyrant(emperor-tyrant)
На сколько я понял, единственное отличие тиран-режима, что он сам проставляет приложению uid и gid, причем uid и gid будут владелец и группа конфигурационного файла. Если пользователи не имеют доступ к редактированию uwsgi-конфигов, то такой режим не обязателен.
> Перелогиниваемся в консоль, чтобы .bashrc загрузился. Теперь у нас должна быть доступна команда mkvirtualenv в консоли.
Не надо никуда перелогиниваться, достаточно выполнить
source /usr/local/bin/virtualenvwrapper.sh
Не надо никуда перелогиниваться, достаточно выполнить
source /usr/local/bin/virtualenvwrapper.sh
Sign up to leave a comment.
Мульти-хостинг django приложений с помощью nginx + uwsgi + virtualenv