IL BLOG DEGLI RHCE ITALIANI

configurare nginx – seconda parte

Andrea Manzini

Torniamo a parlare di NGINX, HTTP server leggero e veloce che sta conquistando sempre più consensi tra chi si occupa di servizi web.
Un software efficiente, riuscendo a servire più connessioni con meno risorse, ci garantisce un risparmio in termini di RAM e CPU. Tutto questo si traduce concretamente in costi minori sia per il gestore (datacenter più piccoli, meno macchine) sia per l’utente finale (basta un VPS meno performante e quindi meno costoso).
Inoltre NGINX è progettato per il zero-downtime: grazie all’utilizzo dei segnali unix è possibile persino aggiornare il programma senza alcun disservizio.

DIRETTIVE PROXY
Uno dei tipici casi d’uso di NGINX è come front-end davanti al “vero” application server. Configuriamo un semplice reverse-proxy:

http {
  server {
    location / {
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_pass http://localhost:8080;
    }
    location ~ \.(gif|jpg|png)$ {
       root /data/images;
    }
  }
}

con la prima direttiva location, vediamo come sia possibile modificare gli header HTTP prima di inoltrare la richiesta al webserver destinatario, che in questo caso sarà in ascolto sulla porta 8080 in locale. Ovviamente è possibile passare le richieste anche ad un server remoto semplicemente inserendo il suo indirizzo. Le richieste per immagini statiche, che quindi soddisfano la regexpr della location più sotto, saranno invece servite direttamente dal motore di NGINX. E’ utile sapere che per default le richieste vengono bufferizzate, ma a tal proposito segnaliamo a chi volesse approfondire che esistono anche le direttive di controllo della cache.

VIRTUALHOST

Servire più siti diversi con nginx è facile: si aggiungono tanti blocchi server, ciascuno con la propria root e si usa la direttiva server_name per indicare il dominio a cui dovrà rispondere il sito. Esempio:

http {
  server {
    listen 80 default_server;
    root /home/primosito/public_html;
    index index.html index.htm;
    server_name primosito.com;
    location / {
      try_files $uri $uri/ =404;
    } 
  }
  server {
    listen 80;
    root /home/secondosito/public_html;
    index index.html index.htm;
    server_name secondosito.it www.secondosito.it;
    location / {
      try_files manutenzione.html $uri $uri/ =404;
    } 
  }
}

Possiamo notare che il sito di default, mostrato nel caso in cui contattassimo il server per indirizzo ip, è il primo; mentre puntando il browser al secondo sito (che ha due nomi) visualizzeremo pagine diverse. Abbiamo introdotto la direttiva “try_files” che è molto utile per fornire alternative diverse allo stesso percorso logico nell’URL. Nel nostro esempio, quando l’utente chiama la homepage del sito, viene prima cercato il file manutenzione.html (che creeremo quando vogliamo segnalare lavori sul sito); se non esiste quello, nginx carica e serve il file indicato dall’utente (con due varianti: con e senza slash finale) e infine il classico “404” nel caso la pagina richiesta non venga trovata.
Come nota a margine, ricordiamo che “virtualhost” è un termine del gergo di Apache e in ngix questo tipo di configurazione prende il nome di “server blocks”.

AUTENTICAZIONE

Se vogliamo fare in modo che una certa sezione del nostro sito sia accessibile solo previa digitazione di una password, possiamo configurare una determinata location perché richieda autenticazione:

server {
  listen 80;
  server name dominio.it www.dominio.it;
  root /data/www/html;  #contenuto normale
 
  location /admin {
    auth_basic "Area Riservata";
    auth_basic_user_file /data/www/.htpasswd;
  }
  
  #!!IMPORTANTE!! nega accesso a file nascosti
  location ~ /\. {deny all;}
}

Notiamo in questa nuova configurazione la presenza di un file esterno, chiamato per convenzione .htpasswd (ma andrebbe bene qualsiasi altro nome) che deve contenere le coppie username/password, come potrebbe essere

$ cat /data/www/.htpasswd
admin:saMNhdbYqwtng

per generare password con questo tipo di cifratura possiamo usare dei servizi online, oppure rispolverare il buon vecchio Perl…

$ perl -le 'print crypt("PasswordSegreta", "salt-hash")'

cosa molto importante, il file deve essere leggibile dal demone nginx (controllare quindi i permessi sul filesystem e contesto SELinux) ma non deve assolutamente “uscire” dal webserver: un malintenzionato potrebbe farsi servire il file stesso da nginx e decifrare la password con dei tool di bruteforce. Per evitare questo, inseriamo la riga di deny che inizia con “~” (tilde). Quando NGINX incontra una location con questa sintassi, interpreta la porzione successiva come una regular expression, e se c’è un matching, esegue la direttiva. Nel nostro caso la regexp è semplice: se l’utente chiede qualunque file che inizi con un “.” (il carattere va quotato con una backslash) l’accesso è negato.

PAGINE DINAMICHE
Come testimoniano siti di grande successo , NGINX è un prodotto maturo, adatto non solo come proxy o siti statici ma per gestire contenuti complessi; in questa sezione vediamo come esempio una possibile configurazione per l’onnipresente linguaggio PHP. Iniziamo con l’installazione dei pacchetti necessari:

$ sudo yum -y install php-fpm
[...]
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
[...]
Installato:
  php-fpm.x86_64 0:5.4.16-36.el7_1
Dipendenza installata:
  libzip.x86_64 0:0.10.1-8.el7
  php-common.x86_64 0:5.4.16-36.el7_1                                            
 
Completo!
 
$ sudo systemctl start php-fpm
$ sudo systemctl enable php-fpm
$ systemctl status php-fpm
php-fpm.service - The PHP FastCGI Process Manager
   Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled)
   Active: active (running) since mer 2015-07-15 09:08:43 UTC; 22s ago
 Main PID: 20051 (php-fpm)
   Status: "Processes active: 0, idle: 5, Requests: 0, slow: 0, Traffic: 0req/sec"
   CGroup: /system.slice/php-fpm.service
           ├─20051 php-fpm: master process (/etc/php-fpm.conf)
           ├─20052 php-fpm: pool www
           ├─20053 php-fpm: pool www
           ├─20054 php-fpm: pool www
           ├─20055 php-fpm: pool www
           └─20056 php-fpm: pool www

Nella configurazione diciamo a NGINX che tutte le richieste che finiscono per “.php” vanno dirette al socket locale su cui ascolta php-fpm , il demone FastCGI Process Manager:

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

events {
    worker_connections  512;
}

http {
  index  index.html;
  server {
    listen  80;
    root /data/www;
    location / {
      try_files $uri $uri/ /index.html;
    }
    location ~ \.php$ {
      fastcgi_index   index.php;
      fastcgi_pass    127.0.0.1:9000;
      #fastcgi_pass   unix:/var/run/php-fpm/php-fpm.sock; #abilitare uno o l'altro in caso 
      include         fastcgi_params;
      fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
    }
  }
}

qui ci torna comoda la direttiva include, perché sfruttiamo un file fornito dal pacchetto nginx che contiene già le associazioni tra i parametri FCGI e le variabili della richiesta esposte dal webserver. Prepariamoci una pagina per capire se venga eseguito correttamente l’interprete PHP:

$ echo '<!--?php phpinfo(); ?-->' |sudo tee /data/www/index.php

e, dopo aver ricaricato la nuova configurazione di NGINX, puntiamo il browser alla pagina di test:

con questo tipo di setup, possiamo gestire qualsiasi tipo di applicazione php, come wordpress.

STATUS
alla pari di Apache, NGINX ha una ricca scelta di moduli extra, sia sviluppati internamente che di terze parti; come dimostrazione, vediamo la possibilità di configurare una pagina di “status” che ci informi sulla “salute” del nostro server:

location /server_status {
  stub_status on;
  access_log off;
  allow 192.168.1.111;
  deny all;
}

visualizzando la pagina /server_status otteniamo una serie di informazioni, la cui descrizione è dettagliata nella documentazione del modulo.

Active connections: 1 
server accepts handled requests
 3 3 4 
Reading: 0 Writing: 1 Waiting: 0 

CONCLUSIONE

Per il momento concludiamo qui la nostra panoramica sulle configurazioni di NGINX; nel prossimo articolo affronteremo altri aspetti… Ma ovviamente accettiamo commenti e proposte !

Info about author

Andrea Manzini

Prenota subito il tuo corso ufficiale Red Hat

GUARDA I CORSI