Ambiente di sviluppo Docker per Wordpress con PHP-apache, MariaDB e MailHog. Docker environment stack for Wordpress with PHP-apache, MariaDB and MailHog for developments.
Richiesto docker-compose
- Wordpress - PHP-apache (WEB)
- MariaDB (DB)
- MailHog (SMTP-TEST)
- wordpress:${WP_CORE_VERSION}-php${PHP_VERSION}-apache
- mariadb:10.3
- mailhog/mailhog
- https://hub.docker.com/_/wordpress
- https://hub.docker.com/_/mariadb
- https://hub.docker.com/r/mailhog/mailhog/
- https://hub.docker.com/_/php
docker-wordpress
│ .env
│ .env.example
│ .gitignore
│ docker-compose.yml
│ LICENSE
│ README.md
│
├───db.backup
│ └───.gitignore
│
├───db.init
│ └───zzz-migrate.sql.example
│
└───wp-content
├───mu-plugins
├───plugins
└───themes
Il file .env è fondamentale! Utilizzare .env.example come template.
Crea una copia del file .env.example rinominandolo .env
Edita le variabili per il tuo ambiente, di seguito una descrizione di queste.
PROJECT_NAME: Nome assegnato allo stack docker.VERSION_ID: ID del progetto. (Da usare se si prevedono più versioni dello stack o del progetto).WEB_PORT_EXPOSED: Porta HTTP esposta per il sito web (default 80).PHP_VERSION: Versione PHP che si desidera utilizzare (default 7.2).DB_PORT_EXPOSED: Usata se si desidera connettersi al database anche con un cliente esterno (HeidiSQL, MySQL Workbench, ecc.).DB_ROOTPASS: Password dell'utente root di MySQL. Ehy, in produzione è inaccettabile ma qui siamo su un ambiente di sviluppo ;)DB_USER: Username dell'utente database.DB_PASS: Password dell'utente database.DB_NAME: Nome del database.WP_CORE_VERSION: Versione di Wordpress che si desidera utilizzare.WP_TABLE_PREFIX: Prefisso delle tabelle sul database utilizzato da wordpress.
Cose di cui dovresti essere informato
Verifica in prima istanza il file .env se non esiste prendi spunto dal file .env.example
Data la gestione poco dinamica degli URL imposta da Wordpress sui contenuti caricati tramite la dashboard wp-admin, è buona norma aggiungere sul file hosts del proprio terminale un puntamento locale al DNS utilizzato dall'ambiente finale.
es. 127.0.0.1 www.ilmiositonelmondo.net
Questa è una procedura opzionale ma fortemente consigliata se è previsto, terminati gli sviluppi, di migrare il sito in produzione.
Il repository così configurato (vedi bene il .gitignore) potrebbe essere eseguito, per il deploy, direttamente sul webserver (testing, pre-produzione, debug, produzione, ecc.) tramite git senza dover utilizzare FTP/SCP/SSH.
Se devi lavorare su una versione già esistente del sito WP ed hai a disposizione il dump del database e i sorgenti wordpress del sito, aggiungi il dump (.sql o .gz) dentro la cartella db.init e l'intera cartella wp-content nella cartella principale di progetto ed esegui il comando di build di Docker, ma prima cancella, se già presenti, i volumi già esistenti del tuo stack altrimenti non verranno apportate modifiche al tuo ambiente.
Dopo la build, Wordpress e il server web gireranno all'interno di un container ad eccezione della cartella wp-content che sarà disponibile nella cartella principale di progetto.
Il file wp-config.php viene editato con i parametri indicati nel file delle variabili d'ambiente .env. Qualora fosse necessario apportare modifiche a tale file questo può avvenire accedendo direttamente all'interno del container Docker tramite il comando docker-compose exec wp bash e una volta dentro il container con bash ci troviamo in un ambiente linux ma con molti ma molti meno applicativi e comandi a disposizione, ovvero non sono presenti editor testuali (nano, vi, pico, ecc.) ma è presente il comando sed (buona fortuna e in culo alla balena!)
Se avere a disposizione i sorgenti del core WP è fondamentale, nel docker-compose.yml, dobbiamo indicare come volume di Wordpress un percorso localmente raggiungibile anziché un volume docker (righe 18,19 e 47 del file). Usando un percorso localmente raggiungibile dopo la build sarà presente la cartella wp nella cartella principale di progetto. Qui potrà essere editato il file wp-config.php e potranno essere eseguiti operazioni tramite il proprio file manager su wp-admin e wp-includes. NB la wp-content usata dallo stack sarà sempre quella presente nella cartella principale di progetto e non quella dentro wp.
Una lista di variabili d'ambiente da utilizzare è disponibile nel Docker Hub Wordpress. Queste variabili vanno aggiunte al file docker-compose.yml prima di una build.
Comunque se non hai capito quello che è scritto o cosa siano i volumi di docker forse è il caso che lasci il docker-compose.yml così com'è e ti fidi di Docker e dei manutentori di Wordpress del Docker Hub.
E' consigliato modificare il file wp-config.php solo per aggiungere gli switchs utili al debug, per esempio:
ini_set('log_errors', 'On');
ini_set('error_log', '/CUSTOM_LOGS_PATH/php-errors.log');
define('WP_ALLOW_REPAIR', true);
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);
Per il database viene utilizzato un container MariaBD, nulla vieta di usare un container MySQL. I sorgenti dei databases risiedono in un volume docker. Salvare questi sorgenti su un percorso localmente raggiungibile potrebbe compromettere la build sopratutto se vengono utilizzate alcune versioni di MariaDB o MySQL.
Qualora avessimo a disposizione il dump di un database, di formato .sql o .gz può essere aggiunto dentro la cartella db.init. I file .sql o .gz presenti all'interno di questa cartella vengono eseguiti alla prima inizializzazione del server, nel nostro caso una build. Qui possono essere inseriti dump o file con all'interno query SQL. I file vengono eseguiti in ordine alfa-numerico crescente.
Es. abbiamo un dump di un sito in produzione che vogliamo importare sull'ambiente di sviluppo docker e dobbiamo modificare gli URL del sito e l'email di admin. Quindi caricherò il file mio-dump.sql dentro la cartella e modifico il file zzz-migrate.sql dove al suo interno sono già presenti alcune query da usare come esempio per svolgere le operazioni sopra descritte.
Per effettuare i backup e restore del database è stata mappata una cartella db.backup presente nella cartella principale di progetto.
I backup si effettuano accedendo nella bash del container db.
docker-compose exec db bash
Al suo interno ci troviamo in un ambiente linux dove è possibile eseguire comandi mysql.
mysqldump --force --opt -uroot -ppassword --databases wordpress > /backup/wordpress-$(date +%U).sql
mysqldump --force --opt -uroot -ppassword --databases wordpress | gzip > /backup/wordpress-$(date +%U).sql.gz
mysql -uroot -ppassword wordpress < /backup/wordpress-#.sql
mysql -uroot -ppassword < /backup/wordpress-#.sql
gunzip < /backup/wordpress-#.sql.gz | mysql -uroot -ppassword wordpress
gunzip < /backup/wordpress-#.sql.gz | mysql -uroot -ppassword
Fai un down dello stack e cancella il volume attuale del DB (vedi comandi docker), inserisci uno dei backup (.sql o .gz) all'interno di db-init ed esegui nuovamente docker-compose build -d
Per connettersi tramite client MySQL esterno (HeidiSQL_, MySQL Workbench, ecc.) i parametri da utilizzare sono i seguenti.
- host:
127.0.0.1odb - port: la variabile d'ambiente
DB_PORT_EXPOSED - username:
root(in alternativa la variabile d'ambienteDB_USER) - password:
- la variabile d'ambiente
DB_ROOTPASSperroot(accesso a tutti databases) - la variabile d'ambiente
DB_PASSperDB_USER(accesso al solo databaseDB_NAME)
- la variabile d'ambiente
In questo stack è stato aggiunto MailHog che è un sistema di sviluppo semplice e poco invasivo per testare l'invio email.
Su Wordpress si consiglia di installare un plugin per invio email tramite SMTP (consiglio Easy WP SMTP). I parametri di configurazione SMTP sono:
- host:
mailhog - port:
1025 - nessuna autenticazione
Per controllare le email inviate (compresi MIME, Formati, ecc.) dal browser vai su http://localhost:8025
Comandi docker in pillole.
-
docker-compose up -d --build- costruisce e inizializza lo stack -
docker-compose down- rimuove lo stack mantenendo database e sorgenti -
docker-compose start- avvia lo stack -
docker-compose stop- arresta lo stack -
docker-compose down --volumes- come down ma cancella anche i volumi (cancella database e sorgenti se non mappati localmente) -
docker-compose config- verifica la configurazione dello stack -
docker-compose exec SERVICE_NAME bash- accesso tramite terminale all'interno di un container- SERVICE_NAME =
wp- per accedere sul server web - SERVICE_NAME =
db- per accedere sul server database - SERVICE_NAME =
mailhog- per accedere sul server smtp
- SERVICE_NAME =
-
docker volume lslista dei volumi docker -
docker volume rm NOME-VOLUMEcancella il volume docker indicato dal nome