.
_______ ________
| | | |
| n | -> site1.com ->| |-->| uwsgi1 |-->| |--> app1 for site1
| g | | | |________| | |
-->| i | -> site2.com ->|->| ________ |-->|--> app2 for site2
| n | | | | | | |
| x | -> site3.com ->| |-->| uwsgi2 |-->| |--> app3 for site3
|_______| |________|
Это примерная общая структура деплоя нескольких питоновских wsgi-приложений.
1) Nginx ставят вперёд в основном для:
a) отдачи статики
b) балансировки нагрузки
Он быстрый, надёжный, статику отдаёт лучше, чем uwsgi, плюс, можно настроить всякие https. Однако, nginx не умеет запускать питоновские приложения. Для этого он проксирует запрос на wsgi-совместимый сервер.
2) В wsgi-сервере запускаются все доступные питоновские приложения. Uwsgi можно довольно гибко конфигурировать, посмотри оф доки. Одной из классных штук является emperor-mode: uwsgi может сканировать папку на наличие конфигов и автоматом подхватывать питоновские приложения. Обычно создаётся 1 папка, а каждое wsgi-приложение просто делает симлинк с конфигом в эту папку.
3) Uwsgi можно запустить как через обычный tcp-сокет, так и через unix-сокет. Что ты выберешь, то и надо будет указывать в конфиге nginx
4) Uwsgi лучше запускать через supervisord. Он позволяет перезапускать приложение при падении, гибко настраивать запуск похожих демонов, перенаправлять stdout/stderr, настраивать переменные окружения и т.д.. Опять же, смтри доки. В конфиге прописываешь, как у тебя будет запускаться uwsgi и какой конфиг/папку с конфигами uwsgi будет читать.
5) Если сервер имеет N ядер, то имеет смысл запустить N-1 штук процессов uwsgi на разных портах/с разными sock-файлами. Тогда nginx сможет балансировать нагрузку между ними. Запускать группу процессов можно либо через супервизор, либо задав настройки в конфиге самого Uwsgi, тут как удобнее. Разница будет лишь в том, что в первом варианте при падении одного uwsgi, остальные будут жить, а во втором случае, перезапустятся все процессы uwsgi (скорее всего).
6) Не надо описывать конфиг каждого uwsgi-сервера в nginx отдельно, для группы есть upstream.
7) Насколько я понимаю, если питоновское приложение 1, то лучше запустить несколько экземпляров uwsgi через супервизор, если их много - запускать несколько штук uwsgi в emperor-mode.
Я точно не помню синтаксис конфигов, но должно получиться что-то похожее на такое:
# Конфиг supervisor:
[program:uwsgi]
numprocs = 3 (для 4-х ядерного серва)
command = uwsgi --emperor /path/to/conf/dir --socket /tmp/uwsgi/uwsgi-%(process_num).sock
Либо так:
# Конфиг uwsgi: /path/to/conf/default.ini
[uwsgi]
socket = /tmp/sockets/uwsgi-%(vassal_name).sock
# Конфиг супервизора
[program:uwsgi]
command = uwsgi --emperor /path/to/conf/dir ----vassals-include path/to/conf/default.ini
В любом случае, всё это дело потом легко добавляется в nginx:
upstream backend {
server localhost:8001; #для tcp-сокетов
server localhost:8002;
server unix:/tmp/uwsgi/uwsgi-1.sock; # для unix-сокетов
server unix:/tmp/uwsgi/uwsgi-2.sock;
}
# А потом просто проксируешь на эту штуку:
server {
location / {
listen 80;
server_name site1.com;
proxy_pass http://backend;
}
}
server {
location / {
listen 80;
server_name site2.com;
proxy_pass http://backend;
}
}
PS Возможно, если количество питоновских приложух сопоставимо с количеством процессоров, то
может будет лучше настроить так: 1 экземпляр uwsgi на 1 приложение. Но я точно не знаю, имеет ли это смысл, надо читать внимательно доки uwsgi и nginx.