Пользователь
0,0
рейтинг
16 июня 2014 в 18:04

Разработка → Django на production. uWSGI + nginx. Подробное руководство перевод tutorial

Перед вами руководство по настройке production окружения для Django. Здесь будут описаны необходимые шаги по настройке Django, uWSGI и nginx. Руководство охватывает все три компонента — полный стек серверного ПО для веб-приложений.

Подразумевается, что вы используете Unix-подобную операционную систему и менеджер пакетов, эквивалентный aptitude. Найти эквивалент aptitude почти для любой операционной системы, в том числе и для Mac OS X, для вас не составит никакого труда.

Руководство написно для версий Django 1.4 или выше. Если вы используете более раннюю версию, то вам придется самостоятельно найти wsgi модуль для нее. Также вы заметите, что файловая структура проекта будет немного отличаться от представленной здесь.

Общая идея


Веб-сервер может по запросу отдавать пользователям файлы из своей файловой системы, однако он не может напрямую работать с Djangо приложениями. Веб-серверу нужен интерфейс, который будет запускать Django приложение, передавать ему запрос от пользователя и возвращать ответ.

Для выполнения этих задач был разработан Web Server Gateway Interface — WSGI — стандарт взаимодействия Python программ и веб-сервра.

uWSGI — одна из реализаций WSGI. В этом руководстве мы установим и настроим uWSGI для создания Unix сокета и взаимодействия с веб-сервером по протоколу WSGI.

Полный стек компонентов будет выглядеть следующим образом:
Пользователь <-> Веб-сервер <-> Сокет <-> uwsgi <-> Django

Перед установкой uWSGI


virtualenv


Создадаем и активируем виртуальное окружение для софта, который нам будет необходим (ниже я расскажу, как установить uwsgi глобально):
virtualenv uwsgi-tutorial
cd uwsgi-tutorial
source bin/activate

Django


Устонавливаем Django в наше виртуальное окружение:
pip install Django

Создаем новый проект и переходим в его корневую папку:
django-admin.py startproject mysite
cd mysite

Домен и порт


В этом руководстве мы будем использовать для нашего учебного проекта домен yourserver.com. Вам нужно будет заменить его на собственное доменное имя или IP адрес вашего сервера.

Для получения запросов от пользователей мы будем использовать порт 8000. Вы можете использовать любой другой порт. Я выбрал именно 8000, потому что его использование не приведет к конфликтам с другими задачами, выполняемыми сервером.

Установка и базовая настройка uWSGI


Установка uWSGI в виртуальное окружение


Один из хороших способов установить uWSGI:
pip install uwsgi

Нам понадобятся Python development пакеты. Если вы используете Debian или основнную на Debian операционную систему (например, Ubuntu или Mint), вам нужно установить пакет pythonX.Y-dev, где X.Y — нужная вам версия Python.

Проверка


Создаем файл test.py:
# test.py
def application(env, start_response):
    start_response('200 OK', [('Content-Type','text/html')])
    return [b"Hello World"] # python3
    #return ["Hello World"] # python2

Запускаем uWSGI:
uwsgi --http :8000 --wsgi-file test.py

Опции:
  • http: 8000: используется протокол http и порт 8000
  • wsgi-file test.py: uwsgi загрузит определенный файл (в нашем случае test.py)

В браузере переходим по адресу yourserver.com:8000.
Видим: «Hello, world», значит, мы все сделали правильно и следующие компоненты работают:
Пользователь <-> uWSGI <-> test.py

Проверка работы Django приложения


Теперь сделаем так, чтобы uWSGI работал с Django приложением, а не с файлом test.py.

Проверим, что только что созданный проект mysite запускается на сервере для разработки:
python manage.py runserver 0.0.0.0:8000

Если проект запустился, останавливаем сервер для разработки и запускаем uWSGI следующим образом:
uwsgi --http :8000 --module mysite.wsgi

  • module mysite.wsgi: uwsgi загрузит модуль mysite.wsgi

В браузере переходим по адресу yourserver.com:8000.
Видим стартовую страницу Djangо, значит, мы все сделали правильно и следующие компоненты работают:
Пользователь <-> uWSGI <-> Django


Это нехорошо, что комьютер пользователя на прямую обращается к uWSGI. Между пользователем и uWSGI должен находиться веб-сервер.

Устновка и базовая настройка nginx


Установка и запуск nginx


sudo apt-get install nginx
sudo /etc/init.d/nginx start 

Чтобы проверить, что nginx установлен и запущен, перейдите по адресу yourserver.com:80. Если вы видите сообщение “Welcome to nginx!”, значит, все окей и следующие компоненты работают:
Пользователь <-> Веб-сервер

Если у вас занят восьмидесятый порт, измените конфигурацию nginx так, чтобы он использовал какой-нибудь другой (в этом руководстве nginx будет использовать порт 8000).

Конфигурация nginx для работы с Django


Нам понадобится файл uwsgi_params, который можно взять здесь: github.com/nginx/nginx/blob/master/conf/uwsgi_params.
Скачиваем его в корневую папку нашего проекта.

Создаем файл mysite_nginx.conf:
# mysite_nginx.conf

upstream django {
    # server unix:///path/to/your/mysite/mysite.sock; # взаимодействие с uwsgi через Unix-сокет (мы воспользуемся этим вариантом позже) 
    server 127.0.0.1:8001; # взаимодействие с uwsgi через веб-порт 
}

# конфигурация веб-сервера
server {
    # порт, который будет слушать веб-сервер в ожидании запросов от пользователй
    listen      8000;
    # доменное имя
    server_name     yourserver.com; # замените на собственный домен или IP адрес
    charset     utf-8;

    # максимальный размер загружаемых на сервер данных
    client_max_body_size 75M;  

    # обслуживание медиа файлов и статики
    location /media  {
        alias /path/to/your/mysite/media;  # расположение медиафайлов (при необходимости измените)
    }

    location /static {
        alias /path/to/your/mysite/static;  # расположение статики (при необходимости измените)

    }

    # Остальные запросы перенаправляются в Django приложение
    location / {
        uwsgi_pass  django;
        include     /path/to/your/mysite/uwsgi_params; # файл uwsgi_params, который мы только что взяли с github
    }
}

Этот конфигурационный файл указывает nginx, что он должен отдавать пользователям медиа и статик файлы из файловой системы, а все остальные запросы перенаправлять в Django приложение. В больших проектах лучше использовать два сервера: один для обслуживания статик и медиа файлов, а другой для Django приложения. С небольшими, и тем более с учебными проектами, справится и один сервер.

В папке /etc/nginx/sites-enabled создаем ссылку на файл mysite_nginx.conf, чтобы nginx увидел его:
sudo ln -s ~/path/to/your/mysite/mysite_nginx.conf /etc/nginx/sites-enabled/

Статика в одном месте


Перед запуском nginx поместим всю статику в папку static. Для этого добавляем в файл mysite/settings.py следующую строку:
STATIC_ROOT = os.path.join(BASE_DIR, "static/")

И выполняем команду:
python manage.py collectstatic

Проверка осблуживания статики и медиа


Перезапускаем nginx:
sudo /etc/init.d/nginx restart

Помещаем файл с именем, например, media.png в папку /path/to/your/project/project/media.

В браузере переходим по адресу yourserver.com:8000/media/media.png и, если видим наш файл, значит мы все сделали правильно.

nginx + uWSGI + test.py


Настраиваем взаимодействие nginx и test.py через uSWGI.
uwsgi --socket :8001 --wsgi-file test.py

Почти то же самое, что мы сделали недавано, за исключением одной опции:
  • socket :8001: используем протокол uWSGI, порт 8001

Как вы помните, мы сконфигурировали nginx(файл mysite_nginx.conf) для работы с uWSGI через порт 8001.

Если перейти по адресу yourserver.com:8001, то мы ничего не увидим, поскольку браузер использует протокол http, а не uWSGI, однако uWSGI выведет сообщение о попытке соединения в терминал.

Unix сокеты вместо веб-портов


До этого мометна мы использовали сокет, привязанный к TCP порту (я называл его веб-порт), потому что так было проще, но на деле рекомендуется использовать Unix-сокет из-за преимущества в производительности.

Редактируем mysite_nginx.conf следующим образом:
server unix:///path/to/your/mysite/mysite.sock; # взаимодействие с uwsgi через Unix-сокет
# server 127.0.0.1:8001; # взаимодействие с uwsgi через веб-порт 

И перезапускаем nginx:
sudo /etc/init.d/nginx restart

Запускаем uWSGI:
uwsgi --socket mysite.sock --wsgi-file test.py

На этот раз опция socket указывает на файл.
Открываем в браузере yourserver.com:8000/

Если не заработало


Проверьте лог ошибок nginx, скорее всего он находится в файле var/log/nginx/error.log

Если найдете там что-то похожее на
connect() to unix:///path/to/your/mysite/mysite.sock failed (13: Permission denied)

значит есть проблема с правами доступа к файлу mysite.sock. Необходимо сделать так, чтобы nginx имел разрешение на использование этого файла.

Попробуйте запустить uWSGI так:
uwsgi --socket mysite.sock --wsgi-file test.py --chmod-socket=666 #много полномочий

Или так:
uwsgi --socket mysite.sock --wsgi-file test.py --chmod-socket=664 #более разумно


Чтобы проблем с доступом в будущем не было, добавьте вашего пользователя в группу www-data.

Информация, которую uWSGI выводит в терминал, полезна при поиске и исправлении возможных ошибок или неисправностей.

nginx + uWSGI + Django


Запускаем:
uwsgi --socket mysite.sock --module mysite.wsgi --chmod-socket=664

В браузере переходим на yourserver.com:8000/ и видим стартовую страницу Django.
Пользователь <-> Веб-сервер <-> Сокет <-> uwsgi <-> Django

Мы собрали всю цепочку, но настройка еще не закончена, идем дальше.

Конфигурация uWSGI через ini файл


Очень удобно все опции, с которыми мы запускаем uWSGI, указать в ini файле, а при запуске передавать только путь к этому файлу.

Создаем файл mysite_uwsgi.ini:
#mysite_uwsgi.ini 
[uwsgi]

# Настройки, связанные с Django
# Корневая папка проекта (полный путь)
chdir           = /path/to/your/project
# Django wsgi файл
module          = project.wsgi
# полный путь к виртуальному окружению
home            = /path/to/virtualenv

# общие настройки
# master
master          = true
# максимальное количество процессов
processes       = 10
# полный путь к файлу сокета
socket          = /path/to/your/project/mysite.sock
# права доступа к файлу сокета
# chmod-socket    = 664
# очищать окружение от служебных файлов uwsgi по завершению
vacuum          = true

Запускаем uWSGI:
uwsgi --ini mysite_uwsgi.ini

Проверяем. Все работает? Дальше.

Устанавливаем uWSGI глобально


До сих пор uWSGI был установлен в виртуальном окружении. Чтобы была возможность автоматически запускать uWSGI при старте операционной системы, мы установим его глобально.

Деактивируем виртуальное окружение:
deactivate

Устанавливаем uwsgi:
sudo pip install uwsgi
# Или можно установить LTS (с долговременной поддержкой) версию
pip install http://projects.unbit.it/downloads/uwsgi-lts.tar.gz

На вики странице uWSGI описано несколько вариантов установки. Перед тем, как установить uWSGI глобально, вам не помешает определиться с выбором версии и методом установки.

Запусить uWSGI можно той же командой, что и раньше:
uwsgi --ini mysite_uwsgi.ini

Режим Emperor


Если сервер обслуживает несколько проектов, каждый из которых использует uWSGI, то нужно исползовать режим Emperor. В этом режиме uWSGI просматривает папку с конфигурационными файлами и для каждого файла запускает отдельный процесс (вассал).

Если один из конфигурационных файлов будет изменен, uWSGI перезапустит соответствующего вассала.

Создаем папку для конфигурационных файлов:
sudo mkdir /etc/uwsgi
sudo mkdir /etc/uwsgi/vassals

Создаем в ней ссылку на mysite_uwsgi.ini:
sudo ln -s /path/to/your/mysite/mysite_uwsgi.ini /etc/uwsgi/vassals/

Запускаем uWSGI в режиме Emperor:
sudo uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data

Опции:
  • emperor: папка с конфигурациолнными файлами
  • uid: id пользователя, от имени которого будет запущен процесс
  • gid: id группы, от имени которой будет запущен процесс

Проверяем. yourserver.com:8000/

Автоматичесеий запуск uWSGI после загрузки операционной системы


В файл /etc/rc.local, перед строкой “exit 0” добавляем:
/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data

Дело сделано.
Перевод: wiki
Саша Журавлев @88z
карма
13,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (51)

  • 0
    тока не пип инсталл увсги
    а апт-гет инсталл увсги… (ну или йум… как там дальше)
    • +4
      Нет, потому что используется virtualenv.
    • 0
      А pip разве не умеет ставить system-wide?
      • +5
        pip умеет, но вот этого как раз лучше не делать. Для системного софта — системный менеджер пакетов.
    • 0
      Нет. Именно pip глобально. В пакетах обычно довольно старая версия.
      • +1
        Нет. Если версия в пакетах не устраивает, собираем актуальную в пакет и его ставим. Никакого глобального пипа.
        • 0
          Оч хороший вариант. Я иногда и целые джанго проекты запихивал в .deb-ки и деплоил через apt)
          Еще как вариант установить uwsgi в какое-то отдельное виртуальное окружение и просто оттуда его вызывать /path/to/virtualenv/bin/uwsgi или с помощью github.com/jsvine/envplus который может одно вирт окруж комбинировать с другими. У меня например есть окружение со всем связанным с postgresql там и psycopg2 и всякие django-hstore итд, и я чтобы при разработке не ставить все лишний раз в новое окружение просто прописываю envplus add имя_нужного_окружения(ну естественно я заблаговременно подготовил несколько тематических окружений по разным нуждам и систематически обновляю в них пакеты)
  • +5
    Мне вот другое интересно, а насколько сейчас актуально uWSGI? Последнее время везде вижу Django + Gunicorn. И всё это управляется через supervisor.

    В чём принципиальная разница между этими двумя подходами, что работает эффективнее и т. п.?
    • 0
      Гуглил тесты — по ним uwsgi несколько быстрее получается. С другой стороны, gunicorn отдает готовый http, и если статику вынести на s3 или в cdn, то на веб-воркере можно вообще без nginx обойтись.
      • 0
        Нельзя. Gunicorn плохо предназначен для того, чтобы смотреть в мир, и в итоге вы получите Apache со всеми его проблемами.
        • 0
          Не «в мир», а на лоад-балансер, скорее. Правда, nginx на балансере так же может проксировать запросы и на uwsgi, так что это и правда так себе аргумент.
      • 0
        Так uwsgi тоже сам умеет по http разговаривать. Ичо?

        gunicorn уже починил проблему межденных соединений (когда ответ tcp тянут по одному байту в пол-часа, чем забивают всех имеющихся воркеров и получают dos)?
        • 0
          Выше обсудили уже — да, совсем наружу этот 80 порт выставить все равно не получится.
    • +3
      Спорный вопрос. uWSGI emperior мне показался более удобным в плане деплоймента. Принципиальная разница в том между nginx и uwsgi демоном данные уже обработаные бегают отсюда небольшой выигрыш.
  • +2
    Запускать лучше специально сделанной для этого тулзой типа supervisor-а.

    Еще есть мнение, что процессы в uwsgi работают не очень хорошо, и лучше руками запускать Х процессов uwsgi, а балансировку делать nginx-ом.
    • 0
      Полностью поддерживаю вариант с supervisor. 2 года в проде на этой схеме.
  • 0
    Ага, так и готовлю джанго сайты уже много лет: nginx + uwsgi
    Вот тут скрипт, который с нуля конфигурит пустой debian под связку nginx + uwsgi + django: bitbucket.org/lorien/django-server/src/tip/install.sh
  • 0
    Я бы таки рекомендовал Gunicorn вместо uWSGI, как более простое и стабильное решение.
    • 0
      Огромный плюс uWSGI в том, что его можно использовать для развёртывания приложений как Python/WSGI, так и Ruby/rack, а также PHP и многих других. Причём uWSGI предоставляет богатые средства интеграции этих веб-приложений, конфигурирования их в общем стиле и т.д. В общем, проект амбициозный, с очень широким функционалом, рекомендую почитать документацию.
      • 0
        Рекомендую почитать исходники uWSGI. ;)
  • 0
    Использую похожую связку, только в ней присутствует ещё и supervisor
  • +4
    так как у вас в 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
    


    а ниже например могут быть секции типа таких:
    [stats]
    stats = %d%c.uwsgi.stats.sock
    stats = :1717
    [cache]
    cache = 1000
    cache-blocksize = 65536
    


    или:
    [development]
    print = Hello I'm the %x config for %c django project %X!
    ini = :uwsgi
    ini = :staticfiles
    procname-master = [uWSGI Master for %c app Dev]
    procname = [uWSGI Worker for %c app Dev]
    socket = %d%c.uwsgi.sock
    module = %c.wsgi
    logto = %dlogs/%c.uwsgi.%x.log
    py-autoreload = 2
    


    тут например видно что в местах
    ini = :uwsgi
    ini = :staticfiles
    подхватывается конфиг из других секций.

    py-autoreload = 2 — отличная штука — uWSGI автоматом перезагружается при разработке как и джанговский девелопмент сервер после изменения файлов.

    так-же при разработке или например на хероку можно использовать что-то типа:
    [staticfiles]
    static-map2 = /assets=%dpublic
    static-map2 = /uploads=%dpublic
    

    Тут предполагается что папка public лежит в корне проекта, а в ней assets как static и uploads как media
    а в settings.py например так:
    STATIC_URL = '/assets/'
    STATIC_ROOT = cd('public/assets')
    MEDIA_URL = '/uploads/'
    MEDIA_ROOT = cd('public/uploads')
    

    тогда uWSGI вообще можно использовать без nginx(если есть необходимость) и он вообще вполне сносно раздает статические файлы.

    вот например один из моих Procfile:
    web: newrelic-admin run-program uwsgi uwsgi.ini:development
    ws: newrelic-admin run-program uwsgi uwsgi.ini:websocket
    

    Тут сразу становится понятно как запускать нужную секцию, в которой вы сделали импорты других нужных вам секций.

    Незнаю почему вообще сравнивают 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
    • +2
      Забыл упомянуть про 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 легко.
      • 0
        А nginx.conf и uwsgi.ini конкретно проекта находятся в его репе или вы их отдельно кладёте в проект? Интересует, насколько это удобно/гиморно держать конфиги веб-сервера в репе проекта.
        • 0
          Конфиги nginx.conf и uwsgi.ini касающиеся проекта лежат в репе с проектом конечно если проект изначально заточен под полное взаимодействие с nginx и uwsgi(например кеширование и многое другое там прописано и у каждого проекта могут быть нюансы к примеру какой-то проект может использовать что-то типа django-nginx-image)
          Посмотрите на репозиторий проекта rtfd.org — там вообще вроде как немеряно конфигов nginx валяется, если что-то не изменилось.
          • 0
            А вот такой пример. У нас куча проектов, запущенных через emperor mode. Мы хотим временно остановить какой-нибудь проект. Что делать? Я обычно просто убираю ini файл в каталог disabled, но у меня все uwsgi ini файлы сайтов в одном месте лежат. А если эти ini файлы будут в репозиториях, получается, эта операция будет затрагивать репозиторий.
            • 0
              Ну тут все зависит от конкретного проекта и причин почему его нужно остановить. Так-то способов остановить конкретного вассала не мало)
              Вообще по-хорошему так бд и файлопомойка должны быть вообще на другом сервере а проект который нужно именно остановить (а не перезапустить или еще что-то) бы вообще оттуда снести и потом когда надо снова задеплоить из репы и все.
              • 0
                А как можно остановить вассала, без физического удаления конфиг-файла из директории, за которой наблюдает император?
            • +1
              Если у вас есть необходимость останавливать какого-то вассала, а проектов прямо куча, то уже только ради удобства использования я бы советовал вам держать конфиги вассалов например в mongodb или в postgresql. если вассала из бд удалить или пометить неактивным — процессы этого вассала останавливаются, при добавлении в бд нового вассала или если пометить его активным — автоматом стартуют. У меня в планах было сделать простенькую админку для таких целей в рамках django-uwsgi чтобы через нее можно было править конфиги и перегружать вассалов и поддерживать все возможные способы чтения конфигов у uwsgi
              P.S. все равно считаю что хранить конфиги в репе очень желательно, при деплое например их использовать или нет — дело десятое, но хотябы в качестве примера работающего если вдруг срочно надо будет составить конфиг под конкретно этот проект а сисадмина или кого-то еще рядом нет…
              • 0
                Скопипастил конфиг из репы, ввел имя конфига и расширение и заполнил другие поля, в бд сохранил и процессы вассала запустились.
              • 0
                Так вроде бы уже сделано:
                """
                Django-uWSGI Features:
                Admin page with uWSGI stats (options to reload/stop uWSGI, clear uWSGI cache)
                """

                (сам ещё не пробовал)
                • 0
                  Так там просто выводится статистика именно того uwsgi под которым работает эта админка. Там грубо говоря просто статистика и возможность перегрузить а нет возможности создать нового вассала или поменять его конфиг.
                  Выше же я имел ввиду сделать что-то типа админки для управления сразу всеми вассалами — типа что-то типа панели хостера например, где ты видишь все запущенные вассалы и можешь ими рулить.
    • 0
      Одно время пользовался spooler. Не устроило например что по touch-reload процесс spooler так же рестартует и если в этот момент выполнялась какая-то фоновая задача — её выполнение прерывалось. Как поменять поведение не нашел (если это вообще было возможно).
    • 0
      Спасибо, добрый человек, за это:

      uid = user
      gid = user
      chown-socket = www-data:www-data
      


      Целый день мучился, искал информацию о том, как uWSGI запустить от рядового пользователя, чтобы nginx с ним взаимодействовал через сокет.

      Получал ошибку:

      attempt to write a readonly database
      
  • 0
    Почему все мануалы на эту тему забывают --plugin python --plugin http?

    Или это исключительно особенности новой убунты, что плагины не цепляются итз коробки?
    • +2
      а потому что по умолчанию uwsgi уже собирается с этими модулями и не нужно ничего прописывать.
      если вы пробовали ту uwsgi которая ставится через apt — так там модульная сборка которая расчитана на легковесность(только в конфиге подключаются нужные модули и они уже отдельными файлами лежат например в папке plugins а не встроены в бинарнике uwsgi). я всегда ставлю uwsgi через pip, а если нужен какой-то особенный профиль сборки просто подставляю нужные параметры например: UWSGI_PROFILE=gevent pip install uwsgi тогда uwsgi установится сразу еще и с плагином gevent и его не надо прописывать как plugin а просто сразу в конфиге использовать. Если ставить uwsgi через pip там же после установки указано какие плагины скомпилились вместе с uwsgi.
    • +1
      Тут можно посмотреть на конфиги разных профилей))
  • +1
    Кто-нибудь кроме меня запускает uWSGI через upstart? Без supervisor / uWSGI Emperor…
    • +1
      Я запускаю чаще через upstart в том числе с Emperor
  • –2
    рекомендуется использовать Unix-сокет из-за преимущества в производительности.

    мифического преимущества. датаграммы проигрывают tcp из-за дропов в очереди и отсутствии бэклога принятия соединений, а тут ещё и даже вопрос не ставится об увеличении длины очереди датаграмм
    • 0
      Unix-сокет != датаграммы

      Вы всё напутали.
      • 0
        Бес попутал, простите.
        Очереди приёма соединений всё равно так и нет.
        • +1
          Да ладно, как же без очереди соединения то с одного сокета разбирать: net.core.somaxconn!? =)
          У unix-сокетов нет syn-бэклога (tcp_max_syn_backlog), по очевидным причинам. Ну так оно им и не нужно.
  • 0
    [deleted]
  • 0
    А как сделать чтобы в конце порт не нужно было прописывать?
    То есть чтобы сайт был доступен не по:
    http://yourserver.com:8000/
    А по:
    http://yourserver.com/

    Спасибо.
    • 0
      Вместо 8000 используйте порт 80.
  • 0
    Дошел до момента с запуском через «ini» файл. Последний удачный запуск через «socket» удается только с правами «666» вот так:
    uwsgi --socket mysite.sock --module mysite.wsgi --chmod-socket=666
    Пытаюсь запустить через ini файл:
    uwsgi --ini mysite_uwsgi.ini
    и выдает ошибку:
    ...
    current working directory: /home/user/.virtualenvs/uwsgi-tutorial/mysite
    detected binary path: /home/user/.virtualenvs/uwsgi-tutorial/bin/uwsgi
    chdir(): No such file or directory [core/uwsgi.c line 2537]
    chdir(): No such file or directory [core/uwsgi.c line 1565]

    В чем может быть проблема? Конфиг такой:
    [uwsgi]
    plugins = python27
    harakiri = 60
    chdir = /home/user/.virtualenv/uwsgi-tutorial/mysite/
    module = %(chdir)/mysite.wsgi
    home = /home/user/.virtualenv/
    socket = %(chdir)/mysite.sock
    master = true
    processes = 10
    vacuum = true
    uid = www-data
    gid = www-data
    chmod-socket = 666
    chown-socket = www-data:www-data
    [development]
    py-autoreload = 2
    • 0
      Поясните, почему у вас в сообщении uwsgi — /home/user/.virtualenvs/uwsgi-tutorial, а в конфиге — /home/user/.virtualenv/uwsgi-tutorial (без s)? Может быть, в этом дело? Какой путь на самом деле?

      Во-вторых, возможно, у вас уже есть файл %(chdir)/mysite.sock? От какого пользователя вы запускаете указанную команду, кто является владельцем %(chdir) (и какие на ней права)?

      Ну и я ещё не понимаю, зачем вам этот virtualenv прятать. У меня они называются по смыслу проектов, для которых сделаны, или по набору софта в виртуалэнве: ~/py32d16, например, а там python3.2 и установлена django 1.6.

      Схему, подобную описанной в топике, применил ещё задолго до его описания, в то время и django 1.4 только выходил. uwsgi у меня запускается от имени того пользователя, чей это homе, т.е. конфиг имеет вид
      [uwsgi]
      chdir = /home/merlin/ac1532.office.rterm.ru
      socket = %(chdir)/ac1532.uwsgi
      plugin = python32
      pyhome = /home/merlin/django15python32
      module = ac1532.wsgi
      chmod = 666
      master = 1
      workers = 8
      cheaper = 2
      idle = 30
      procname-master = uWSGI master
      procname-prefix-spaced = ac1532
      logfile-chown = 1
      daemonize = %(chdir)/logs/uwsgi_log
      pidfile = %(chdir)/ac1532.pid
      vacuum = 1
      uid = merlin
      gid = merlin

      это работает из uwsgi emperor, в котором включен режим тирана и он таким образом запускает мастер-процесс с этим ini-файлом от имени merlin:merlin.
      • 0
        Спасибо, во всем разобрался. По мимо ошибок в путях были еше проблемы с правами.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.