Hlavní navigace

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.

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?

15. 5. 2009 10:54

Architekt (neregistrovaný)
Výhodou oproti FastCGI je až několikanásobně větší rychlost.

29. 4. 2009 10:38

Zaujimave na tomto clanku je ze cely cas hovori o mod_wsgi a pritom je v clanku spomenute len WSGI. WSGI je univerzalny standard na interakciu Pythonu s webovym serverom, podobny CGI. mod_wsgi je modul do Apache podporujuci tento standard.
Podnikatel.cz: Podnikatelům dorazí varování od BSA

Podnikatelům dorazí varování od BSA

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

Root.cz: Pinebook: linuxový notebook za 89 dolarů

Pinebook: linuxový notebook za 89 dolarů

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Lupa.cz: Co se dá měřit přes Internet věcí

Co se dá měřit přes Internet věcí

DigiZone.cz: Recenze Westworld: zavraždit a...

Recenze Westworld: zavraždit a...

120na80.cz: Jak oddálit Alzheimera?

Jak oddálit Alzheimera?

Vitalia.cz: Jmenuje se Janina a žije bez cukru

Jmenuje se Janina a žije bez cukru

Lupa.cz: Teletext je „internetem hipsterů“

Teletext je „internetem hipsterů“

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Vitalia.cz: Mondelez stahuje rizikovou čokoládu Milka

Mondelez stahuje rizikovou čokoládu Milka

Měšec.cz: U levneELEKTRO.cz už reklamaci nevyřídíte

U levneELEKTRO.cz už reklamaci nevyřídíte

Vitalia.cz: Říká amoleta - a myslí palačinka

Říká amoleta - a myslí palačinka

Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?

DigiZone.cz: NG natáčí v Praze seriál o Einsteinovi

NG natáčí v Praze seriál o Einsteinovi

DigiZone.cz: ČT má dalšího zástupce v EBU

ČT má dalšího zástupce v EBU

DigiZone.cz: Rádio Šlágr má licenci pro digi vysílání

Rádio Šlágr má licenci pro digi vysílání

Podnikatel.cz: Zavře krám u #EET Malá pokladna a Teeta?

Zavře krám u #EET Malá pokladna a Teeta?

Vitalia.cz: To není kašel! Správná diagnóza zachrání život

To není kašel! Správná diagnóza zachrání život

Vitalia.cz: Spor o mortadelu: podle Lidlu falšovaná nebyla

Spor o mortadelu: podle Lidlu falšovaná nebyla