Úvod
Nginx je vysoce výkonný webový server, který se používá také jako reverzní proxy, poštovní proxy, nástroj pro vyrovnávání zátěže a HTTP cache. Nginx je bezplatný a open-source, což umožňuje komukoli jej stáhnout a používat ve svém serverovém prostředí.
Možná jste již Nginx použili k provozování webových stránek. V tomto návodu budeme diskutovat o dalších možnostech Nginx. HTTP proxyování schopnost Nginx mu umožňuje předávat požadavky na backendové HTTP servery ke zpracování. S touto funkcí můžete nastavit více backendových serverů. Umožňuje vám škálovat vaši infrastrukturu podle potřeby, abyste zvládli nárůsty klientských požadavků.
Jak budeme v návodu postupovat, dozvíte se o škálování vaší infrastruktury pomocí vyrovnávání zátěže v Nginx, bufferingu a cachování odpovědí pro zlepšení výkonu vašeho serveru a zajištění lepšího zážitku pro klienty. Začněme!
Nejprve se podívejte na náš návod, jak nainstalovat Nginx na váš server Ubuntu.
Obecné informace o proxyování
Pokud se vaše znalosti o webových serverech týkají pouze zpracování požadavků na webové stránky a poskytování webových stránek, možná se ptáte, proč potřebujeme požadavky proxyovat. Níže vysvětlíme důvody, které za tím stojí.
Jedním z důvodů pro proxyování požadavků na jiné servery z Nginx je podpora škálovatelnosti vaší infrastruktury. Nginx ve výchozím nastavení zpracovává mnoho připojení současně. Díky tomu je ideální jako první bod kontaktu pro klienty. Poté může předávat požadavky různým backendovým serverům, které se postarají o samotné zpracování klientských požadavků. To je to, co rozkládá zátěž. Zajišťuje to tedy, že můžete svou infrastrukturu škálovat co nejvíce. Umožňuje vám to také odstavit jiné servery kvůli údržbě, zatímco ostatní nadále vyřizují požadavky.
Druhým důvodem, proč můžete chtít proxyovat požadavky na jiné servery, je situace, kdy používáte aplikační servery, které nejsou vhodné pro přímé zpracování požadavků od klientů v produkčním prostředí. Několik frameworků, včetně webových serverů, není uzpůsobeno pro vysoký výkon jako Nginx. Pokud necháte Nginx jako vstupní bod a budete proxyovat požadavky na tyto servery s nižším výkonem, můžete zajistit, že vaši uživatelé budou mít lepší zkušenost. Navíc to může zaručit vyšší bezpečnost vaší aplikace.
Proces proxyování požadavků v Nginx zahrnuje úpravu požadavku ze serveru Nginx a jeho předání dalším backendovým serverům k samotnému zpracování. Jakmile ostatní backendové servery požadavek zpracují, předají výsledek zpět Nginx. Ten pak odešle výsledek jako odpověď klientovi. Klientem je v tomto případě webový prohlížeč nebo dokonce mobilní webová aplikace. Ostatní backendové servery mohou být lokální servery, které nejsou veřejně přístupné na internetu, vzdálené servery nebo dokonce jiné virtuální servery v rámci konfigurací serverových bloků Nginx. Tyto ostatní servery, na které Nginx proxyuje požadavky, se označují jako upstream servery.
Nginx může proxyovat požadavky na servery, které komunikují pomocí několika protokolů včetně HTTP(S), Memcached, SCGI, FastCGI a uWSGI. Pro každý typ protokolu existují sady direktiv. V tomto návodu se zaměříme na protokol HTTP. Nginx analyzuje požadavky a komponenty zpráv do formátu, který dokáže upstream server interpretovat a zpracovat.
Analýza základního HTTP Proxy Pass
Nejjednodušší typ proxy zahrnuje předání požadavku jedinému serveru, který komunikuje přes HTTP. Tento typ proxy se obecně označuje jako „proxy pass“ a je zpracováván příhodně pojmenovanou direktivou proxy_pass v konfiguračních souborech Nginx.
Direktiva proxy_pass se objevuje v blocích location. Nachází se také v blocích kontextu location a v kontextech limit_except. Když se požadavek shoduje s location, která obsahuje direktivu proxy_pass, požadavek směřuje na URL, kterou direktiva specifikuje. Níže je příklad konfiguračního fragmentu:
|
1 2 3 4 |
listen 80; location / { proxy_pass http://127.0.0.1:3000; } |
Ve výše uvedeném příkladu by požadavky na port 80 směřovaly na localhost:3000:
Výše uvedený snímek obrazovky ukazuje výchozí stránku Nginx, když se pokusíte připojit k localhost. Po restartování serveru Nginx s aktivní direktivou proxy pass budou všechny požadavky směřovat na port 3000. Na portu 3000 běží ukázková aplikace, kterou můžete vidět na obrázku níže a ke které se můžete připojit přímo z localhost bez zadání portu:
V dalším příkladu nebylo na konci serveru v definici proxy_pass specifikováno žádné URI. U definic odpovídajících tomuto vzoru bude URI, které klient požaduje, předáno upstream serveru v nezměněné podobě.
|
1 2 3 |
location /match/url/here { proxy_pass http://example.com; } |
Například když tento blok zpracovává požadavek na /match/url/here, URI požadavku bude odesláno na server example.com jako http://example.com/match/url/here.
Níže je uveden příklad alternativního fragmentu konfigurace:
|
1 2 3 |
location /match/url/here { proxy_pass http://example.com/new/url/prefix; } |
Jak můžete vidět ve výše uvedeném fragmentu, na konci proxy serveru jsme definovali segment URI jako new/url/prefix. Když definujete URI v definici proxy_pass, část požadavku, která odpovídá definici location, je při odesílání na upstream server ke zpracování nahrazena tímto URI.
Například požadavek na /match/url/here na serveru Nginx se předá upstream serveru jako http://example.com/new/url/here. Část /match/url je nahrazena /new/url. Mějte tento bod na paměti.
V některých případech není předávání URI výše uvedeným způsobem možné. V takových případech Nginx ignoruje URI na konci definice proxy_pass. Nakonec se na upstream server předá buď původní URI od klienta, nebo URI, které modifikují jiné direktivy.
Příkladem je situace, kdy regulární výrazy odpovídají bloku location. Nginx nemusí být schopen určit, která část URI odpovídá výrazu. Proto odešle původní URI požadavku klienta. To způsobí přepisování a zpracování URI klienta ve stejném bloku. V takovém případě se předá přepsané URI.
Jak Nginx zpracovává hlavičky?
Hlavičky jsou klíčové pro to, jak server zpracovává požadavek. Některé hlavičky mohou obsahovat autentizační informace. Proto musíme pochopit, jak bude proxy server Nginx hlavičky zpracovávat. Požadavek proxy z Nginx na upstream server bude vypadat jinak než ten, který přišel přímo od klienta. Některé z rozdílů jsou důsledkem hlaviček, které jdou spolu s požadavkem proxy.
Během předávání požadavku (proxying) provede Nginx úpravy hlaviček požadavků, které obdrží od klienta. Mezi tyto úpravy patří:
-
Odstranění všech prázdných hlaviček. Prázdné hlavičky požadavek pouze nafukují, takže nemá smysl je předávat na upstream server.
-
Jakékoli hlavičky obsahující podtržítka jsou ve výchozím nastavení považovány za neplatné, a proto jsou z požadavku odstraněny. Pokud byste chtěli toto chování změnit a povolit Nginx interpretovat hlavičky s podtržítky jako platné, můžete nastavit direktivu underscores_in_headers na „on“. Pokud tak neučiníte, takové hlavičky od klienta se na upstream server nikdy nedostanou.
-
Hlavička „Host“ je přepsána na hodnotu určenou proměnnou $proxy_host. Jedná se o IP adresu nebo název a číslo portu upstream serveru, jak je specifikováno direktivou proxy_pass.
-
Hodnota hlavičky „Connection“ se změní na „close“. Hlavička connection obsahuje informace o konkrétním spojení navázaném mezi dvěma stranami. Když Nginx nastaví její hodnotu na close, signalizuje tím upstream serveru, že spojení bude ukončeno, jakmile bude na původní požadavek odpovězeno, takže by neměl očekávat, že půjde o trvalé spojení.
Zde je několik bodů, které si můžeme povšimnout u výše popsaných úprav hlaviček požadavků proxy:
-
Pokud nechcete, aby byla hlavička předána upstream serveru, pak její nastavení na prázdný řetězec ji z požadavku zcela odstraní.
-
Pokud bude aplikace ve vašem upstream serveru zpracovávat nestandardní hlavičky, ujistěte se, že hlavičky neobsahují podtržítko. Volitelně můžete ve své konfiguraci nastavit direktivu underscores_in_headers na „on“ (platné buď v kontextu výchozí deklarace serveru pro kombinaci IP adresy/portu, nebo v kontextu HTTP). Tím zajistíte, že hlavičky nebudou označeny jako neplatné, a proto budou skutečně předány upstream serveru.
-
Hlavička „Host“ je ve většině situací s proxy servery poměrně důležitá. Ve výchozím nastavení je nastavena na hodnotu $proxy_host, což je proměnná obsahující doménové jméno nebo IP adresu a port získaný ze specifikace proxy_pass. Tato adresa je vybrána ve výchozím nastavení a načtena přímo z informací o připojení. Je to jediná adresa, u které má Nginx záruku, že na ni upstream server odpoví.
Níže jsou uvedeny nejčastější hodnoty pro hlavičku „Host“:
-
$host – proměnná se nastavuje v pořadí priorit podle názvu hostitele ze samotného řádku požadavku, hlavičky „Host“ z požadavku klienta nebo názvu serveru odpovídajícího požadavku.
-
$http_host – proměnná, která nastavuje hlavičku „Host“ na hlavičku „Host“ z požadavku klienta. Hlavičky v požadavku klienta jsou pro Nginx vždy dostupné jako proměnné. Tyto proměnné začínají předponou $http_ a následuje název hlavičky malými písmeny. Zatímco proměnná $http_host bude většinou fungovat bez problémů, pokud v požadavku klienta chybí platná hlavička „Host“, může to vést k selhání předání.
-
$proxy_host – proměnná, která nastavuje hlavičku „Host“ na kombinaci doménového jména nebo IP adresy a portu získanou ze specifikace proxy_pass. Z pohledu Nginx se jedná o výchozí chování, a proto je považováno za bezpečné. Nemusí to však být to, co server potřebuje ke správnému zpracování požadavku.
Většina konfigurací bude zahrnovat nastavení hlavičky „Host“ na proměnnou $host. Je vysoce flexibilní a poskytne upstream serveru přesně vyplněné hlavičky.
Nastavení a úprava hlaviček
Direktiva proxy_set_header nám umožňuje nastavit nebo upravit hlavičky pro proxy připojení. U dříve diskutované hlavičky „Host“ můžeme provést následující úpravy a přidat další hlavičky běžné u proxy požadavků:
|
1 2 3 4 5 6 7 8 |
location /shoda/zde { proxy_set_header HOST $host; proxy_set_header X-Forwarded-Proto $schema; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://example.com/new/prefix; } |
Ve výše uvedeném fragmentu konfigurace nastavujeme hlavičku „Host“ na proměnnou $host, která obsahuje informace o původním požadovaném hostiteli. Hlavičku X-Forwarded-Proto nastavujeme s informacemi o schématu původního požadavku od klienta (může se jednat o požadavek HTTP nebo HTTPS).
Skutečnou IP adresu klienta předáváme do X-Real-IP. To umožňuje upstream serveru činit příslušná rozhodnutí nebo ukládat protokoly na základě IP adresy původu klienta. Hlavička X-Forwarded-For obsahuje seznam všech IP adres patřících serverům, přes které byl klient směrován (proxy), než dosáhl tohoto bodu. Ve výše uvedeném fragmentu kódu ji nastavujeme na proměnnou $proxy_add_x_forwarded_for. Tato proměnná vezme hodnotu původní hlavičky X-Forwarded-For získané od klienta a na konec přidá IP adresu proxy serveru Nginx.
Pokud si přejete, aby se na direktivy proxy_set_header odkazovalo na více než jednom místě (location), můžete je přesunout do kontextu server nebo http. Zvažte níže uvedený fragment konfigurace:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
proxy_set_header HOST $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; location /match/here { proxy_pass http://example.com/new/prefix; } location /different/match { proxy_pass http://example.com; } |
Definování kontextu upstream pro vyvažování zátěže proxy připojení
Až do tohoto bodu jste se seznámili s tím, jak provést jednoduché http proxy na jeden backendový upstream server. Naštěstí s Nginx můžete takovou konfiguraci škálovat definováním fondů backendových serverů, kterým se budou předávat požadavky ke zpracování.
Nginx poskytuje direktivu nazvanou upstream, která se používá k definování fondu serverů. V rámci konfigurace této direktivy musíte specifikovat pouze servery, které jsou schopny zpracovat požadavek klienta. Nginx jako proxy server umožňuje škálování infrastruktury s minimálním úsilím. Direktiva upstream musí být specifikována v rámci kontextu http vaší konfigurace Nginx.
Zde je příklad ukazující direktivu upstream:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
upstream several_backend_hosts { server host1.example.com; server host2.example.com; server host3.example.com; } server { listen 80; server_name example.com; location /proxy-me { proxy_pass http://several_backend_hosts; } } |
Ve výše uvedeném fragmentu konfiguračního kódu jsme definovali kontext upstream s názvem several_backend_hosts. Definovaný název kontextu je nyní k dispozici v rámci proxy_pass. Lze jej použít, jako by se jednalo o běžnou doménu, jak je znázorněno v příkladu. V rámci bloku server předáváme všechny požadavky směřované na example.com/proxy-me/… do fondu, který jsme definovali pomocí direktivy upstream, v tomto případě several_backend_hosts. Hostitel v rámci fondu je pro zpracování příchozích požadavků vybrán na základě konfigurovatelného algoritmu. Ve výchozím nastavení se výběr řídí procesem round-robin (kruhovým) – každý požadavek je postupně směrován na jiného hostitele.
Jak změnit algoritmus vyvažování upstreamu
Jak bylo uvedeno výše, proces výběru se řídí metodou round-robin. V této části si ukážeme, jak můžeme upravit algoritmus vyvažování používaný fondem upstream. Chcete-li upravit algoritmus, zahrňte do kontextu upstream další direktivy nebo příznaky, jak je definováno níže:
-
(round-robin) – pokud není specifikována žádná jiná direktiva pro vyvažování upstreamu, jsou požadavky ve výchozím nastavení předávány každému serveru definovanému v kontextu upstream postupně za sebou.
-
least_conn – tato direktiva instruuje upstream, aby vybral backendový server s nejmenším počtem aktivních připojení. To je užitečné v situacích, kdy připojení k jednomu backendovému serveru mohou trvat delší dobu.
-
hash – tato direktiva je běžná pro proxyování memcached. Připojení jsou předávána backendovým serverům na základě hodnoty náhodně poskytnutého hashovacího klíče. Hodnotou hashovacího klíče mohou být proměnné, text nebo kombinace obojího. hash je shodou okolností jedinou metodou vyvažování, která vyžaduje vstup od uživatelů, jenž slouží jako klíč pro hashování.
-
ip_hash – tato direktiva instruuje upstream, aby distribuoval požadavky na různé servery na základě IP adresy klienta. První tři oktety IP adresy jsou klíčem k určení, který server má požadavek zpracovat. Výhodou této direktivy je, že klienti obvykle pokaždé obdrží stejný server, což zajišťuje konzistenci relace.
Zde je příklad, jak můžeme přidat direktivu algoritmu vyvažování do kontextu upstream:
|
1 2 3 4 5 6 7 8 |
upstream several_backend_hosts { least_conn; server host1.example.com; server host2.example.com; server host3.example.com; } |
Ve výše uvedeném fragmentu kódu vybere Nginx pro zpracování příchozího požadavku kterýkoli ze serverů s nejmenším počtem připojení. Direktiva ip_hash se řídí stejnou syntaxí. Pro direktivu hash musíte zadat klíč podle svého výběru, podle kterého se bude hashovat, zde je příklad:
|
1 2 3 4 5 6 7 8 |
upstream several_backend_hosts { hash $remote_addr$remote_port consistent; server host1.example.com; server host2.example.com; server host3.example.com; } |
Zde použitý hash bude výsledkem IP adresy a portu klienta. Volitelný parametr consistent implementuje algoritmus konzistentního hashování ketama. To zajišťuje minimální dopad na vaši mezipaměť, pokud byste změnili své upstream servery.
Jak specifikovat váhu serveru pro vyvažování
Ve výchozím nastavení mají při deklaraci backendových serverů všechny servery stejnou váhu. Předpokládá se, že každý server má prostředky a schopnosti zvládnout stejné množství zátěže, což samozřejmě závisí na tom, jaký algoritmus vyvažování v kontextu upstream určíte. Chcete-li toto výchocí chování změnit, můžete při deklaraci nastavit každému serveru jinou váhu. Podívejme se na příklad:
|
1 2 3 4 5 |
upstream backend_hosts { server host1.example.com weight=2; server host2.example.com; server host3.example.com; } |
V tomto příkladu obdrží host1.example.com dvakrát větší provoz než ostatní dva servery. Váha každého serveru je ve výchozím nastavení jedna.
Uvolnění backendových serverů pomocí vyrovnávacích pamětí
Při konfiguraci proxy v konfiguraci serveru se můžete obávat dopadu přidání dalších serverů do procesu na výkon. Nginx naštěstí přichází s funkcemi ukládání do vyrovnávací paměti a mezipaměti, které mohou tyto problémy s výkonem pomoci zmírnit.
Rychlost dvou různých připojení jistě ovlivní uživatelský zážitek klienta při proxyování na jiný server:
-
První připojení je od klienta k proxy serveru Nginx.
-
Druhé připojení je z proxy serveru Nginx k backendovému upstream serveru.
Nginx může upravit své chování tak, aby pomohl optimalizovat kterékoli z těchto připojení podle potřeby.
Pokud vyrovnávací paměti odstraníme, data z upstream backendu se začnou přenášet ke klientovi okamžitě na proxy serveru Nginx. Pokud víte, že vaši klienti jsou rychlí, můžete ukládání do vyrovnávací paměti zcela vypnout, abyste zajistili, že se data dostanou ke klientovi dostatečně rychle. Pokud máte vyrovnávací paměti zapnuté, proxy server Nginx dočasně ukládá data odpovědi přijatá z backendového upstream serveru. Poté data odesílá klientovi v závislosti na jeho rychlosti. Jakmile má Nginx odpověď ve svých vyrovnávacích pamětech, může ukončit připojení k backendovému serveru. Poté bude distribuovat data klientovi rychlostí, kterou klient podporuje. Zároveň tím umožňuje backendovému serveru pokračovat ve zpracování dalších příchozích požadavků.
Ve výchozím nastavení bude mít Nginx ukládání do vyrovnávací paměti zapnuté. Je to proto, že nemůžeme znát rychlosti připojení klientů. Klienti mívají různá připojení, která mohou být pomalejší. Níže definujeme různé direktivy, které můžeme specifikovat pro úpravu chování ukládání do vyrovnávací paměti v Nginx. Tyto direktivy lze definovat v kontextech http, server nebo location, nicméně je třeba poznamenat, že direktivy určující velikost se konfigurují pro každý požadavek. Jejich zvýšení nad rámec toho, co je nezbytně nutné, proto může ovlivnit výkon vašeho serveru, pokud existuje příliš mnoho příchozích požadavků klientů. Zde jsou tyto direktivy:
-
proxy_buffering – direktiva, která řídí, zda je buffering aktivní pro konkrétní kontext a podřízené kontexty. Výchozí konfigurace pro proxy_buffering je „on“.
-
proxy_buffer_size – direktiva, která určuje velikost bufferu pro ukládání hlaviček nalezených v odpovědi z backendového serveru. Hlavičky tvoří první část odpovědi z backendového serveru. Buffering těchto hlaviček je oddělený od zbytku odpovědi. Ve výchozím nastavení je nastavená velikost tohoto bufferu stejná jako u proxy_buffers. Pokud jsou však informace v hlavičce malé, můžete velikost nastavit na nižší hodnotu.
-
proxy_buffers – direktiva řídící počet (první argument) a velikost (druhý argument) bufferů pro proxy odpovědi. Výchozí konfigurace určuje 8 bufferů o velikosti rovné jedné paměťové stránce (buď 4k, nebo 8k). Zvýšením počtu bufferů můžete povolit buffering více informací.
-
proxy_max_temp_file_size – direktiva určující maximální velikost dočasného souboru na disku na jeden požadavek. Dočasné soubory se vytvářejí, když je odpověď z upstreamu příliš velká, než aby se vešla do bufferu.
-
proxy_busy_buffers_size – direktiva určující maximální velikost bufferů, které mohou přejít do stavu „připraveno pro klienta“ (client-ready), a jsou tedy obsazené (busy). Klient může číst data pouze z jednoho bufferu současně. Buffery jsou však ve frontě pro odesílání klientovi v dávkách. Úpravou této direktivy můžete určit velikost prostoru bufferu, který může být v tomto stavu.
-
proxy_temp_file_write_size – direktiva určující množství dat, které Nginx zapíše do dočasného souboru najednou, když je odpověď z backendového upstream serveru příliš velká, než aby se vešla do nakonfigurovaných bufferů.
-
proxy_temp_path – direktiva určující cestu k umístění na disku, kam má Nginx ukládat dočasné soubory, pokud je odpověď z upstreamového backend serveru příliš velká, než aby se vešla do nakonfigurovaných bufferů.
Nginx je vysoce přizpůsobitelný a poskytuje několik direktiv pro vyladění chování bufferingu. Ve většině případů budou výchozí hodnoty fungovat naprosto v pořádku. Zároveň je dobré vědět, že některé z těchto hodnot můžete upravit pro svou vlastní implementaci. Nejčastěji budete chtít upravit direktivy proxy_buffers a proxy_buffer_size.
Níže je uveden příklad, který zvyšuje počet dostupných proxy bufferů pro každý upstream požadavek. Činí tak a zároveň snižuje velikost bufferu, který ukládá hlavičky:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
server { proxy_buffering on; proxy_buffer_size 1k; proxy_buffers 24 4k; proxy_busy_buffers_size 8k; proxy_max_temp_file_size 2048m; proxy_temp_file_write_size 32k; location / { proxy_pass http://example.com; } } |
Podívejme se, jak můžete rychlým klientům poskytovat data rychleji úplným vypnutím bufferingu. Pokud se stane, že váš klient není dostatečně rychlý, Nginx automaticky použije buffery. Nejprve však odešle data klientovi, místo aby čekal na fondy bufferů. Tato konfigurace má však nevýhodu. Způsobuje, že připojení k upstream serveru zůstane pro pomalé klienty otevřené, dokud klient nepřijme všechna data odpovědi. Pokud je buffering nastaven na „off“, použije se pouze buffer definovaný direktivou proxy_buffer_size. Zde je ukázka, jak byste specifikovali vypnutí bufferingu:
|
1 2 3 4 5 6 7 8 9 |
server { proxy_buffering off; proxy_buffer_size 4k; location / { proxy_pass http://example.com; } } |
-
Konfigurace vysoce dostupné (HA) infrastruktury (volitelné nastavení)
Do konfigurace proxy serveru Nginx můžete přidat redundantní sadu load balancerů, což zajistí, že bude robustnější, a tedy vysoce dostupná. Nastavení s vysokou dostupností (HA) je infrastruktura bez jediného bodu selhání (single point of failure). Load balancery jsou součástí této konfigurace. S více než jedním load balancerem můžete zabránit potenciálním výpadkům, pokud jeden load balancer selže nebo bude offline kvůli údržbě.
Jak implementovat proxy cache v Nginx pro snížení doby odezvy
V předchozí části jsme probrali, jak pomocí bufferování uvolnit backendové servery, aby mohly zpracovávat více požadavků. Nginx přichází s další funkcí, která nám umožňuje ukládat data odpovědí z backendu do cache. Zcela tak odpadá nutnost připojovat se k upstreamu pro všechny příchozí požadavky.
Implementace proxy cache
Direktiva proxy_cache_path nám umožňuje nastavit cache určením oblasti na disku, která se bude používat pro ukládání proxy obsahu. Direktiva proxy_cache_path se definuje v kontextu http.
Níže uvedený fragment konfiguračního kódu je příkladem toho, jak můžete implementovat systém cachování:
|
1 2 3 4 5 6 |
http { proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=backendcache:8m max_size=50m; proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args"; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; } |
V tomto fragmentu kódu jsme použili direktivu proxy_cache_path k definování adresáře v souborovém systému, který bude obsahovat naši cache. V tomto případě jsme nastavili adresář /var/lib/nginx/cache. Můžete si libovolně definovat cestu k adresáři podle vlastního výběru. Pomocí následujících příkazů vytvořte vybrané adresáře se správnými oprávněními a vlastnictvím:
|
1 2 3 |
sudo mkdir -p /var/lib/nginx/cache sudo chown www-data /var/lib/nginx/cache sudo chmod 700 /var/lib/nginx/cache |
Ve fragmentu kódu parametr levels= určuje organizaci cache. Nginx vytvoří klíč cache hashováním hodnoty klíče (určeného pomocí direktivy proxy_cache_key). Úrovně, které jsme specifikovali (1:2), indikují, že bude vytvořen jednoznakový adresář (tj. poslední znak hashované hodnoty) s dvouznakovým podadresářem (převzatým z dalších dvou znaků od konce hashované hodnoty). Ve většině případů se tím nebudete muset zabývat. Je však dobré vědět, jak to Nginxu pomáhá rychle najít příslušné hodnoty.
Parametr keys_zone= definuje název zóny cache, v našem případě jsme ji pojmenovali backendcache. Zde také definujeme, kolik metadat chceme ukládat. V tomto příkladu ukládáme 8 MB klíčů. Nginx dokáže uložit přibližně 8000 záznamů na každý megabajt. Parametr max_size specifikuje maximální velikost samotných cachovaných dat, v našem příkladu 50 MB.
Všimněte si také použité direktivy proxy_cache_key. Tato direktiva určuje klíč, který použijeme k ukládání cachovaných hodnot. Stejný klíč použijeme ke kontrole, zda požadavek v cache existuje. Tento klíč jsme definovali jako kombinaci schématu (http nebo https), metody požadavku HTTP a vyžadovaného hostitele a URI.
Kromě toho jsme použili direktivu proxy_cache_valid. Tuto direktivu lze zadat vícekrát pro různé stavové kódy. Umožňuje nám určit, jak dlouho se mají hodnoty ukládat v závislosti na stavovém kódu. Ve fragmentu kódu jsme specifikovali 10 minut pro úspěšné kódy a 1 minutu pro odpovědi 404.
Vzhledem k tomu, že jsme nakonfigurovali zónu cache, dalším krokem je uvést konfiguraci v platnost tím, že Nginxu řekneme, kdy má cache použít. Níže je konfigurační fragment ukazující, jak můžeme použití této cache implementovat:
|
1 2 3 4 5 6 7 8 9 |
server { location /proxy-me { proxy_cache backendcache; proxy_cache_bypass $http_cache_control; add_header X-Proxy-Cache $upstream_cache_status; proxy_pass http://backend; } } |
V direktivě proxy_cache jsme specifikovali, že pro tento kontext by měla být použita vyrovnávací paměť (cache zóna) backendcache. Pokud jste v konfiguraci cache zvolili jiný název, zde jej nahradíte. U každého platného záznamu Nginx před předáním požadavku na backendový upstream server zkontroluje cache.
Definujeme direktivu proxy_cache_bypass pro použití proměnné $http_cache_control. Tato proměnná říká serveru, zda má odpovědět verzí z cache, nebo novou, ne-cachovanou verzí prostředku. Správné nastavení této direktivy umožňuje Nginx správně zpracovávat různé typy příchozích požadavků od klientů.
Je také specifikována dodatečná hlavička s názvem X-Proxy-Cache. Tato hlavička má hodnotu proměnné $upstream_cache_status. Poskytuje nám informace o tom, zda požadavek skončil zásahem cache (cache hit), minutím cache (cache miss), nebo zda byla cache explicitně obejita. Takové informace mohou být užitečné pro klienta a klíčové při ladění aplikací.
Důležité body týkající se cachování výsledků
Ačkoli cachování výrazně zlepší výkon vašeho proxy serveru, při implementaci cachování byste měli vzít v úvahu následující:
Jakákoli data související s osobními údaji uživatele by neměla být cachována, aby se předešlo scénářům, kdy jsou data jednoho uživatele viditelná pro jiného uživatele.
Vaše backendové servery by měly zohledňovat všechny dynamické prvky vašeho webu. V naší odpovědi můžeme specifikovat několik hlaviček Cache-Control pro různé účely. Pojďme si je probrat:
-
no-cache – specifikuje, že proxy musí před odesláním odpovědi zkontrolovat, zda se data na backendu nezměnila. To platí pro dynamická a důležitá data. Při každém požadavku se kontroluje hlavička s hashem metadat ETag, a pokud backend vrátí stejnou hodnotu hashe, použije se předchozí hodnota.
-
no-store – specifikuje zákaz cachování pro jakákoli přijatá data, takže každý požadavek půjde na server pro nová data. To je nejbezpečnější pro citlivá data.
-
private – specifikuje, že žádný sdílený prostor cache by neměl data cachovat. Tuto hlavičku můžete použít k určení cachování v prohlížeči uživatele, ale zároveň tím informujete proxy server, aby považoval data za neplatná pro následné požadavky.
-
public – specifikuje veřejnou odpověď a umožňuje cachování v jakémkoli bodě připojení.
Pomocí hlavičky max-age můžete v sekundách určit, jak dlouho má cache vydržet. Různé výše definované hlavičky vám mohou pomoci implementovat cachování a zároveň udržet citlivá data v bezpečí, dynamická data čerstvá a především zlepšit výkon vašeho serveru.
Pokud na vašich backendových serverech běží servery Nginx, můžete v blocích server specifikovat, jak dlouho má být cache platná. Můžete to provést přidáním direktivy expires do konfigurace, jak je znázorněno níže:
|
1 2 3 4 5 6 7 |
location / { expires 59m; } location /check-me { expires -1; } |
První blok umožňuje cachování obsahu po dobu 59 minut, zatímco druhý blok indikuje zákaz cachování. Tato nastavení platí pro možnosti hlaviček Cache-Control, například „no-cache“ pro druhý blok.
K nastavení dalších hodnot můžete použít direktivu add-header:
|
1 2 3 4 |
location /private { expires -1; add_header Cache-Control "no-store"; } |
Závěr
V tomto návodu jsme se seznámili s výkonnými funkcemi Nginx. Nginx je jak webový server, tak především reverzní proxy. Architektura Nginx umožňuje zpracovávat tisíce souběžných připojení. Díky tomu je ideální pro vyvažování zátěže (load balancing). Vzhledem k této architektuře je předávání požadavků na jiné backendové servery ke zpracování poměrně jednoduché.
S vědomostmi z tohoto návodu byste měli být schopni implementovat komplexní proxy servery a nástroje pro vyrovnávání zátěže, a to díky flexibilitě Nginx.
Zde je několik zdrojů, které najdete na našem blogu které vás mohou blíže seznámit s Nginx:
Příjemnou práci!
Komentáře
Zatím žádné komentáře. Buďte první.