NGINX-server-Web ad alte prestazioni progettato per casi d'uso con traffico elevato | Linuxiano.it
Privacy Policy

NGINX-server-Web ad alte prestazioni progettato per casi d’uso con traffico elevato

NGINX-server-Web

Come configurare NGINX

NGINX è un server Web leggero e ad alte prestazioni progettato per casi d’uso con traffico elevato

Una delle caratteristiche più forti di NGINX è la capacità di servire in modo efficiente contenuti statici come HTML e file multimediali utilizzando un modello asincrono basato sugli eventi che fornisce prestazioni prevedibili sotto carico.

Trasferisce contenuti dinamici a CGI, FastCGI o altri server Web come Apache. Questo contenuto viene quindi restituito a NGINX per la consegna al client. Questo documento ti renderà familiare con i parametri e le convenzioni NGINX di base.

Direttive, blocchi e contesti Permalink

Tutti i file di configurazione NGINX si trovano nella directory /etc/nginx/. Il file di configurazione principale è /etc/nginx/nginx.conf.

Le opzioni di configurazione in NGINX sono chiamate direttive, che sono organizzate in gruppi noti come blocchi o contesti. I due termini sono sinonimi.

Le righe precedute da un carattere # sono commenti non interpretati da NGINX. Le righe contenenti direttive devono terminare con a; o NGINX non riuscirà a caricare la configurazione e segnalerà un errore.

Di seguito è riportata una copia condensata del file /etc/nginx/nginx.conf che è incluso con le installazioni dai repository NGINX. Il file inizia con 5 direttive: user , worker_processes , error_log e pid . Questi sono al di fuori di qualsiasi blocco o contesto specifico, quindi si dice che esistano nel contesto main. Gli events e i blocchi http sono aree per direttive aggiuntive e esistono anche nel contesto main .

Vedere i documenti NGINX per le spiegazioni di queste direttive e altre disponibili nel contesto main:

user nginx;
worker_processes 1;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
. . .
}

http {
. . .
}

Installazione di nginx-server-web

Potete verificare se il software è installato con il seguente comando:

Terminale
  • nginx -t

Se vedete questo messaggio nel terminale:

Comando «nginx» non trovato, ma può essere installato con:

Terminale
  • sudo  -s
  • apt install nginx-core
  • apt install nginx-extras
  • apt install nginx-full
  • apt install nginx-light

nginx in questo caso non è installato, per installare copiate il comando che desiderate (nel mio caso ho scelto sudo apt install nginx-core ) e incollatelo nel terminale Nginx sarà installato sul vostro sistema operativo.

Per verificare se l’ installazione è andata a buon fine aprite il browser e incollate questo comando:

browser
  • file:///usr/share/nginx/html/index.html

nginx-server-web

Il blocco http Permalink

Il blocco http contiene direttive per la gestione del traffico web. Queste direttive sono spesso definite universali perché sono trasmesse a tutte le configurazioni del sito Web offerte da NGINX. Vedere i documenti NGINX per un elenco di direttive disponibili per il blocco http:

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

log_format main ‘$remote_addr – $remote_user [$time_local] “$request” ‘
‘$status $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent” “$http_x_forwarded_for”‘;

access_log /var/log/nginx/access.log main;

sendfile on;
#tcp_nopush on;

keepalive_timeout 65;

#gzip on;

include /etc/nginx/conf.d/*.conf;
}

Blocchi del server Permalink

Il blocco http sopra contiene una direttiva che indica a NGINX dove si trovano i file di configurazione del sito web.

Se hai installato dal repository NGINX-server-web ufficiale, questa linea dirà /etc/nginx/conf.d/*.conf; come fa nel blocco http sopra. Ogni sito Web ospitato con NGINX deve avere il proprio file di configurazione in /etc/nginx/conf.d/, con il nome formattato come example.com.conf. I siti che sono disabilitati (non serviti da NGINX) dovrebbero essere denominati example.com.conf.disabled.

Se hai installato NGINX dai repository Debian o Ubuntu, questa riga include /etc/nginx/sites-enabled/*;. La cartella ../sites-enabled/ contiene simbolici ai file di configurazione del sito memorizzati in /etc/nginx/sites-available/. I sites-available nei sites-available possono essere disabilitati rimuovendo il collegamento simbolico ai sites-enabled.

A seconda dell’origine dell’installazione, troverai un file di configurazione di esempio in /etc/nginx/conf.d/default.conf o etc/nginx/sites-enabled/default.

Indipendentemente dall’origine dell’installazione, i file di configurazione del server conterranno un blocco (o blocchi) del server per un sito Web. Per esempio:

server {
listen 80 default_server;
listen [::]:80 default_server;
server_name example.com www.example.com;
root /var/www/example.com;
index index.html;
try_files $uri /index.html;
}

Porte d’ascolto Permalink

La direttiva listen dice a NGINX il nome host / IP e la porta TCP dove dovrebbe ascoltare le connessioni HTTP. L’argomento default_server indica che questo host virtuale risponderà alle richieste sulla porta 80 che non corrisponde in modo specifico all’istruzione di ascolto di un altro host virtuale. La seconda istruzione ascolta IPv6 e si comporta allo stesso modo.

Hosting virtuale basato sul nome Permalink

La direttiva server_name consente al server_name più domini da un singolo indirizzo IP.  Il server decide quale dominio servire in base all’intestazione della richiesta che riceve.

Generalmente,  devi creare un file per dominio o sito che desideri ospitare sul tuo server. Ecco alcuni esempi:

1. Elabora richieste per example.com e www.example.com:

server_name example.com www.example.com;

2. La direttiva server_name può anche utilizzare i caratteri jolly. *.example.com e .example.com al server di elaborare le richieste per tutti i sottodomini di example.com:

server_name *.example.com;
server_name .example.com;

3. Elabora richieste per tutti i nomi di dominio che iniziano con l’ example.:

server_name example.*;

NGINX consente di specificare i nomi dei server che non sono nomi di dominio validi utilizzando il nome dall’intestazione HTTP per rispondere alle richieste, indipendentemente dal fatto che il nome del dominio sia valido o meno.

L’utilizzo di nomi host non di dominio sono utili se il tuo server si trova su una LAN o se conosci già tutti i client che faranno richieste al server. Ciò include i server proxy front-end con le voci /etc/hosts configurate per l’indirizzo IP su cui NGINX è in ascolto.

Blocchi di posizione

L’impostazione della location consente di configurare il modo in cui NGINX risponderà alle richieste di risorse all’interno del server. Proprio come la direttiva server_name indica a NGINX come elaborare le richieste per il dominio, le direttive sulla location coprono le richieste di file e cartelle specifici, come http://example.com/blog/ . Ecco alcuni esempi:

location / { }
location /images/ { }
location /blog/ { }
location /planet/ { }
location /planet/blog/ { }

Le posizioni sopra sono corrispondenze di una stringa letterale, che corrisponde dopo il segmento host a qualsiasi parte di una richiesta HTTP:

Richiesta: http://example.com/

Resi: supponendo che esista una voce server_name per example.com , la location / direttiva determinerà cosa succede con questa richiesta:

NGINX soddisfa sempre le richieste utilizzando la corrispondenza più specifica:

Richiesta: http://example.com/planet/blog/ o http://example.com/planet/blog/about/

Resi: questo è soddisfatto dalla location /planet/blog/ direttiva perché è più specifico, anche se location /planet/ corrisponde anche a questa richiesta:

location ~ IndexPage\.php$ { }
location ~ ^/BlogPlanet(/|/index\.php)$ { }

Quando una direttiva di location è seguita da una tilde ( ~ ), NGINX esegue una corrispondenza di espressioni regolare. Queste corrispondenze sono sempre case-sensitive. Quindi, IndexPage.php corrisponderebbe al primo esempio sopra, ma indexpage.php non lo farebbe. Nel secondo esempio, l’espressione regolare:

^/BlogPlanet(/|index\.php)$ corrisponderà alle richieste per /BlogPlanet/ e /BlogPlanet/index.php , ma non /BlogPlanet , /blogplanet/ , o /blogplanet/index.php . NGINX usa le espressioni regolari compatibili con Perl (PCRE)

location ~* \.(pl|cgi|perl|prl)$ { }
location ~* \.(md|mdwn|txt|mkdn)$ { }

Se desideriamo che le corrispondenze siano senza distinzione tra maiuscole e minuscole, utilizziamo una tilde con un asterisco ( ~ *). Gli esempi sopra specificano in che modo nginx dovrebbe elaborare richieste che terminano in una particolare estensione di file. Nel primo esempio, qualsiasi file che termina in: .pl , .PL , .cgi , .CGI , .perl , .Perl , .prl e .PrL (tra gli altri) corrisponderà alla richiesta:

location ^~ /images/IndexPage/ { }
location ^~ /blog/BlogPlanet/ { }

L’aggiunta di un segno di omissione e di una tilde ( ^ ~ ) alle direttive sulla location indica a NGINX, se corrisponde a una particolare stringa, di interrompere la ricerca di corrispondenze più specifiche e di utilizzare invece le direttive. Oltre a questo, queste direttive funzionano come le corrispondenze stringa letterali nel primo gruppo. Anche se c’è una partita più specifica più tardi, se una richiesta corrisponde a una di queste direttive, verranno utilizzate le impostazioni qui. Vedi sotto per maggiori informazioni sull’ordine e priorità dell’elaborazione della direttiva sulla location:

location = / { }

Infine, se aggiungi un segno di uguale ( = ) all’impostazione di location , questo impone una corrispondenza esatta con il percorso richiesto e quindi interrompe la ricerca di corrispondenze più specifiche. Ad esempio, l’esempio finale corrisponderà solo a http://example.com/ , non http://example.com/index.html. L’utilizzo di corrispondenze esatte può velocizzare leggermente i tempi di richiesta, il che può essere utile se hai richieste particolarmente popolari.

Le direttive sono elaborate nel seguente ordine:

Le corrispondenze delle stringhe esatte sono elaborate per prime. Se viene trovata una corrispondenza, NGINX interrompe la ricerca e soddisfa la richiesta.
Le restanti direttive string letterali sono elaborate successivamente. Se NGINX incontra una corrispondenza in cui viene usato l’argomento ^ ~ , si ferma qui e soddisfa la richiesta. In caso contrario, NGINX continua ad elaborare direttive di localizzazione.
Tutte le direttive di posizione con espressioni regolari ( ~ e ~ *) sono elaborate. Se un’espressione regolare corrisponde alla richiesta, nginx interrompe la ricerca e soddisfa la richiesta.
Se nessuna espressione regolare corrisponde, viene utilizzata la corrispondenza stringa letterale più specifica.

Assicurati che ogni file e cartella in un dominio corrisponda ad almeno una direttiva di location .

Root e indice di posizione Permalink

L’impostazione della location è un’altra variabile che ha il proprio blocco d’  argomenti.

Una volta che NGINX ha determinato quale direttiva di location si adatta meglio a una determinata richiesta, la risposta a questa richiesta è determinata dal contenuto del blocco di direttive di location associato. Ecco un esempio:

location / {
root html;
index index.html index.htm;
}

In questo esempio, la root del documento si trova nella directory html/. Sotto il prefisso d’ installazione predefinito per NGINX, il percorso completo di questa posizione è /etc/nginx/html/ .

Richiesta: http://example.com/blog/includes/style.css

Restituisce: NGINX tenterà di servire il file situato in /etc/nginx/html/blog/includes/style.css

La variabile index indica a NGINX quale file pubblicare se nessuno è specificato. Per esempio:

Richiesta: http://example.com

Restituisce: NGINX tenterà di servire il file situato in /etc/nginx/html/index.html.

Se vengono specificati più file per la direttiva index , NGINX elabora l’elenco in ordine e soddisfa la richiesta con il primo file esistente. Se index.html non esiste nella directory pertinente, verrà utilizzato index.htm. Se nessuno dei due esiste, verrà inviato un messaggio 404.

Ecco un esempio più complesso, che mostra un insieme di direttive di location per un server che risponde al dominio example.com:

location / {
root /srv/www/example.com/public_html;
index index.html index.htm;
}

location ~ \.pl$ {
gzip off;
include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/var/run/fcgiwrap.socket;
fastcgi_index index.pl;
fastcgi_param SCRIPT_FILENAME /srv/www/www.example.com/public_html$fastcgi_script_name;
}

In questo esempio, tutte le richieste di risorse che terminano con un’estensione .pl vengono gestite dal secondo blocco di posizione, che specifica un gestore fastcgi per queste richieste. In caso contrario, NGINX utilizza la prima direttiva di posizione. Le risorse si trovano nel file system in /srv/www/example.com/public_html/ . Se nella richiesta non è specificato alcun nome di file, NGINX cercherà e fornirà il file index.html o index.htm. Se non vengono trovati file di index , il server restituirà un errore 404.

Analizziamo cosa succede durante alcune richieste:

Richiesta: http://example.com/

Restituisce: /srv/www/example.com/public_html/index.html se esiste. Se quel file non esiste, verrà pubblicato /srv/www/example.com/public_html/index.htm. Se nessuno dei due esiste, NGINX restituisce un errore 404.

Richiesta: http://example.com/blog/

Restituisce: /srv/www/example.com/public_html/blog/index.html se esiste. Se quel file non esiste, verrà pubblicato /srv/www/example.com/public_html/blog/index.htm. Se nessuno dei due esiste, NGINX restituisce un errore 404.

Richiesta: http://example.com/tasks.pl

Restituisce: NGINX utilizzerà il gestore FastCGI per eseguire il file situato in /srv/www/example.com/public_html/tasks.pl e restituire il risultato.

Richiesta: http://example.com/username/roster.pl

Restituisce: NGINX utilizzerà il gestore FastCGI per eseguire il file che si trova in /srv/www/example.com/public_html/username/roster.pl e restituire il risultato.

Esempio d’uso

Per le seguenti operazioni dobbiamo essere “root”. Apriamo un terminlale e copiamo i seguenti comandi:

Terminale
  • sudo  -s

Ora rechiamoci nella cartella di destinazione creata al momento del’ installazione del software con il comando sotto indicato:

Terminale
  • cd /etc/nginx/conf.d/

Ora apriamo il file vir.conf con il seguente comando:

Terminale
  • gedit vir.conf

All’ interno del file di testo che si aprirà incollate le seguenti righe:

server {
listen 80 default_server;
listen [::]:80 default_server;
server_name example.com www.example.com;
root /var/www/example.com;
index index.html;
try_files $uri /index.html;
}

Ora riavvia il tuo servizio nginx come segue:

Terminale
  • systemctl restart nginx

Ora verifichiamo con il seguente comado:

Terminale
  • curl -I http://www.example.com/index1.jpg

Risultato:

HTTP/1.1 404 Not Found
Cache-Control: max-age=604800
Content-Type: text/html; charset=UTF-8
Date: Sun, 02 Sep 2018 11:01:28 GMT
Expires: Sun, 09 Sep 2018 11:01:28 GMT
Server: EOS (vny006/0453)
Vary: Accept-Encoding
Content-Length: 1270

Rimuovere

Per rimuovere aprite un terminale e copiate il seguente comando:

Terminale
  • sudo apt-get –purge remove nginx

Grazie! per l’utilizzo della Guida di Linuxiano.

Trovi questo tutorial utile? Condividi con i tuoi amici per tenerlo in vita.
Sii il primo a commentare, apprezzo i tuoi suggerimenti. Per ulteriori domande potete commentare qui sotto.