ARCHIV

Tři způsoby jak provozovat Python s Lighttpd

Když sem začal přemýšlet o výměně PHP za Python, narazil sem na základní problém, a to jak dotyčnou Python webovku vlastně provozovat a tím pádem jí i psát. Nabízí se v podstatě několik možností, mod_python, CGI, FastCGI a aplikační server. O vybraných možnostech budu psát v následujícím článku, ale o mod_python se jen zmíním.

8.9.2009 00:00 | Ondřej Tůma | Články autora | přečteno 14057×

CGI

Stejně jako libovolná aplikace, i aplikace psané v Pythonu se mohou pouštět přes CGI. Python má pro tyto případy samozřejmě škálu základních  modulů, které ulehčují práci při psaní aplikace pro CGI. Režie serveru je pak zřejmá, aplikace se pouští pokaždé, když je volán Pythoní script z webového serveru. Co dotaz, to jedno spuštění v okamžiku požadavku. Pro malé nezatížené weby, či méně využívané aplikace dostačující. Z vyjmenovaných možností tedy nejnáročnější na systémové prostředky, ale nejméně náročné na konfiguraci.

lighttpd.conf:
server.modules  += ( "mod_cgi" )
static-file.exclude-extensions += (".py")
cgi.assign      = (
	".py"  => "/usr/bin/python",
)

cgi_app.py:
import cgi

def main():
   cgi.test()
   return

main()

mod_python

mod_python je modul do serveru Apache. Pokud přehlédnu, že bych rád provozoval aplikace psané v Pythonu i mimo prostředí serveru Apache, nejlépe na Lighttpd, jde o běžný způsob jak propojit Apache a Python. mod_python se v tomto podobá mod_php, tedy zpřístupňuje některé taje Apache jazyku (Pythonu snad o něco více), a práce vypadá tak, že při požadavku na Pythoní script, prostě server tento script spustí pomocí interpretru v mod_python. Apache tento modul inicializuje při svém spuštění a pak svůj proces forkuje do zásoby. Takže v okamžiku požadavku na takový script je již Python v paměti a jen spustí script (oproti PHP vlastně jen bytecode pokud existuje). Problém je že se mod_python spouští i když to není třeba, což je vlastně důvod, proč například na notebooku vyvíjím aplikace pod malým, nenáročným a výkonným Lighttpd. Tento způsob provozu je tedy o něco výkonnější než CGI, ale jen proto, že se interpretr jazyka spouští dopředu, bez ohledu na to, zda bude využit. Na rozdíl od PHP sem ale nenašel způsob jak například hostovat mod_python genericky, tj bez přidávání jednotlivých aplikací do konfiguračních souborů Apache, i když by to podle některých návodů snad mělo jít.

FastCGI

FastCGI je na tom výrazně lépe. V případě PHP se vlastně interpretr pustí a čeká v paměti, až mu webový server předhodí nějaký ten script ke zpracování. U Pythonu je ale situace o malinko jiná. Nenašel sem způsob, jak provozovat Python v režimu FastCGI stejně jako PHP (i když by to šlo vlastně naprogramovat:)), ale Python se k takovému použití staví čelem. Nejde tedy jen o puštěný interpretr jazyka, ale o celou aplikaci. Aplikace prostě běží v systému pořád, a obsluhuje požadavky webového serveru. Stejně jako u mod_python i zde je problém v případě nějakého mass-hostingu. Na serveru by pak \\\"zbytečně\\\" běželo třeba 1000 aplikací Pythonu současně, ale to je daň za rychlou odezvu \\\"aplikačního serveru\\\". Schválně sem uvedl slova aplikační server, protože v tomto případě jde už opravdu o aplikační server. V žebříčku efektivity řadím tento způsob na až druhé místo proto, že vyžaduje doinstalaci dalších modulů do Pythonu. A způsob provozu FastCGI aplikací v Pythonu je velmi nejednotný a přináší mnoho problémů při rozcházení.

lighttpd.conf:
server.modules  += ( "mod_fastcgi" )
server.error-handler-404 = "flup-fcgi.py"
fastcgi.server             = ( ".py" =>
                               ( "localhost" =>
                                   ( "min-procs" => 1,
                                     "host" => "127.0.0.1",
                                    "port" => 8070
                                   )
                               )
                            )

flup-fcgi.py:
#!/usr/bin/env python

from flup.server.fcgi import WSGIServer

def app(environ, start_response):
   start_response('200 OK', [('Content-Type', 'text/html')])
   yield '<h1>FastCGI Environment</h1>\n'
   yield '<table>\n'
   for k, v in sorted(environ.items()):
       yield '<tr><th>%s</th><td>%s</td></tr>\n' % (k, v)
   yield '</table>\n'
WSGIServer(app, bindAddress=('127.0.0.1',8070),).run()

Aplikační (webový) server

Označení aplikační server je velmi nepřesné, protože to může být i FastCGI. V podstatě jsem ale měl na mysli provoz vlastního webového serveru, naprogramovaného v Pythonu za pomocí standardních modulů. Python nabízí předpřipravený malý webový server, který v podstatě může nahradit celý Lighttpd. Tento server ale neumí sám od sebe řešit mnoho problémů, které řeší opravdové webové servery jako jsou Lighttpd, Apache a další. Samozřejmě můžeme si naprogramovat celý webový server, otázka ale je, zda je to rozumný nápad. V tomto případě se hodí, když tento webový Python server, bude obsluhovat jen logiku aplikace a o zbytek se postará webový server před ním.

Použití je tedy jednoduché, prostě se webový server nakonfiguruje jako proxy server a ten některé požadavky přesměruje na něj. Na žebříčku efektivity dávám první místo, pro snadnost spuštění takového webového serveru a možná a o malinko menší zátěži než u FastCGI. Je ale třeba si uvědomit, že stejně jako i FastCGI, i zde bude každá aplikace v systému spuštěná, ať je využívána nebo ne, a bude čekat na požadavky webového \\\"proxy\\\" serveru před ní. Z hlediska bezpečnostního, je ale takovéto hostování bezpečnější, protože aplikační server může, a je to vhodné, běžet s právy uživatele serveru, nikoli s právy web serveru.

lighttpd.conf:
$HTTP["url"]    !~  ".(png|jpg|jpeg|css|html|htm)" {
   proxy.server        = ( "" =>
                             (
                               ( "host" => "127.0.0.1",
                                 "port" => 8071
                               )
                             )
                            )
}

web-test.py:
#!/usr/bin/python

from wsgiref.simple_server import make_server

def simple_app(environ, start_response):

   status = '200 OK'
   headers = [('Content-type', 'text/html; charset=utf-8')]

   start_response(status, headers)
   
   ret = [("<tr><td>%s:</td><td>%s</td></tr>\n" % (key, value)).encode("utf-8")
          for key, value in environ.items()]
   return ['<h1>Pytho Web Server Test</h1>','<table>'] + ret + ['</table>']

httpd = make_server('', 8071, simple_app)
httpd.serve_forever()

Závěrem

Nijak nechci hodnotit pozici Pythonu u webhostingových firem, i když je zatím velmi oslabená, a je to mima jiného i problematičností konfigurace. Python je ale přeci jen více nízkoúrovňový jazyk než PHP a dokáže si z ledasčem poradit, když to zvládne programátor. Uvedené možnosti nejsou zcela jistě jediné, a určitě existuje i mnoho dalších. Tyto jsou z mého pohledu rozumně schůdné, relativně dobře konfigurovatelné a ještě je mezi nimi na výběr.

Verze pro tisk