Il problema
Ogni volta che si fa una demo a un cliente, o si vuole testare un aggiornamento su un ambiente simile alla produzione, serve un clone del sito. Con database reale, dati reali, plugin attivi.
Le soluzioni tradizionali hanno costi o complessità elevate: un VPS dedicato per ogni demo, oppure strumenti a pagamento come WP Staging Pro. L'obiettivo era trovare un approccio automatizzabile, economico e replicabile su qualsiasi stack PHP.
L'approccio: embedded database in immagine Docker
L'idea di base: includere il dump del database direttamente nell'immagine Docker, così ogni container è completamente autonomo — niente dipendenze esterne, niente database server separato.
Struttura Dockerfile per WordPress:
FROM php:8.1-apache # App COPY app/ /var/www/html/ COPY database.sql.gz /docker-entrypoint-initdb.d/ # MySQL embedded in /tmp (Cloud Run ha filesystem temporaneo) RUN apt-get install -y mariadb-server COPY entrypoint.sh /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"]
L'entrypoint gestisce: avvio MySQL, import del dump, rimozione cache Redis (incompatibile con ambiente standalone), configurazione wp-config per socket locale.
Criticità WordPress
WordPress aggiunge alcune complicazioni rispetto a Laravel:
- Object cache Redis: se il sito usa Redis in produzione, il container crasha senza Redis. Soluzione: rimuovere
object-cache.phpnell'entrypoint o disabilitare il plugin. - Socket MySQL: WordPress di default usa
localhostma con MySQL embedded serve il path esplicito del socket. Va impostato inwp-config.php. - URL nel database: i link interni puntano al dominio di produzione. Serve un search-replace post-import (
wp search-replaceo manuale nel SQL).
Risultati POC
| Metrica | WordPress | Laravel |
|---|---|---|
| Dimensione database (compressa) | 2.1 MB | 23 MB |
| Dimensione app (senza uploads) | 272 MB | — |
| Cold start | ~70s | ~60s |
| HTTP response dopo boot | 200 OK | 200 OK |
Costo
al mese per snapshot, calcolato su:
- GCR storage: ~$0.04/mese per immagine
- Cloud Run: ~$0.07/mese per 50 richieste demo/mese
Cloud Run scala a zero quando non usato. Costo effettivo ≈ zero se il link demo non viene visitato.
Utilizzi pratici
- Demo clienti: link a un ambiente identico alla produzione, senza toccare il sito reale
- Test aggiornamenti: clona il sito, aggiorna plugin/core, verifica che tutto funzioni prima di applicare in produzione
- QA freelance: il cliente può testare modifiche su un ambiente separato
- Backup navigabile: snapshot storici del sito accessibili via URL
Il pattern è valido per qualsiasi app PHP con MySQL. Il cold start di 60-70 secondi è il limite principale — accettabile per demo, non per produzione. Per ridurlo si può pre-caricare il container tenendolo "warm" con una richiesta ogni 15 minuti (costo aggiuntivo trascurabile).