Docker per WordPress: Perché i Container Isolati Cambiano Tutto

L'hosting tradizionale per WordPress mette più siti su un unico server. Condividono PHP, condividono l'accesso al file system e spesso condividono un server di database. Va bene finché non va male — e quando va male, è un problema serio.

PAGEnza fornisce ogni sito WordPress nel proprio container Docker. Questo post spiega cosa significa in pratica e perché è importante per le agenzie che gestiscono siti di più clienti.

Il problema dell'hosting condiviso

Su un tipico piano di hosting condiviso o anche su un VPS di base con più installazioni di WordPress:

Contesa delle risorse: un sito che riceve un picco di traffico rallenta ogni altro sito sul server. Un plugin poco ottimizzato sul sito A degrada le prestazioni sul sito B.

Contaminazione della sicurezza: se un'installazione di WordPress viene compromessa — tramite un plugin vulnerabile, una password debole o una versione core obsoleta — un attaccante che ottiene l'accesso al file system può spesso leggere i file di altri siti sullo stesso server.

Conflitti di versione PHP: il sito A necessita di PHP 7.4 per un vecchio plugin. Il sito B necessita di PHP 8.2 per uno più recente. Sull'hosting condiviso, si sceglie una versione.

Esposizione del database: i server di database condivisi significano che un'autorizzazione utente mal configurata può esporre i dati di altri siti.

I container Docker risolvono tutti questi problemi a livello di infrastruttura.

Cos'è effettivamente un container

Un container Docker è un processo leggero e isolato che ha il proprio:

• File system (il container non può vedere i file al di fuori dei propri confini)
• Stack di rete (il proprio indirizzo IP, le proprie porte)
• Spazio di processo (non può vedere i processi di altri container)
• Limiti di risorse (limiti di CPU e memoria)

Condivide il kernel dell'host con altri container, ma tutto ciò che è al di sopra del kernel è isolato. Non è una macchina virtuale completa — si avvia in secondi, non in minuti, e utilizza una frazione delle risorse.

Per WordPress, un singolo container esegue: Nginx, PHP-FPM e i file di WordPress. Il database viene eseguito in un container separato, collegato solo a quel specifico container WordPress.

Come PAGEnza fornisce un sito

Quando crei un nuovo sito cliente in PAGEnza, ecco cosa succede in meno di 45 secondi:

1. Viene avviato un nuovo container Docker da un'immagine base di WordPress
2. WordPress viene configurato con un nuovo database sull'istanza MariaDB condivisa (isolato alle credenziali di quel container)
3. Il plugin PAGEnza viene installato e attivato automaticamente
4. Viene configurato un virtual host Nginx con il sottodominio del cliente
5. Viene emesso SSL tramite Let's Encrypt
6. Il container viene registrato nel reverse proxy con le regole di routing corrette

Il cliente ottiene un URL come nomecliente.pagenza.com che è attivo entro 45 secondi dal clic su "Crea sito". Nessuna configurazione manuale del server, nessun SSH, nessun tempo di attesa DNS (per il sottodominio — la propagazione DNS del dominio personalizzato è separata).

Isolamento dei container in pratica

Limiti di memoria: ogni container ha un limite di memoria configurabile. Se un plugin fuori controllo causa un picco di memoria sul sito di un cliente, non può consumare la memoria allocata ad altri container. Il sito potrebbe rallentare o restituire un 503 — ma non influenzerà altri clienti.

Isolamento del file system: i file di WordPress del cliente A sono completamente invisibili al container del cliente B. Un plugin compromesso sul sito del cliente A non ha accesso ai file del cliente B.

Isolamento di rete: i container comunicano solo attraverso ponti di rete definiti. Il container del database per il cliente A accetta connessioni solo dal container WordPress del cliente A — non da nessun altro container sul sistema.

PHP per container: poiché ogni container esegue la propria istanza PHP-FPM, è possibile eseguire diverse versioni di PHP per diversi clienti. Il plugin legacy del cliente A che necessita di PHP 7.4 funziona bene accanto allo stack moderno del cliente B su PHP 8.2.

Domini personalizzati

La configurazione predefinita fornisce a ogni cliente un sottodominio *.pagenza.com. Per i clienti che desiderano il proprio dominio, il processo è:

1. Il cliente punta il record A del proprio dominio all'indirizzo IP del server PAGEnza
2. Nella dashboard PAGEnza, si inserisce il dominio personalizzato
3. La configurazione del reverse proxy viene aggiornata automaticamente
4. SSL viene emesso per il dominio personalizzato tramite Let's Encrypt

Le opzioni siteurl e home di WordPress vengono aggiornate di conseguenza. Dal punto di vista del cliente, il suo sito funziona semplicemente al suo dominio — nessun reindirizzamento, nessun sottodominio visibile ai visitatori.

Cosa significa questo per le agenzie

Il vantaggio pratico per le agenzie che gestiscono più siti di clienti:

Velocità di onboarding: la fornitura di un nuovo sito cliente richiede meno di un minuto. Nessuna configurazione del server, nessun cPanel, nessuna installazione manuale di WordPress.

Separazione dei clienti: il sito di ogni cliente è genuinamente isolato. Un cliente che installa un plugin problematico influisce solo sul proprio sito.

Scalabilità: l'aggiunta di un nuovo cliente non richiede la fornitura di un nuovo server. L'infrastruttura dei container scala alla capacità dell'host, e l'aggiunta di ulteriore capacità è una questione di aggiunta di più nodi host.

Disaster recovery: poiché ogni sito è containerizzato, il backup e il ripristino operano a livello di container. Il ripristino del sito di un singolo cliente non influisce su nessun altro cliente.

Il compromesso è che l'hosting containerizzato costa di più per sito rispetto all'hosting condiviso. Ma per le agenzie in cui l'affidabilità del sito e la separazione dei clienti sono non negoziabili, l'economia funziona — specialmente quando si considerano i risparmi di tempo di provisioning.