nginx – lehkotonážní webserver

5. 8. 2009 | Amy Winston, Mark Stopka | Sítě | 12804×

Spousta z vás jistě používá webový server Apache. Ve chvílích, kdy Apache přestává stíhat, máte v podstatě jen dvě možnosti; buď upgradovat hardware (případně pořídit nějaké load-balancing řešení), nebo zkusit vyměnit težkotonážní Apache za nějaký jiný server, např. nginx. Seznámení s webovým serverem nginx jsme si pro vás v tomto článku připravili.

Představení

nginx (vyslovováno engine x) je lehkotonážní webový server/reverzní proxy vydaný pod licencí BSD. Mimo protokolů http/http(s) zvládá i POP3 a IMAP, takže se ve skutečnosti nejedná jen o webový server. Ale na e-mailové vlastnosti tohoto webového serveru se v článku zaměřovat nebudeme.

Tento webový server umí servírovat veškerý statický obsah (statické HTML, CSS, iso, ...) a určitý typ požadavků směřovat jinam. Nativně webserver neumí PHP, ani Python, Ruby, ... je to jen "hloupá proxy" a webový server pro statický obsah. Avšak důležité je to, že je to i proxy. Pokud si totiž jako pomocníka přivoláme buď FastCGI, nebo jiný webový server (který už mod_php nebo cokoli jiného, po čem toužíme, umí), můžeme nginx použít jako proxy pro servírování tohoto obsahu.

nginx s FastCGI PHP

Na svém serveru ism.m4r3k.org používám FastCGI PHP s nginxem. FastCGI PHP je zhruba stejně rychlé jako mod_php, avšak nese sebou větší paměťový overhead, což však u méně náročných webových prezentací nemusí vůbec vadit. Moje konfigurace vypadá následovně:

user  nginx;
worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

    gzip  on;

    server {
        listen       [::]:80;
        server_name  ism.m4r3k.org;

        location / {
            root   /srv/www/htdocs/ism.m4r3k.org/;
            index  index.html index.htm index.php;
        }

        # redirect server error pages to the static page /50x.html
        error_page   500 502 503 504 50x.html;
        location = /50x.html {
            root   /srv/www/htdocs/ism.m4r3k.org/;
        }

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000

        location ~ \.php$ {
            root           html;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /srv/www/htdocs/ism.m4r3k.org/$fastcgi_script_name;
            include        fastcgi_params;
        }
    }
}

První řádek user říká nginxu, aby po svém startu zahodil rootovská privilegia a začal fungovat pod uživatelem nginx. Start pod uživatelem root je nutný, pokud chcete, aby nginx běžel na portech nižších než 1024, které si může nabindovat jen root.

Řádek worker_processes říká, kolik má běžet procesů pro obsluhu uživatelských požadavků. Každý worker proces může obsloužit takový počet příchozích spojení, jaký je definován konfiguračním řádkem worker_connections. Důvodem pro zvýšení počtu worker procesů může být například využití více jader/procesorů u serveru s SMP, případně snížení latence způsobené blokacemi z I/O. Pokud si chcete spočítat maximální počet spojení, které je v jednu chvíli váš server schopen obsloužit, docílíte toho tím, že vynásobíte počet worker procesů hodnotou worker spojení (worker_processes * worker_connections), v naší konfiguraci je tedy webový server schopen obsloužit maximálně 1024 klientů.

V části konfigurace http načítáme soubor mime.types, který obsahuje přiřazení Content-Type k jednotlivým příponám souborů.

types {
    text/html                             html htm shtml;
    text/css                              css;
    text/xml                              xml;
    image/gif                             gif;
    image/jpeg                            jpeg jpg;
    application/x-javascript              js;
    application/atom+xml                  atom;
    application/rss+xml                   rss;
}

Parametr gzip udává, zda se budou odchozí soubory komprimovat gzipem, nebo ne. V případě zapnuté gzip komprese můžete konfigurační soubor rozšířit o volby:

• gzip_min_length - pouze odpovědi větší než zadaná hodnota budou komprimovány gzipem
• gzip_buffers - velikost bufferů, do kterých bude uložena komprimovaná odpověd; pokud není volba nastavena, použije se velikost stránky, která je v závislosti na platformě 4, nebo 8K
• gzip_types - jaké mime typy se mají komprimovat; ve výchozím nastavení se komprimují jen text/html

Více konfiguračních voleb pro modul gzip najdete v dokumentaci.

Sekce http má podsekci server, ve které už se konfigurují jednotliví virtuální hosté.

Řádek listen [::]:80; určuje, na jakých adresách a portech má nginx nabindovat svůj socket. Uvedená konfigurace nabidnuje nginx na port 80 na všechny IPv4 a IPv6 adresy; parametr listen může obsahovat adresu, na kterou se má server nabindovat, případně port.

• 127.0.0.1 - nabinduje nginx na adresu 127.0.0.1 port 80
• 127.0.0.1:8080 - nabinduje nginx na adresu 127.0.0.1 port 8080
• 443 default ssl - nabinduje nginx na všech IPv4 adresách na port 443 pro https spojení

Konfigurační volba server_name se používá pro named virtual hosty. Z každého příchozího HTTP požadavku se vezme hlavička Host a ta je pak porovnávána se server_name. Při první shodě je požadavek obsloužen podle dané konfigurace. Volba server_name může být klasické jméno ism.m4r3k.org, jméno se žolíkovým znakem (wildcard) na začátku či konci (*.ism.m4r3k.org, ism.m4r3k.*) nebo jméno definované regulárním výrazem. server_name může mít více záznamů, v takovém případě se jednotlivé záznamy oddělují mezerou.

První část location obsahuje pokyny, jak obsloužit všechny HTTP požadavky, volba root určuje cestu k adresáři, kde jsou k nalezení požadovaná data. Na rozdíl od webového serveru Apache nginx nezahazuje matchující se část v location. Budete li tedy chtít mít pro adresář /tmp/ povoleno procházení (autoindexing), musíte vytvořit následující location.

location /tmp/ {
	root /srv/www/htdocs/ism.m4r3k.org/;
	autoindex on;
}

Tato část konfiguračního souboru zajistí, že každý požadavek http://ism.m4r3k.org/tmp/nejaky-soubor.txt bude směřovat do adresáře /srv/www/htdocs/ism.m4r3k.org/tmp/. A pokud se někdo pokusí otevřít http://ism.m4r3k.org/tmp/, tak se mu zobrazí všechny soubory včetně podadresářů, vizte například tuto stránku.

Konfigurační volba error_page slouží k nastavení chování chybových kódů HTTP protokolů. Uvedený řádek error_page 500 502 503 504 50x.html; zajistí, aby byly uvedené chybové kódy 500, 502, 503, 504 přesměrovány na statickou stránku 50x.html. Úplně stejně můžete pracovat i s dalšími kódy jako 404 Not found nebo 403 Forbiden. Případně můžete také zajistit změnu chybového kódu, například pokud místo kódu 404 Not found chcete vracet nějaký soubor s kódem 200 OK, můžete do konfiguračního souboru přidat následující řádek error_page 404 =200 vraceny-soubor.html;.

FastCGI PHP

Jak jsem již řekl, nginx neumí mod_php, jako to dělá Apache, ale umí FastCGI, což je na většinu použití dostatečné. A pokud FastCGI nestačí, může nám na pozadí běžet Apache a nginx dělat k tomuto webserveru jen proxy. O FastCGI PHP se nám stará poslední část uvedeného konfiguračního souboru, tedy ta začínající location ~ \.php$. Znak ~ označuje regulární výraz, který slouží k identifikaci požadavků, jež mají být zpracovávány pomocí FastCGI. Volba fastcgi_pass specifikuje, kam má nginx předávat své požadavky na zpracování. Může se jednat o IP adresu a port jako v mém případě nebo o Unixový socket - zadáte unix:/cesta-k/socketu.socket. Řádek fastcgi_index index.php; říká, jaké má být jméno zpracovávaného souboru, pokud bude uvedená cesta končit znakem lomítka (/). V našem případě se jedná o FastCGI PHP, takže očekáváme v adresáři soubor index.php. Další řádek je fastcgi_param. Ten slouží k nastavování parametrů pro CGI požadavek, který bude odeslán na cíl podle volby fastcgi_pass. V našem příkladu nastavujeme volbu SCRIPT_FILENAME na cestu k samotnémi CGI skriptu, tedy /srv/www/htdocs/prace.m4r3k.org/$fastcgi_script_name. Jak jistě uhádnete, proměnná $fastcgi_script_name obsahuje všechno, co následuje po / v požadavku GET, který webserver obdržel. Pokud tedy bude požadavek GET vypadat takto: GET /scripts/rss.php HTTP/1.1, tak v proměnné $fastcgi_script_name bude cesta scripts/rss.php.

Posledním řádkem načítám soubor /etc/nginx/fastcgi_params, který obsahuje následující parametry pro FastCGI:

fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx;

fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;

fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;

fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;

Nyní, když jsme donutili nginx předávat požadavky na php soubory někam dále, slušelo by se ještě zajistit, aby tyto požadavky i očekávalo něco, co je následně zpracuje - jinak dostaneme chybovou zprávu 502 Bad gateway. Já osobně jsem se inspiroval tím, jak to dělá lighttpd, a použil jsem program spawn-fcgi k tomu, aby mi vytvořil požadovaný počet procesů php-cgi, nabindoval jim sockety a zahodil rootovská privilegia. spawn-fcgi spouštím s následujícími parametry:

/usr/bin/spawn-fcgi -C 10 -a 127.0.0.1 -p 9000 -u nginx -f /usr/bin/php-cgi

Parametr -C udává počet instancí, které mají být spuštěny, -a je adresa, na kterou se má php-cgi nabindovat, -p udává port, na který se bude bindovat, -u udává uživatele, pod kterým se má php-cgi spouštět, a -f udává cestu k binárce, která se má spouštět.

       

Komentáře

[Messa]

Ve chvílích, kdy Apache přestává stíhat

To mi v této oblasti přijde už jako klišé. Apache toho zvládne docela hodně, záleží na konfiguraci, přičemž konfigurace "jeden Apache dělá všechno" není zrovna z nejvýkonnějších. Ale je pravda, že servery jako nginx nebo Lighttpd mají nároky (prostředky OS, CPU i paměť) ještě menší a hlavně mají i jednodušší (nebo prostě jen hezčí) konfiguraci.

je to jen "hloupá proxy"

Ehm, jak vypadá chytrá proxy? Je mi jasné, že pokud něco neumí out-of-the-box nativně PHP, spousta PHP programátorů to bude považovat za nepotřebný balast a proto je třeba je poučit, ale zacházet až tak daleko

Důvodem pro zvýšení počtu worker procesů může být například využití více jader/procesorů u serveru s SMP, případně snížení latence způsobené blokacemi z I/O.

Myšleno je nejspíš diskové I/O, že... Blokující síťové I/O, to by si snad při single-process single-thread architektuře nikdo nedovolil... Vlastně když už jsme u té architektury, jaký že je to ten hlavní rozdíl mezi nginxem a Apachem a proč narozdíl od Apache můžeme s klidným svědomím nechat worker_processes na hodnotě 1? A rozdíl by tu byl ještě jeden

[frEon]

To mi v této oblasti přijde už jako klišé. Apache toho zvládne docela hodně, záleží na konfiguraci, přičemž konfigurace "jeden Apache dělá všechno" není zrovna z nejvýkonnějších. Ale je pravda, že servery jako nginx nebo Lighttpd mají nároky (prostředky OS, CPU i paměť) ještě menší a hlavně mají i jednodušší (nebo prostě jen hezčí) konfiguraci.

Vim o mistech kde apache nestihal a nginx se flaka

Vlastně když už jsme u té architektury, jaký že je to ten hlavní rozdíl mezi nginxem a Apachem a proč narozdíl od Apache můžeme s klidným svědomím nechat worker_processes na hodnotě 1?

epoll/poll/select/rtsignals...

[ByCzech]

>> A rozdíl by tu byl ještě jeden

 

Nesmíte věřit všemu co se kde píše. Tyhle věci se dají nastavovat a zpravidla jsou nastaveny správně, aby se podobné věci neděly.

[sadfdcvsdbv]

V defaultnom nastaveni to funguje na Apache so Suhosinom; aj docela velke obmedzenia sa daju obist tymto utokom.

[Käyttäjä 11133]

Myšleno je nejspíš diskové I/O, že...

Ano, mysleli jsme samozřejmě diskové I/O.

[Lampa]

seberte programatorum .htaccess nebo rewrite, ti budou nadavat

[xfwrwe]

bez .htaccess nepouzitelne

[Käyttäjä 11133]

Ono to umí rewrite, sám mám rewrite na www.m4r3k.org nasazen.

[Jan Molič]

Setkal jsem se už s celou řadou webserverů, které si dávaly za cíl nahradit Apache. Momentálně například používám Lighttpd. Přesto autoři těchto webserverů opomíjejí základní problémy, které brání většímu nasazení alternativních webserverů:

1. jiný formát konfiguračního souboru - osobně bych navrhoval načítací hanismus, který by rozuměl jak vlastnímu konfiguráku, tak formátu httpd.conf
2. uživatelům musí fungovat aspoň základní nastavení v .htaccess - většina lidí používá CMS a vůbec tomu nerozumí; parser .htaccess souvisí s možností načítat formát httpd.conf
3. mod_rewrite - napsat kompatibilní mod_rewrite by nemělo být těžké; tento modul je snad nejdůležitější pro většinu uživatelů Apache

[Jendа]

1. a 3. - proč by měly být tyto webservery kompatibilní s Apachem? Osobně se mi líbí právě proto, že jdou jinou cestou. [stejně jako Linux] Chápu, že možnost načtení konfiguráku konkurence je výhoda, ale osobně už půl roku jedu na pár strojích lighttpd a k apachí konfiguraci bych se už vrátit nechtěl.

2. - ano, to je bohužel blocker

[frEon]

ten nginx ma ngx_http_rewrite_module: http://translate.google.com/translate?hl=en&sl=ru&u= http://sysoev.ru/nginx/docs/http/ngx_http_rewrite_module.html &ei=xVd5StDYA4j5_Aa03LCPBg&sa=X&oi=translate&resnum=1&ct=result&prev=/search%3Fq%3D http://sysoev.ru/nginx/docs/http/ngx_http_rewrite_module.html%26hl%3Den%26client%3Dopera%26rls%3Den%26hs%3DO0I

[Limoto]

Ale je nekompatibilní s Apache. Stejně jako v lighttpd...

[frEon]

ake to snad neni problem, ne? imo dulezity je, ze to nabizi stejnou funkcionalitu

[happy barney]

to poznám v tvare "nechcem windows, ale chcem, aby to bolo ako windows"

[motyq]

btw pryc jsou doby kdy na nginx byla potreba rustina :)
aktualni anglicka wikina je uz velice schopna a vseobjimajici

http://wiki.nginx.org/NginxHttpRewriteModule

[frEon]

pravdu mas, nemoh jsem to v rychlosti najit

[Fluttershy, yay!]

Kdo je to Amy Winston?

[Amy]

To budu asi ja ;)

[Fluttershy, yay!]

Aha, já si říkal, že je to takové typické české jméno. ~_^

[Käyttäjä 11133]

Zhruba stejně typicky české jako Max Devaine (Max).

[Fluttershy, yay!]

Že jo!

[Käyttäjä 11133]

:)

[me]

Chybi mi aspon strucne zduvodneni, proc by jsem mel zkusit nginx  a ne treba lighttpd (ktery je znamejsi). V cem je nginx lespi nez lighttpd?

 

[Brud]

Nebo teba boa ?

Ci jine valstni napsane web servery ?

Uznavam ze apache2 je na lecktere veci tezsi ...

... ale neni to spis o konfiguraci ?

[me]

A proc BOA??

23 Feb 2005 - Version 0.94.14rc21 released!

ten projekt prakticky skoncil... Jak jej muzete porovnavat s lighttpd?

 

[Messa]

To ale neznamená, že by Boa nefungoval Boa je tak trochu legenda, je to webserver s pollovací architekturou snad už od roku 1995. Pamatuju si, že na přednášce o sítích na FELu, když se mluvilo o pollování, říkali tomu "ve stylu Boa".

A nějaký vlastní webserver... o tom snad ani nemá cenu mluvit