Nginx? Qëllimi, veçoritë, opsionet e cilësimeve - këto janë gjëra që çdo zhvillues i uebit duhet t'i njohë për të testuar punën e tyre.

Le të themi një fjalë për nginx

Ky mjet ka një proces kryesor dhe disa punëtor. E para ka të bëjë me leximin dhe kontrollimin e konfigurimit. Menaxhimi i procesit të punës është gjithashtu nën kontrollin e tij. Detyra e këtij të fundit është të përpunojë kërkesat e ardhura. Nginx përdor një model të bazuar në ngjarje. Mekanizmat e varur nga sistemi operativ për të arritur shpërndarje efikase të kërkesave drejtpërdrejt ndërmjet proceseve të punëtorëve. Numri i tyre tregohet gjithmonë në skedari i konfigurimit. Vlera mund të fiksohet ose të vendoset automatikisht, bazuar në numrin bërthamat e procesorit, me të cilin mund të punoni. Në nginx, sistemi dhe modulet konfigurohen duke përdorur një skedar konfigurimi. Prandaj, nëse keni nevojë të ndryshoni diçka, atëherë duhet ta kërkoni atë. Zakonisht ndodhet në direktivën /etc/nginx (por shtegu mund të ndryshojë kur përdorni sisteme të tjera) dhe ka një shtrirje .conf.

Nisja, rinisja dhe regjistrat

Për ta bërë këtë, ju duhet të bëni që skedari i ekzekutueshëm të funksionojë. Konfigurimi i serverit nginx është i mundur vetëm kur ai po funksionon. Kontrollohet duke telefonuar skedari i ekzekutueshëm me parametrin -s. Për ta bërë këtë, përdorni shënimin e mëposhtëm:

sinjal nginx -s

NË në këtë rast Ju mund të zëvendësoni komandat e mëposhtme (duhet të vijnë nga përdoruesi që ka nisur mjetin):

1. Ndalo. Përdoret për të mbyllur shpejt punën.
2. Ringarkoj. Komanda është e nevojshme për të ringarkuar skedarin e konfigurimit. Çështja është se asnjë ndryshim nuk do të zbatohet ndërsa skedari është duke u ekzekutuar. Dhe që ato të hyjnë në fuqi, është e nevojshme një rindezje. Sapo të merret ky sinjal, procesi kryesor do të fillojë të kontrollojë korrektësinë e sintaksës së skedarit të konfigurimit dhe të përpiqet të zbatojë udhëzimet atje. Nëse dështon, do të rikthejë ndryshimet dhe do të punojë me cilësimet e vjetra. Nëse gjithçka ndodhi me sukses, atëherë proceset e reja të punëtorëve do të nisin, dhe atyre të vjetra do t'u dërgohet një kërkesë për të përfunduar.
3. Hiq dorë. Përdoret për përfundimin pa probleme të punës. Përdoret nëse duhet të prisni derisa kërkesat aktuale të përfundojnë shërbimin.
4. Rihap. Mbyllni dhe hapni skedarët e regjistrit.

Përdorimi i shërbimeve

Proceset gjithashtu mund të konfigurohen duke përdorur veglat Unix (veprimtaria kill do të konsiderohet si shembull). Ata zakonisht përdorin një mekanizëm për të dërguar një sinjal në proces drejtpërdrejt me të dhëna. Ata janë të lidhur duke përdorur ID. Këto të dhëna ruhen në skedarin nginx.pid. Le të themi se jemi të interesuar për procesin nr.134. Pastaj për përfundimin e qetë, duhet të dërgojmë informacionin e mëposhtëm:

kill -s QUIT 1628

Le të themi se duam të shohim një listë të të gjithë skedarëve të ekzekutuar. Ne përdorim programin ps për këtë. Komanda do të duket si kjo:

ps -ax | grep nginx

Kjo do të thotë, siç mund ta shihni, kur përdorni mjete shtesë, tregohet se po përdoret. Tani le të përqendrohemi në mënyrën se si bëhet konfigurimi i nginx.

Struktura e skedarit të konfigurimit

Instalimi dhe konfigurimi i nginx përfshin punën me module. Ato janë konfiguruar duke përdorur direktivat që janë të specifikuara në skedarin e konfigurimit. Ato janë të thjeshta dhe të bllokuara. Lloji i parë i direktivës përbëhet nga një emër dhe parametra, të cilët ndahen me hapësira dhe përfundojnë me një pikëpresje (;). Blloku ka një strukturë të ngjashme. Por në këtë direktivë, në vend të një përfundimi, vendoset një grup udhëzime shtesë, të cilat vendosen në mbajtëse kaçurrelë ((udhëzime)). Nëse ato mund të përmbajnë emrat dhe parametrat e proceseve të tjera, atëherë ndërtime të tilla quhen kontekst. Shembujt përfshijnë http, vendndodhjen dhe serverin.

Shërbyer përmbajtje statike

Kjo është një nga detyrat më të rëndësishme me të cilat përballet konfigurimi i nginx. Me shpërndarjen e përmbajtjes statistikore nënkuptojmë imazhe dhe faqe HTML (jo dinamike). Le të themi se na duhet një punë një herë për të ngritur një grup nix nginx. A është e vështirë të bëhet? Jo, dhe le të shohim një shembull. Para fillimit të tij, është e nevojshme të detajoni kushtet e detyrës. Pra, në varësi të kërkesave, skedarët do të vijnë nga drejtori të ndryshme lokale. Pra, në /data/www kemi dokumente HTML. Dhe drejtoria /data/images përmban imazhe. Vendosja optimale nginx në këtë rast kërkon redaktimin e skedarit të konfigurimit, në të cilin duhet të konfiguroni bllokun e serverit brenda http. Dy lokacione do të përdoren gjithashtu për mbështetje.

Implementimi: server

Pra, së pari duhet të krijojmë vetë drejtoritë dhe të vendosim skedarë në to zgjerimet e nevojshme(ju duhet të shtoni përmbajtje në html). Pastaj hapni skedarin e konfigurimit. Si parazgjedhje, ai tashmë përmban disa blloqe serveri, të cilët kryesisht komentohen. Për të arritur rezultate optimale, ky proces duhet të bëhet për të gjithë komponentët e paracaktuar. Pastaj shtojmë një bllok të ri serveri duke përdorur kodin e mëposhtëm:

Skedari i konfigurimit mund të funksionojë me disa blloqe të tilla. Por ato duhet të ndryshojnë në emrat e tyre dhe portet përmes të cilave merren të dhënat.

Zbatimi: vendndodhja

Përcaktuar brenda serverit:

Prania e shenjës "/" është e nevojshme për të krahasuar të dhënat e marra dhe për të parë nëse një adresë e tillë nga kërkesa e përpunuar është këtu. Nëse nuk ka probleme, atëherë specifikoni shtegun /data/www te skedari i kërkuar, çfarë është në këtë sistemi lokal. Nëse ka një ndeshje me disa blloqe, atëherë zgjidhet ai me prefiksin më të gjatë. Në shembullin e dhënë, gjatësia e tij është e barabartë me një, domethënë do të përdoret ekskluzivisht nëse nuk ka "konkurrent". Tani le ta përmirësojmë:

vendndodhja /imazhet/ (

Si mund ta dalloni nëse po kërkojmë imazhe? Tani le të kombinojmë të gjitha zhvillimet që janë bërë më parë dhe konfigurimin ky moment si në vazhdim:

vendndodhja /imazhet/ (

Ky është një opsion pune, i cili është standard.Ky server mund të aksesohet në kompjuterin lokal pa asnjë problem nëse shkoni në adresën: http://localhost/. Si do të funksionojë e gjithë kjo?

Si funksionon shembulli

Pra, kur mbërrijnë kërkesat që fillojnë me /images, serveri do t'i dërgojë përdoruesit skedarë nga drejtoria përkatëse. Nëse mungon, informacioni që tregon një gabim 404 do të transmetohet. Nëse nginx është konfiguruar në një kompjuter lokal, atëherë kur të kërkojmë http://localhost/images/example.png do të marrim një skedar, vendndodhja e të cilit është /data/images/ shembull.png. Nëse specifikoni një karakter "/", kërkimi do të kryhet në drejtorinë /data/www. Por ne thjesht ndryshuam konfigurimin. Që të fillojë të funksionojë, duhet të rindizet. Për ta bërë këtë, përdorni komandën nginx -s reload. Në rastin kur funksionimin normal nuk është e mundur, atëherë mund të kërkoni shkakun e problemit në skedarët error.log dhe access.log të vendosura në direktivën /usr/local/nginx/logs.

Krijimi i një serveri të thjeshtë proxy

Dikush mund të thotë në lidhje me nginx - vendosja e këtij objekti është një nga përdorimet e zakonshme (dhe mjaft e lehtë, meqë ra fjala). Ai përdor parimin e një serveri që pranon kërkesat dhe më pas i ridrejton ato në faqet e nevojshme. Pas kësaj pritet një përgjigje prej tyre, e cila i drejton tek ai që ka caktuar detyrën. Pra, le të shohim një shembull të krijimit të një pike bazë. Ai do të trajtojë kërkesat e përdoruesve dhe do t'u sigurojë atyre imazhe nga drejtoria lokale. Pra, në bllokun http ne shtojmë një server tjetër me përmbajtjen e mëposhtme:

Tani më lejoni ta deshifroj për ju: po krijohet një server i thjeshtë. Ai do të dëgjojë. Nëse nuk e specifikoni listen, serveri do të funksionojë në 80. Të gjitha kërkesat brenda zonës lokale do të shfaqen sistemi i skedarëve, të cilat drejtohen në drejtorinë /data/up1 (natyrisht, do të duhet të krijohet para kësaj). Për të qenë në gjendje ta kontrolloni atë, duhet të vendosni skedarin index.html atje. Duke vendosur direktivën rrënjësore në kontekstin e serverit, ne mund të përdorim vendndodhjen në çdo kusht (pasi kjo heq kufizimet e aksesit). Tani po punojmë në krijimin e një serveri proxy. Që të funksionojë, na duhet direktiva proxy_pass, për të cilën protokolli, emri dhe porta e objektit do të specifikohen si parametra (nëse lidhje lokale do të duket si http://localhost:8080). Do të merrni rezultatin e mëposhtëm:

proxy_pass http://localhost:8080;

vendndodhja /imazhet/ (

Nëse shikoni kodin dhe e analizoni atë, mund të vëreni se blloku i vendndodhjes së dytë është ndryshuar. Pra, në këtë rast mund të funksionojë me shtesa tipike të imazhit. Mund të shfaqet pak më ndryshe si kjo:

vendndodhja ~ \.(gif|jpg|png)$ (

rrënjë / të dhëna / imazhe;

Konfigurimi përfundimtar i serverit proxy duket si ky:

proxy_pass http://localhost:8080/;

vendndodhja ~ \.(gif|jpg|png)$ (

rrënjë / të dhëna / imazhe;

Ai do të filtrojë pyetjet që përfundojnë me shtesat e specifikuara, dhe dërgojini tek personi që i ka kërkuar dosjet. Mos harroni se nëse doni të kontrolloni skedarin e konfigurimit, do t'ju duhet ta rifreskoni atë. Dhe më besoni, ky është konfigurimi më i thjeshtë i nginx. Nëse hapni skedarin e konfigurimit të serverit të VKontakte ose një kompanie tjetër të madhe, ata do të kenë më shumë kod sesa fjalë në këtë artikull.

Dhe të tjerët). Versioni aktual,0.6.x, konsiderohet e qëndrueshme për sa i përket besueshmërisë, dhe lëshimet nga dega 0.7 konsiderohen të paqëndrueshme. Është e rëndësishme të theksohet se funksionaliteti i disa moduleve do të ndryshojë, si rezultat i të cilave mund të ndryshojnë edhe direktivat, prandaj përputhshmëria e prapambetur në nginx para versionit 1.0.0 nuk është i garantuar.

Pse është nginx kaq i mirë dhe pse administratorët e projekteve me ngarkesë të lartë e duan atë kaq shumë? Pse të mos përdorni vetëm Apache?

Pse Apache është i keq?

Së pari duhet të shpjegojmë se si funksionojnë në përgjithësi. serverët e rrjetit. Ata që janë të njohur me programimin e rrjetit e dinë se ekzistojnë në thelb tre modele të funksionimit të serverit:

1. Konsistente. Serveri hap një prizë dëgjimi dhe pret që të shfaqet një lidhje (është në gjendje të bllokuar gjatë pritjes). Kur arrin një lidhje, serveri e përpunon atë në të njëjtin kontekst, mbyll lidhjen dhe pret përsëri lidhjen. Natyrisht, kjo është larg nga mënyra më e mirë, veçanërisht kur puna me një klient kërkon shumë kohë dhe ka shumë lidhje. Përveç kësaj, modeli serik ka shumë më tepër disavantazhe (për shembull, pamundësia për të përdorur shumë procesorë), dhe në kushte reale praktikisht nuk përdoret.
2. Shumëprocesore (me shumë fije). Serveri hap një prizë dëgjimi. Kur arrin një lidhje, ajo e pranon atë, pas së cilës krijon (ose merr nga një grup me të para-krijuara) një proces ose fill të ri që mund të punojë me lidhjen për aq kohë sa dëshiron, dhe pas përfundimit të punës, të përfundojë ose kthehu në pishinë. Ndërkaq, filli kryesor është gati të pranojë një lidhje të re. Kjo është më model popullor, për shkak se është relativisht i lehtë për t'u zbatuar, lejon që të kryhen llogaritje komplekse dhe që kërkojnë kohë për çdo klient dhe përdor të gjithë procesorët në dispozicion. Një shembull i përdorimit të tij - Web- Server Apache. Sidoqoftë, kjo qasje ka edhe disavantazhe: me një numër të madh lidhjesh të njëkohshme, krijohen shumë fije (ose, edhe më keq, procese) dhe sistemi operativ harxhon shumë burime në ndërprerësit e kontekstit. Është veçanërisht e keqe kur klientët janë shumë të ngadaltë në pranimin e përmbajtjes. Kjo rezulton në qindra tema ose procese të ngarkuara vetëm me dërgimin e të dhënave te klientët e ngadaltë, gjë që krijon ngarkesë shtesë në programuesin e OS, rrit numrin e ndërprerjeve dhe konsumon mjaft memorie.
3. Priza jo bllokuese/makinë gjendje. Serveri funksionon brenda një thread të vetëm, por përdor bazat jo-bllokuese dhe një mekanizëm votimi. Ato. server në çdo përsëritje lak i pafund Zgjedh nga të gjitha prizat atë që është gati të marrë/dërgojë të dhëna duke përdorur thirrjen select(). Pasi të zgjidhet priza, serveri i dërgon të dhëna ose i lexon ato, por nuk pret për konfirmim, por shkon në gjendjen fillestare dhe pret një ngjarje në një prizë tjetër ose përpunon atë tjetër në të cilën ndodhi ngjarja gjatë përpunimit të e mëparshme. Ky model përdor procesorin dhe memorien në mënyrë shumë efikase, por është mjaft kompleks për t'u zbatuar. Për më tepër, brenda këtij modeli, përpunimi i ngjarjeve në një prizë duhet të ndodhë shumë shpejt - përndryshe shumë ngjarje do të grumbullohen në radhë dhe përfundimisht do të vërshojnë. Ky është pikërisht modeli mbi të cilin punon nginx. Përveç kësaj, ju lejon të ekzekutoni procese të shumta të punëtorëve (të ashtuquajturit punëtorë), d.m.th. mund të përdorë shumë procesorë.

Pra, imagjinoni situatën e mëposhtme: 200 klientë me një kanal 256 Kbit/s lidhen me një server HTTP me një kanal 1 Gbit/s:

Çfarë ndodh në rastin e Apache? Janë krijuar 200 fije/procese që gjenerojnë përmbajtje relativisht shpejt (kjo mund të jetë diçka si faqe dinamike, dhe skedarët statikë të lexuar nga disku), por ngadalë po ua shpërndajnë klientëve. Sistemi operativ është i detyruar të përballet me një mori fijesh dhe bllokimesh I/O.

Në këtë situatë, Nginx shpenzon një rend të madhësisë më pak burime OS dhe memorie për secilën lidhje. Megjithatë, këtu ka një kufizim modeli i rrjetit nginx: nuk mund të gjenerojë përmbajtje dinamike brenda vetes, sepse kjo do të çojë në bllokime brenda nginx. Natyrisht, ekziston një zgjidhje: nginx mund të proksojë kërkesa të tilla (për gjenerimin e përmbajtjes) në çdo server tjetër në internet (për shembull, i njëjti Apache) ose në një server FastCGI.

Le të shqyrtojmë mekanizmin e funksionimit të kombinimit nginx si serverin "kryesor" dhe Apache si serverin për gjenerimin e përmbajtjes dinamike:

Nginx pranon lidhjen nga klienti dhe lexon të gjithë kërkesën prej tij. Këtu duhet theksuar se derisa nginx nuk e ka lexuar të gjithë kërkesën, nuk e dorëzon atë për “përpunim”. Për shkak të kësaj, pothuajse të gjithë treguesit e përparimit të ngarkimit të skedarëve zakonisht "prihen" - megjithatë, është e mundur t'i rregulloni ato duke përdorur modulin upload_progress të palëve të treta (kjo do të kërkojë modifikim të aplikacionit).

Pasi nginx të ketë lexuar të gjithë përgjigjen, hap një lidhje me Apache. Ky i fundit bën punën e tij (gjeneron përmbajtje dinamike), pas së cilës i dërgon përgjigjen e tij nginx, i cili e ruan atë në memorie ose skedar i përkohshëm. Ndërkohë, Apache po çliron burimet. Më pas, nginx ia dorëzon ngadalë përmbajtjen klientit, ndërsa shpenzon urdhra të madhësisë më pak burime se Apache.

Kjo skemë quhet frontend + backend dhe përdoret shumë shpesh.

Instalimi

Sepse nginx sapo ka filluar të fitojë popullaritet, ka disa probleme me paketat binare, kështu që përgatituni ta përpiloni vetë. Zakonisht nuk ka probleme me këtë, thjesht duhet të lexoni me kujdes daljen e komandës./configure --help dhe zgjidhni opsionet e kompilimit që ju nevojiten, për shembull këto:

./konfiguro\
--prefiksi =/opt/nginx-0.6.x \ # prefiksi i instalimit
--conf-path=/etc/nginx/nginx.conf \ # vendndodhja e skedarit të konfigurimit
—pid-path=/var/run/nginx.pid \ # ... dhe skedari pid
—user=nginx \ # emri i përdoruesit nën të cilin do të ekzekutohet nginx
—me-http_ssl_module —with-http_gzip_static_module —with-http_stub_status_module \ # lista e të kërkuarave
—pa-http_ssi_module —pa-http_userid_module —pa-http_autoindex_module —pa-http_geo_module —pa-http_referer_module —pa-http_memcached_module —pa-http_module_unlimitary ... dhe

Pas konfigurimit, duhet të ekzekutoni standardin make && make install, pas së cilës mund të përdorni nginx.

Përveç kësaj, në Gentoo mund të përdorni një ebuild nga pema standarde e porteve; në RHEL/CentOS nga depoja epel (që përmban nginx 0.6.x) ose srpm për versionin 0.7, i cili mund të shkarkohet nga këtu: http://blogs.mail.ru/community/nginx; në Debian mund të përdorni paketën nginx nga dega e paqëndrueshme.

Skedari i konfigurimit

Skedari i konfigurimit nginx është shumë i përshtatshëm dhe intuitiv. Zakonisht quhet nginx.conf dhe ndodhet në $prefix/conf/ nëse vendndodhja nuk është anashkaluar gjatë përpilimit. Më pëlqen ta vendos në /etc/nginx/, siç bëjnë zhvilluesit e të gjitha paketave të përmendura më sipër.

Struktura e skedarit të konfigurimit është si më poshtë:

përdoruesi nginx; # emër përdoruesi me të drejtat e të cilit do të ekzekutohet nginx
punëtori_proceset 1; # numër i proceseve të punonjësve
ngjarjet (
<…># ky bllok specifikon mekanizmin e votimit që do të përdoret (shih më poshtë) dhe numrin maksimal të lidhjeve të mundshme
}

Http(
<глобальные директивы http-сервера, например настройки таймаутов и т.п.>;
<почти все из них можно переопределить для отдельного виртуального хоста или локейшена>;

# përshkrim i serverëve (kjo është ajo që quhet VirtualHost në apache)
server (
# adresa dhe emri i serverit
dëgjo *:80;
emri i serverit aaa.bbb;

<Директивы сервера. Здесь обычно указывают расположение докуменов (root), редиректы и переопределяют глобальные настройки>;

# dhe kështu mund të përcaktoni një vendndodhje, për të cilën gjithashtu mund të anashkaloni pothuajse të gjitha direktivat e specifikuara në nivele më globale
vendndodhja /abcd/ (
<директивы>;
}
# Përveç kësaj, ju mund të bëni vendndodhjen duke përdorur një shprehje të rregullt, për shembull si kjo:
vendndodhja ~ \.php$ (
<директивы>;
}
}

# server tjetër
server (
dëgjo *:80;
emri i serverit ccc.bbb;

<директивы>
}
}

Ju lutemi vini re se çdo direktivë duhet të përfundojë me një pikëpresje.
Reverse proxying dhe FastCGI

Pra, më lart ne shikuam avantazhet e skemës frontend + backend, kuptuam instalimin, strukturën dhe sintaksën e skedarit të konfigurimit, dhe tani do të shohim se si të zbatojmë proxy-in e kundërt në nginx.

Dhe është shumë e thjeshtë! Për shembull si kjo:

vendndodhja/(
proxy_pass http://1.2.3.4:8080;
}

Në këtë shembull, të gjitha kërkesat që bien në vendndodhjen / do të proksiohen te serveri 1.2.3.4, porti 8080. Ky mund të jetë ose apache ose ndonjë server tjetër http.

Sidoqoftë, ka disa hollësi që lidhen me faktin se aplikacioni do të konsiderojë që, së pari, të gjitha kërkesat vijnë tek ai nga e njëjta adresë IP (e cila mund të konsiderohet, për shembull, si një përpjekje për një sulm DDoS ose hamendje të fjalëkalimit), dhe së dyti, supozoni se po funksionon në host 1.2.3.4 dhe portin 8080 (në përputhje me rrethanat, gjeneroni ridrejtime të pasakta dhe lidhjet absolute). Për të shmangur këto probleme pa pasur nevojë të rishkruaj aplikacionin, më duket i dobishëm konfigurimi i mëposhtëm:
Nginx dëgjon ndërfaqen e jashtme në portin 80.

Nëse backend-i (le të themi Apache) ndodhet në të njëjtin host si nginx, atëherë ai "dëgjon" në portin 80 në 127.0.0.1 ose në një adresë tjetër IP të brendshme.

Konfigurimi nginx në këtë rast duket si ky:

server (
dëgjo 4.3.2.1:80;
# vendosni titullin Host dhe X-Real-IP: për çdo kërkesë të dërguar në backend
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host:$proxy_port;
# ose "proxy_set_header Host $host;" nëse aplikacioni do t'i shtohet:80 të gjitha lidhjeve
}

Në mënyrë që aplikacioni të dallojë adresat IP të vizitorëve, duhet ose të instaloni modulin mod_extract_forwarded (nëse ekzekutohet nga serveri Apache), ose të modifikoni aplikacionin në mënyrë që të marrë informacione për adresën IP të përdoruesit nga X- Titulli real-IP HTTP.

Një tjetër opsion backend është përdorimi i FastCGI. Në këtë rast, konfigurimi nginx do të duket diçka si kjo:

server (
<…>

# vendndodhje ku do të shkojnë kërkesat për skriptet php
vendndodhja ~ .php$ (
fastcgi_pass 127.0.0.1: 8888; # përcaktoni adresën dhe portin e serverit fastcgi,
fastcgi_index index.php; # ...skedar indeks

# dhe disa parametra që duhet t'i kalojnë serverit fastcgi në mënyrë që të kuptojë se cilin skript duhet të ekzekutojë dhe me cilët parametra:
fastcgi_param SCRIPT_FILENAME /usr/www/html$fastcgi_script_name; # emër skripti
fastcgi_param QUERY_STRING $query_string; # varg pyetjesh
# dhe parametrat e kërkesës:
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
}

# për shkak të faktit se vendndodhjet me shprehje të rregullta kanë një "përparësi" të lartë, të gjitha kërkesat jo-php do të bien këtu.

vendndodhja/(
rrënjë /var/www/html/
}

Statika

Në mënyrë që të ngarkoni më pak backend, është më mirë të shërbeni skedarët statikë vetëm përmes nginx - ai e përballon këtë detyrë më mirë, sepse ai shpenzon shumë më pak burime për çdo kërkesë (nuk ka nevojë të hapet një proces i ri, por procesi nginx zakonisht konsumon më pak memorie, dhe mund të shërbejë shumë lidhje).

Në skedarin e konfigurimit duket diçka si kjo:

server (
dëgjo *:80;
emri i serverit myserver.com;

Vendndodhja/(
proxy_pass


">http://127.0.0.1:80;

}

# supozojmë se të gjithë skedarët statikë janë në /files
vendndodhja /skedarët/ (
rrënjë /var/www/html/; # tregoni shtegun për në fs
skadon 14 ditë; # shtoni titullin Skadon:
error_page 404 = @back; # dhe nëse skedari nuk gjendet, ne e dërgojmë atë në vendndodhjen e emërtuar @back
}

# kërkesa nga /files për të cilat nuk u gjet asnjë skedar dërgohen në backend dhe mund të gjenerojë skedari i kërkuar, ose shfaq mesazh i bukur në lidhje me gabimin
vendndodhja @mbrapa (
proxy_pass
"title="http://127.0.0.1:80;

">http://127.0.0.1:80;

}

Nëse të gjitha statikat nuk vendosen në një drejtori specifike, atëherë përdorni një shprehje të rregullt:

vendndodhja ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf |js)$ (
# e ngjashme me atë që është më sipër, vetëm të gjitha kërkesat që përfundojnë me një nga prapashtesat e specifikuara do të shkojnë në këtë vendndodhje
rrënjë /var/www/html/;
error_page 404 = @back;
}

Fatkeqësisht, ai nuk zbatohet në nginx punë asinkrone me dosje. Me fjalë të tjera, punëtori nginx është i bllokuar në operacionet I/O. Pra, nëse keni shumë skedarë statikë dhe, veçanërisht nëse ato lexohen nga disqe të ndryshëm, është më mirë të rrisni numrin e proceseve të punës (në një numër që është 2-3 herë më i madh se numri i përgjithshëm i kokave në disk ). Kjo, natyrisht, rrit ngarkesën në OS, por performanca e përgjithshme rritet. Për të punuar me një sasi tipike të përmbajtjes statike (jo një numër shumë i madh skedarësh relativisht të vegjël: CSS, JavaScript, imazhe), mjaftojnë një ose dy flukse pune.

Vazhdon

Lidhjet

Këtu mund të gjeni informacione shtesë rreth nginx:

Nginx është një server në internet dhe përfaqësues i postës elektronike që ka qenë i disponueshëm publikisht që nga viti 2004. Zhvillimi i projektit filloi në 2002; në rusisht emri tingëllon si motor-ex. Duke qenë krijimi i programuesit të famshëm Igor Sysoev, Nginx fillimisht ishte menduar për kompaninë Rambler. Është projektuar për sistemet operative që i përkasin grupit të ngjashëm me Unix. Asambleja është testuar me sukses në OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. Në platformë Microsoft Windows Nginx filloi të punojë me ardhjen e versionit 0.7.52 të asamblesë binare.

Statistikat për mars 2011 tregojnë se numri i faqeve të shërbyera nga Nginx tashmë ka kaluar shifrën 22 milionë. Sot Nginx përdoret nga projekte të tilla të njohura si Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru dhe të tjerë. Së bashku me lighttpd, Nginx përdoret për të shërbyer përmbajtje statike të krijuar nga një aplikacion uebi "i papërshtatshëm" që funksionon "nën autoritetin" e një serveri tjetër në internet.
Por përpara se të futemi në xhunglën e veçorive funksionale të Nginx, do të ishte e dobishme të mbani mend se çfarë është një server në internet në përgjithësi dhe një server proxy në veçanti.

Web server dhe proxy server

Web serverështë një server që pranon kërkesat HTTP nga shfletuesit e internetit dhe klientë të tjerë dhe lëshon përgjigje HTTP ndaj tyre. Këto të fundit zakonisht përfaqësohen Faqe HTML, transmetimi i medias, imazhi, skedari, të dhëna të tjera. Një server në internet kuptohet si software, kryerja e funksioneve të serverit të uebit dhe pajisjeve. Shkëmbimi i të dhënave dhe informacionit të kërkuar kryhet nëpërmjet protokollit HTTP.

Shtoje ne liste funksione shtesë serverët e uebit përfshijnë: autorizimin dhe vërtetimin e përdoruesve, regjistrimin e aksesit të tyre në burime, mbështetjen HTTPS për komunikim të sigurt me klientët, dhe të tjera. Ueb serveri më i përdorur në sistemet operative të ngjashme me Unix është Apache. Nginx aktualisht zë vendin e tretë në listën e preferencave të klientëve.

Proxy server lejon klientët të merren me pyetje kërkimi për të shërbimet e rrjetit në formë indirekte. Kjo do të thotë, është një server që është i specializuar në ridrejtimin e kërkesave të klientëve në serverë të tjerë. Duke u lidhur me një server proxy dhe duke kërkuar një burim të vendosur në një server tjetër, klienti ka mundësinë të ruajë anonimitetin dhe të mbrojë kompjuterin nga sulmet e rrjetit. Serveri proxy i siguron klientit të dhënat e kërkuara ose nga cache e tij (nëse ka një të tillë) ose pasi i ka marrë ato nga serveri i specifikuar. Në disa raste (për të arritur qëllimet e mësipërme), përgjigja e serverit, si kërkesa e klientit, mund të modifikohet nga serveri proxy.

Proxy serveri më i thjeshtë është Përkthyesi i Adresave të Rrjetit ose NAT. Në vitin 2000, proxy NAT u ndërtua në Shpërndarja e Windows. Proxy serverët, si çdo fenomen, kanë dy anët e medaljes, domethënë mund të përdoren si për të mirën ashtu edhe për të keqen. Për shembull, me ndihmën e tyre, ata që kanë frikë nga sanksionet për veprimet e tyre të pahijshme në internet fshehin adresat e tyre IP...

Gama funksionale Nginx:

• mirëmbajtja e serverit të skedarëve të indeksit, pyetjet statike, gjenerimi i përshkruesve të cache-ve të skedarëve të hapur, lista e skedarëve;
• proxying i përshpejtuar, shpërndarja elementare e ngarkesës, toleranca ndaj gabimeve;
• mbështetje për caching gjatë proxying të përshpejtuar dhe FastCGI;
• mbështetje për serverët FastCGI (të përshpejtuar) dhe memcached;
• modulariteti, filtrat, duke përfshirë rifillimin (varg-byte) dhe kompresimin (gzip);
• Autentifikimi HTTP, përgjigjet e copëtuara, filtri SSI;
• ekzekutimi paralel i disa nënpyetjeve në një faqe të përpunuar përmes FastCGI ose një përfaqësuesi në filtrin SSI;
• Mbështetje StartTLS dhe SSL;
• aftësia për të mbështetur Perl të integruar;
• vërtetim i thjeshtë (USER/PASS, LOGIN);
• ridrejtimi i serverit (përfaqësuesi IMAP/POP3) i përdoruesit në prapavijën IMAP/POP3 duke përdorur një server të jashtëm vërtetimi (HTTP).

Për ata që nuk janë të njohur me këtë terminologji, përshkrimi i funksionalitetit Nginx mund të duket shumë i paqartë. Por kur flasim për mënyrat specifike të përdorimit të këtij serveri në internet, ai gradualisht do të fillojë të shpërndahet.

Arkitektura dhe Konfigurimi

Proceset e punonjësve në Nginx shërbejnë njëkohësisht për lidhje të shumta, duke u siguruar atyre thirrjet OS (sistemi operativ) epoll (Linux), selektoni dhe vendosni në radhë (FreeBSD). Të dhënat e marra nga klienti analizohen duke përdorur një makinë shtetërore. Kërkesa e analizuar përpunohet nga një zinxhir modulesh të specifikuara nga konfigurimi. Përgjigja ndaj klientit gjenerohet në buferë, të cilët mund të tregojnë një seksion të një skedari ose të ruajnë të dhënat në memorie. Sekuenca e transferimit të të dhënave te klienti përcaktohet nga zinxhirët në të cilët grupohen buferët.

Strukturisht, serveri Nginx HTTP është i ndarë në serverë virtualë, të cilët nga ana tjetër ndahen në vendndodhje. Një server virtual ose direktivë mund të specifikohet me porte dhe adresa për marrjen e lidhjeve. Për vendndodhjen, mund të specifikoni një URI të saktë, një pjesë të një URI ose një shprehje të rregullt. Për menaxhimin e memories në internet, përdoren grupe, të cilat janë një sekuencë e blloqeve të memories të zgjedhura paraprakisht. Një bllok, i caktuar fillimisht për pishinën, ka një gjatësi nga 1 deri në 16 kilobajt. Ndahet në zona - të pushtuara dhe të pabanuara. Ndërsa kjo e fundit mbushet, ndarja e një objekti të ri sigurohet nga formimi i një blloku të ri.

Klasifikimi gjeografik i klientëve sipas adresës së tyre IP bëhet në Nginx duke përdorur modul i veçantë. Sistemi i pemës Radix ju lejon të punoni shpejt me adresat IP, duke zënë një minimum memorie.

Përfitimet e Nginx

Nginx konsiderohet shumë i shpejtë Serveri HTTP. Në vend të Apache ose së bashku me të, Nginx përdoret për të shpejtuar përpunimin e kërkesave dhe për të zvogëluar ngarkesën në server. Fakti është se mundësi të mëdha, e natyrshme në arkitekturën modulare të Apache, nuk kërkohen nga shumica e përdoruesve. Ju duhet të paguani për këtë funksionalitet të pakërkuar me një konsum të konsiderueshëm të burimeve të sistemit. Faqet e zakonshme, si rregull, karakterizohen nga një "dominim" i qartë i skedarëve statikë (imazhe, skedarë stili, JavaScript), në vend të skripteve. Asnjë funksionalitet i veçantë nuk kërkohet për të transferuar këto skedarë te një vizitor i burimit, pasi detyra është shumë e thjeshtë. Kjo do të thotë që serveri në internet për përpunimin e kërkesave të tilla duhet të jetë i thjeshtë dhe i lehtë, si Nginx.

Mënyrat për të përdorur Nginx

Në një port/IP të veçantë. Nëse burimi është i ngopur me imazhe ose skedarë për shkarkim, Nginx mund të konfigurohet në një port ose IP të veçantë dhe të shpërndajë përmbajtje statike përmes tij. Për ta bërë këtë, megjithatë, do t'ju duhet të shqetësoheni pak me ndryshimin e lidhjeve në sit. Nëse ka një numër të madh kërkesash për skedarë statikë, ka kuptim të krijoni një server të veçantë dhe të instaloni Nginx në të.

Përfaqësimi i përshpejtuar. Me këtë opsion, të gjitha kërkesat e vizitorëve shkojnë së pari në Nginx. Kërkesat për skedarë statikë (për shembull, fotografi, HTML e thjeshtë, skedar JavaScript ose CSS) Nginx e përpunon atë në mënyrë të pavarur. Nëse një përdorues akseson një skript të caktuar, ai do ta ridrejtojë kërkesën në departamentin e Apache. Nuk ka nevojë të bëni ndonjë transformim me kodin e faqes.

Nëse kanali nga serveri te vizitori dhe anasjelltas është i ngadalshëm, ky përdorim i Nginx mund të japë një efekt shtesë. Nginx kalon kërkesën e marrë nga vizitori në Apache për përpunim. Pas përpunimit të kërkesës, Apache e përcjell faqen në Nginx dhe mbyll lidhjen me një ndjenjë të arritjes. Nginx tani mund t'i dërgojë një faqe një përdoruesi për aq kohë sa dëshiron, praktikisht pa konsumuar burime të sistemit. Puna e Apache-s në vend të saj do të shoqërohej me një ngarkesë të paarsyeshme të lartë në kujtesë kur funksionon pothuajse në punë. Nga rruga, ky rast përdorimi për Nginx ka një emër tjetër: "frontend për Apache".

Nginx plus FastCGI. Apache mund të mos jetë fare i nevojshëm nëse përkthyesi i gjuhës në të cilën janë shkruar skriptet e faqes mbështet teknologjinë FastCGI. Gjuhë të tilla përfshijnë, për shembull, PHP, Perl dhe një sërë të tjerash. Megjithatë, në këtë rast mund t'ju duhet të modifikoni kodet e skriptit.

Ka shumë materiale të detajuara se si të instaloni dhe konfiguroni Nginx në internet. Mund të mësoni më shumë rreth Nginx në faqen e internetit të zhvilluesit të saj Igor Sysoev.

Për momentin, dy serverë në internet kanë fituar popullaritetin më të madh. Këto janë Apache dhe Ngnix. Secila prej tyre ka të mirat dhe të këqijat e veta. Apache u zhvillua në vitin 1995 dhe zhvillimi i tij nuk mori parasysh të gjitha nevojat e mundshme të përdoruesit; ai konsumon shumë memorie dhe burime të sistemit, por është i lehtë për t'u konfiguruar. Nginx u zhvillua pak më vonë në 2002, duke marrë parasysh gabimet e Apache dhe duke u fokusuar në performancën maksimale.

Ne nuk do të hyjmë në detaje në lidhje me të mirat dhe të këqijat e të dy këtyre serverëve në internet. Secila prej tyre ka zonën e vet të aplikimit. Ky udhëzues do të mbulojë instalimin e Nginx Ubuntu 16.04. Edhe pse do të flas për Ubuntu 16.04, të gjithë hapat do të funksionojnë edhe për shpërndarjet e tjera. Vendosja e Nginx është e njëjtë kudo, vetëm komanda e instalimit është e ndryshme.

Hapi i parë është të instaloni vetë serverin në internet në sistem. Programi është në depot zyrtare, por versioni i tij tashmë është pak i vjetëruar, kështu që nëse dëshironi versionin më të fundit, duhet të shtoni një PPA:

sudo apt-add-repository ppa:nginx/stable

Aktualisht versioni 1.10.0 është i disponueshëm në magazinat zyrtare, dhe 1.10.1 është tashmë i disponueshëm në PPA të qëndrueshme. Nëse nuk ju nevojitet versioni, mund të bëni pa PPA. Më pas, përditësoni listat e paketave nga depot:

Dhe instaloni ngnix:

sudo apt instaloni nginx

Pas instalimit Serveri Nginx do të përfundojë, shtoni programin në fillim në mënyrë që të fillojë automatikisht:

sudo systemctl mundëson nginx

Nëse hapni shfletuesin tuaj tani, do të shihni se nginx po funksionon, por ne ende duhet ta konfigurojmë atë.

Konfigurimi i Nginx Ubuntu

Vendosja e Nginx Ubuntu është shumë më e ndërlikuar se Apache. Këtu nuk do të shqyrtojmë të gjitha opsionet dhe aftësitë e programit, por do të flasim vetëm për ato kryesore. Hani konfigurime të ndryshme, në të cilin Nginx përdoret si një server proxy, dhe serveri kryesor Apache, por ne nuk do të jemi të interesuar për këtë. Ne duhet të instalojmë Nginx si një server të pavarur në internet.

Cilësimet e Nginx janë shumë të ndryshme - ekziston vetëm një skedar konfigurimi kryesor dhe skedarë për hostet virtualë. Konfigurimi nga çdo direktori, si në Apache, nuk mbështetet.

• /etc/nginx/nginx.conf- skedari kryesor i konfigurimit
• /etc/nginx/sites-available/*- skedarët e konfigurimit për hostet virtualë, me fjalë të tjera, për secilën faqe.
• /etc/nginx/sites-enabled/*- skedarët e konfigurimit të faqeve të aktivizuara.

Në fakt, skedarët e konfigurimit për hostet virtualë lexohen vetëm nga drejtoria e aktivizuar për faqet, por kjo përmban lidhje me faqet e disponueshme. Ky sistem u shpik për të bërë të mundur çaktivizimin e përkohshëm të faqeve të caktuara pa fshirë konfigurimin e tyre. Të gjithë skedarët e tjerë përmbajnë vetëm deklarata të variablave dhe cilësimet standarde, të cilat nuk kanë nevojë të ndryshohen. Sa i përket nginx.conf, të gjithë skedarët nga faqet e aktivizimit përfshihen në të, dhe për këtë arsye ato mund të përmbajnë të gjitha të njëjtat udhëzime. Tani le të shohim skedarin kryesor të konfigurimit:

sudo vi /etc/nginx/nginx.conf

Siç mund ta shihni, skedari është i ndarë në seksione. Struktura e përgjithshme eshte kjo:

opsionet globale
ngjarje ()
http(
server (
vendndodhja ()
}
server ()
}
postë ()

• opsionet globale janë përgjegjës për funksionimin e të gjithë programit.
• ngjarjet- ky seksion përmban cilësimet për të punuar me rrjetin.
• http- përmban cilësimet e ueb serverit. Duhet të përmbajë një seksion të serverit për rregullimin e mirë të çdo faqeje.
• server- ky seksion përmban cilësimet për çdo sajt të vendosur në serverin e uebit.
• vendndodhjen- seksioni i vendndodhjes mund të vendoset vetëm brenda seksionit të serverit dhe përmban cilësime vetëm për një kërkesë specifike.
• postë- përmban cilësimet e përfaqësuesit të postës.

Para se të kalojmë te opsionet, duhet të themi edhe disa fjalë për sintaksën e linjës në skedarin e konfigurimit. Duket kështu:

vlera e parametrit vlerë_shtesë...;

Rreshti duhet të përfundojë me një ";" dhe të gjitha kllapat e hapura (duhet të mbyllen.

Tani që keni studiuar pak strukturën globale, mund të vazhdoni të shikoni vetë parametrat. Nuk ka shumë opsione globale:

• përdorues- përdoruesi në emër të të cilit do të ekzekutohet programi.
• punëtor_proceset- përcakton se sa procese duhet të nisen për të paralelizuar punën e programit; nuk duhet të nisni më shumë procese sesa keni bërthama. Ju mund të vendosni parametrin auto dhe më pas programi do ta përcaktojë vetë këtë numër.
• pid= skedari i programit pid.
• punëtori_rlimit_nofile- tregon numrin maksimal të skedarëve që programi mund të hapë. Llogaritur si proceset_punëtor *lidhjet_punëtor* 2.

Ne kemi mbaruar me opsionet globale; nuk kishte shumë prej tyre dhe ato nuk ishin aq interesante. Shumë më interesante për sa i përket optimizimit janë opsionet nga seksioni i ngjarjeve:

• punëtor_lidhjet- numri i lidhjeve që programi mund të përpunojë njëkohësisht në një proces. Nëse shumëzojmë worker_process me këtë parametër, marrim numrin maksimal të përdoruesve që mund të lidhen me serverin në të njëjtën kohë. Rekomandohet të vendosni vlerën nga 1024 në 4048.
• shumë_pranoj- lejoni pranimin e shumë lidhjeve në të njëjtën kohë, aktivizoni ose çaktivizoni parametrin.
• përdorni- një mënyrë për të punuar me grupin e rrjetit. Parazgjedhja është sondazhi, por në Linux është më efikas të përdoret epoll.

• sendfile- përdorni metodën e dërgimit të të dhënave sendfile. Vlera është aktive.
• tcp_nodelay, tcp_nopush- dërgoni titujt dhe fillimin e skedarit në një paketë. Vlera është aktive.
• keepalive_timeout- skadon koha e pritjes përpara se lidhja mbajtëse të mbyllet, parazgjedhja është 65, por mund të reduktohet në 10 sekonda.
• mbaj_kërkesat- Numri maksimal i lidhjeve të mbajtura nga një klient, i rekomanduar 100.
• reset_timeout_connection- ndërpresin lidhjet pas një kohe. Vlera është aktive.
• hapur_file_cache- informacion për cache në lidhje me skedarët e hapur. Linja e cilësimeve duket kështu: open_file_cache max=200000 inactive=20s; max - numri maksimal i skedarëve në cache, koha e memorizimit.
• open_file_cache_valid- tregon pas asaj kohe që informacioni duhet të fshihet nga cache. Për shembull: open_file_cache_valid 30s;
• open_file_cache_min_uses- informacione memorie për skedarët që janë hapur të paktën një numër të caktuar herë.
• Open_File_cache_errors- informacioni i memories për skedarët që mungojnë, vlera më e lartë.

Parametrat kryesorë janë rishikuar. Këto cilësime do t'ju ndihmojnë të merrni performancë më të mirë nga nginx. Ne do të shikojmë seksionet e serverit dhe vendndodhjes në konfigurimin e hosteve virtualë.

Konfigurimi i kompresimit Gzip

Kompresimi i përmbajtjes është i nevojshëm për të zvogëluar madhësinë e të dhënave të shkarkuara nga shfletuesi. Kjo përshpejton ngarkimin e faqes, por shton ngarkesë shtesë në procesorin e serverit. Për të aktivizuar kompresimin në seksionin http, duhet të shtoni parametrin e mëposhtëm:

Kjo direktivë mund të përdoret gjithashtu në seksionin e serverit, atëherë do të funksionojë vetëm për domenin virtual të specifikuar. Më pas, ne konfigurojmë parametrat e kompresimit duke përdorur opsionet e mëposhtme:

• gzip_min_length- gjatësia minimale e faqes në bajt në të cilën duhet të përdoret kompresimi, për shembull, 1000 (1 kb)
• gzip_proxied- nëse është e nevojshme të kompresohen kërkesat e proksiuara, çdo thotë se gjithçka duhet të kompresohet.
• gzip_llojet- llojet e skedarëve që duhet të kompresohen, për shembull: tekst/aplikacion i thjeshtë/aplikacion xml/tekst x-javascript/tekst javascript/css text/json;
• gzip_disable "msie6"- Kompresimi nuk mbështetet në IE 6, kështu që ne e çaktivizojmë atë.
• gzip_comp_level- niveli i kompresimit, opsionet e disponueshme nga 1 në 10. 1 - minimale, 10 - kompresim maksimal.

Vendosja e hosteve virtuale

Siç e dini, një server mund të presë shumë faqe interneti. Të gjitha kërkesat vijnë në IP-në e serverit dhe nginx tashmë përcakton, bazuar në domenin, se çfarë përmbajtje duhet të shërbehet. Në mënyrë që nginx të dijë se çfarë i përket cilit domen duhet të konfigurohet host virtual. Çdo host zakonisht vendoset në një skedar të veçantë. Konfigurimi i hostit ndodhet në seksionin e serverit, por meqenëse të gjithë skedarët nga faqet e aktivizuara importohen në seksionin http, logjika e strukturës së skedarit të konfigurimit nuk prishet.

Le të shohim një konfigurim shembull:

vi /etc/nginx/sites-enabled/site.conf

• dëgjo 80- specifikon që një lidhje duhet të dëgjohet në portin 80, mund të përmbajë gjithashtu një opsion serveri i paracaktuar, që do të thotë se ky domen do të hapet nëse domeni nuk është specifikuar në kërkesë.
• rrënjë /var/www/html- drejtoria në të cilën ndodhen skedarët e faqes.
• indeksi i indeksit.html- faqja që do të hapet si parazgjedhje.
• Emri i serverit - Emri i domenit faqe.
• hyrje_log- një skedar për regjistrimin e një regjistri kërkesash në server, mund të përdoret si globalisht në seksionin http ashtu edhe për një lloj skedari specifik në vendndodhje.
• error_log- Regjistri i gabimeve të serverit të uebit, mund të pranojë një parametër shtesë që tregon detajet e regjistrit. paralajmëroj - maksimum, crit - vetëm gabime kritike.

Këto janë të gjitha cilësimet bazë për hostin virtual, pas së cilës ai tashmë do të funksionojë. Por ekziston gjithashtu një seksion vendndodhjeje, i cili ju lejon të konfiguroni sjelljen e serverit për drejtori dhe skedarë të caktuar. Sintaksa e vendndodhjes është:

adresa e vendndodhjes ()

Si një adresë mund të përdoren si një pyetje e drejtpërdrejtë në lidhje me rrënjën e serverit dhe shprehjet e rregullta. Për të përdorur shprehje të rregullta, paraprihet nga një karakter "~". Le të shohim shembujt më poshtë, por tani për tani le të shohim direktivat e mundshme:

• lejojnë- lejoni aksesin në vendndodhje për përdoruesit, të gjithë - të gjithë, mund të specifikoni gjithashtu një ip ose nënrrjet.
• mohojnë- mohoni hyrjen në vendndodhje, të gjitha - për të gjithë.
• provo-skedarët- përpiqet të hapë skedarët në një rend të caktuar, hap skedarin e parë të gjetur. Për shembull, ky ndërtim: $uri $uri/index.html $uri.html =404; fillimisht provon të hapë $uri, pastaj index.html, nëse $uri.html nuk gjendet dhe më pas, nëse nuk ekziston asnjë nga skedarët parafjalë, jep një gabim 404.
• skadon- cakton kohën e memorizimit të shfletuesit për elementin e caktuar, për shembull, 1d - një ditë, 2h - dy orë, 30s - 30 sekonda.

Përveç këtyre udhëzimeve kryesore, të tjera mund të përdoren këtu. Për më shumë detaje, shihni dokumentacionin zyrtar. Le të shohim disa shembuj:

Mos regjistro favicon:

vendndodhja = /favicon.ico (
log_not_found off;
hyrja_log off;
}

Refuzo qasjen te skedarët që fillojnë me një pikë:

vendndodhja ~ /\. (
mohoj të gjitha;
}

Ruani skedarët e rregullt për 90 ditë:

vendndodhja ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2 |doc|xls|exe|ppt|tar|mesi|midi|wav|bmp|rtf)$ (
hyrja_log off; log_not_found off; skadon 90 ditë;

Nginx është një server i popullarizuar dhe i fuqishëm në internet dhe një përfaqësues i kundërt.

Nginx ka shumë përparësi, por cilësimet e tij janë mjaft komplekse dhe jo gjithmonë të qarta për fillestarët. Ky udhëzues do t'ju ndihmojë të kuptoni parametrat bazë, sintaksën dhe skedarët e konfigurimit të Nginx.

shënim: Ky tutorial është bërë në Ubuntu 12.04.

Hierarkia e Drejtorisë Nginx

Nginx ruan skedarët e konfigurimit në drejtorinë /etc/nginx.

Kjo direktori përmban disa drejtori të tjera dhe skedarë konfigurimi modular.

cd /etc/nginx
ls -F

conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/

Përdoruesit e Apache janë tashmë të njohur me direktoritë e faqeve të disponueshme dhe të aktivizuara nga faqet. Këto drejtori përcaktojnë konfigurimet e faqes. Skedarët zakonisht krijohen dhe ruhen në faqet e disponueshme; faqet e aktivizuara ruan vetëm konfigurimet e sajteve të aktivizuara. Për ta bërë këtë, ju duhet të krijoni një lidhje simbolike nga faqet e disponueshme për faqet e aktivizuara.

Drejtoria conf.d mund të përdoret gjithashtu për të ruajtur konfigurimet. Çdo skedar me një shtesë .conf do të lexohet kur të fillojë Nginx. Sintaksa e skedarëve të tillë nuk duhet të përmbajë gabime.

Pothuajse të gjithë skedarët e mbetur ruhen në /etc/nginx, i cili përmban informacione konfigurimi për procese specifike ose komponentë shtesë.

Skedari kryesor i konfigurimit Nginx është nginx.conf.

skedar nginx.conf

Skedari nginx.conf lexon skedarët përkatës të konfigurimit dhe i kombinon ato në një skedar të vetëm konfigurimi kur serveri fillon.

Hapni skedarin:

sudo nano /etc/nginx/nginx.conf

përdoruesi www-data;
punëtori_proceset 4;
pid /var/run/nginx.pid;
ngjarjet (
punëtor_lidhjet 768;
#shumë_pranoj në;
}
http(
. . .

Rreshtat e parë japin informacion të përgjithshëm rreth Nginx. Përdoruesi i linjës www-data specifikon përdoruesin me të cilin është nisur serveri.

Direktiva pid specifikon se ku të ruhet Përpunoni PID-të Për përdorim të brendshëm. Linja worker_processes përcakton numrin e proceseve që Nginx mund të mbështesë njëkohësisht.

Ju gjithashtu mund të specifikoni regjistrat në këtë pjesë të skedarit (për shembull, regjistri i gabimeve përcaktohet duke përdorur direktivën e error_log).

Pas informacionit të përgjithshëm rreth serverit është seksioni i ngjarjeve. Ai menaxhon trajtimin e lidhjeve Nginx. Pasohet nga blloku http. Përpara se të vazhdojmë me konfigurimet e serverit të uebit, duhet të kuptojmë se si është formatuar skedari i konfigurimit Nginx.

Struktura e skedarit të konfigurimit Nginx

Skedari i konfigurimit Nginx është i ndarë në blloqe.

Blloku i parë është ngjarjet, i ndjekur nga http dhe fillon hierarkia kryesore e konfigurimeve.

Detajet e konfigurimit të një blloku http janë shtresuar duke përdorur blloqe të mbyllura që trashëgojnë vetitë nga blloku në të cilin ndodhen. Blloku http ruan shumicën e konfigurimeve të përgjithshme Nginx, të cilat ndahen në blloqe serveri, të cilët nga ana tjetër ndahen në blloqe vendndodhjeje.

Kur konfiguroni Nginx, është e rëndësishme të mbani mend rregullin e mëposhtëm: sa më i lartë të jetë niveli i konfigurimit, aq më shumë blloqe trashëgojnë këtë konfigurim; sa më i ulët të jetë niveli i konfigurimit, aq më "individual" është. Kjo do të thotë, nëse parametri X duhet të përdoret në çdo bllok server, atëherë një parametër i tillë duhet të vendoset në bllokun http.

Nëse shikoni nga afër skedarin, do të vini re se ai përmban shumë opsione që përcaktojnë sjelljen e programit në tërësi.

Për shembull, për të konfiguruar kompresimin e skedarit, duhet të vendosni parametrat e mëposhtëm:

gzip në;
gzip_disable "msie6";

Kjo do të mundësojë mbështetjen e gzip për kompresimin e të dhënave të dërguara te klienti dhe çaktivizimin e gzip për Internet Explorer 6 (sepse ky shfletues nuk mbështet kompresimin e të dhënave).

Nëse duhet të ketë ndonjë parametër kuptim të ndryshëm në disa blloqe serveri, atëherë një parametër i tillë mund të vendoset në niveli më i lartë dhe pastaj anashkaloni atë brenda blloqeve të serverit vetë. Si rezultat, Nginx do të ekzekutojë parametrin e nivelit më të ulët.

Ky shtresim i konfigurimeve shmang nevojën për të menaxhuar të shumëfishta skedarë identikë. Gjithashtu, nëse keni harruar të përcaktoni parametrat në niveli më i ulët, Nginx thjesht do të zbatojë opsionet e paracaktuara.

Blloku http në skedarin nginx.conf përfundon kështu:

përfshijnë /etc/nginx/conf.d/*.conf;
përfshijnë /etc/nginx/sites-enabled/*;

Kjo do të thotë që blloqet e serverit dhe vendndodhjes, të cilat përcaktojnë cilësimet për sajte dhe URL specifike, do të ruhen jashtë këtij skedari.

Kjo lejon një arkitekturë konfigurimi modular në të cilën mund të krijohen skedarë të rinj për të shërbyer faqet e reja. Gjithashtu ju lejon të gruponi skedarë të ngjashëm.

Mbyllni skedarin nginx.conf. Tani ju duhet të studioni cilësimet e faqeve individuale.

Blloqe virtuale Nginx

Blloqet e serverëve në Nginx janë analoge me hostet virtualë Apache (por për lehtësi, ato quhen gjithashtu host virtual). Në thelb, blloqet e serverëve janë specifikimet uebsajte të veçanta të pritura në të njëjtin server.

Në drejtorinë e disponueshme të faqeve mund të gjeni skedarin e paracaktuar të bllokut të serverit që vjen me serverin. Ky skedar përmban të gjitha të dhënat e nevojshme për mirëmbajtjen e faqes.

faqet e cd-ve të disponueshme
sudo nano parazgjedhje

rrënjë /usr/share/nginx/www;
index index.html index.htm;
emri i serverit lokalhost;
vendndodhja/(

}
vendndodhja /doc/ (

pseudonimi /usr/share/doc/;
autoindeks aktiv;
lejoj 127.0.0.1;
mohoj të gjitha;

Skedari i paracaktuar është komentuar shumë mirë, por në shembullin e mësipërm komentet janë lënë jashtë për thjeshtësi dhe lehtësi.

Blloku i serverit përfshin të gjitha cilësimet e vendosura midis kllapave kaçurrelë:

server (
. . .
}

Ky bllok vendoset në skedarin nginx.conf afër fundit të bllokut http duke përdorur direktivën e përfshirjes.

Direktiva rrënjësore specifikon direktorinë në të cilën do të ruhet përmbajtja e sajtit. Nginx do të shikojë në këtë direktori për skedarët e kërkuar nga përdoruesi. Si parazgjedhje kjo është /usr/share/nginx/www.

Ju lutemi vini re: të gjitha rreshtat përfundojnë me një pikëpresje. Kështu Nginx ndan një direktivë nga një tjetër. Nëse nuk ka pikëpresje, Nginx do t'i lexojë dy direktivat (ose direktivat e shumta) si një direktivë me argumente shtesë.

Direktiva e indeksit specifikon skedarët që do të përdoren si indeks. Serveri i uebit do t'i kontrollojë skedarët sipas renditjes që janë renditur. Nëse nuk është kërkuar asnjë faqe, blloku i serverit do të gjejë dhe do të kthejë skedarin index.html. Nëse nuk mund ta gjejë atë skedar, do të përpiqet të përpunojë index.htm.

direktiva e emrit të serverit

Direktiva e emrit të serverit përmban një listë të emrave të domeneve që do të shërbehen nga ky bllok server. Numri i domeneve është i pakufizuar; Domenet në listë duhet të ndahen me hapësira.

Një yll (*) në ​​fillim ose në fund të një domeni specifikon një emër me një maskë, ku ylli përputhet me një pjesë (ose disa pjesë) të emrit. Për shembull, emri *.example.com do të përputhet me emrat forum.example.com dhe www.animals.example.com.

Nëse url-ja e kërkuar përputhet me më shumë se një direktivë server_name, ajo së pari do të përgjigjet me atë që përputhet saktësisht.

Nëse adresa nuk gjen një përputhje, ajo do të kërkojë më shumë emër i gjatë me një maskë që përfundon me një yll. Nëse nuk gjen një emër të tillë, do të kthejë përputhjen e parë të shprehjes së rregullt.

Emrat e serverëve që përdorin shprehje të rregullta fillojnë me një tildë (~). Për fat të keq, Kjo temëështë përtej qëllimit të këtij neni.

Blloqet e vendndodhjes

Vendndodhja / rreshti tregon se direktivat në kllapa do të zbatohen për të gjitha burimet e kërkuara që nuk përputhen me asnjë bllok tjetër vendndodhjeje.

Blloqe të tilla mund të përmbajnë një shteg uri (për shembull /doc/). Për të vendosur një përputhje të plotë midis vendndodhjes dhe uri, përdoret simboli =. Karakteri ~ përputhet me shprehjet e rregullta.

Tilda mundëson modalitetin e ndjeshme ndaj shkronjave të mëdha, ndërsa tilda me një yll mundëson modalitetin e pandjeshëm ndaj shkronjave të mëdha.

Nëse kërkesa përputhet plotësisht me bllokun e vendndodhjes, atëherë serveri ndalon kërkimin dhe përdor një bllok të tillë. Nëse serveri nuk gjen një bllok vendndodhjeje që përputhet plotësisht, ai krahason URI-në me parametrat e direktivave të vendndodhjes. Nginx do të zgjedhë një bllok që përdor kombinimin e karaktereve ^~ dhe që përputhet me URI.

Nëse opsioni ^~ nuk përdoret, Nginx do të zgjedhë përputhjen më të afërt dhe do të kryejë një kërkim të rregullt shprehjesh për të provuar të përputhet me një nga modelet e disponueshme. Nëse gjen një shprehje të tillë, e përdor. Nëse nuk ka një shprehje të tillë, atëherë serveri përdor përputhjen URI të gjetur më parë.

Si shënim përfundimtar, Nginx preferon ndeshjet e sakta. Nëse nuk ka përputhje të tillë, ai kërkon një shprehje të rregullt dhe më pas kërkon URI. Për të ndryshuar prioritetin e kërkimit të një URI, përdorni kombinimin e karaktereve ^~.

direktiva try_files

Direktiva try_files është shumë mjet i dobishëm, i cili kontrollon skedarët në një renditje të caktuar dhe përdor skedarin e parë të gjetur për të përpunuar kërkesën.

Kjo ju lejon të përdorni parametra shtesë përcaktoni se si Nginx do të shërbejë kërkesat.

Skedari i konfigurimit të paracaktuar ka rreshtin:

try_files $uri $uri/ /index.html;

Kjo do të thotë që kur merret një kërkesë që shërbehet nga një bllok vendndodhjeje, Nginx fillimisht do të përpiqet të shërbejë uri si një skedar (kjo sjellje është e specifikuar nga ndryshorja $uri).

Nëse serveri nuk gjen një përputhje për variablin $uri, ai do të përpiqet të përdorë uri si një direktori.

Duke përdorur një vijë të pjerrët pasuese, serveri kontrollon ekzistencën e një drejtorie, për shembull $uri/.

Nëse nuk gjendet asnjë skedar ose drejtori, Nginx ekzekuton skedarin e paracaktuar (në këtë rast index.html në direktorinë rrënjë të bllokut të serverit). Çdo direktivë try_files përdor parametrin e fundit si rezervë, kështu që skedari duhet të ekzistojë në sistem.

Në rast se serveri në internet nuk gjen një përputhje në parametrat e mëparshëm, ai mund të kthejë një faqe gabimi. Për ta bërë këtë, përdorni shenjën e barabartë dhe kodin e gabimit.

Për shembull, nëse vendndodhja / blloku nuk mund të gjejë burimin e kërkuar, ai mund të kthejë një gabim 404 në vend të një skedari index.html:

try_files $uri $uri/ =404;

Për ta bërë këtë, duhet të vendosni një shenjë të barabartë dhe të vendosni kodin e gabimit si parametrin e fundit (=404).

Opsione shtesë

Direktiva e pseudonimit lejon Nginx të shërbejë faqet e bllokut të vendndodhjes jashtë një drejtorie të caktuar (për shembull, jashtë rrënjës).

Për shembull, skedarët e kërkuar nga /doc/ do të shërbehen nga /usr/share/doc/.

Indeksi automatik në direktivë ju lejon të aktivizoni listën e drejtorive Nginx për një direktivë të caktuar vendndodhjeje.

Linjat e lejimit dhe mohimit kontrollojnë aksesin në drejtori.

konkluzioni

Serveri i uebit Nginx është i pasur me veçori dhe shumë i fuqishëm, por terminologjia dhe opsionet e tij mund të jenë konfuze.

Pasi të kuptoni konfigurimet e Nginx dhe të mësoni se si të punoni me to, do të merrni të gjitha përfitimet e këtij mjeti të fuqishëm dhe të lehtë.

Etiketa: ,