V blízké budoucnosti mě čeká převzetí administrace jednoho serveříku hostujícího cca stovku webů. Přesněji řečeno, čeká mě převzetí hostovaných dat a nastavení zbrusu nového serveru. Ten současný totiž funguje na Windows Serveru 2008, jedná se o klasický WAMP a na jeho konfiguraci a ladění se zvysoka se*e. V plánu je odstěhovat to všechno na nějakou pořádnou mašinu a sloučit s tou hrstkou webů, které hostuji já. A protože jsem, jako správný admin, hrozně líný, rád bych, aby mi to všechno běželo na prostředí, které se dá snadno poskládat z dostupných .deb balíčků v oficiálních repozitářích. Zjistil jsem však, že mé požadavky není schopen dokonale uspokojit žádný HTTP server.

Startovní pozice

Netajím se tím, že mé nároky jsou docela vysoké. Bezpodmínečně potřebuji, aby můj server dokázal obsluhovat

• Virtual hosty. (Ono se zdá, že vhosts podporují všichni, ale zdání někdy klame)
• CGI skripty (tj. perl). CGI je sice nebezpečné a fuj, ale mám tu pár aplikací, které jej bezpodmínečně potřebují, protože se s jeho pomocí vybavují s cizími platebními servery. Navíc budu moci použít dynamické generování stránek AWStats.
• FastCGI, protože PHP je civilizační choroba, které se nedá zbavit. Ideální by pro mě bylo, aby se bez problémů bavil s PHP-FPM, protože to je alespoň trochu použitelné.
• WSGI, protože má nová láska - Pyramid framework - si jej žádá. Podobně jako u PHP bych preferoval komunikaci s uWSGI kontejnerem před přímým spouštěním WSGI aplikací.

A pak několik méně potřebných, ale stále důležitých fíčur

• SSL/TLS, úplně super by bylo, kdyby podporoval i SNI.
• Streaming FLV. Na několika webech mám FLVčka sypaná přímo po HTTP. Sice na serveru mám i RTSP/RTMP server, který by byl schopen proudění FLV obsloužit, ale byl by to pro mě krok zpátky.
• IPv6, protože jej mám rád, pár mých klientů jej využívá a ten /64 IPv6 subnet, který k housingu dostanu, by byla škoda nevyužít.
• Traffic shaping, tedy třeba limitování počtu spojů na jednu IP adresu nebo nastavení maximální rychlosti downloadu.

Jelikož se už nějaký pátek kolem podobných middlewarových záležitostí pohybuji, rozhodoval jsem se mezi starým známým a mnou nenáviděným Apachem, mým oblíbeným lighttpd a nginxem a po pár dnech drbání se s konfigurací jsem v úvahu ještě přibral pro mě méně známý cherokee.

Připravit! Pozor! Teď!

Apache nemám rád přesně kvůli tomu, kvůli čemu je ostatními milován. Je robustní, bezpečný a existuje do něj spousta modulů. To pro mě tedy znamená, že je nechutně rozežraný, co se systémových prostředků týče, neohrabaný a pomalý. Bytostně nesnáším jeho preforkovací model. Samozřejmě chápu, jaké benefity přináší a souhlasím s tím, že při spouštění kočkopsů s příponou .php je potřeba držet si je co nejdále od těla a zároveň ohlídat, aby nenadělali moc velkou paseku, ale zrovna tenhle způsob se mi moc nelíbí. Apache naštěstí kromě preforku nabízí i další multi-processing moduly, které se mi zamlouvají více. Konkrétně event a worker. Filozofie workerů je totiž podobná jako u ostatních „rychlých“ C10k problem resistentních serverů. Oproti preforku má worker při zpracovávání požadavků menší overhead a taky sežere méně systémových prostředků. Sice se jej nedoporučuje používat ve spojení s mod_php5, ale to mě netrápí, protože já chci PHP dráždit pomocí PHP-FPM naslouchajícím na unixovém socketu, takže bych použil mod_fastcgi. Co se týče dalších požadavků, vyhovuje všem až na FLV streamování. To je však možno doplácnout vlastnoručně kompilovaným modulem nebo použitím různých rovnáků na vohejbáky psaných v perlu nebo PHP. Ani z jedné varianty nejsem příliš nadšen, ale když by nebylo zbytí, asi bych ten modul byl schopen překousnout.

Lehká váha

Momentálně používám na drtivé většině webserverů lighttpd. Mám jej rád, dobře se mi konfiguruje, umí všechno, co jsem dosud potřeboval. Teď by se mi ale navíc hodilo, aby lighttpd šéfovalo i WSGI aplikacím nebo komunikovalo s uWSGI kontejnerem. To však lighttpd v oficiálních repozitářích neumí. Návody na stránkách lighttpd radí WSGI aplikace lámat přes lua skript a SCGI, což teda rozhodně odmítám dělat. V repozitáři pak existuje balíček uwsgi-extra, který obsahuje zdrojáky uWSGI modulů pro lighttpd a nginx, takže si je můžete přilepit ke zdrojákům lighttpd a rekompilovat si jej. To se mi nechce. Lighttpd má ovšem ještě jednu vadu na kráse. Podporuje sice virtuální hosty, ale záměrně neumožňuje „virtualizovat“ error log. Tvůrci se hájí tím, že je možno zaznamenávat chyby přímo z FastCGI, což je sice pravda, ale důvod k odmítnutí implementace něčeho, co všechny ostatní servery nabízí a co uživatelé chtějí, to určitě není.

Stroj X

Nginx, oproti lighttpd, vhost-based error logy nabízí. Dokonce i s uWSGI si rozumí a integrace WSGI aplikace nezabere více než pět řádků v konfiguračním souboru. Stejně tak chodí perfektně i s PHP-FPM a umí všechno co bych si přál. Tedy téměř všechno. Protože bych to měl moc jednoduché, tak pro jistotu nepodporuje CGI. Podle nginx wiki proto, že jsou CGI skripty příliš nebezpečné a radí je zabalit do FastCGI a obsluhovat přes socket. Stejně jako v případě WSGI pro lighttpd, děkuji, nechci. Nginx je ale perfektní proxy. S minimálním úsilím je přes něj možno propasírovat data téměř kamkoliv a proto druhým doporučeným postupem pro servírování CGI obsahu skrze nginx je použít jiný HTTP server, který se s CGI baví a CGI požadavky mu předávat. Podle nginx wiki je takový vhodný maličký sekundární server třeba thttpd s malým patchem, který je ale v repozitářích Debianu a Ubuntu obsažen. Není to sice úplně ideální, ale nemusím nic rekompilovat, takže budu mít pořádek v balíčcích a budu schopen instalaci snadno reprodukovat na jiném systému.

Indiáni trochu jinak

Při mém divokém googlení řešení výše popsaných úskalí jsem tu a tam zavadil o nějaký link popisující nastavení jakéhosi cherokee web serveru. Tak jsem jej vyzkoušel a nestačil se divit. Cherokee umí vše, co potřebuju a jako bonus přihodí konfigurační GUI. To mě napřed trochu vyděsilo, protože se mi ze začátku zdálo až příliš komplexní. Ovšem bez čtení jakýchkoliv manuálů, tipů nebo wikin jsem se s ním během deseti minut skamarádil a bez problémů v něm replikoval pár testovacích webů. GUI je v některých situacích trochu těžkopádné, ale v případě, že jej ovládá někdo méně zkušený, kontroluje a hlásí některé chyby a vůbec se snaží být nápomocné. Nevýhodou je pak téměř nečitelný konfigurák s poznámkou

NOTE: This file is NOT meant to be edited by hand.

Robustnost cherokee se také znatelně projevuje na jeho rychlosti. Při servírování dynamického obsahu je o malinko pomalejší a rozežranější než lighttpd nebo nginx, což bych ještě přežil, ale při obsluhování statických souborů jeho rychlost „padá“ na úroveň Apache. Slovo „padá“ je v uvozovkách, protože rychlost ve skutečnosti nepadá a je vyšší než při obsluhování dynamického obsahu, ale lighttpd a nginx jsou na statických souborech tak zatraceně rychlí, že Apache nechávají daleko vzadu a cherokee někde na půli cesty.

Cílová rovinka

A kdo tedy moji soutěž vyhrál? Apache to nebyl a dostává ode mě bramborovou medaili. Mám k němu předsudky a použil bych jej jen, kdyby mi opravdu nic jiného nezbývalo. Lighttpd jsem používal doteď a měl jej celkem rád, ale absence nastavení logování chyb „per vhost“ a neúplná podpora WSGI jej ve světle nových rozhodnutí staví na třetí příčku. V souboji o vítěze tedy zůstal nginx a cherokee. Cherokee je fajn a umí toho spoustu. Jeho GUI je zajímavá přednost na poli HTTP serverů, díky které vypadá jako opravdový full-featured aplikační server, ale zároveň kvůli němu mám obrovský strach z nekonzistence konfigurace. Kdyby na novém serveru bylo totiž GUI, hrozilo by, že se o jeho administraci budou pokoušet i méně zkušení „spoluadmini“ a to by nemuselo dopadnout úplně dobře. Konfigurák je prostě konfigurák. Jeden soubor pro jednoho virtual hosta, ve kterém mám vše na jednom místě a nemusím nikam zběsile překlikávat. Ze svých logů jsem pak vyčetl, že požadavků na statický obsah je zhruba osmkrát více než požadavků na obsah dynamický. Cherokee tedy získává krásné druhé místo s příslibem, že pokud se mi prostředí s nginxem bude jevit jako nestabilní nebo nebezpečné, přijdu si pro něj.