Nel nostro articolo di base abbiamo già riassunto per voi cosa sia NGINX, come in­stal­lar­lo sul vostro sistema e come con­fi­gu­rar­lo. Nel seguente tutorial, vi offriamo una pa­no­ra­mi­ca sui comandi base e sulle pos­si­bi­li­tà di con­fi­gu­ra­zio­ne di questo moderno web server.

L’unità di controllo centrale: nginx.conf

Rispetto ad Apache, NGINX funziona in maniera diversa, in quanto si basa su eventi. Le singole richieste non vengono clas­si­fi­ca­te di volta in volta come un nuovo processo di lavoro, per il quale devono essere caricati tutti i moduli, ma come eventi. Questi eventi vengono suddivisi tra i processi di lavoro esistenti, che vengono mantenuti at­tra­ver­so il processo prin­ci­pa­le so­vraor­di­na­to. Come molti processi di lavoro avvengono e come si di­stri­bui­sco­no le richieste del server (cioè gli eventi), è definito nel file di con­fi­gu­ra­zio­ne nginx.conf. Di solito, li trovate nelle cartelle /usr/local/nginx/conf, /etc/nginx o in /usr/local/etc/nginx. 

Gestire i processi e occuparsi delle nuove con­fi­gu­ra­zio­ni

NGINX inizia l’in­stal­la­zio­ne in maniera au­to­ma­ti­ca, ma potete anche eseguirla, in al­ter­na­ti­va, dando i seguenti comandi:

sudo service nginx start

Potete ve­ri­fi­ca­re se il web server viene avviato, in­ter­ro­gan­do i processi (prima di tutto quello prin­ci­pa­le) con il parametro -s e un preciso segnale. La sintassi del relativo comando è semplice:

sudo nginx -s signal

Tra i “signal” (segnali) avete, tra le altre, le seguenti quattro pos­si­bi­li­tà:

  • stop: NGINX viene subito chiuso.
  • quit: NGINX viene chiuso, subito dopo aver risposto a tutte le richieste attive.
  • reload: il file di con­fi­gu­ra­zio­ne viene ri­ca­ri­ca­to.
  • reopen: i file di log vengono riavviati.

L’opzione reload, con la quale il file di con­fi­gu­ra­zio­ne viene caricato di nuovo, rap­pre­sen­ta una buona op­por­tu­ni­tà per salvare le modifiche, senza dover arrestare il web server o riav­viar­lo. In ogni caso dovete scegliere una variante (il riavvio completo del server o un semplice reload di nginx) affinché le modifiche vengano salvate. Se avete scelto quest’ultima opzione e avete eseguito il comando sot­to­stan­te, il processo prin­ci­pa­le riceve l’istru­zio­ne di apportare le modifiche nel file nginx.conf: 

sudo nginx -s reload

A questo scopo viene ve­ri­fi­ca­ta anche la cor­ret­tez­za della sintassi. Se si riceve una risposta positiva, il processo prin­ci­pa­le avvia nuovi processi di lavoro con le nuove im­po­sta­zio­ni e in­co­min­cia allo stesso tempo a bloccare quelli vecchi. Se non si riesce a con­va­li­da­re la sintassi, viene mantenuta la con­fi­gu­ra­zio­ne pre­ce­den­te. Tutti i processi di lavoro attivi vengono terminati, non appena tutte le richieste attive sono state elaborate.

Tra l’altro potete in­di­riz­za­re i processi NGINX anche in maniera mirata con l’aiuto del comando kill. Avete bisogno solo del ri­spet­ti­vo ID del processo, che trovate nel file nginx.pid all’interno della cartella /usr/local/nginx/logs o in al­ter­na­ti­va in quella /var/run. Ad esempio, se il processo prin­ci­pa­le ha l’ID 1628, può essere terminato con kill e con il segnale quit, come mostrato nella stringa qui sotto: 

sudo kill -s quit 1628

Con il servizio ps potete inoltre vi­sua­liz­za­re una lista di tutti i processi eseguiti con NGINX:

sudo ps -ax | grep nginx

Come regolare la ri­pro­du­zio­ne dei contenuti sta­ti­sti­ci

Pro­ba­bil­men­te usate il vostro web server per far vi­sua­liz­za­re dati sotto forma di immagini, video o contenuti statici in HTML. Per ragioni di ef­fi­cien­za si consiglia di scegliere diverse cartelle locali per diversi tipi di contenuti. Per esempio: iniziate creando un’ipotetica cartella /data/html e inserendo lì un documento HTML, anch’esso ipotetico, index.html e poi create una cartella /data/immagini dove inserire delle immagini di esempio.

Nel prossimo passaggio entrambe le cartelle devono essere inserite nel file di con­fi­gu­ra­zio­ne, man­te­nen­do­le entrambe nella direttiva in un blocco server, che altro non è che una sot­to­di­ret­ti­va del blocco HTTP. Qui sono stabilite di default due diverse istru­zio­ni, che potete anche di­sat­ti­va­re (off). Create poi sem­pli­ce­men­te un’istru­zio­ne separata del blocco server:

http {
    server {
    }
}

In questo blocco server do­vreb­be­ro ora essere indicate entrambe le cartelle, nelle quali si trovano le immagini e documenti HTML. Il risultato cor­ri­spon­den­te sarebbe:

server {
    location / {
        root /data/html;
    }
    location /bilder/ {
        root /data;
    }
}

Questa con­fi­gu­ra­zio­ne è un’im­po­sta­zio­ne standard di un server, che ascolta sulla porta 80 ed è ac­ces­si­bi­le tramite localhost. Tutte le richieste, i cui URI iniziano con /immagini/, vengono ora richiesti come file dalla cartella /data/immagini. Se non esiste il file cor­ri­spon­den­te, compare un avviso di errore. Tutti gli eventi NGINX, i cui URI non iniziano con /immagini/, vengono inoltrati nella cartella /data/html.

Alla fine ri­ca­ri­ca­te o riavviate NGINX per apportare le modifiche.

Con­fi­gu­ra­zio­ne di un semplice server proxy NGINX

Molto spesso NGINX viene con­fi­gu­ra­to dai gestori di un server proxy per ricevere al posto del server vero e proprio le richieste in entrata, per filtrarle secondo diversi criteri, inol­trar­le e per tra­smet­te­re la relativa risposta ai client. Par­ti­co­lar­men­te amati sono i caching proxy, salvati lo­cal­men­te, che tra­smet­to­no di­ret­ta­men­te i contenuti statici e rein­di­riz­za­no solo tutte le ulteriori richieste al server. Allo stesso modo, molto diffusi sono i proxy firewall, che filtrano ul­te­rior­men­te le con­nes­sio­ni non sicure o in­de­si­de­ra­te. Nell’esempio seguente ci sono i caching proxy sopra citati, che mostrano le immagini richieste sulla cartella locale e che do­vreb­be­ro inoltrare tutte le ulteriori richieste al web server.   Nel primo passaggio definite nel nginx.conf il server prin­ci­pa­le: 

server {
    listen 8080;
    root /data/up1;
    location / {
    }
}

A dif­fe­ren­za dell’esempio pre­ce­den­te, usate a questo proposito delle liste con delle direttive, perché per le richieste in entrata non si dovrebbe uti­liz­za­re la porta standard, ma quella 8080. Inoltre create la cartella rilevata /data/up1 e lì la pagina index.html.

Poi il server proxy e la sua funzione di tra­smet­te­re contenuti visivi vengono definiti, usando la direttiva proxy_pass, inclusiva delle in­for­ma­zio­ni relative al server prin­ci­pa­le che viene uti­liz­za­to, cioè il pro­to­col­lo (http), il nome (localhost) e la porta (8080):

server {
    location / {
        proxy_pass http://localhost:8080;
    }
    location ~ \.(gif|jpg|png) $ {
        root /data/bilder;
    }
}

Il secondo blocco (location) assegna il proxy server che deve ri­spon­de­re da solo a tutte le richieste, i cui URI finiscono con le esten­sio­ni tipiche per immagini, cioè .gif, .jpg e .png, e ri­chia­man­do il contenuto cor­ri­spon­den­te dalla cartella locale /data/bilder. Tutte le altre richieste vengono rein­di­riz­za­te al server prin­ci­pa­le. Come anche nelle im­po­sta­zio­ni pre­ce­den­ti, salvate il vostro proxy per le immagini tramite il segnale reload o riav­vian­do NGINX. Trovate ulteriori direttive possibili per im­po­sta­zio­ni più complesse del proxy nel manuale ufficiale online di NGINX.

Vai al menu prin­ci­pa­le