Directivele de bază ale fișierului de configurare a serverului web nginx. Crearea unui server proxy simplu. Instalarea managerului de pachete aptitude, actualizarea indexului și a pachetelor

Unul dintre cele mai populare servere web

Nginx este foarte popular printre utilizatorii de servere web și proxy datorită performanței sale. Serverul are multe avantaje, dar configurarea lui va fi dificilă pentru un începător. Dorim să vă ajutăm să înțelegeți fișierele de configurare, sintaxa și configurarea parametrilor de bază Nginx.

Ierarhia directoarelor

Toate fișierele de configurare a serverului se află în directorul /etc/nginx. În plus, există mai multe foldere în interiorul directorului, precum și fișiere de configurare modulare.

cd /etc/nginx
ls -F
conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf site-available/win-utf
koi-utf naxsi_core.rules proxy_params site-enabled/

Dacă ați folosit Apache, ar trebui să vă familiarizați cu directoarele cu site-uri activate și site-uri disponibile. Ele determină configurația site-urilor. Fișierele create sunt stocate în ultimul director. Dosarul activat pentru site-uri este necesar doar pentru stocarea configurațiilor pagini activate. Pentru a le conecta ai nevoie legătură simbolicăîntre dosare. Configurațiile pot fi stocate și în directorul conf.d. În același timp, în timpul pornirii Nginx, fiecare fișier cu extensia .conf va fi citit din nou. Când scrieți fișierele de configurare, introduceți codul fără erori și urmați sintaxa. Toate celelalte fișiere se află în /etc/nginx. Configuratorul conține informații despre procese specifice, precum și componente suplimentare.

Fișierul principal de configurare Nginx este nginx.conf.

Citește toate fișierele de configurare, combinându-le într-unul care este solicitat la pornirea serverului. Deschideți fișierul cu:

sudo nano /etc/nginx/nginx.conf

Următoarele linii vor apărea pe ecran:

utilizator www-data;
lucrător_procese 4;
pid /var/run/nginx.pid;
evenimente (
conexiuni_muncitor 768;
#multi_accept pe;
}
http(
. . .

Primul este Informații generale despre Nginx. Expresia user www-data indică utilizatorul care conduce serverul. Directiva pid arată unde sunt destinate procesele PID uz intern. Linia worker_processes arată câte procese poate rula Nginx simultan. În plus, puteți specifica aici jurnalele (de exemplu, jurnalul de erori este determinat folosind directiva error_log). Mai jos este secțiunea evenimente. Este necesar pentru a gestiona conexiunile la server. După ce este blocul http.

Structura fișierului de configurare Nginx

Înțelegerea structurii de formatare a fișierelor vă va ajuta să înțelegeți mai bine configurația serverului dvs. web. Este împărțit în blocuri structurale. Detaliile de configurare a blocului http sunt stratificate folosind blocuri private. Ei moștenesc proprietăți de la părinte, adică. cel în care se află. Acest bloc stochează majoritatea configurațiilor serverului. Ele sunt împărțite în blocuri de server, în interiorul cărora locație.

Când ai configurat Serverul Nginx, amintiți-vă că cu cât blocul de configurare este mai jos, cu atât mai puține elemente vor moșteni proprietăți și invers. Fișierul conține un număr mare de opțiuni care modifică funcționarea serverului. Puteți seta compresia pentru fișierele trimise către client, de exemplu. Pentru a face acest lucru, introduceți parametrii:

gzip on;
gzip_disable „msie6”;

Vă rugăm să rețineți că același parametru poate lua sensuri diferiteîn diverse blocuri. Mai întâi setați-l în partea de sus, apoi redefiniți parametrul la nivelul dorit. Dacă ultima acțiune nu este efectuată, programul va seta automat valorile.

Ultimele rânduri ale fișierului nginx.conf sunt:

includ /etc/nginx/conf.d/*.conf;
includ /etc/nginx/sites-enabled/*;

Ele indică faptul că locația și blocurile de server sunt stocate în afara acestui fișier. Acestea definesc setările pentru adrese URL și fișiere specifice. Această structură este necesară pentru a menține o structură de configurare modulară. În interiorul acestuia puteți crea directoare și fișiere noi pentru diferite site-uri. In afara de asta, fișiere similare poti grupa. După luare în considerare, puteți închide fișierul nginx.conf.

Blocuri virtuale

Sunt analoge cu gazdele virtuale din Apache. Blocurile secțiunii server includ caracteristici ale site-urilor individuale care se află pe server. În folderul site-available veți găsi fișierul implicit de blocare a serverului. În interiorul acestuia puteți găsi datele necesare care pot fi necesare la întreținerea site-urilor.

site-uri cd-disponibile
sudo nano implicit
Server(
root /usr/share/nginx/www;
index index.html index.htm;
nume_server gazdă locală;
Locație/(
try_files $uri $uri/ /index.html;
}
locație /doc/ (
alias /usr/share/doc/;
autoindex activat;
permite 127.0.0.1;
nega totul;
}
}

În exemplul de mai sus, comentariile au fost eliminate în mod intenționat. Acest lucru a fost făcut pentru ușurința percepției. În interiorul blocurilor de server există setări cuprinse între acolade:

Acest bloc este plasat folosind directiva include la sfârșitul http, scrisă în fișierul nginx.conf. Directiva rădăcină definește directorul în care va fi localizat conținutul site-ului. În acesta, programul va căuta fișiere pe care utilizatorul le va solicita. Calea implicită este: /usr/share/nginx/www. Nginx separă liniile sau directivele unele de altele folosind punct și virgulă. Dacă nu puneți semn de punctuație, mai multe rânduri vor fi citite ca unul singur. Pentru a specifica regulile care vor fi folosite ca index, utilizați directiva index. Serverul le va verifica în ordinea în care sunt listate. Dacă niciuna dintre paginile disponibile nu a fost solicitată de utilizator, va fi returnat index.html. Dacă nu este acolo, serverul va căuta index.htm.

regula nume_server

Include o listă de nume de domenii pe care blocul serverului va trebui să le proceseze. Puteți introduce orice număr dintre ele, separate prin spații. Dacă puneți * la sfârșitul sau începutul domeniului, puteți specifica un nume cu o mască. Asteriscul se potrivește cu o parte a numelui. Dacă introduceți *.com.ua, atunci aceasta va include toate adresele specificate zona de domeniu. Dacă adresa se potrivește cu descrierea mai multor directive, atunci va răspunde la cea care se potrivește pe deplin. Dacă nu există potriviri, răspunsul va fi cel mai mare nume lung, care are mască. În caz contrar, potrivirea expresiilor regulate va fi efectuată. Numele de server care folosesc expresii regulate încep cu un tilde (~).

Blocuri de locație

Următorul la rând vom avea blocul de locație. Este necesar să se determine metoda de prelucrare anumite cereri. Dacă resursele nu se potrivesc cu niciun alt bloc de locație, atunci li se vor aplica directivele specificate în paranteze. Aceste blocuri pot include o cale ca /doc/. Pentru a stabili o potrivire completă între uri și locație, se folosește semnul =. Folosind tilde, puteți potrivi expresii regulate. De asemenea, puteți seta diferența de majuscule și minuscule punând ~. Dacă adăugați un asterisc, majusculele nu vor conta.

Rețineți: atunci când solicitarea se potrivește pe deplin cu blocul de locație, aceasta va fi folosită și căutarea se va opri. Când potrivirea este incompletă, URI-ul va fi comparat cu parametrii directivelor de locație. Utilizați un bloc cu ^~ care se potrivește cu URI pentru a selecta blocul. Dacă această opțiune nu utilizați, serverul selectează potrivirea optimă și, de asemenea, efectuează o căutare folosind expresii obisnuite. Acest lucru este necesar pentru a selecta unul dintre șabloanele potrivite. Dacă se găsește o expresie potrivită, aceasta va fi folosită. În caz contrar, potrivirea anterioară a URI va fi aplicată. Cu toate acestea, rețineți că Nginx preferă potrivirile complete. Dacă nu sunt acolo, va începe să caute expresii regulate și apoi după URI. Paritatea de căutare este specificată de combinația de simboluri ^~.

regula try_files

Aceasta este foarte unealtă folositoare, capabil să verifice prezența fișierelor în în modul prescris. Folosește primul care corespunde criteriilor pentru a procesa cererea. Puteți utiliza parametri suplimentari pentru a specifica modul în care serverul va servi cererile. Configuratorul are această linie implicită:

try_files $uri $uri/ /index.html;

Ce înseamnă? Dacă vine o solicitare care este servită de un bloc de locație, serverul va încerca mai întâi să trateze uri-ul ca pe un fișier. Aceasta este furnizată de variabila $uri. Când nu există potriviri, uri-ul va fi tratat ca un director. Îi puteți verifica existența adăugând o bară oblică: $uri/. Există situații în care nici fișierul, nici directorul nu vor fi găsite. În acest caz, fișierul implicit va fi încărcat - index.html. Se aplică regula try_files ultimul parametru ca opțiune de rezervă. Acesta este motivul pentru care acest fișier trebuie să fie în sistem. Cu toate acestea, dacă nu se găsesc potriviri, Nginx va returna o pagină de eroare. Pentru a-l seta, introduceți = și codul de eroare:

Opțiuni suplimentare

Dacă aplicați regula alias, veți putea servi paginile blocului de locație în afara directorului rădăcină, de exemplu. Când sunt necesare fișiere din doc, acestea vor fi solicitate din /usr/share/doc/. În plus, regula de autoindexare începe să listeze directoarele serverului pentru directiva de locație specificată. Dacă scrieți liniile de deny și allow, veți putea schimba accesul la directoare.

Ca o concluzie, merită să spunem că Nginx este un instrument multifuncțional foarte puternic. Dar pentru a înțelege bine principiul funcționării sale, va fi nevoie de timp și efort. Dacă înțelegeți cum funcționează configurațiile, vă puteți bucura pe deplin de toate caracteristicile programului.

Nginx? Scop, caracteristici, opțiuni de setări - acestea sunt lucruri cu care fiecare dezvoltator web ar trebui să fie familiarizat pentru a-și testa munca.

Să spunem un cuvânt despre nginx

Acest instrument are un proces principal și mai multe procese de lucru. Prima se ocupă de citirea și verificarea configurației. Managementul procesului de lucru este, de asemenea, sub controlul său. Sarcina acestuia din urmă este să proceseze cererile primite. Nginx folosește un model bazat pe evenimente. Mecanisme dependente de sistem de operare pentru a realiza distribuirea eficientă a cererilor direct între procesele lucrătorilor. Numărul lor este întotdeauna indicat în fișierul de configurare. Valoarea poate fi fie fixă, fie setată automat, în funcție de număr nuclee de procesor, cu care poți lucra. În nginx, sistemul și modulele sunt configurate folosind un fișier de configurare. Prin urmare, dacă trebuie să schimbați ceva, atunci trebuie să îl căutați. Este de obicei localizat în directiva /etc/nginx (dar calea se poate schimba atunci când utilizați alte sisteme) și are o extensie .conf.

Pornire, repornire și jurnalele

Pentru a face acest lucru, trebuie să faceți ca fișierul executabil să funcționeze. Configurarea serverului nginx este posibilă numai atunci când rulează. Controlul se realizează prin apelare fisier executabil cu parametrul -s. Pentru a face acest lucru, utilizați următoarea notație:

semnal nginx -s

În acest caz, puteți înlocui următoarele comenzi (trebuie să provină de la utilizatorul care a lansat instrumentul):

Stop. Este folosit pentru finalizare rapidă muncă.
Reîncărcați. Comanda este necesară pentru a reîncărca fișierul de configurare. Ideea este că nicio modificare nu va fi aplicată în timp ce fișierul rulează. Și pentru ca acestea să aibă efect, este necesară o repornire. De îndată ce acest semnal este primit, procesul principal va începe să verifice corectitudinea sintaxei fișierului de configurare și să încerce să aplice instrucțiunile disponibile acolo. Dacă nu reușește, va anula modificările și va funcționa cu setările vechi. Dacă totul s-a întâmplat cu succes, atunci vor fi lansate noi procese de lucru, iar celor vechi vor fi trimise o solicitare de terminare.
Părăsi. Folosit pentru finalizarea fără probleme a lucrărilor. Folosit dacă trebuie să așteptați până când solicitările curente se termină de service.
Redeschide. Închideți și deschideți fișierele jurnal.

Utilizarea Utilităților

Procesele pot fi configurate și folosind instrumente Unix (utilitatea kill va fi considerată ca exemplu). Ei folosesc de obicei un mecanism pentru a trimite un semnal către proces direct cu date. Acestea sunt conectate folosind ID. Aceste date sunt stocate în fișierul nginx.pid. Să zicem că ne interesează procesul nr. 134. Apoi, pentru o finalizare fără probleme, trebuie să trimitem următoarele informații:

kill -s QUIT 1628

Să presupunem că vrem să vedem o listă cu toate fișiere care rulează. Folosim utilitarul ps pentru asta. Comanda va arăta astfel:

ps -ax | grep nginx

Adică, după cum puteți vedea, atunci când utilizați instrumente suplimentare, este indicat că este utilizat. Acum să ne concentrăm asupra modului în care se realizează configurarea nginx.

Structura fișierului de configurare

Instalarea și configurarea nginx implică lucrul cu module. Acestea sunt configurate folosind directivele care sunt specificate în fișierul de configurare. Sunt simple și bloc. Primul tip de directivă constă dintr-un nume și parametri, care sunt separați prin spații și sunt terminați cu punct și virgulă (;). Blocul are o structură similară. Dar în această directivă, în loc de un final, este plasat un set instructiuni aditionale, care sunt plasate în acolade ((instrucțiuni)). Dacă pot conține numele și parametrii altor procese, atunci astfel de construcții se numesc context. Exemplele includ http, locația și serverul.

Se difuzează conținut static

Aceasta este una dintre cele mai importante sarcini cu care se confruntă configurația nginx. Prin distribuirea de conținut statistic ne referim la imagini și pagini HTML (nu dinamice). Să zicem că avem nevoie un loc de muncă la configurarea unui cluster nix nginx. Este greu de făcut? Nu, și să ne uităm la un exemplu. Înainte de a începe, este necesar să detaliați condițiile problemei. Deci, în funcție de solicitări, fișierele vor proveni din diferite directoare locale. Deci, în /data/www avem documente HTML. Și directorul /data/images conține imagini. Setare optimă nginx în acest caz necesită editarea fișierului de configurare, în care trebuie să configurați blocul serverului în http. Două locații vor fi, de asemenea, folosite pentru sprijin.

Implementare: server

Deci, mai întâi trebuie să creăm directoarele în sine și să plasăm fișiere cu extensiile necesare în ele (trebuie să adăugați conținut în html). Apoi deschideți fișierul de configurare. În mod implicit, conține deja mai multe blocuri de server, care sunt în mare parte comentate. Pentru a obține rezultate optime, acest proces trebuie efectuat pentru toate componentele implicite. Apoi adaugam bloc nou server cu acest cod:

Fișierul de configurare poate funcționa cu mai multe astfel de blocuri. Dar trebuie să difere în ceea ce privește numele și porturile prin care sunt primite datele.

Implementare: locatie

Definit în interiorul serverului:

Prezența semnului „/” este necesară pentru a compara datele primite și pentru a vedea dacă o astfel de adresă din cererea procesată este aici. Dacă nu există probleme, atunci specificați calea /data/www către fișierul necesar, ce este în asta sistem local. Dacă există o potrivire cu mai multe blocuri, atunci este selectat cel cu cel mai lung prefix. În exemplul dat, lungimea sa este egală cu unu, adică va fi folosit exclusiv dacă nu există „concurenți”. Acum să o îmbunătățim:

locație /imagini/ (

Cum poți să-ți dai seama dacă căutăm imagini? Acum să combinăm toate dezvoltările care au fost făcute anterior, iar configurația în acest moment arată astfel:

locație /imagini/ (

Aceasta este o opțiune de lucru care se întâmplă să fie standard. Acest server poate fi accesat calculator local, dacă mergeți la adresa: http://localhost/. Cum vor funcționa toate acestea?

Cum funcționează exemplul

Deci, atunci când vin solicitări care încep cu /images, serverul va trimite fișiere din directorul corespunzător către utilizator. Dacă este absent, vor fi transmise informații care indică o eroare 404 Dacă nginx este configurat pe un computer local, atunci când solicităm http://localhost/images/example.png vom primi un fișier a cărui locație este /data/images/. exemplu.png. Dacă specificați un caracter „/”, căutarea va fi efectuată în directorul /data/www. Dar tocmai am schimbat configurația. Pentru ca acesta să înceapă să funcționeze, trebuie să fie repornit. Pentru a face acest lucru, utilizați comanda nginx -s reload. În cazul când operatie normala nu este posibil, atunci puteți căuta cauza defecțiunii în fișierele error.log și access.log aflate în directiva /usr/local/nginx/logs.

Crearea unui server proxy simplu

Puteți spune despre nginx - configurare a acestui obiect este una dintre utilizările frecvente (și destul de ușoară, de altfel). Folosește principiul unui server care primește cereri și apoi le redirecționează către site-urile necesare. După aceasta, se așteaptă un răspuns de la ei, care îi direcționează către cel care i-a atribuit sarcina. Deci, să ne uităm la un exemplu de creare a unui punct de bază. Acesta va gestiona solicitările utilizatorilor și le va furniza imagini din directorul local. Deci, la blocul http adăugăm un alt server cu următorul conținut:

Acum permiteți-mi să vă descifrez: se creează un server simplu. Va asculta dacă nu specificați ascultare, serverul va rula pe 80. Toate cererile din zona locală vor fi afișate Sistemul de fișiere, care sunt direcționate către directorul /data/up1 (desigur, va trebui creat înainte de aceasta). Pentru a putea verifica, trebuie să plasați fișierul index.html acolo. Prin plasarea directivei rădăcină în contextul serverului, putem folosi locația în orice condiții (deoarece aceasta elimină restricțiile de acces). Acum lucrăm la crearea unui server proxy. Pentru ca acesta să funcționeze, avem nevoie de directiva proxy_pass, pentru care protocolul, numele și portul obiect vor fi specificate ca parametri (dacă conexiune locală va arăta ca http://localhost:8080). Veți obține următorul rezultat:

proxy_pass http://localhost:8080;

locație /imagini/ (

Dacă te uiți la cod și îl analizezi, s-ar putea să observi că al doilea bloc de locație a fost schimbat. Deci, în acest caz, poate funcționa cu extensii tipice de imagine. Ar putea fi afișat puțin diferit, astfel:

locație ~ \.(gif|jpg|png)$ (

root /data/imagini;

Configurația finală a serverului proxy arată astfel:

proxy_pass http://localhost:8080/;

locație ~ \.(gif|jpg|png)$ (

root /data/imagini;

Acesta va filtra cererile care au extensiile specificate la sfârșit și le va trimite persoanei care a cerut fișierele. Nu uitați că, dacă doriți să verificați fișierul de configurare, va trebui să-l reîncărcați. Și credeți-mă, aceasta este cea mai simplă configurare nginx. Dacă deschideți fișierul de configurare al serverului Vkontakte sau altul companie mare, vor avea mai mult cod decât cuvinte în acest articol.

Subiectul este corect setările nginx Este foarte mare și, mă tem, nu se încadrează în cadrul unui articol despre Habré. În acest text am încercat să vorbesc structura generala config, pot veni mai târziu lucruri mici și detalii mai interesante. :)

Un bun punct de plecare pentru configurarea nginx este configurația care vine cu distribuția, dar multe dintre capabilitățile acestui server nici măcar nu sunt menționate în el. Mult mai mult exemplu detaliat disponibil pe site-ul lui Igor Sysoev: sysoev.ru/nginx/docs/example.html. Totuși, să încercăm mai bine să ne construim configurația de la zero, cu bridge și poeteses. :)

Sa incepem cu setari generale. În primul rând, vom indica utilizatorul în numele căruia va rula nginx (este rău să funcționeze ca root, toată lumea știe :))

Acum, să spunem lui nginx câte procese de lucru să apară. De obicei, buna alegere Uneori, numărul de procese este egal cu numărul de nuclee de procesor de pe serverul dvs., dar merită să experimentați cu această setare. Dacă se așteaptă o sarcină mare HDD, puteți face un proces pentru fiecare hard disk fizic, deoarece toată munca va fi încă limitată de performanța sa.

Lucrător_procese 2;

Să clarificăm unde să scriem jurnalele de erori. Apoi, pentru serverele virtuale individuale, acest parametru poate fi suprascris, astfel încât în acest jurnal să apară doar erori „globale”, de exemplu, legate de pornirea serverului.

Notificare Error_log /spool/logs/nginx/nginx.error_log; # Nivelul de notificare „notificare” poate fi desigur modificat

Acum vine secțiunea „evenimente” foarte interesantă. În ea puteți seta suma maxima conexiuni pe care le va procesa simultan un proces de lucrător și o metodă care va fi utilizată pentru a primi notificări asincrone despre evenimentele din sistemul de operare. Desigur, puteți selecta doar acele metode care sunt disponibile pe sistemul de operare și au fost incluse în timpul compilării.

Aceste setări pot avea un impact semnificativ asupra performanței serverului dvs. Acestea trebuie selectate individual, în funcție de sistemul de operare și hardware. Pot să dau doar câteva reguli generale.

Module pentru lucrul cu evenimente:
- select și poll sunt de obicei mai lente și încarcă procesorul destul de greu, dar sunt disponibile aproape peste tot și funcționează aproape întotdeauna;
- kqueue și epoll - mai eficiente, dar disponibile numai în FreeBSD și, respectiv, Linux 2.6;
- rtsig - drăguță metoda eficienta, și este acceptat chiar și de Linux-uri foarte vechi, dar poate cauza probleme atunci când un numar mare conexiuni;
- /dev/poll - din câte știu eu, funcționează în puțin mai mult sisteme exotice, ca Solaris, și este destul de eficient în el;

parametrul worker_connections:
- Numărul maxim total de clienți serviți va fi egal cu worker_processes * worker_connections;
- Uneori pot lucra Partea pozitivă chiar și cele mai extreme valori, cum ar fi 128 de procese, 128 de conexiuni per proces sau 1 proces, dar cu parametrul worker_connections=16384. În acest din urmă caz, totuși, cel mai probabil va trebui să reglați sistemul de operare.

Evenimente (
conexiuni_muncitor 2048;
utilizați kqueue; # Avem BSD :)
}

Următoarea secțiune este cea mai mare și conține cele mai interesante lucruri. Aceasta este o descriere a serverelor virtuale și a unor parametri comuni tuturor acestora. Voi omite setări standard, care sunt în fiecare configurație, cum ar fi căile către jurnalele.

HTTP(
# Tot codul de mai jos va fi în această secțiune %)
# ...
}

În această secțiune pot exista niște parametri destul de interesanți.

Apelul de sistem sendfile este relativ nou pentru Linux. Vă permite să trimiteți date în rețea fără a fi nevoie să le copiați în spațiul de adrese al aplicației. În multe cazuri, acest lucru îmbunătățește semnificativ performanța serverului, așa că cel mai bine este să activați întotdeauna opțiunea sendfile.

Parametrul keepalive_timeout este responsabil pentru timp maxim menținerea unei conexiuni keepalive dacă utilizatorul nu solicită nimic prin intermediul acesteia. Luați în considerare modul în care site-ul dvs. trimite solicitări și ajustați această setare. Pentru site-urile care folosesc activ AJAX, este mai bine să păstrați conexiunea mai mult timp pentru paginile statice pe care utilizatorii le vor citi mult timp, este mai bine să întrerupeți conexiunea mai devreme; Rețineți că, menținând o conexiune keepalive inactivă, luați o conexiune care ar putea fi utilizată diferit. :)

Keepalive_timeout 15;

Separat, merită evidențiate setările proxy nginx. Cel mai adesea, nginx este folosit tocmai ca server proxy, prin urmare au destul mare importanță. În special, este logic să setați dimensiunea tamponului pentru cererile proxy nu mai puțin decât dimensiunea de răspuns așteptată de la serverul backend. Cu backend-uri lente (sau, dimpotrivă, foarte rapide), este logic să schimbați intervalele de timp pentru așteptarea unui răspuns din partea backend-ului. Amintiți-vă, cu cât aceste timeout-uri sunt mai lungi, cu atât utilizatorii dvs. vor aștepta mai mult un răspuns dacă backend-ul este lent.

Proxy_buffers 8 64k;
proxy_intercept_errors activat;
proxy_connect_timeout 1s;
proxy_read_timeout 3s;
proxy_send_timeout 3s;

Un mic truc. În cazul în care nginx servește mai mult de unul gazdă virtuală, este logic să creați o „gazdă virtuală implicită” care va procesa cererile în cazurile în care serverul nu poate găsi o altă alternativă folosind antetul Gazdă din cererea clientului.

# gazdă virtuală implicită
Server(
asculta 80 implicit;
nume_server gazdă locală;
nega totul;
}

Aceasta poate fi urmată de una (sau mai multe) secțiuni „server”. Fiecare dintre ele descrie o gazdă virtuală (cel mai adesea, bazată pe nume). Pentru proprietarii mai multor site-uri pe o singură găzduire sau pentru hosteri, poate exista ceva de genul unei directive

Includeți /spool/users/nginx/*.conf;

Restul va descrie cel mai probabil gazda lor virtuală direct în configurația principală.

Server (
asculta 80;

# Vă rugăm să rețineți că directiva server_name poate specifica mai multe nume în același timp.
nume_server myserver.ru myserver.com;
access_log /spool/logs/nginx/myserver.access_log cronometrat;
error_log /spool/logs/nginx/myserver.error_log warn;
# ...

Să setăm codarea implicită pentru ieșire.

Charset utf-8;

Și să spunem că nu vrem să acceptăm cereri de la clienți care au o lungime mai mare de 1 megaoctet.

Client_max_body_size 1m;

Să activăm SSI pentru server și să cerem să rezervăm cel mult 1 kilooctet pentru variabilele SSI.

Si on;
ssi_value_length 1024;

Și, în final, vom descrie două locații, dintre care una va duce la backend, la Apache care rulează pe portul 9999, iar a doua va trimite imagini statice din sistemul de fișiere local. Pentru două locații, acest lucru nu are sens, dar pentru un număr mai mare dintre ele are sens, de asemenea, să definiți imediat o variabilă în care va fi stocat directorul rădăcină al serverului și apoi să o utilizați în descrierile locațiilor.

Nginx este un server web și un proxy de e-mail care este disponibil public din 2004. Dezvoltarea proiectului a început în 2002 în limba rusă, numele sună ca engine-ex. Fiind o lucrare a mâinilor renumit programator, Igor Sysoev, Nginx a fost inițial destinat companiei Rambler. Este conceput pentru sistemele de operare aparținând grupului Unix-like. Ansamblul a fost testat cu succes pe OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. Pe platformă Microsoft Windows Nginx a început să lucreze odată cu apariția versiunii de ansamblu binar 0.7.52.

Statisticile pentru martie 2011 indică faptul că numărul de site-uri deservite de Nginx a depășit deja pragul de 22 de milioane. Astăzi, Nginx este folosit de proiecte cunoscute precum Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru și altele. Alături de lighttpd, Nginx este folosit pentru a servi conținut static generat de o aplicație web „incomodă” care funcționează „sub autoritatea” unui alt server web.
Dar înainte de a pătrunde în jungla caracteristicilor funcționale ale lui Nginx, ar fi util să ne amintim ce este un server web în general și un server proxy în special.

Server web și server proxy

server web este un server care acceptă solicitări HTTP de la browsere web și alți clienți și emite răspunsuri HTTP la acestea. Acestea din urmă sunt de obicei reprezentate Pagina HTML, flux media, imagine, fișier, alte date. Un server web este înțeles ca software, efectuând funcții de server web și hardware. Schimbul de date și informații solicitate se realizează prin protocolul HTTP.

Adaugă la listă funcții suplimentare serverele web includ: autorizarea și autentificarea utilizatorilor, înregistrarea accesului acestora la resurse, suport HTTPS pentru comunicarea securizată cu clienții și altele. Cel mai des folosit server web pe sisteme de operare asemănătoare Unix este Apache. Nginx ocupă în prezent locul trei în lista preferințelor clienților.

Server proxy permite clienților să se ocupe de interogări de căutare la serviciile de rețea în formă indirectă. Adică, este un server specializat în redirecționarea cererilor clienților către alte servere. Conectându-se la un server proxy și solicitând o resursă situată pe un alt server, clientul are posibilitatea de a păstra anonimatul și de a proteja computerul de atacuri de rețea. Serverul proxy furnizează clientului datele solicitate fie din propriul cache (dacă există), fie primind-o de la serverul specificat. În unele cazuri (pentru a atinge obiectivele de mai sus), răspunsul serverului, precum cererea clientului, poate fi modificat de serverul proxy.

Cel mai simplu server proxy este Network Address Translator sau NAT. În 2000, a fost încorporat proxy NAT Distribuție Windows. Serverele proxy, ca orice fenomen, au două fețe ale monedei, adică pot fi folosite atât pentru bine, cât și pentru rău. De exemplu, cu ajutorul lor, cei care se tem de sancțiuni pentru acțiunile lor nepotrivite online își ascund adresele IP...

Gama funcțională Nginx:

întreținerea serverului de fișiere index, interogări statice, generarea de descriptori cache deschide fișiere, lista de fișiere;
proxy accelerat, distribuție elementară a sarcinii, toleranță la erori;
suport pentru cache în timpul proxy-ului accelerat și FastCGI;
suport pentru FastCGI (accelerat) și servere memcached;
modularitate, filtre, inclusiv reluare (interval de octeți) și compresie (gzip);
Autentificare HTTP, răspunsuri fragmentate, filtru SSI;
executarea paralelă a mai multor subinterogări pe o pagină procesată prin FastCGI sau un proxy în filtrul SSI;
Suport StartTLS și SSL;
capacitatea de a suporta Perl încorporat;
autentificare simplă (UTILIZATOR/PASS, LOGIN);
redirecționarea serverului (proxy IMAP/POP3) a utilizatorului către backend-ul IMAP/POP3 utilizând un server de autentificare extern (HTTP).

Pentru cei care nu sunt familiarizați cu această terminologie, descrierea funcționalității Nginx poate părea foarte vagă. Dar când vine vorba de moduri utilizare specifică acest server web - va începe treptat să se disipeze.

Arhitectură și configurație

Procesele de lucru din Nginx servesc simultan mai multe conexiuni, oferindu-le apeluri cu OS (sistem de operare) epoll (Linux), select și kqueue (FreeBSD). Datele primite de la client sunt analizate folosind o mașină de stări. Cererea analizată este procesată de un lanț de module specificat de configurare. Răspunsul către client este generat în buffere, care pot indica o secțiune a unui fișier sau pot stoca date în memorie. Secvența transferului de date către client este determinată de lanțurile în care sunt grupate tampoanele.

Din punct de vedere structural, serverul HTTP Nginx este împărțit în servere virtuale, care la rândul lor sunt împărțite în locații. Server virtual sau directivă, puteți specifica porturi și adrese pentru primirea conexiunilor. Pentru locație, puteți specifica un URI exact, o parte dintr-un URI sau o expresie obișnuită. Pentru gestionarea memoriei online, se folosesc pool-uri, care sunt o secvență de blocuri de memorie preselectate. Un bloc, alocat inițial pentru pool, are o lungime de la 1 la 16 kilobytes. Este împărțit în zone - ocupate și neocupate. Pe măsură ce acesta din urmă se umple, alocarea unui nou obiect este asigurată de formarea unui nou bloc.

Clasificarea geografică a clienților după adresa lor IP se realizează în Nginx folosind un modul special. Sistemul de arbore Radix vă permite să lucrați rapid cu adrese IP, ocupând un minim de memorie.

Beneficiile Nginx

Nginx este considerat foarte rapid server HTTP. În loc de Apache sau împreună cu acesta, Nginx este folosit pentru a accelera procesarea cererilor și pentru a reduce sarcina pe server. Faptul este că majoritatea utilizatorilor nu au nevoie de capabilitățile enorme inerente arhitecturii modulare Apache. Trebuie să plătiți pentru această funcționalitate nerevendicată cu un consum semnificativ de resurse de sistem. Site-urile obișnuite, de regulă, sunt caracterizate de o „dominare” clară a fișierelor statice (imagini, fișiere de stil, JavaScript), mai degrabă decât de scripturi. Nu este necesară nicio funcționalitate specială pentru a transfera aceste fișiere către un vizitator de resurse, deoarece sarcina este foarte simplă. Aceasta înseamnă că serverul web pentru procesarea unor astfel de solicitări trebuie să fie simplu și ușor, precum Nginx.

Modalități de utilizare a Nginx

Pe un port/IP separat. Dacă resursa este saturată cu imagini sau fișiere pentru descărcare, Nginx poate fi configurat pe un port sau IP separat și să distribuie conținut static prin intermediul acestuia. Pentru a face acest lucru, va trebui, totuși, să schimbați puțin link-urile de pe site. La cantitati mari Este logic să creați interogări pentru fișierele statice server separatși instalați Nginx pe el.

Proxy accelerat. Cu această opțiune, toate solicitările vizitatorilor ajung mai întâi la Nginx. Solicitări de fișiere statice (de exemplu, imagini, HTML simplu, JavaScript sau fișier CSS) Nginx îl procesează independent. Dacă un utilizator accesează un anumit script, el va redirecționa solicitarea către departamentul Apache. Nu este nevoie să faceți nicio transformare cu codul site-ului.

Dacă canalul de la server la vizitator și invers este lent, această utilizare a Nginx poate da efect suplimentar. Nginx trece cererea primită de la vizitator către Apache pentru procesare. După procesarea cererii, Apache redirecționează pagina către Nginx și încheie conexiunea cu un sentiment de realizare. Nginx poate trimite acum o pagină unui utilizator atâta timp cât dorește, practic fără a consuma resurse de sistem. Lucrarea Apache în locul său ar fi însoțită de o încărcare nerezonabilă a memoriei atunci când rulează aproape inactiv. Apropo, acest caz de utilizare pentru Nginx are un alt nume: "frontend către Apache".

Nginx plus FastCGI. Apache poate să nu fie deloc necesar dacă interpretul limbii în care sunt scrise scripturile site-ului acceptă tehnologia FastCGI. Astfel de limbi includ, de exemplu, PHP, Perl și o serie de altele. Cu toate acestea, în acest caz, poate fi necesar să modificați codurile de script.

Există multe materiale detaliate despre cum să instalați și să configurați Nginx pe Internet. Puteți afla mai multe despre Nginx pe site-ul web al dezvoltatorului său Igor Sysoev.