Apache 101: 0-WordPress in 15 minuti

61

Ingrandisci / Missili Hellfire non inclusi. Di recente, abbiamo dato un’occhiata al server Web Caddy. Oggi faremo un piccolo backup delle cose e osserveremo la A dal classico stack LAMP: il server Web Apache.

Apache ha una cattiva reputazione per essere vecchio, burbero e con prestazioni scarse, ma questa idea deriva principalmente dalla persistenza di antiche guide che mostrano ancora agli utenti come configurarlo in modi estremamente antiquati. In questa guida, configureremo un droplet Ubuntu 20.04 su Digital Ocean con un server Web Apache configurato correttamente e in grado di gestire livelli di traffico elevati.

Installazione

Dopo aver creato una nuova VM da $ 5/mese (Digital Ocean le chiama “goccioline”), la prima cosa che faremo è quello che chiunque dovrebbe fare con qualsiasi server Linux nuovo di zecca. Controlliamo e installiamo gli aggiornamenti e, poiché uno di questi era una nuova versione del kernel Linux, riavviamo il server.

root@apache:~# apt update root@apache:~# apt dist-upgrade root@apache:~# shutdown -r now

Con quel po’ di piccole pulizie fuori mano, è ora di installare Apache stesso e il linguaggio PHP richiesto dalla maggior parte delle applicazioni Web.

root@apache:~# apt install apache2 php-fpm

Gli amici non consentono agli amici di usare mod_php in modo inappropriato

Voglio chiarire in modo incredibilmente chiaro ciò che non abbiamo installato: non abbiamo installato e non installeremo il modulo mod_php Apache.

root@apache:~# apt policy libapache2-mod-php libapache2-mod-php: Installato: (nessuno) Candidato: 2:7.4+75 Tabella delle versioni: 2:7.4+75 500 500 http://mirrors.digitalocean.com /ubuntu focal/main pacchetti amd64

Il modulo mod_php era, una volta, il modo preferito per integrare il supporto PHP nel tuo server Web. In generale, ha sostituito il vecchio metodo CGI (Common Gateway Interface), che passava i file con estensioni specificate a un’applicazione diversa per l’elaborazione, la più comune a quei tempi era Perl.

Mod_php fa le cose in modo diverso: invece di un eseguibile PHP separato che gestisce il codice PHP, il linguaggio PHP è incorporato direttamente nel processo Apache stesso. Questo è un modo estremamente efficiente per elaborare il codice PHP, ma fa assolutamente schifo per un server che dovrebbe gestire contenuti non PHP, perché ogni singolo processo Apache deve portare con sé un intero ambiente di esecuzione PHP, limitando drasticamente il numero di processi Apache totali disponibili a causa del rigonfiamento della memoria.

L’installazione di mod_php significa anche richiedere che Apache venga eseguito con il vecchio prefork MPM (Multi Process Module), che non si adatta a tutti i processi di lavoro disponibili come l’evento MPM predefinito moderno. Il motivo per cui mod_php e prefork sono ancora in circolazione è che sono ottimi per un puro servizio applicativo, carico di lavoro PHP al 100 percento, con tutti i CSS, HTML statico, immagini e così via scaricati su uno o più server diversi.

Annuncio

Php-fpm è la scelta giusta per un server Web multiuso

Invece, abbiamo installato php-fpm, il PHP FastCGI Process Manager. In questo modello, Apache non porta le capacità di gestione di PHP nei processi Apache stessi, ma consegna le sue esigenze di esecuzione del codice a un pool di lavoratori PHP dedicati, che a loro volta ritrasmettono i risultati ad Apache.

L’offload dei compiti di esecuzione di PHP su un set di thread di lavoro PHP dedicati consente ad Apache di utilizzare il suo gestore MPM di eventi più moderno e con una migliore scalabilità. Significa anche che ogni singolo thread Apache può essere avviato senza l’ingombro di un ambiente di esecuzione PHP, riducendo drasticamente la quantità di RAM necessaria per ogni thread.

Ingrandisci / I rapporti GTMetrix sono uno strumento prezioso per gli amministratori Web che desiderano ottimizzare la distribuzione dei loro siti.

La prima pagina del mio blog personale comporta 31 richieste HTTPS separate. Dieci di questi sono per altri domini: fonts.googleapis.com, fonts.gstatic.com e la mia istanza Matomo. Index.php stesso è un altro e i restanti venti sono file statici consegnati dallo stesso server.

La RAM è facilmente la risorsa più preziosa su quella VM e poiché ora sappiamo che sto servendo file statici con un rapporto di circa 20:1 rispetto alle pagine dinamiche, ovviamente non dovrei sprecare RAM in un ambiente PHP completo per ogni Apache processo operaio!

Abilitazione di php-fpm e installazione dei restanti pacchetti di supporto

La maggior parte delle applicazioni Web del mondo reale vorranno installare un sacco di moduli PHP aggiuntivi. Se volessimo installare WordPress, ad esempio, vorremmo il seguente elenco di estensioni PHP:

root@apache:~# apt install php-fpm php-common php-mbstring php-xmlrpc php-soap php-gd php-mysql \ php-xml php-intl php-mysql php-cli php-ldap php-zip php- arricciare

Accidenti. Se non hai familiarità con l’uso della barra rovesciata lì, è un modo per forzare un’interruzione di riga nel terminale senza influire sull’esecuzione del codice: quindi è davvero tutto solo una grande riga, l’installazione di tutte le estensioni PHP aggiuntive che WordPress vorrà.

Con quelli installati, dobbiamo abilitare php-fpm stesso, con i seguenti comandi:

root@apache:~# a2enmod proxy_fcgi root@apache:~# a2enconf php7.4-fpm.conf root@apache:~# systemctl riavvia apache2

Questo è tutto: ora abbiamo creato il nostro ambiente server Web completo e pronto per WordPress. Il prossimo passo è creare un database MySQL per WordPress, che assomiglia a questo:

root@apache:~# mysql -u debian-sys-maint -p mysql> crea database wordpress; mysql> crea l’utente ‘wordpress’@’localhost’ identificato da ‘supersecretpassword’; mysql> concedi tutto su wordpress.* a ‘wordpress’@’localhost’; mysql> esci;

Ora siamo pronti per creare un nuovo vhost, host virtuale, per contenere il nuovo sito WordPress. Potremmo semplicemente utilizzare la configurazione predefinita di vhost, ma non lo faremo: lo faremo come professionisti e saremo pronti a gestire un ambiente multisito.

Annuncio

Configurazione del sito, del modulo e della configurazione di Apache (non è un errore di battitura!)

La cosa che mi piace di più dell’utilizzo di Apache anziché di server Web concorrenti è l’approccio altamente segmentato che utilizza per la gestione della configurazione. Ai vecchi tempi, cosa che ricordo non troppo affettuosamente, un server avrebbe un singolo file httpd.conf monolitico che poteva facilmente essere lungo migliaia di righe e contenere configurazioni globali per il server e tutte le configurazioni individuali per ogni sito sul server . Che schifo!

Fortunatamente, Apache alla fine ha introdotto la direttiva Include, che ha consentito al file di configurazione principale di Apache di collegarsi ad altri file di configurazione e, soprattutto, a directory che potrebbero essere piene di file di configurazione. Ciò ha consentito agli amministratori del sito di creare un singolo file di configurazione breve per ogni sito e, semplicemente scaricandolo nella directory appropriata, le configurazioni di quel sito vengono aggiunte automaticamente alla configurazione del server esistente dopo un systemctl ricarica apache2 (o, su macchine non systemd, apache2ctl ricarica).

La brava gente di Debian, a sua volta, ha preso quel concetto e l’ha seguito. Quando installi Apache su un moderno sistema derivato da Debian come Ubuntu, vengono create automaticamente le seguenti directory:

/etc/apache2 /etc/apache2/sites-disponibili /etc/apache2/sites-enabled /etc/apache2/mods-available /etc/apache2/mods-enabled /etc/apache2/conf-disponibile /etc/apache2/conf -abilitato

Quindi supponiamo che tu voglia aggiungere un modulo, come lo stesso php-fpm, ad Apache. Non è necessario smanettare con il file di configurazione globale in /etc/apache2/apache2.conf, perché il pacchetto php-fpm elimina semplicemente la sua configurazione e carica i file in /etc/apache2/mods-available. In realtà non hanno ancora avuto effetto perché sono solo nelle mod disponibili, non abilitate per le mod, ma ricordi quando abbiamo eseguito il comando a2enmod proxy_fcgi nell’ultima sezione?

root@apache:~# a2enmod proxy_fcgi Considerando il proxy di dipendenza per proxy_fcgi: Abilitazione del proxy del modulo. Abilitazione del modulo proxy_fcgi. Per attivare la nuova configurazione, è necessario eseguire: systemctl restart apache2

Quello che quel comando ha effettivamente fatto è stato collegare simbolicamente il file di configurazione /etc/apache2/mods-available/proxy_fcgi.load a /etc/apache2/mods-enabled/proxy_fcgi.load. E al prossimo riavvio di Apache come richiesto, Apache includerà tutti i file abilitati per le mod, incluso il nostro nuovo amico, proxy_fcgi.load, e quindi avremo il proxy FastCGI disponibile.

Se ricordi, abbiamo eseguito un altro comando subito dopo quello:

root@apache:~# a2enconf php7.4-fpm Abilitazione conf php7.4-fpm. Per attivare la nuova configurazione è necessario eseguire: systemctl reload apache2

Quel comando collegava simbolicamente /etc/apache2/conf-available/php7.4-fpm.conf a /etc/apache2/conf-enabled/php7.4-fpm.conf e, allo stesso modo, Apache includerà tutto ciò che trova in conf-enabledat ogni avvio, quindi ora abbiamo le seguenti direttive di configurazione necessarie abilitate:

root@apache:/etc/apache2/conf-available# cat php7.4-fpm.conf # Reindirizza a php-fpm locale se mod_php non è disponibile # Abilita intestazioni di autorizzazione http SetEnvIfNoCase ^Autorizzazione$ “(.+)” HTTP_AUTHORIZATION= $1 SetHandler “proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost” # Nega l’accesso ai sorgenti php grezzi per impostazione predefinita # Per riattivare si consiglia di abilitare l’accesso ai file # solo in specifici host virtuali o directory Richiedi tutto negato # Nega l’accesso ai file senza nomefile (ad es. ‘.php’) Richiedi tutto negato

Ora, se non ci vedi la bellezza… non so cosa dirti. Se sei confuso su come Apache gestisce esattamente i file PHP quando li incontra, hai un singolo file in cui puoi guardare per vedere quelle stanze di configurazione e solo quelle stanze di configurazione. Puoi visualizzarlo senza essere confuso e infastidito da centinaia o migliaia di altre righe di configurazione e puoi modificarlo se necessario senza temere di rovinare accidentalmente quelle altre centinaia o migliaia di righe di configurazione che non stai toccando, dato che ‘ ri funziona solo in questo singolo file autonomo.

Questo non è solo per le stanze di configurazione fornite dal sistema, niente ti impedisce di scrivere le tue stanze di configurazione per uno scopo particolare, rilasciarle in /etc/apache2/conf-disponibile e a2enconferle come desiderato. Vuoi conoscere tutti i moduli abilitati? ls /etc/apache2/mods-enabled. Vuoi vedere se ne sono disponibili altri? mod disponibili. La stessa cosa vale per le configurazioni in conf-enabled e conf-available e le configurazioni del sito (vhost) in sites-enabled e sites-available.

Questo fa cantare il mio cuore di amministratore di sistema, lo fa davvero.