Python a Apache: hosting bezpečně přes WSGI

Adam Štrauch 15. 4. 2009

Pythoní frameworky jsou velmi užitečným pomocníkem při tvorbě webu. Rozšíření ovšem brání nedostupnost hostingových služeb pro Python ve stejné míře, jako je tomu s PHP. Možná je jedním z důvodů také strach z bezpečnosti, a právě v tomhle je kombinace Apache/Python na velmi dobré úrovni. Za vše může WSGI.

Hostování webových aplikací

Když se porozhlédnete po nabídce hostingových služeb, tak je valná většina z nich omezena pouze na PHP a často se jedná o různě zkompilované a zkonfigurované PHP, na kterém buď to či ono. Velmi oblíbené je např. téma Safemode nebo suPHP. Obojí má ovšem buď funkční nebo výkonovou nevýhodu. Někteří na to šli o něco lépe a používají pro své zákazníky FastCGI, které se výkonnostně podobá mod_php a dokáže web udělat i dostatečně bezpečný. Jedná se ovšem o výjimky a většinou na serverech sedí mod_php.

Za posledních několik let se na webu začaly prosazovat i další jazyky. Známé je třeba Ruby s Ruby on Rails nebo Python a Django, případně TurboGears, Cherrypy, Pylon atd. Mé srdce vždy více táhlo k Pythonu, takže jsem se mu v uplynulých měsících také hodně věnovat z pohledu hostování pythonovských webových aplikací.

Prošel jsem přes různé technologie a přes dva webové servery Apache a Lighttpd. O druhém jmenovaném je na Rootu dokonce celý seriál. Apache se nakonec ukázal jako lepší volba už jen pro množství informací a návodů na Internetu, takže jsem asi po roce a půl provozu Lighttpd v kombinaci s FastCGI vyměnil za Apache.

Dlouhou dobu jsem řešil problém, kdy jsem si musel FastCGI nahazovat přes vedlejší skript a hlídat v něm, jestli server běží. To se ukázalo být trochu nespolehlivé. Lighttpd se občas nechytl po restartu aplikace a hlásil chybu 500. Hledal jsem proto řešení, které bude konfigurovatelné pouze u serveru a ze strany aplikace nebude vyžadovat žádné spouštění, nastavování komunikačního kanálu atd.

První pokusy s Apachem dopadaly všelijak, ale nakonec se to ukázalo jako správná volba.

Dobrý den, já jsem WSGI

S WSGI bylo vše najednou jednodušší. Hledal jsem dál a narazil i na výkonnostní testy, které ukázaly, že WSGI dokáže být i velmi rychlé. Rozhodl jsem se na něj navěsit některé aplikace, co mi běží na serveru. Výsledek byl rychlejší než FastCGI. První zkušenosti dopadly dobře.

Začal jsem se pídit po podpoře v pythoních frameworcích a jelikož je WSGI pythonová záležitost, najdeme podporu prakticky ve všech více i méně známých nástrojích včetně samotného Pythonu 3.

Výhody WSGI

  • Rychlost
  • Jednoduchost
  • Embedded a daemon mód

Co to WSGI je

Stejně jako CGI, FastCGI a další *GI je WSGI komunikační protokol mezi webserverem a aplikací. Jak již bylo zmíněno, WSGI je vytvořeno pro Python. Podrobnější informace jsou k nalezení pod PEP 333.

Proč WSGI vzniklo

Dnes je již docela běžné, že všelijaké frameworky můžeme propojit s web serverem všemožnými způsoby. Určitou měrou za to může i WSGI, které umí komunikovat s webserverem i přes jiné *GI a dokonce i mod_python. Jde tedy o velmi univerzální nástroj. Nejefektivnější je ovšem při použití bez wrapperů neboli middleware.

Dřív taková možnost neexistovala a projekty si implementovaly, co chtěly. WSGI bylo navrženo tak, že tyto nedostatky překrývá a řeší tak výše popsaný problém a k tomu přidává jednoduchost a rychlost.

WSGI je dnes již podporováno řadou projektů:

  • CherryPy
  • Django
  • Myghty
  • Nettri
  • notmm
  • Paste WebKit
  • pycoon
  • Pylons
  • QWeb
  • simpleweb
  • skunk.web
  • TurboGears
  • Wareweb
  • web.py
  • WebStack
  • Zope 3

Seznam zahrnuje známé i neznámé projekty, takže cíl se rozhodně splnit podařilo.

Jak to funguje

WSGI aplikace není nic jiného než objekt, který musí přijmout dva parametry, se kterými pracuje jak web server, tak aplikace. Web server se postará o vytvoření objektů a díky tomu se vše dá ovlivnit přes jeho konfigurační soubory.

Mezi webserver a aplikaci lze umístit ještě tzv. middleware. Tak říkáme něčemu, co ovlivňuje procházející data. Pomocí tohoto nástroje se může WSGI chovat jako FastCGI atd.

Daemon vs. embedded mód

WSGI aplikace může běžet ve dvou módech. Je to tzv. embedded mód, při kterém se vše chová podobně jako třeba mod_python, a pak daemon mód, který dokáže zajistit zmíněnou bezpečnost a má i nástroje pro ladění výkonu.

To co se po webových serverech, určených pro mass hosting, již dlouhá léta požaduje, je oddělení jedné běžící aplikace (v tomto případě jednoho webu) od jiného tak, aby měl každý svého uživatele. Pokud všechny skripty běží po stejným uživatelem, mají všechny také přístup ke všem datům. To je u mass hostingu nežádoucí.

WSGI aplikace v režimu daemon bude spuštěna web serverem pod vlastním uživatelem a bude mezi nimi existovat pouze kanál, kterým se budou posílat požadavky od uživatelů a přijímat reakce od aplikace. Díky tomu si můžeme na server vpustit i další uživatele, kteří nemusejí mít stejná oprávnění jako web server. Všechen kód je prováděn uvnitř spuštěného daemona a web server pouze servíruje vygenerovaný obsah na správnou adresu. Nevýhodou jsou vyšší nároky na paměť. Naštěstí WSGI umožňuje nastavit, kolik procesů se má spustit a kolik má mít každý z procesů vláken. Tím můžeme dobře vyladit výkon tak, aby nám vyhovoval a zároveň nevyčerpal veškeré systémové prostředky.

Oproti tomu embedded mód spouští všechen kód uvnitř samotného web serveru a tudíž má i jeho oprávnění. Toto řešení je ovšem úspornější na systémové prostředky.

Konfigurace

Podpora WSGI u serverů není tak dobrá jako u aplikací. Mínus bod zde dávám za absenci WSGI u Lighttpd, které ani ve své verzi 1.5 podporu nemá. Otázkou je, jak moc je to s tímto konceptem vývoje reálné.

Modul s WSGI najdeme např. v serverech Apache a Nginx. Na Linuxu letí více Apache, takže si ukážeme konfiguraci s ním na jednoduchém vhostu.

Daemon mód

<VirtualHost *:80>
    # Základní nastavení
    ServerName domena.cz
    ServerAlias *.domena.cz
    DocumentRoot /cesta/k/aplikaci

    # Nastavení WSGI procesů
    WSGIDaemonProcess mojeaplikace user=uzivatel group=skupina processes=1 threads=2
    # Nastavení skupiny aplikací
    WSGIProcessGroup mojeaplikace
    # Přesměrování požadavků z / na naši aplikaci
    WSGIScriptAlias / /cesta/k/aplikaci/aplikace.wsgi

    # Přístup k adresáři
    <Directory /cesta/k/aplikaci>
        Order deny,allow
        Allow from all
    </Directory>

</VirtualHost> 

Z uvedeného kousku konfiguračního souboru je již jasné, že konfigurace není složitá a poskytuje přesně to, co každý admin potřebuje. Existují i další konfigurační direktivy, které najdeme v dokumentaci.

V příkladu si můžeme určit počet procesů a vláken, vlastníka procesu, název a nakonec nesmíme zapomenou předat cestu k samotné aplikaci. U té se řídíme dokumentací pro daný framework. Níže najdete ukázku pro Django a Cherrypy.

Embedded mód

Pro konfiguraci embedded módu stačí pouze direktiva WSGIScriptAlias.

    WSGIScriptAlias / /cesta/k/aplikaci/ 

V tomto případě budou jako WSGI spuštěný všechny soubory, které z adresáře zavoláme.

Frameworky

Vlastní zkušenost mám pouze s frameworky Django a Cherrypy. Oba WSGI podporují dobře. Pro chod Djanga nám stačí vytvořit si soubor s objektem, se kterým bude WSGI modul ve web serveru pracovat.

widgety

import os, sys
sys.path.append('/cesta/k/projektu')
os.environ['DJANGO_SETTINGS_MODULE'] = 'projekt.settings'

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler() 

V CherryPy to je ještě jednodušší, protože tam je tento objekt rovnou k dispozici, a tak stačí do Apache předat pouze adresu skriptu.

Závěr

WSGI je přesně to, co jsem hledal pro svoje projekty. Šlape velmi stabilně, je dostatečně rychlé, jednoduché a hlavně bezpečné. Bohužel je např. pro Django v dokumentaci doporučeno používat mod_python a WSGI je tlačeno do pozadí.

Odkazy

Našli jste v článku chybu?
120na80.cz: Poslední možnost změnit zdravotní pojišťovnu

Poslední možnost změnit zdravotní pojišťovnu

Podnikatel.cz: EET a účetní programy. Vše hotovo?

EET a účetní programy. Vše hotovo?

Lupa.cz: Cimrman má hry na YouTube i vlastní doodle

Cimrman má hry na YouTube i vlastní doodle

DigiZone.cz: Banaxi: videa kdekoli na světě

Banaxi: videa kdekoli na světě

Lupa.cz: Proč jsou firemní počítače pomalé?

Proč jsou firemní počítače pomalé?

DigiZone.cz: Rapl: seriál, který vás smíří s ČT

Rapl: seriál, který vás smíří s ČT

Vitalia.cz: dTest odhalil ten nejlepší kečup

dTest odhalil ten nejlepší kečup

Vitalia.cz: Tahák, jak vyzrát nad zápachem z úst

Tahák, jak vyzrát nad zápachem z úst

Vitalia.cz: Jsou vegani a vyrábějí nemléko

Jsou vegani a vyrábějí nemléko

DigiZone.cz: DVB-T2 ověřeno: seznam TV zveřejněn

DVB-T2 ověřeno: seznam TV zveřejněn

Vitalia.cz: Tradiční čínská medicína a rakovina

Tradiční čínská medicína a rakovina

Vitalia.cz: 5 chyb, které děláme při skladování potravin

5 chyb, které děláme při skladování potravin

120na80.cz: Galerie: Čínští policisté testují českou minerálku

Galerie: Čínští policisté testují českou minerálku

120na80.cz: Co je padesátkrát sladší než cukr?

Co je padesátkrát sladší než cukr?

Lupa.cz: Blíží se konec Wi-Fi sítí bez hesla?

Blíží se konec Wi-Fi sítí bez hesla?

Podnikatel.cz: ČSSZ posílá přehled o důchodovém kontě

ČSSZ posílá přehled o důchodovém kontě

DigiZone.cz: Technisat připravuje trojici DAB

Technisat připravuje trojici DAB

Lupa.cz: Jak se prodává firma za miliardu?

Jak se prodává firma za miliardu?

DigiZone.cz: Digi Slovakia zařazuje stanice SPI

Digi Slovakia zařazuje stanice SPI

Vitalia.cz: Voda z Vltavy před a po úpravě na pitnou

Voda z Vltavy před a po úpravě na pitnou