de Stefanos Vardalos

Introducere în NGINX pentru dezvoltatori

Introducere in NGINX pentru dezvoltatori

Imaginați-vă acest lucru – ați creat o aplicație web și acum căutați serverul web potrivit pentru a o găzdui.

Aplicația dvs. poate consta din mai multe fișiere statice – HTML, CSS și JavaScript, un serviciu API backend sau chiar mai multe servicii web. Utilizarea Nginx ar putea fi ceea ce căutați și există câteva motive pentru asta.

NGINX este un server web puternic și folosește o arhitectură non-threaded, bazată pe evenimente, care îi permite să depășească Apache dacă este configurat corect. Poate face, de asemenea, alte lucruri importante, cum ar fi echilibrarea încărcării, cache HTTP, sau poate fi folosit ca un proxy invers.

Introducere in NGINX pentru dezvoltatori
Arhitectura NGINX

În acest articol, voi acoperi câțiva pași de bază despre cum să instalați și să configurați cele mai comune părți ale NGINX.

Instalare de bază – Arhitectură

Există două moduri de a instala NGINX, fie folosind un binar pre-construit, fie construindu-l din sursă.

Prima metodă este mult mai ușoară și mai rapidă, dar construirea ei de la sursă oferă posibilitatea de a include diverse module terțe care fac NGINX și mai puternic. Ne permite să-l personalizăm pentru a se potrivi nevoilor aplicației.

Pentru a instala un pachet Debian preconstruit, singurul lucru pe care trebuie să-l faceți este:

sudo apt-get updatesudo apt-get install nginx

După terminarea procesului de instalare, puteți verifica dacă totul este în regulă executând comanda de mai jos, care ar trebui să tipărească cea mai recentă versiune de NGINX.

sudo nginx -vnginx version: nginx/1.6.2

Noul dvs. server web va fi instalat la locație /etc/nginx/. Dacă intrați în acest folder, veți vedea mai multe fișiere și foldere. Cele mai importante care vor necesita atenția noastră mai târziu sunt fișierul nginx.conf și dosarul sites-available.

Setări de configurare

Setările de bază ale NGINX sunt în nginx.conf fișier, care în mod implicit arată astfel.

user www-data;worker_processes 4;pid /run/nginx.pid;events {	worker_connections 768;	# multi_accept on;}http {	sendfile on;	tcp_nopush on;	tcp_nodelay on;	keepalive_timeout 65;	types_hash_max_size 2048;	# server_tokens off;	# server_names_hash_bucket_size 64;	# server_name_in_redirect off;	include /etc/nginx/mime.types;	default_type application/octet-stream;	access_log /var/log/nginx/access.log;	error_log /var/log/nginx/error.log;	gzip on;	gzip_disable "msie6";	# gzip_vary on;	# gzip_proxied any;	# gzip_comp_level 6;	# gzip_buffers 16 8k;	# gzip_http_version 1.1;	# gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;	include /etc/nginx/conf.d/*.conf;	include /etc/nginx/sites-enabled/*;}

Fișierul este structurat în Contextele. Primul este evenimente Context, iar al doilea este http Context. Această structură permite unele straturi avansate ale configurației dvs., deoarece fiecare context poate avea alte contexte imbricate care moștenesc totul de la părintele lor, dar pot, de asemenea, să suprascrie o setare, după cum este necesar.

Diverse lucruri din acest fișier pot fi modificate în funcție de nevoile dvs., dar NGINX este atât de simplu de utilizat încât puteți merge chiar și cu setările implicite. Unele dintre cele mai importante piese ale fișierului de configurare NGINX sunt:

  • procese_muncitor: Această setare definește numărul de procese de lucru pe care le va folosi NGINX. Deoarece NGINX are un singur thread, acest număr ar trebui să fie de obicei egal cu numărul de nuclee CPU.
  • conexiuni_muncitor: Acesta este numărul maxim de conexiuni simultane pentru fiecare proces muncitor și îi spune muncitorilor noștri procese câte persoane pot fi deservite simultan de NGINX. Cu cât este mai mare, cu atât mai mulți utilizatori simultani vor fi capabili să deservească NGINX.
  • access_log & error_log: Acestea sunt fișierele pe care NGINX le va folosi pentru a înregistra orice erori și a încerca accesul. Aceste jurnale sunt în general revizuite pentru depanare și depanare.
  • gzip: Acestea sunt setările pentru compresia GZIP a răspunsurilor NGINX. Activarea acestuia împreună cu diferitele sub-setări care sunt comentate implicit va avea ca rezultat o actualizare de performanță destul de mare. Din sub-setările GZIP, trebuie avut grijă de gzip_comp_level, care este nivelul de compresie și variază de la 1 la 10. În general, această valoare nu trebuie să fie peste 6 – câștigul în ceea ce privește reducerea dimensiunii este nesemnificativ, deoarece are nevoie de mult mai multă utilizare a procesorului. gzip_types este o listă a tipurilor de răspuns pe care se va aplica compresia.

Instalarea dvs. NGINX poate suporta mult mai mult decât un singur site web, iar fișierele care definesc site-urile serverului dvs. sunt disponibile în directorul / etc / nginx / sites-available.

Cu toate acestea, fișierele din acest director nu sunt „live” – aici puteți avea câte fișiere de definiție a site-ului doriți, dar NGINX nu va face de fapt nimic cu ele decât dacă sunt conectate simbolic în / etc / nginx / director activat de site-uri (le-ați putea copia și acolo, dar link-ul simbolic asigură că există o singură copie a fiecărui fișier de urmărit).

Aceasta vă oferă o metodă de a pune rapid site-urile online și de a le scoate offline, fără a fi necesar să ștergeți efectiv orice fișier – când sunteți gata pentru un site pentru a fi conectat, conectați-l în site-uri activate și reporniți NGINX.

sites-available directorul include configurații pentru gazde virtuale. Aceasta permite configurarea serverului web pentru mai multe site-uri care au configurații separate. Site-urile din acest director nu sunt live și sunt activate numai dacă creăm o legătură simbolică în sites-enabled pliant.

Fie creați un fișier nou pentru aplicația dvs., fie editați-l pe cel implicit. O configurație tipică arată ca cea de mai jos.

upstream remoteApplicationServer {    server 10.10.10.10;}upstream remoteAPIServer {    server 20.20.20.20;    server 20.20.20.21;    server 20.20.20.22;    server 20.20.20.23;}server {    listen 80;    server_name www.customapp.com customapp.com    root /var/www/html;    index index.html        location / {            alias /var/www/html/customapp/;            try_files $uri $uri/ =404;        }        location /remoteapp {            proxy_set_header   Host             $host:$server_port;            proxy_set_header   X-Real-IP        $remote_addr;            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;            proxy_pass http://remoteAPIServer/;        }        location /api/v1/ {            proxy_pass https://remoteAPIServer/api/v1/;            proxy_http_version 1.1;            proxy_set_header Upgrade $http_upgrade;            proxy_set_header Connection 'upgrade';            proxy_set_header Host $host;            proxy_cache_bypass $http_upgrade;            proxy_redirect http:// https://;        }}

La fel ca nginx.conf, acesta folosește și conceptul de contexte imbricate (și toate acestea sunt, de asemenea, imbricate în interiorul HTTP contextul nginx.conf, deci moștenesc tot de la el).

Server context definește un server virtual specific pentru a gestiona solicitările clienților dvs. Puteți avea mai multe blocuri de server, iar NGINX va alege între ele în funcție de listen și server_name directivelor.

În interiorul unui bloc de server, definim multiple Locație contexte care sunt utilizate pentru a decide cum să gestioneze solicitările clientului. Ori de câte ori apare o cerere, NGINX va încerca să-și potrivească URI-ul cu una dintre acele definiții de locație și să o gestioneze în consecință.

Există multe directive importante care pot fi utilizate în contextul locației, cum ar fi:

  • try_files va încerca să difuzeze un fișier static găsit sub folderul care indică directiva rădăcină.
  • proxy_pass va trimite cererea către un server proxy specificat.
  • rescrie va rescrie URI-ul de intrare pe baza unei expresii regulate, astfel încât un alt bloc de locație să îl poată gestiona.

în amonte context definește un grup de servere către care NGINX va proxy cererile. După ce creăm un bloc în amonte și definim un server în interiorul acestuia, îl putem referi după nume în blocurile noastre de locație. Mai mult, un context din amonte poate avea atribuite mai multe servere, astfel încât NGINX va face o oarecare echilibrare a încărcării la proxy-ul cererilor.

Porniți NGINX

După ce am terminat configurarea și am mutat aplicația noastră web în folderul corespunzător, putem porni NGINX folosind comanda de mai jos:

sudo service nginx start

După aceea, ori de câte ori schimbăm ceva în configurația noastră, trebuie doar să-l reîncărcăm (fără timp de oprire) folosind comanda de mai jos.

service nginx reload

În cele din urmă, putem verifica starea NGINX folosind comanda de mai jos.

service nginx status

Concluzie

Cu atât de multe funcții disponibile, NGINX poate fi o modalitate excelentă de a vă servi aplicația sau chiar de a fi folosit ca proxy HTTP sau echilibru de încărcare pentru celelalte servere web. Înțelegerea modului în care funcționează NGINX și gestionează cererile va oferi multă putere scalării și echilibrării încărcării aplicațiilor dvs.