Guida alla configurazione di un web server LEMP

Guida pratica per installare un web server LEMP – Linux Ubuntu, Nginx, PHP FPM e MySQL. LEMP non è LAMP, attenzione.

La maggior parte dei siti WordPress gira su stack software LAMP tradizionale: Linux come sistema operativo, Apache come web server, MySQL come software per gestire il database (in certi casi su un server separato) e PHP come linguaggio di programmazione. Ognuno di questi è uno strumento open source molto conosciuto e ampiamente utilizzato. La maggior parte delle persone nel mondo WordPress “parla” LAMP, quindi è facile ottenere aiuto e supporto.

Quando un utente visita un sito WordPress, il browser genera da sei a otto connessioni per utente verso il web server. Mentre l’utente naviga il sito PHP assembla le pagine al volo, chiedendo le risorse al database MySQL per rispondere alle richieste.

Gli stack LAMP funzionano bene finché il traffico è limitato, da poche a, forse, centinaia di utenti simultanei. Tuttavia, improvvisi aumenti del traffico sono comuni online e – di solito – sono anche una buona cosa. Ma quando un sito LAMP-stack si sovraccarica, con centinaia o migliaia di utenti simultanei collegati, può sviluppare gravi colli di bottiglia. Le due cause principali dei colli di bottiglia sono:

• Il web server Apache – Apache consuma risorse sostanziali per ogni singola connessione. Se Apache accetta troppe connessioni simultanee, la memoria può essere esaurita e le prestazioni rallentano perché i dati devono essere cercati sul disco. Se le connessioni sono limitate per proteggere i tempi di risposta, le nuove connessioni devono attendere, il che porta anche a una scarsa esperienza utente.
• L’interazione PHP/MySQL: insieme, un server di applicazioni con PHP e un server database MySQL possono servire un numero massimo di richieste al secondo. Quando il numero di richieste supera il limite massimo, gli utenti devono attendere. Il superamento del valore massimo di richieste per una quantità relativamente piccola può causare un notevole rallentamento della reattività per tutti gli utenti collegati. Il superamento di due o più volte il numero massimo può causare notevoli problemi di prestazioni.

I colli di bottiglia delle prestazioni in un sito LAMP non sono semplicissime da risolvere, soprattutto perché in genere si tende a risolvere problemi legati all’aumento di traffico potenziando l’hardware: più CPU, più spazio su disco e così via. Gli aumenti incrementali delle prestazioni dell’hardware non possono tenere il passo con gli aumenti esponenziali della domanda di risorse di sistema che Apache e la combinazione PHP/MySQL generano quando vengono sovraccaricati.

L’alternativa principale a uno stack LAMP è uno stack LEMP: Linux, NGINX, MySQL e PHP (nell’acronimo LEMP, la E sta per il suono all’inizio di “engine-x”).

Installare il software

Il pacchetto LEMP è un gruppo di software che può essere utilizzato per gestire pagine Web dinamiche e applicazioni Web. Questo è un acronimo che descrive un sistema operativo Linux, con un web server Nginx. I dati di back-end sono memorizzati nel database MySQL e l’elaborazione dinamica è gestita da PHP.

In questa guida trovi come installare uno stack LEMP su un server Ubuntu 16.04. Prima di completare il tutorial linkato, dovresti avere un account utente normale, non root sul tuo server con privilegi sudo. Puoi imparare come configurare questo tipo di account completando la guida sulla configurazione iniziale del server di Ubuntu 16.04. Una volta che hai a disposizione l’utente, accedi al tuo server con quel nome utente. Ora sei pronto per iniziare.

NGINX può memorizzare nel suo sistema di cache le risposte da applicazioni FastCGI come PHP. Questo metodo offre le migliori prestazioni per un web server rispetto ad uno stack LAMP. Quando utilizzi FastCGI, ti consiglio di installare il plug-in Nginx Helper di WordPress e di utilizzare una configurazione del Virtual Host come quella che ti mostro in questa guida (fastcgi_cache_key e fastcgi_cache_purge sono particolarmente importanti). Il plug-in per WordPress elimina automaticamente la cache di Nginx quando una pagina o un post viene pubblicato o modificato, viene pubblicato un nuovo commento o la cache viene eliminata manualmente dalla dashboard di amministrazione di WordPress. Il plug-in Nginx Helper può anche aggiungere una stringa alla fine del codice HTML delle tue pagine, confermando che la cache funziona e mostrando alcune statistiche come ad esempio la data e l’ora di creazione della chache. Puoi anche avere conferma che la cache funzioni correttamente usando la variabile $upstream_cache_status.

Impostare gli host virtuali

Quando si utilizza il web server Nginx, i blocchi del server (simili agli host virtuali in Apache) possono essere utilizzati per incapsulare i dettagli di configurazione e ospitare più di un dominio su un singolo server. Con questa guida impari a configurare i blocchi del server in Nginx su un server Ubuntu 16.04.

Una volta configurato il blocco in “sites-available” devi creare un syslink verso “sites-enabled”:

sudo ln -s /etc/nginx/sites-available/miosito.com /etc/nginx/sites-enabled/

Impostare i permessi

Assegna i permessi all’utente www-data per poter accedere e gestire le cartelle con le risorse web.
sudo chown -R www-data:www-data /var/www

Importare il db MySQL

In caso di migrazione di un sito esistente nel tuo nuovo server sarà necessario importare i database. Per procedere ci sono due opzioni:

Con richiesta di password:
mysql -u -p <

Con immissione diretta della password (non sicuro):
mysql -u -p <

Esempio:
mysql -u root -p wp_users < wp_users.sql
mysql -u root -pPassword123 wp_users < wp_users.sql

Installare cURL

A partire dalla versione 4.0.2, PHP supporta libcurl (o più comunemente cURL), una potente libreria grazie alla quale i nostri script PHP potranno comunicare con server remoti per svolgere determinate operazioni di invio e/o ricezione dati. cURL è alquanto flessibile e consente di instaurare comunicazioni con server remoti sfruttando diversi protocolli: http, https, ftp, gopher, telnet, dict, file, ldap.

Attraverso cURL potremo effettuare svariate operazioni su server remoti, ad esempio potremo: recuperare il contenuto di una pagina web (scraping); effettuare il submit di un form; effettuare autenticazioni ad aree protette; connetterci ad un web service;, e molto altro ancora.

Per installare cURL digita:
apt-get install php7.0-curl

Installare il certificato SSL con Certbot

Ora non resta che attivare il certificato HTTPS. A questo fine possiamo usare il certificato fornito da terzi, come Cloudflare, oppure creare il nostro con Letsencrypt, in particolare usando Certbot. Per approfondire Certbot qui trovi la guida.

Di seguito link tre guide per installare il certificato fornito da Cloudflare:

• How to use Cloudflare SSL Origin Certificates with Nginx
• How to install an Origin CA certificate in NGINX
• How to install an Origin CA Certificate (Other)

L’alternativa che preferisco in quanto a semplicità è usare Certbot, un piccolo software sviluppato da Letsencrypt.

Per installare il certificato segui questa guida: Automatically enable HTTPS on your website with EFF’s Certbot, deploying Let’s Encrypt certificates.

Il processo è molto semplice:

$ sudo apt-get update 
$ sudo apt-get install software-properties-common 
$ sudo add-apt-repository ppa:certbot/certbot 
$ sudo apt-get update 
$ sudo apt-get install python-certbot-nginx 

Per avviare Certbot digita:
sudo certbot --nginx

Per maggiori info puoi seguire questa guida: How To Secure Nginx with Let’s Encrypt on Ubuntu 16.04

Configurare la cache di Nginx

Ora modifica il blocco dell’host virtuale dove vuoi abilitare la cache di Nginx. Basta inserire due blocchi di codice: proxy_cache_path all’inizio del virtual host e un location alla fine.

La configurazione richiede di impostare i seguenti campi:

• fastcgi_cache_path: La directory del disco locale per la cache /path/to/cache/.
• levels: imposta una gerarchia di directory a due livelli in /path/to/cache/. Avere un numero elevato di file in una singola directory può rallentare l’accesso ai file, quindi si raccomanda una gerarchia di directory a due livelli per la maggior parte delle distribuzioni Linux. Se il parametro levels non è incluso, NGINX mette tutti i file nella stessa directory.
• keys_zone: imposta nome e dimensione di una zona di memoria condivisa per l’archiviazione delle chiavi della cache e dei metadati come i timer di utilizzo. Avere una copia delle chiavi in memoria consente a NGINX di determinare rapidamente se una richiesta è un HIT o un MISS senza dover andare a verificare su disco, accelerando notevolmente il controllo. Una zona da 1 MB può memorizzare dati per circa 8000 chiavi, pertanto la zona da 10 MB configurata nell’esempio può memorizzare dati per circa 80.000 chiavi.
• max_size: imposta il limite superiore della dimensione della cache (a 50 megabyte in questo esempio). È opzionale; non specificando un valore si consente alla cache di crescere per utilizzare tutto lo spazio disponibile su disco. Quando la dimensione della cache raggiunge il limite, un processo chiamato gestore della cache rimuove i file che sono stati utilizzati meno di recente per riportare la dimensione della cache al di sotto del limite.
• inactive: specifica per quanto tempo un elemento può rimanere nella cache senza essere accessibile. In questo esempio, un file che non è stato richiesto per 1440 minuti viene automaticamente eliminato dalla cache dal processo di gestione della cache, indipendentemente dal fatto che sia scaduto o meno. Il valore predefinito è 10 minuti (10m). Il contenuto inattivo differisce dal contenuto scaduto. NGINX non elimina automaticamente il contenuto scaduto come definito da un’intestazione di controllo della cache (Cache-Control: max-age = 120 per esempio). Il contenuto scaduto (stale) viene eliminato solo quando non è stato effettuato l’accesso per il tempo specificato da inattivo. Quando si accede al contenuto scaduto, NGINX lo aggiorna dal server di origine e reimposta il timer inattivo.
• use_temp_path: NGINX prima scrive i file destinati alla cache in un’area di memoria temporanea e la direttiva use_temp_path=off ordina a NGINX di scriverli nelle stesse directory in cui verranno memorizzati nella cache. Si consiglia di disattivare questo parametro per evitare la copia non necessaria di dati tra i file system.
• fastcgi_cache: indica il nome dello spazio cache assegnato in keys_zone.

Fai riferimento alla guida ufficiale per maggiori info.

Esempio virtual host con HTTPS e cache Nginx

Di seguito trovi un esempio di host virtuale per un sito ospitato su Nginx con protocollo HTTPS e cache.

fastcgi_cache_path /etc/nginx/cache/1 levels=1:2 keys_zone=CACHESITO:10m max_size=50m inactive=1440m use_temp_path=off;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

add_header X-Cache $upstream_cache_status;

server {
	listen 80;
  listen [::]:80;

	#redirect to HTTPS
  server_name miosito.com www.miosito.com;
	rewrite ^(.*) https://miosito.com$1 permanent;
}

server {
	listen 443 ssl http2;
  listen [::]:443 ssl http2;
		
	ssl on;
  ssl_certificate 	/etc/letsencrypt/live/miosito.com-0001/fullchain.pem; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/miosito.com-0001/privkey.pem; # managed by Certbot

	#redirect www to not-www
  server_name www.giobrazo.com;
	rewrite ^(.*) https://giobrazo.com$1 permanent;
}

server {
	listen 443 ssl http2;
  listen [::]:443 ssl http2;
	ssl on;
	ssl_prefer_server_ciphers   on;  
 	ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 
  ssl_certificate 	/etc/letsencrypt/live/giobrazo.com-0001/fullchain.pem; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/giobrazo.com-0001/privkey.pem; # managed by Certbot

  server_name miosito.com;
	root /var/www/html/miosito;

	# Add trailing slash to */wp-admin requests.
  rewrite /wp-admin$ $scheme://$host$uri/ permanent;
		
	# Add index.php to the list if you are using PHP
	index index.php index.html index.htm index.nginx-debian.html;
	
	# CACHE
	location ~*  \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 365d;
  }
	
	set $skip_cache 0;

	# POST requests and urls with a query string should always go to PHP
	if ($request_method = POST) {
		set $skip_cache 1;
	}   
	if ($query_string != "") {
	  set $skip_cache 1;
	}   

	# Don't cache uris containing the following segments
	if ($request_uri ~* "/wp-admin/|/sw.js|/manifest.json|/xmlrpc.php|wp-.*.php|/feed/|index.php|robots.txt|sitemap(_index)?.xml") {
		set $skip_cache 1;
	}   

	# Don't use the cache for logged in users or recent commenters
	if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
		set $skip_cache 1;
	}
	
	location / {
    # This is cool because no php is touched for static content.
    # include the "?$args" part so non-default permalinks doesn't break when using query string
    try_files $uri $uri/ /index.php?$args;
    }
    
    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
	  location ~ \.php$ {
		include snippets/fastcgi-php.conf;
		fastcgi_pass unix:/run/php/php7.0-fpm.sock;
		fastcgi_cache CACHESITO;
		fastcgi_cache_valid 200 302 1440m; #minuti
		fastcgi_cache_valid 404      1m;
	}
}