Найти - Пользователи
Полная версия: nginx + cherryd непонятки
Начало » Web » nginx + cherryd непонятки
1
emissary
Доброго всем времени суток.

Решил попробывать python как язык для web. Начитавшись умных статей и полазив по форумам понял в какую сторону копать.

Выбор пал на nginx фронтендом и тот самый быстрый сервер из cherrypy wsgi бекендом. Далее по порядку - установил nginx и cherrypy, обнаружил cherryd, попробывал запустить - все пошло норм, в консоль вывалилось что запустился он на порту 8080. Прописал правила проксирования в конфиге nginx, даже написал init скрипт для cherryd =), а дальше…

Тут видно сработали стереотипы, полученные от програмирования на php. Начал искать какое-нибудь подобие document_root у cherryd, чтобы попробывать положить туда чтонибудь вроде
def app(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return ['Hello World!\n']
nginx добросовесно проксировал, а firebug вываливал 404 ошибки.

2 дня втыкал в гугл и cherrypy.org, потом начали закрадываться нехорошие мысли что, просто одиноко лежащий файлик (скрипт) не подсунешь работающему бекэнду, он его не обработает и не отдаст результат.

написал test.py с import cherrypy и cherrypy.quickstart(), сервер запустился, http://localhost плюнул hello world

подумал, а зачем не cherrypy? ведь нужен же только сам сервер

на этом и остановился


собственно вот в этом и вопрос?

возможна ли работа подобной связки в привычном ( по крайней мере для меня ) понимании, вроде того что есть в /server/www куча файлов, статику отдает сам nginx, а например index.py с чистым wsgi ( как в примере выше) скриптом передает бекэнду, который в свою очередь его обрабатывает и возвращает?

Или бекэнд это и есть работающий скрипт? зачем тогда отдельный cherryd? какой толк от его запуска?

если что написано сумбурно, извиняйте, 2 сутки из головы не лезет это…

заранее спасибо за просветление)
slav0nic
в связи с отсутствием mod_wsgi и текучестью flup - вполне можно, я когда-то наткнулся на баг джанга + lighttpd и тоже запускал бекенд на чеии (да и до сих пор запускается)
в принципе у черри неплохой static server, для среднестатистического сайта должно хватить (это я к тому, что nginx можно убрать)

кстати
nulld4y:~# curl -I python.su
HTTP/1.1 200 OK
Vary: Cookie
Content-Type: text/html; charset=utf-8
Date: Wed, 09 Sep 2009 13:20:09 GMT
Server: CherryPy/3.1.1 WSGI Server
B]

имхо у черри 1 недостаток - отсутствие fork mode, но это вроде можно сделать через bus
emissary
а что собственно делает cherryd, когда получает например GET /index.py ?
slav0nic
в нашем случае передаёт его джанге через wsgi )
а вообще на главной странице cherrypy есть пример кода ;)
если ты пользуешься cherryd - то ему надо передавать конфиг сайта
emissary
slav0nic
в нашем случае передаёт его джанге через wsgi )
Нету у меня джанги еще=) хотелось поставить и написать что-то для примера, например как <? echo “hello world” ?> в пыхе, и собственно разобраться в том как оно работает )

Собственно, вот к чему я пришел на данный момент=)

1. Скрипты - это миф=) бекэнд ,в моем случае, это программа написаная на питоне с модулем cherrypy.wsgiserver, которыя принимает http запросы и обрабатывает их встроеными в нее функциями, а не интерпретирует python код и выдает результат, как я думал изначально.

2. из cherrypy при добавлении в тело программы import cherrypy и cherrypy.quickstart() я использую только функции и классы из …/wsgiserver/__init__.py

3. весь написаный мной код интерпретируется сразу, и висит сервером…

4. cherrypy.wsgiserver и мой скрипт становятся единым байт-кодом после запуска скрипта, и ошибки в моем коде могут повлеч падения всего демона.

Я нигде не ошибся?)
slav0nic
1) смотря какой скрипт, если ты пишешь для cherrypy - то оно будет работаьт только на нём, но на чери есть wsgiserver, который может запускать любые “скрипты” с поддержкой wsgi (в том числе и фреймворки аля django, pylons и тп). TurboGears раньше тоже юзал cherry
2) есть сервер wsgi есть сервер черри, первое занимает где-то 1.5к строк - остальное больше)
3)не обязательно, посмотри как работает mod_wsgi, хотя тут есть доля правды: при запуске скрипта через fcgi, scgi, flup (хрень содержащая всякие адаптеры для этих протоколов) запускает некий сервер Fcgi -> WSGI -> твой_код. В общем да, висит и ест память, но не обязательно является web-сервером
4) нет, вылетит эксепшн на странице, сервер не упадёт

в общем питон не php - тут нет такого, что в директорию кидают кучу скриптов *.py и делают по ним запросы (разве что если юзать CGI, но это прошлый век)
ты просто начал с изучения питона по вебсерверу (cherrypy), глянь webpy тотже, может проще будет понять, ну а потом уже читай про django, pylons etc
emissary
slav0nic
в общем питон не php - тут нет такого, что в директорию кидают кучу скриптов *.py и делают по ним запросы (разве что если юзать CGI, но это прошлый век)
ты просто начал с изучения питона по вебсерверу (cherrypy), глянь webpy тотже, может проще будет понять, ну а потом уже читай про django, pylons etc
Спасибо огромное за ответы. Теперь хоть ясно куда копать дальше)
ZioN
slav0nic
ты просто начал с изучения питона по вебсерверу (cherrypy), глянь webpy тотже, может проще будет понять, ну а потом уже читай про django, pylons etc
С webpy у него возможно и отвращение появится :) и окончательно сломает мозг, особенно при работе с шаблонами.

emissary
возможна ли работа подобной связки в привычном ( по крайней мере для меня ) понимании, вроде того что есть в /server/www куча файлов, статику отдает сам nginx, а например index.py с чистым wsgi ( как в примере выше) скриптом передает бекэнду, который в свою очередь его обрабатывает и возвращает?
В wsgi как у нормального приложения есть точка входа, в которое передаются “аргументы” (environ - http://www.python.org/dev/peps/pep-0333/#environ-variables ) в зависимости от этих данных ты и строишь ответ серверу.


emissary
Или бекэнд это и есть работающий скрипт? зачем тогда отдельный cherryd? какой толк от его запуска?
“cherryd” и есть веб сервер (точнее часть его, в твоем случае) предназначенный только для работы с протоколом wsgi, который ты “проксируешь” nginx`ом.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB