Subiect setări corecte 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 apărea 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 conexiunile pe care le va procesa un singur lucrător simultan ș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 pe 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 când un numar mare conexiuni;
- /dev/poll - din câte știu eu, funcționează în sisteme ceva mai exotice, precum Solaris, și este destul de eficient acolo;

parametru 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ările standard care sunt în fiecare configurație, cum ar fi căile către jurnale.

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 timpul maxim de menținere a unei conexiuni keepalive dacă utilizatorul nu solicită nimic pentru aceasta. 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 bufferului 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 deservește mai mult de o gazdă virtuală, este logic să se creeze o „gazdă virtuală implicită” care va procesa cererile în cazurile în care serverul nu poate găsi o altă alternativă folosind antetul Host 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;

Cel mai probabil, restul își vor descrie gazda 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 kilobyte 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ă a serverului și apoi să o utilizați în descrierile locațiilor.

Server web dedicat bazat pe nginx – metodă grozavăîmbunătățirea performanței site-urilor web. În viteza de procesare continut static pur și simplu nu are egal: poate rezista cu ușurință la câteva mii conexiuni simultaneși poate fi ușor optimizat și ajustat la orice configurație. In orice caz? Acționând ca front-end pentru Apache, nginx se dovedește a fi cel mai vulnerabil punct al întregii infrastructuri web, așa că trebuie acordată o atenție deosebită securității nginx.

Acest articol este un fel de program educațional sau, dacă doriți, un rezumat al tuturor tehnicilor de îmbunătățire a securității nginx. Nu va conține teorie, o descriere a elementelor de bază ale instalării unui server web și alte puf. În schimb, veți primi un cuprinzător material practic, care descrie toți pașii de bază care trebuie parcurși pentru a avea un server Web cu adevărat sigur.

Instalare

Pachetul nginx este disponibil în formă precompilată pentru orice distribuție. Cu toate acestea, construind singur serverul, îl puteți face mai compact și mai fiabil și veți avea, de asemenea, posibilitatea de a schimba linia de întâmpinare a serverului web pentru a descuraja copiii cu scenarii proști.

Schimbați linia de întâmpinare a serverului Web

Descărcați sursele nginx, deschideți fișierul src/http/ngx_http_header_filter_module.c și găsiți următoarele două rânduri:

static char ngx_http_server_string = "Server: nginx" CRLF;
static char ngx_http_server_full_string = "Server: " NGINX_VER CRLF;

Înlocuiește-le cu ceva de genul acesta:

static char ngx_http_server_string = "Server: ][ Server Web„CRLF;
static char ngx_http_server_full_string = "Server: ][ Web Server" CRLF;

Eliminați toate modulele nginx pe care nu le utilizați

Unele module nginx se conectează la serverul web direct în timpul compilării și oricare dintre ele este plin de pericol potențial. Poate că în viitor se va găsi o vulnerabilitate într-una dintre ele, iar serverul tău va fi în pericol. Prin dezactivarea modulelor inutile, puteți reduce semnificativ riscul apariției unei astfel de situații.

Construiți folosind următoarele comenzi:

# ./configure --without-http_autoindex_module --without-http_ssi_module
#face
# face instalarea

În acest fel, veți obține nginx cu modulele SSI (Server Side Includes) și Autoindex dezactivate în avans (și în cele mai multe cazuri inutile). Pentru a afla ce module pot fi eliminate în siguranță de pe serverul Web, rulați scriptul de configurare cu indicatorul „-help”.

Să disecăm nginx.conf

După instalare, nginx ar trebui configurat. Pe paginile revistei exista deja material care descrie acest proces, dar vom rămâne la subiectul articolului și vom vorbi despre modalități de creștere a securității serverului.

Dezactivați afișarea versiunii serverului pe toate paginile de eroare

Adăugați linia „server_tokens off” în fișierul nginx.conf. Acest lucru va forța nginx să ascundă informații despre tipul și versiunea serverului web pe paginile generate ca răspuns la o solicitare eronată a clientului.

Configurați protecția împotriva întreruperii stivei

Adăugați la secțiunea server următoarele rânduri:

# vi /etc/nginx/nginx.conf

# Dimensiunea maximă a memoriei tampon pentru stocarea corpului solicitării clientului
client_body_buffer_size 1K;
# Dimensiunea maximă a memoriei tampon pentru stocarea antetelor cererilor clientului
client_header_buffer_size 1k;
# Dimensiunea maximă a corpului solicitării clientului, specificată în câmpul antet Content-Length. Dacă serverul trebuie să accepte încărcări de fișiere, această valoare trebuie mărită
client_max_body_size 1k;
# Numărul și dimensiunea bufferelor pentru citirea antetului de cerere mare a clientului
large_client_header_buffers 2 1k;

Acordați atenție directivei large_client_header_buffers. În mod implicit, nginx alocă patru buffere pentru a stoca șirul URI, fiecare de dimensiune egal cu dimensiunea pagini de memorie (pentru x86 aceasta este de 4 KB). Bufferele sunt eliberate de fiecare dată când conexiunea intră în starea de menținere în viață după procesarea unei cereri. Două buffer-uri de 1 KB pot stoca URI-uri cu o lungime de numai 2 KB, ceea ce ajută la combaterea roboților și a atacurilor DoS.

Pentru a îmbunătăți performanța, adăugați următoarele rânduri:

# vi /etc/nginx/nginx.conf

# Timeout în timp ce citiți corpul solicitării clientului
client_body_timeout 10;
# Timeout la citirea antetului solicitării clientului
client_header_timeout 10;
# Timeout după care conexiunea keep-alive cu clientul nu va fi închisă din partea serverului
keepalive_timeout 5 5;
# Timeout la trimiterea răspunsului către client
send_timeout 10;

Controlați numărul de conexiuni simultane

Pentru a proteja serverul Web de supraîncărcare și încercări de a efectua un atac DoS, adăugați următoarele linii la configurație:

# vi /etc/nginx/nginx.conf

# Descriem zona (limitele) în care vor fi stocate stările de sesiune. O zonă de 1 MB poate stoca aproximativ 32000 de stări, am setat dimensiunea ei la 5 MB
limit_zone slimits $binary_remote_addr 5m;
# Setați numărul maxim de conexiuni simultane pentru o sesiune. În esență, acest număr specifică numărul maxim de conexiuni de la un IP
limit_conn slimits 5;

Prima directivă ar trebui să fie în secțiunea HTTP, a doua în secțiunea locație. Când numărul de conexiuni depășește limitele, clientul va primi un mesaj „Serviciu indisponibil” cu codul 503.

Permite conexiuni numai la domeniul tău

Hackerii pot folosi boți pentru a scana subrețele și pentru a găsi servere Web vulnerabile. De obicei, roboții parcurg pur și simplu intervalele de adrese IP căutând 80 de porturi deschise și trimit o solicitare HEAD pentru a obține informații despre serverul web (sau pagina de pornire). Puteți preveni cu ușurință o astfel de scanare interzicând accesul la server după adresa IP (adăugați la subsecțiunea locație):

# vi /etc/nginx/nginx.conf

dacă ($gazdă !~ ^(gazdă.com|www.gazdă.com)$) (
întoarcere 444;
}

Limitați numărul de metode disponibile pentru accesarea serverului Web

Unii roboți folosesc o varietate de metode pentru a contacta serverul pentru a încerca detectarea tipului și/sau infiltrarea, dar RFC 2616 afirmă clar că serverul web nu este obligat să le implementeze pe toate, iar metodele neacceptate pot pur și simplu să nu fie procesate. Astăzi, doar metodele GET (cerere de document), HEAD (cerere antet server) și POST (cerere de publicare a documentului) rămân în uz, astfel încât toate celelalte pot fi dezactivate fără durere prin plasarea următoarelor linii în secțiunea server a fișierului de configurare:

# vi /etc/nginx/nginx.conf

if ($metoda_cerere !~ ^(GET|HEAD|POST)$) (
întoarcere 444;
}

Închideți roboții

O altă modalitate de a bloca roboții, scanerele și alte spirite rele se bazează pe determinarea tipului de client (user-agent). Nu este foarte eficient, deoarece majoritatea boților vizează browsere complet legitime, dar în unele cazuri rămâne util:

# vi /etc/nginx/nginx.conf

# Blocați managerii de descărcare
dacă ($http_user_agent ~* LWP::Simple|BBBike|wget) (
întoarce 403;
}
# Blocați unele tipuri de roboți
if ($http_user_agent ~* msnbot|scrapbot) (
întoarce 403;
}

Blocați spamul referitor

Dacă site-ul dvs. publică jurnalele Web într-un formular accesibil public, puteți deveni cu ușurință o victimă a spam-ului referitor (când roboții de spam vă contactează serverul, indicând referitor în antet - adresa site-ului promovat). Acest tip de spam poate strica cu ușurință evaluările SEO ale unei pagini web, așa că trebuie blocat fără greș. O modalitate de a face acest lucru este să puneți pe lista neagră cele mai comune cuvinte găsite în adresele site-urilor promovate.

# vi /etc/nginx/nginx.conf

# Secțiunea Server
dacă ($http_referer ~* (bebe|de vânzare|fată|bijuterii|dragoste|nudit|organic|poker|porno|sex|adolescent))
{
întoarce 403;
}

Blocați legătura rapidă

Un hotlink este includerea unei imagini (sau a unui alt conținut) de pe un alt site pe o pagină. În esență, acesta este un furt, deoarece imaginea pe care ați petrecut mai mult de o oră din timpul liber nu este doar folosită în mod liber de către alții, ci creează și o încărcare pe serverul dvs. Web fără a aduce vizitatori la acesta. Pentru a combate hotlink-urile, este suficient să te asiguri că imaginile sunt trimise clientului doar dacă acesta le-a solicitat în timp ce se afla deja pe site (cu alte cuvinte, antetul cererii de referință ar trebui să conțină numele site-ului tău). Adăugați următoarele rânduri în secțiunea server a fișierului de configurare nginx.conf (host.com este adresa site-ului dvs.):

# vi /etc/nginx/nginx.conf

locație /imagini/ (
valid_referers nici unul blocat www.host.com host.com;
if ($invalid_referer) (
întoarce 403;
}
}

Alternativ, puteți configura serverul pentru a încărca banner special cu un mesaj despre furt în locul imaginii solicitate. Pentru a face acest lucru, înlocuiți linia „return 403” cu linia:

rescrie ^/images/uploads.*\.(gif|jpg|jpeg|png)$ http://www.host.com/banned.jpg ultima

Protejați directoarele importante de străini

Ca orice alt server Web, nginx vă permite să reglați accesul la directoare pe baza adreselor IP și a parolelor. Această caracteristică poate fi folosită pentru a închide anumite părți ale site-ului de la privirile indiscrete. De exemplu, pentru a tăia URI-ul din lumea exterioară:

# vi /etc/nginx/nginx.conf

locație /încărcări/ (
# Permite accesul numai la mașini retea locala
permite 192.168.1.0/24;
# Să-i ucidem pe toți ceilalți
nega totul;
}

Acum doar utilizatorii rețelei locale vor avea acces la documentele din directorul de încărcări. Pentru a seta o parolă, va trebui să faceți mai multe actiuni complexe. Mai întâi, trebuie să creați un fișier de parolă care este privat pentru nginx și să adăugați utilizatorii necesari la acesta (de exemplu, să adăugăm utilizatorul administrator):

# mkdir /etc/nginx/.htpasswd
# htpasswd -c /etc/nginx/.htpasswd/passwd admin

# vi /etc/nginx/nginx.conf

locație /admin/ (
auth_basic „Restricționat”;
auth_basic_user_file /etc/nginx/.htpasswd/passwd;
}

Utilizatori noi pot fi adăugați folosind următoarea comandă:

# htpasswd -s /etc/nginx/.htpasswd/passwd utilizator

Utilizați SSL

Dacă site-ul dvs. funcționează cu date private de utilizator, cum ar fi numere Carduri de credit, parole de la alte servicii sau oferă acces la alte informații importante care pot deveni ştire pentru terți, aveți grijă de criptare. Nginx funcționează bine cu SSL și această caracteristică nu trebuie neglijată.

Pentru a configura criptarea SSL folosind nginx, trebuie doar să urmați câțiva pași simpli. Mai întâi trebuie să creați un certificat utilizând următoarea secvență de comenzi:

# cd /etc/nginx
# openssl genrsa -des3 -out server.key 1024
# openssl req -new -key server.key -out server.csr
# cp server.key server.key.org
# openssl rsa -in server.key.org -out server.key
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Apoi descrieți certificatul în Fișier de configurare nginx:

# vi /etc/nginx/nginx.conf

Server (
nume_server gazdă.com;
asculta 443;
ssl activat;
ssl_certificate /etc/nginx/server.crt;
ssl_certificate_key /etc/nginx/server.key;
access_log /etc/nginx/logs/ssl.access.log;
error_log /etc/nginx/logs/ssl.error.log;
}

După aceasta, puteți reporni serverul web:

# /etc/init.d/nginx reîncărcare

Desigur, fără suport din partea site-ului web în sine, este inutil să faceți acest lucru.

alte metode

Setați valorile corecte pentru variabilele de sistem

Deschideți fișierul /etc/sysctl.conf și plasați următoarele linii în el:

# vi /etc/sysctl.conf

# Protecție împotriva atacurilor ștrumfilor
net.ipv4.icmp_echo_ignore_broadcasts = 1
# Protecție împotriva mesajelor ICMP nevalide
net.ipv4.icmp_ignore_bogus_error_responses = 1
# Protecție împotriva inundațiilor SYN
net.ipv4.tcp_syncookies = 1
# Dezactivează rutarea sursei
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# Protecție anti-spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# Nu suntem un router
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# Activați ExecShield
kernel.exec-shield = 1
kernel.randomize_va_space = 1
# Extinderea gamei de porturi disponibile
net.ipv4.ip_local_port_range = 2000 65000
# Măriți dimensiunea maximă a bufferelor TCP
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_window_scaling = 1

Plasați directorul rădăcină al serverului web pe o partiție dedicată

Prin plasarea directorului rădăcină al serverului Web într-o partiție dedicată și interzicerea plasării oricăruia fișiere executabileși fișierele dispozitivului, veți proteja restul sistemului de oricine poate obține acces la rădăcina serverului Web. În acest caz, intrarea din fișierul /etc/fstab ar trebui să arate cam așa:

/dev/sda5 /nginx ext4 implicite,nosuid,noexec,nodev 1 2

Plasați nginx într-un mediu chroot/jail

Orice sistem *nix modern vă permite să blocați aplicația într-un mediu de execuție izolat. În Linux, puteți utiliza tehnologiile KVM, Xen, OpenVZ și VServer pentru aceasta, în FreeBSD - Jail, în Solaris - Zones. Dacă niciuna dintre aceste tehnologii nu este disponibilă, puteți pune nginx într-un chroot clasic, care, deși mult mai fragil, poate opri majoritatea hackerilor.

Instalați regulile SELinux pentru a proteja nginx

O alternativă bună medii izolate spectacolele sunt sisteme locale instrumente de detectare și prevenire a intruziunilor, cum ar fi SELinux sau AppArmor. Dacă sunt configurate corect, acestea pot preveni încercările de a pirata serverul Web. În mod implicit, niciunul dintre ele nu este configurat să funcționeze împreună cu nginx, totuși, în cadrul proiectului SELinuxNginx(http://sf.net/projects/selinuxnginx/) au fost create reguli pentru SELinux pe care oricine le poate folosi. Tot ce rămâne este să descărcați și să instalați:

# tar -zxvf se-ngix_1_0_10.tar.gz
# cd se-ngix_1_0_10/nginx
#face
# /usr/sbin/semodule -i nginx.pp

Configurare firewall

De obicei, nginx este instalat pe mașini dedicate pregătite pentru încărcare mare, deci este adesea singurul serviciu de rețea care rulează pe server. Pentru a securiza serverul, este suficient să creați un set foarte mic de reguli care să deschidă porturile 80, 110 și 143 (dacă, bineînțeles, nginx ar trebui să funcționeze și ca un proxy IMAP/POP3) și să închidă orice altceva din lumea exterioară. .

Limitați numărul de conexiuni folosind un firewall

Pentru un site Web puțin încărcat, este o idee bună să limitați numărul de încercări de conectare de la o singură adresă IP pe minut. Acest lucru vă poate proteja de anumite tipuri de atacuri DoS și de forță brută. Pe Linux, acest lucru se poate face folosind modulul standard iptables/netfilter state:

# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m stare --state NOU -m recent --set
# iptables -A INPUT -p tcp --dport 80 -i eth0 \
-m stare --state NOU -m recent --actualizare \
--seconds 60 --hitcount 15 -j DROP

Regulile reduc limita numărului de conexiuni de la un IP pe minut la 15. Același lucru se poate face folosind pf:

# vi /etc/pf.conf

webserver_ip="1.1.1.1"
masa persista
blocați rapid din
transmiteți $ext_if proto tcp la $webserver_ip \
port www steagurile S/SA păstrează starea \
(max-src-conn 100, max-src-conn-rate 15/60,\
suprasarcina culoare)

Pe lângă limita privind numărul de conexiuni secvenţiale (15 pe minut), această regulă stabileşte o limită suplimentară pentru numărul de conexiuni simultane egală cu 100.

Configurare PHP

Dacă utilizați nginx împreună cu PHP, nu uitați să îl configurați și pe acesta. Iată cum ar trebui să arate fișierul de configurare /etc/php/php.ini al serverului securizat:

# vi /etc/php/php.ini

# Dezactivează funcțiile periculoase
disable_functions = phpinfo, system, mail, exec
# Timp maxim de execuție a scriptului
max_execution_time = 30
# Timpul maxim pe care scriptul îl poate petrece procesând datele cererii
max_input_time = 60
# Cantitatea maximă de memorie alocată fiecărui script
limita_memorie = 8M
# Dimensiunea maximă a datelor trimise către script folosind metoda POST
dimensiune_max_post = 8M
# Dimensiunea maximă a fișierelor încărcate
upload_max_filesize = 2M
# Nu afișați utilizatorilor erori de script PHP
display_errors = Dezactivat
# Activați modul sigur
safe_mode = Activat
# Activați modul sigur SQL
sql.safe_mode = Activat
# Permiteți executarea comenzilor externe numai în acest director
safe_mode_exec_dir = /path/to/protected/directory
# Protejați-vă împotriva scurgerilor de informații despre PHP
expose_php = Dezactivat
# Păstrăm jurnalele
log_errors = Activat
# Preveniți deschiderea fișierelor de la distanță
allow_url_fopen = Dezactivat

concluzii

Aplicând recomandările descrise în acest articol, veți obține un server Web mult mai sigur. Dar rețineți că nu toate tehnicile se potrivesc configurației dvs. De exemplu, protecția cu forță brută bazată pe reducerea dimensiunii bufferelor alocate de nginx pentru procesarea cererilor clienților poate duce la o scădere a performanței și, în unele cazuri, la eșecuri în procesarea cererilor. Limitarea numărului de conexiuni va afecta grav performanța unui site Web încărcat moderat, dar va fi benefică dacă pagina are trafic redus. Verificați întotdeauna modul în care modificările pe care le faceți afectează performanța și sănătatea generală a paginii Web.

Despre eroul zilei

Nginx este unul dintre cele mai puternice și mai populare servere web din lume. Potrivit Netcraft, este folosit pentru a susține peste 12 milioane de site-uri web din întreaga lume, inclusiv mastodonti precum Rambler, Yandex, Begun, WordPress.com, Wrike, vkontakte.ru, megashara.com, Librusec și Taba.ru. O arhitectură competentă bazată pe conexiuni de multiplexare folosind apeluri de sistem select, epoll (Linux), kqueue (FreeBSD) și un mecanism de gestionare a memoriei bazat pe pool-uri (buffer-uri mici de la 1 la 16 KB) permite nginx să nu se lade chiar și la sarcini foarte mari, rezistând peste 10.000 de conexiuni simultane (așa-numita problemă C10K). Scris inițial de Igor Sysoev pentru Rambler și deschis în 2004 sub o licență asemănătoare BSD.

In contact cu

Si altii). Versiune curentă,0.6.x, este considerat stabil din punct de vedere al fiabilității, iar lansările din ramura 0.7 sunt considerate instabile. Este important de remarcat faptul că funcționalitatea unor module se va modifica, drept urmare directivele se pot modifica și, prin urmare compatibilitate inversăîn nginx înainte de versiunea 1.0.0 nu este garantat.

De ce este nginx atât de bun și de ce administratorii proiectelor cu încărcare mare îl iubesc atât de mult? De ce să nu folosești Apache?

De ce este rău Apache?

Mai întâi trebuie să explicăm cum funcționează în general. servere de rețea. Cei familiarizați cu programarea în rețea știu că există în esență trei modele de funcționare a serverului:

1. Consistent. Serverul deschide o priză de ascultare și așteaptă să apară o conexiune (este într-o stare blocată în timp ce așteaptă). Când ajunge o conexiune, serverul o procesează în același context, închide conexiunea și așteaptă din nou conexiunea. Evident, acesta este departe de cel mai bun mod, mai ales când lucrul cu un client durează mult și există o mulțime de conexiuni. În plus, modelul secvenţial are mult mai multe dezavantaje (de exemplu, incapacitatea de a utiliza mai multe procesoare), iar în condiţii reale practic nu este folosit.
2. Multi-proces (multi-threaded). Serverul deschide o priză de ascultare. Când sosește o conexiune, o acceptă, după care creează (sau preia dintr-un grup de conexiuni pre-create) un nou proces sau fir care poate funcționa cu conexiunea atâta timp cât se dorește și, la terminarea lucrului, se încheie sau întoarce-te la piscină. Între timp, firul principal este gata să accepte o nouă conexiune. Acesta este cel mai popular model deoarece este relativ ușor de implementat, permite efectuarea de calcule complexe și consumatoare de timp pentru fiecare client și utilizează toate procesoarele disponibile. Un exemplu de utilizare a acestuia este Apache Web Server. Această abordare are însă și dezavantaje: când cantitati mari conexiunile simultane creează o mulțime de fire de execuție (sau, chiar mai rău, procese), iar sistemul de operare cheltuiește o mulțime de resurse pe comutatoarele de context. Este deosebit de rău când clienții acceptă foarte încet conținutul. Acest lucru are ca rezultat sute de fire de execuție sau procese ocupate cu trimiterea de date către clienții lenți, ceea ce creează încărcare suplimentară pe planificatorul sistemului de operare, crește numărul de întreruperi și consumă destul de multă memorie.
3. Prize non-blocante/mașină de stat. Serverul operează într-un singur fir, dar folosește socket-uri neblocante și un mecanism de sondare. Acestea. server la fiecare iterație buclă nesfârșită Selectează din toate soclulurile pe cel care este gata să primească/trimite date folosind apelul select(). După ce socket-ul este selectat, serverul îi trimite date sau îl citește, dar nu așteaptă confirmarea, ci trece la starea inițială și așteaptă un eveniment pe alt socket sau îl prelucrează pe următorul în care a avut loc evenimentul în timpul procesării precedentul. Acest model Folosește procesorul și memoria foarte eficient, dar este destul de complex de implementat. În plus, în cadrul acestui model, procesarea evenimentelor pe un socket trebuie să aibă loc foarte rapid - altfel multe evenimente se vor acumula în coadă și, în cele din urmă, se vor deborda. Acesta este exact modelul pe care lucrează nginx. În plus, vă permite să rulați mai multe procese de lucru (așa-numitele lucrători), de exemplu. poate folosi mai multe procesoare.

Deci, imaginați-vă următoarea situație: 200 de clienți cu un canal de 256 Kbit/s se conectează la un server HTTP cu un canal de 1 Gbit/s:

Ce se întâmplă în cazul Apache? Sunt create 200 de fire/procese care generează conținut relativ rapid (ar putea fi ceva de genul pagini dinamice, și fișierele statice citite de pe disc), dar le livrează încet clienților. Sistemul de operare este forțat să facă față unei mulțimi de fire și blocări I/O.

În această situație, Nginx cheltuiește cu un ordin de mărime mai puține resurse ale sistemului de operare și memorie pe fiecare conexiune. Cu toate acestea, acest lucru dezvăluie o limitare a modelului de rețea nginx: nu poate genera conținut dinamic intern, deoarece acest lucru va duce la blocaje în interiorul nginx. Desigur, există o soluție: nginx poate trimite astfel de solicitări (pentru generarea de conținut) către orice alt server web (de exemplu, același Apache) sau către un server FastCGI.

Să considerăm mecanismul de funcționare al combinației nginx ca server „principal” și Apache ca server pentru generarea de conținut dinamic:

Nginx acceptă conexiunea de la client și citește întreaga solicitare de la acesta. Trebuie remarcat aici că până când nginx nu a citit întreaga solicitare, nu o trimite pentru „procesare”. Din acest motiv, aproape toți indicatorii de progres al încărcării fișierelor se „rup” - totuși, este posibil să-i remediați folosind modulul upload_progress de la terț (acest lucru va necesita modificarea aplicației).

După ce nginx a citit întregul răspuns, deschide o conexiune la Apache. Acesta din urmă își face treaba (generează conținut dinamic), după care își trimite răspunsul către nginx, care îl tamponează în memorie sau într-un fișier temporar. Între timp, Apache eliberează resurse. În continuare, nginx livrează lent conținutul clientului, în timp ce cheltuiește ordin de mărime mai puține resurse decât Apache.

Această schemă se numește frontend + backend și este folosită foarte des.

Instalare

Deoarece nginx abia începe să câștige popularitate, există unele probleme cu pachetele binare, așa că fiți pregătit să îl compilați singur. De obicei, nu există probleme cu aceasta, trebuie doar să citiți cu atenție rezultatul comenzii./configure --help și să selectați opțiunile de compilare de care aveți nevoie, de exemplu acestea:

./configure\
--prefix=/opt/nginx-0.6.x \ # prefix de instalare
--conf-path=/etc/nginx/nginx.conf \ # locația fișierului de configurare
—pid-path=/var/run/nginx.pid \ # ... și fișierul pid
—user=nginx \ # nume de utilizator sub care va rula nginx
—cu-http_ssl_module —cu-http_gzip_static_module —cu-http_stub_status_module \ # listă de necesare
—fără-http_ssi_module —fără-http_userid_module —fără-http_autoindex_module —fără-http_geo_module —fără-http_referer_module —fără-http_memcached_module —fără-http_limit_zone_module # ... și module inutile

După configurare, ar trebui să rulați instalarea standard make && make, după care puteți utiliza nginx.

În plus, în Gentoo puteți utiliza un ebuild din arborele standard de porturi; în RHEL/CentOS de către depozitul epel (care conține nginx 0.6.x) sau srpm pentru versiunea 0.7, care poate fi descărcat de aici: http://blogs.mail.ru/community/nginx; pe Debian puteți folosi pachetul nginx din ramura instabilă.

Fișier de configurare

Fișierul de configurare nginx este foarte convenabil și intuitiv. Se numește de obicei nginx.conf și se află în $prefix/conf/ dacă locația nu a fost suprascrisă în timpul compilării. Îmi place să îl pun în /etc/nginx/, la fel ca și dezvoltatorii tuturor pachetelor menționate mai sus.

Structura fișierului de configurare este următoarea:

utilizator nginx; # nume de utilizator cu ale cărui drepturi va rula nginx
lucrător_procese 1; # număr de procese de lucru
evenimente (
<…># acest bloc specifică mecanismul de interogare care va fi utilizat (vezi mai jos) și numărul maxim de conexiuni posibile
}

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

# descrierea serverelor (aceasta este ceea ce se numește VirtualHost în apache)
Server (
# adresa și numele serverului
asculta *:80;
nume_server aaa.bbb;

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

# și așa puteți defini o locație, pentru care puteți, de asemenea, să suprascrieți aproape toate directivele specificate la niveluri mai globale
locație /abcd/ (
<директивы>;
}
# În plus, puteți face locația folosind o expresie regulată, de exemplu, ca aceasta:
locație ~ \.php$ (
<директивы>;
}
}

# un alt server
Server (
asculta *:80;
nume_server ccc.bbb;

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

Vă rugăm să rețineți că fiecare directivă trebuie să se încheie cu punct și virgulă.
Reverse proxy și FastCGI

Deci, mai sus ne-am uitat la avantajele schemei frontend + backend, ne-am dat seama de instalarea, structura și sintaxa fișierului de configurare, iar acum ne vom uita la cum să implementăm reverse proxy în nginx.

Și este foarte simplu! De exemplu astfel:

Locație/(
proxy_pass http://1.2.3.4:8080;
}

În acest exemplu, toate cererile care se încadrează în locație / vor fi trimise proxy către serverul 1.2.3.4, portul 8080. Acesta poate fi fie apache, fie orice alt server http.

Cu toate acestea, există mai multe subtilități legate de faptul că aplicația va considera că, în primul rând, toate solicitările îi vin de la aceeași adresă IP (care poate fi privită, de exemplu, ca o încercare de atac DDoS sau de ghicire a parolei), și în al doilea rând, să presupunem că rulează pe gazda 1.2.3.4 și pe portul 8080 (respectiv, generați redirecționări incorecte și link-uri absolute). Pentru a evita aceste probleme fără a fi nevoie să rescrieți aplicația, găsesc la îndemână următoarea configurație:
Nginx ascultă interfața externă pe portul 80.

Dacă backend-ul (să spunem Apache) este situat pe aceeași gazdă ca nginx, atunci „ascultă” pe portul 80 pe 127.0.0.1 sau pe altă adresă IP internă.

Configurația nginx în acest caz arată astfel:

Server (
asculta 4.3.2.1:80;
# setați antetul Host și X-Real-IP: pentru fiecare solicitare trimisă către backend
proxy_set_header X-Real-IP $adresă_la distanță;
proxy_set_header Gazdă $gazdă:$proxy_port;
# sau „proxy_set_header Host $host;” dacă aplicația va adăuga:80 la toate linkurile
}

Pentru ca aplicația să facă distincția între adresele IP ale vizitatorilor, trebuie să instalați fie modulul mod_extract_forwarded (dacă este executat server Apache), sau modificați aplicația astfel încât să preia informații despre adresa IP a utilizatorului din antetul HTTP X-Real-IP.

O altă opțiune de backend este utilizarea FastCGI. În acest caz, configurația nginx va arăta cam așa:

Server (
<…>

# locație unde vor merge cererile pentru scripturi php
locație ~ .php$ (
fastcgi_pass 127.0.0.1:8888; # determinați adresa și portul serverului fastcgi,
fastcgi_index index.php; # ...fișier index

# și câțiva parametri care trebuie să fie transferați serverului fastcgi, astfel încât acesta să înțeleagă ce script să execute și cu ce parametri:
fastcgi_param SCRIPT_FILENAME /usr/www/html$fastcgi_script_name; # nume de script
fastcgi_param QUERY_STRING $șir_interogare; # șir de interogare
# și parametrii de solicitare:
fastcgi_param REQUEST_METHOD $cerere_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
}

# datorită faptului că locațiile cu expresii regulate au o „prioritate” mare, toate solicitările non-php vor cădea aici.

Locație/(
rădăcină /var/www/html/
}

Statică

Pentru a încărca mai puțin backend-ul, este mai bine să serviți fișiere statice numai prin nginx - face față mai bine acestei sarcini, deoarece cheltuiește mult mai puține resurse pentru fiecare solicitare (nu este nevoie să generați un nou proces, iar procesul Nginx consumă de obicei mai puțină memorie și poate deservi multe conexiuni).

În fișierul de configurare arată cam așa:

Server (
asculta *:80;
nume_server serverul meu.com;

Locație/(
proxy_pass


„>http://127.0.0.1:80;

}

# presupunem că toate fișierele statice sunt în /fișiere
locație /fișiere/ (
rădăcină /var/www/html/; # indica calea către fs
expiră 14d; # adăugați antetul Expires:
error_page 404 = @back; # iar dacă fișierul nu este găsit, îl trimitem la locația numită @back
}

# solicitările de la /fișiere pentru care nu a fost găsit niciun fișier sunt trimise la backend și poate fi generată fișierul necesar, sau spectacol mesaj frumos despre eroare
locație @back (
proxy_pass
"title="http://127.0.0.1:80;

„>http://127.0.0.1:80;

}

Dacă toate statisticile nu sunt plasate într-un anumit director, atunci utilizați o expresie regulată:

locație ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf |js)$ (
# similar cu ceea ce este mai sus, numai toate cererile care se termină cu unul dintre sufixele specificate vor merge în această locație
rădăcină /var/www/html/;
error_page 404 = @back;
}

Din păcate, nu este implementat în nginx lucru asincron cu dosare. Cu alte cuvinte, lucrătorul nginx este blocat la operațiunile I/O. Deci dacă aveți o mulțime de fișiere statice și mai ales dacă sunt citite din ele diferite discuri, este mai bine să creșteți numărul de procese de lucru (la un număr care este de 2-3 ori mai mare decât numărul total de capete de pe disc). Acest lucru, desigur, crește încărcarea sistemului de operare, dar performanța generală crește. Pentru a lucra cu o cantitate tipică de conținut static (nu un număr foarte mare de fișiere relativ mici: CSS, JavaScript, imagini), unul sau două fluxuri de lucru sunt suficiente.

Va urma

Legături

Aici puteți găsi informații suplimentare despre nginx:

Nginx este un server web și un proxy de e-mail care este disponibil public din 2004. Dezvoltarea proiectului a început în 2002; în rusă numele sună ca engine-ex. Fiind creația celebrului 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 prin primirea lor 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, proxy NAT a fost integrat în distribuția 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 pe server a fișierelor index, interogări statice, generarea de descriptori cache a fișierelor deschise, listă 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 vorbim despre modalitățile specifice de utilizare a acestui server web, acesta 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 a unui 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 face în Nginx folosind 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. Dacă există un număr mare de solicitări către fișiere statice, este logic să creați un server separat și să 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 un 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 închide conexiunea cu un sentiment de realizare. Nginx poate trimite acum o pagină unui utilizator atât 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 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.

Buna ziua, dragă utilizatorule Habrakhabra. Discuția mea va fi despre cum să pregătesc terenul pentru proiectele locale de dezvoltare web în sala de operație sistem Ubuntu 16.04.1 LTS.

În acest articol, aș dori să elimin și să explic posibilele dificultăți asociate cu instalarea și configurarea software-ului care este necesar pentru dezvoltarea web modernă, care pot fi întâlnite de dezvoltatorii începători și de alții.

Tehnologii care vor fi folosite în articol: nginx, php-fpm.

Înainte de a începe povestea, vreau să remarc că toate aceste acțiuni le-am făcut pe un sistem „gol”.
Voi lucra cu managerul de pachete aptitude. De asemenea, recomand să actualizați indexul pachetelor și pachetele în sine înainte de a instala software-ul. În acest articol vom face acești pași împreună.

Merge!

Instalarea unui manager de pachete aptitudine, actualizări de index și pachet

Instalare:

Sudo apt install aptitude
Actualizăm indexul.

Sudo aptitude update
Actualizăm pachetele (comanda va actualiza toate pachetele pentru care există versiuni noi; dacă pachetele trebuie eliminate, se va face).

Sudo aptitude complet upgrade

Instalare și configurare nginx(versiunea >= 1.10.0)

Instalăm.

Sudo aptitude instalează nginx
Hai să lansăm.

Serviciul Sudo nginx începe
Verificăm versiunea pentru a ne asigura că nu am instalat una veche, adică mai mică decât 1.10.0.

Instalarea și lansarea au fost finalizate, acum să mergem la directorul în care este instalat nginx-ul nostru și să ne uităm la structura acestuia. Directorul nginx se află pe această cale:

Cd /etc/nginx/
Puteți vizualiza conținutul unui director cu comanda ls; cu steaguri -la va fi mai convenabil să vizualizați conținutul directorului (de fapt, această comandă cu steaguri specifice poate fi descrisă mai detaliat și mai precis, dar avem un alt subiect astăzi).

Ls-la
Momentan suntem interesați de cele două cataloage pe care le vedeți în captură de ecran. Acestea sunt directoarele site-uri disponibile și site-urile activate.

Să mergem la directorul site-available și să începem configurarea gazdei noastre virtuale (site).

Cd /etc/nginx/sites-available
Înainte de a începe să creăm fișierul de configurare, să verificăm ce avem acest catalog. In cazul meu, directorul nu este gol, contine deja fisiere de configurare, le-am sters ca sa nu va induc in eroare.

Digresiune importantă

În cazul instalării nginx „de la zero”, tocmai „de la zero”, de când dezinstalați nginx cu comanda
sudo apt-get remove nginx sau sudo apt remove nginx rămân fișierele de configurare și dacă brusc nu înțelegeți de ce nginx nu funcționează și doriți să-l reinstalați (de obicei, începătorii recurg la acest lucru utilizatorii Linux), atunci nici după reinstalare nu va funcționa corect, deoarece fișierele de configurare vechi (nu sunt șterse după eliminare cu comanda remove) conțin setări incorecte, acestea vor trebui șterse sau configurate corect, abia atunci nginx va funcționa.

Recomand ștergerea cu comanda sudo apt-get purge nginx sau sudo apt purge nginx. Dacă utilizați managerul de pachete aptitude, comanda sudo aptitude purge nginx elimină întregul pachet împreună cu toate dependențele și fișierele de configurare.

În acest director va exista un fișier implicit, numit implicit. Va contine un fisier de configurare cu un exemplu, cu comentarii, il poti studia dupa bunul plac, sau il poti sterge complet (poti oricand sa faci referire la documentatia oficiala).

Ls-la

Să ne creăm propriul fișier de configurare, care va corespunde numelui de domeniu al site-ului nostru local (sau unul real, dacă îi cunoașteți deja numele). Acest lucru este convenabil, în viitor, când există multe fișiere de configurare, vă va scuti de confuzie în ele. Pentru mine acest fișier se va numi project.local.

Sudo touch project.local
Să vedem ce s-a întâmplat.

Acum să-l deschidem în editor, îl voi deschide în nano.

Sudo nano project.local
Vedem că este gol. Acum să trecem la crearea fișierului nostru. Trebuie să aduceți configurația în formular așa cum este scris mai jos. Voi descrie doar directivele vitale ale acestui dosar, nu voi descrie restul, deoarece acest lucru nu este important în acest moment, la urma urmei, avem un subiect setări de bază. Aceste setări „diapozitive” sunt suficiente pentru a dezvolta proiecte la nivel local, nu numai mici, ci și destul de mari. În articolele următoare voi descrie separat fiecare dintre directivele utilizate (așa se numesc liniile, de exemplu server_name) din acest fișier.

Vedeți comentariile direct în fișierul de configurare.

Server (ascultă 80; # port ascultă la nginx server_name project.local; # Numele domeniului legate de curent gazdă virtuală root /home/stavanger/code/project.local; # directorul în care se află proiectul, calea către indexul punctului de intrare index.php; # add_header Access-Control-Allow-Origin *; # serviți fișierele statice direct locația ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ ( access_log off; expiră max; log_not_found off; ) locație / ( # add_header Access-Control-Allow- Origine *; try_files $uri $uri/ /index.php?$query_string; ) locație ~* \.php$ (try_files $uri = 404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix :/var/run/php/php7.0-fpm.sock; # conectați soclu-ul php-fpm fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; ) locație ~ /\.ht ( deny all; ) )
Salvați fișierul. Acum trebuie să verificăm dacă există erori în el. Putem face asta ca o echipă.

Sudo nginx -t
Dacă vedem astfel de informații ca în captura de ecran, atunci totul este corect și putem continua configurarea. Dacă primiți erori, merită să verificați din nou fișierul de configurare.

Acum trebuie să activăm fișierul de configurare, în directorul /etc/nginx/sites-enabled/ trebuie să creăm un link simbolic (link simbolic). Dacă ați instalat nginx de la zero, atunci în acest director există un link simbolic către fișierul implicit, despre care a fost discutat mai sus; îl puteți șterge dacă nu aveți nevoie de el. Accesați directorul dorit.

Cd /etc/nginx/sites-enabled/
Acum suntem în directorul potrivit. Să creăm linkul nostru simbolic. Pentru a crea, utilizați comanda ln cu indicatorul -s, apoi vom indica calea către proiectul nostru.config local.

Sudo ln -s /etc/nginx/sites-available/project.local
Să ne uităm la linkul simbolic creat.

Pentru a ne asigura că încă facem totul corect, să rulăm din nou comanda.

Fişier gazde

Acest fișier se află la /etc/hosts. Prezența intrărilor în acesta vă permite să rulați nginx folosind localhost ca domeniu. În acest fișier puteți atribui aliasuri alternative, de exemplu pentru proiectul nostru project.local, vom atribui domeniul project.local.

Deschideți fișierul în editorul nano.

Sudo nano /etc/hosts
Veți avea alte informații în acest fișier, ignorați-l. Trebuie doar să adăugați o linie ca în captura mea de ecran.

Instalare php-fpm (>=7.0)

sudo aptitude instalează php-fpm
Control versiunea instalată, pentru orice eventualitate, deși în Ubuntu 16.04.1 versiunea 7.0 este în depozite.

PHP-fpm7.0 -v

Să ne asigurăm că totul este în regulă. Să începem php-fpm.

Serviciul Sudo php7.0-fpm începe
Dacă editați configurațiile, nu uitați să reporniți demonul. Așa face. Dar nu vom avea nevoie.

Reporniți serviciul Sudo php7.0-fpm
Aceasta finalizează instalarea și configurarea php-fpm. Într-adevăr, asta-i tot. Acest lucru nu este magic; calea către socket-ul php-fpm a fost deja specificată în fișierul de configurare. Desigur, este posibil să aveți nevoie de unele extensii PHP pentru a dezvolta proiecte personale, dar le puteți instala după cum este necesar.

Acum să mergem la directorul cu proiectul nostru, îl am pe această cale.

Cd /home/stavanger/code/project.local
Să mergem la directorul de mai sus și să facem permisiunile 777 (adică vom face drepturi depline director cu proiectul nostru de proiect.local). Acest lucru ne va salva de probleme inutile în viitor.

Cd .. sudo chmod -R 777 proiect.local
Aceasta completează configurarea software-ului, să creăm un fișier de test în directorul nostru de lucru project.local și să ne asigurăm că totul funcționează. Voi crea un fișier index.php cu acest conținut.

Mergem la browser și vedem că totul funcționează excelent pentru noi! interpret PHP inclusiv.

În ceea ce privește cititorii, Stavanger.