WordPress con Docker

Abbiamo visto in passato varie soluzioni che al tempo offrivano interessanti spunti. Ad esempio Virtualbox, oppure SSHFS, ove non ultimi andando ancora più indietro nel tempo i classici XAMPP e simili che hanno contraddistinto i primi anni 2000. Sebbene le macchine virtuali e lo stesso SSHFS rimangano validi da un po’ di anni è presente un alternativa strana che prende il nome di Docker.

Docker non è una macchina virtuale (o più correttamente un gestore di macchine virtuali) è una specie di via di mezzo perché non è necessario caricare un sistema operativo e di conseguenza non è presente un hypervisor che gestisca la “cosa” virtuale con l’hardware sottostante. Tutto questo è demandato a Docker che gestirà i Container (contenitori) ovvero l’equivalente della bolla virtuale.

Ne consegue che eliminando non poca roba il peso in termini di spazio sarà ridotto e le prestazioni di tutto rispetto. Chiaramente si parla di prestazioni lato server, benché poi Docker riesca a fare un sacco di cose, il suo vero punto di forza sono i server Linux ed applicazioni correlate, come appunto WordPress o Nodejs.

La parte interessante è che il Container potrà essere mappato con il sistema operativo sottostante e quindi potremo lavorare agevolmente nel nostro ambiente che sia Mac, Windows o Linux e con i nostri tool preferiti. Tuttavia il Container girerà in una bolla chiusa, quindi non potrà interagire con il nostro sistema operativo, rendendo di fatto sicuro il lavoro da svolgere. Nel proseguo vedremo in modo chiaro questa peculiarità.

Installiamo Docker

Per prima cosa dobbiamo installare Docker, l’applicativo viene proposto in varie versioni, quella che una volta era definita come Community Edition oggi si chiama Docker Desktop, ed è rimasta gratuita. L’installazione per MacOs e Windows avviene in pochi passaggi e comprende già i comandi relativi alla command line e il Docker Compose che una volta era un elemento separato. Per Linux invece le cose dovrebbero essere più complesse, infatti dovremo installare da repository (a seconda della distribuzione) la versione community che è ancora disponibile. Una volta installato avremo a disposizione sulla shell alcuni nuovi comandi che iniziano per docker. I più importanti sono appunto docker e docker-compose.

Creiamo il nostro LAMP

Come abbiamo detto il Container sarà minimale ma soddisfacente di tutto il necessario per avviare il progetto richiesto, quindi non è necessario andare a cercare file ISO di sistemi operativi, basterà creare un file in formato YAML (estensione .yml o yaml) al resto penserà tutto il Compose. Già, ma come è possibile? In realtà Docker si avvale di una risorsa remota per i Container, alcuni sono proprio realizzati dall’azienda medesima, altri da contributori esterni. Questa realtà si chiama Docker Hub. Infatti se cerchiamo WordPress, nell’Hub, vedremo una lista piuttosto lunga di “immagini”.

A questo punto vediamo come strutturare il nostro ambiente di sviluppo. Creiamo una cartella, ad esempio wordpress-test, all’interno dobbiamo creare un file con un nome obbligatorio che risponde al nome di docker-compose.yml. 

I file di YAML sono un po’ rognosi nel senso che richiedono attenzione all’indentazione e come viene scritto il listato. Quindi bisogna utilizzare un editor di codice, possibilmente YAML compatibile o meglio che abbia un qualche tipo di validatore. Vediamo la prima sezione, del file, il codice si apre sempre con questa dichiarazione:

version: "3.3"

Questa versione non è relativa a Docker e nemmeno a WordPress, ma è una sorta di tabella di comparazione per le versioni di Container con le versioni di Docker Engine. Ci sono appunto delle versioni di tipo breakpoint per cui una data versione di Docker potrà o non potrà gestire determinate versioni di Contanier. Nelle note di rilascio è sempre presente questa tabella. In questo caso la vediamo sotto il nome di “compose file format compatibility matrix”. La versione 3.3 non è l’ultima ma è una delle più utilizzate, quindi è un buon punto di equilibrio per poter poi utilizzare le immagini dei Container che andremo a richiedere a breve.

Ok ora per procedere dobbiamo vedere quali servizi (services) necessitiamo per avviare il nostro ambiente di test. Cioè ci servirà un database MySQL, magari un phpMyAdmin per gestire il database più agevolmente in caso di bisogno e infine il WordPress medesimo. Linux non è citato perché come abbiamo accennato si fa riferimento ad ambiente Unix, è comunque possibile anche utilizzare Windows server, ma non è oggetto di questo articolo.

Partiamo con il strutturare il database, non prima di aver aperto la dichiarazione services per richiedere appunto le immagini a Docker:

version: "3.3"

services:
  db:
     image: mysql:5.7
     ports:
      - "8081:3306"
     volumes:
      - ./db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: wordpressMysqlRootPassword
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpressUser
       MYSQL_PASSWORD: wordpressPassword
  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    ports:
      - "8080:80"
    volumes:
      - ./public:/var/www/html      
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpressUser
      WORDPRESS_DB_PASSWORD: wordpressPassword
  phpmyadmin:
    depends_on:
      - db  
    image: phpmyadmin/phpmyadmin:latest
    ports:
      - "8082:80"
    environment:
      PMA_USER: root
      PMA_PASSWORD: wordpressMysqlRootPassword
      PMA_HOST: db:3306

Partiamo con la spiegazione del listato. db è di fatto una label, poteva essere anche mysql, ben più importante è la image. Questa deve esistere nell’hub di Docker, di fatto è ciò che verrà scaricato. Qui sopra vediamo le tre richieste che differiscono, le riepilogo meglio qui sotto:

db:
	image: mysql:5:7
wordpress:
	image: wordpress:latest
phpmyadmin:
    image: phpmyadmin/phpmyadmin:latest

Come si può vedere per MySQL ho voluto scegliere una versione specifica, ovvero la 5.7, mentre per le altre due ho semplicemente indicato di utilizzare l’ultima versione disponibile. Le immagini sono solitamente aggiornate con molta frequenza, quindi WordPress che è molto richiesto sarà sempre all’ultima versione stabile.

La sezione successiva è stata quella di definire le porte di rete, ad eccezione di WordPress e phpMyAdmin il database poteva anche non essere indicato, in quel caso il MySQL avrebbe girato totalmente protetto. La porta come si vede è divisa in due parti “8081:3306” oppure “8080:80”. La prima cifra è la porta relativa alla nostra macchina, la seconda è la porta di servizio dell’immagine. MySQL di default risponde alla porta 3306, mentre WordPress alla più canonica 80. Nel caso poi abbiamo più richieste contemporanee alla porta 80 dovremo per forza utilizzare una porta locale diversa, nel nostro caso phpMyAdmin risponde alla porta “8082” e sempre alla “80” interna al Container.

Poi ci sono i volumi (volumes). Potrebbero potenzialmente non essere indicati ma siccome noi vogliamo utilizzare WordPress come ambiente di sviluppo è necessario poter accedere fisicamente ai file. Con la direttiva “volumes” andiamo, in modo simile a quello visto per le porte, a mappare una cartella locale con quella dell’immagine.

db:
     volumes:
      - ./db_data:/var/lib/mysql
wordpress:
    volumes:
      - ./public:/var/www/html

In questo caso la cartella locale fa riferimento alla cartella in cui è presente il file YAML medesimo. Non è necessario creare le cartelle db_data e public  poiché sarà Docker a gestire il tutto. Come si vede la sezione relativa a phpMyAdmin non ha un volume perché non ci interessa dover andare a modificarlo. Le indicazioni lato immagine invece sono quelle di tipo canonico, ovvero i file di tipo raw di mysql sono installati li in quella posizione. In linea generale servirà a poco vedere i file del DB, a meno che non vi avvaliate di tool di database design o statistica.

La direttiva “depends_on” con indicato db per WordPress e Phpmyadmin si spiega da sola, questi due senza il database non possono funzionare. La direttiva restart indica se far ripartire il servizio ad esempio dopo un blocco. Nella versione 3.x esiste una policy molto più complessa ed articolata che non vediamo qui per brevità.

Infine ci sono tutte le indicazioni di tipo “environment” per collegarsi al database o configurare WordPress, quelle che vedete sono direttive proprie delle immagini e non di Docker. Nell’Hub citato in precedenza, nelle schede delle immagini troverete (o dovreste trovare) queste indicazioni.

Come lanciare il Container.

Bene, a questo punto dopo aver salvato il file non ci resta che partire, entriamo con il nostro terminale a riga di comando nella cartella e diamo il comando:

docker-compose up -d

Up significa parti, con “-d” si indica di agire in modo non verboso. Il file docker-compose.yml è automaticamente trovato senza doverlo citare espressamente. La prima volta partirà una procedura una tantum che serve a scaricare le immagini dei servizi richiesti:

docker-compose up -d
Creating network "wordpress-test_default" with the default driver
Creating volume "wordpress-test_db_data" with default driver
Pulling db (mysql:5.7)...
5.7: Pulling from library/mysql
f17d81b4b692: Downloading [=========================>                         ]  11.48MB/22.49MB

Al termine di questa procedura, che dipende per lo più dalla disponibilità di banda della vostra connessione si ritorna al prompt. Il Container è stato avviato, infatti se ora andiamo sotto http://localhost:8080 vedremo la pagina di configurazione di WordPress. Mentre all’interno della cartella che avevamo scelto troveremo le sotto cartelle public e db_data, dove la prima vedremo tutti i file di WordPress con cui potremo agevolmente interagire visto che sono in tutto e per tutto nel nostro filesystem, ma contemporaneamente in esecuzione su una istanza Docker.

Come fermare il Container.

Siamo giunti al termine, non ci resta che stoppare il nostro Container. Docker e Docker-Compose dispongono di molte opzioni, nel caso del compose per fermare le istanze ci sono due comandi, ma con grosse differenze. Quello che state cercando è probabilmente:

docker-compose stop

Questo ferma le istanze, la volta successiva vi ritroverete tutto quanto avevate fatto, un po’ come se avessimo dato il poweroff ad un server. Se invece diamo il comando:

docker-compose down

L’istruzione down è un po’ sibillina, ad una prima vista può far intendere che possiamo spegnere, in realtà è si uno spegnimento, ma l’immagine rimuoverà volumi, rete e immagini. In sostanza è una funzione propedeutica alla cancellazione di un Container.

Conclusioni

Tutto in un articolo non ci può stare, le cose da dire sono pressoché infinite, infatti non ho citato l’iterazione da sistema locale al Container, come fare un backup e mille altre disquisizioni che magari farò in articoli separati. Tuttavia si vede come questo sistema, specie come ambiente di sviluppo, possa essere ottimo, tra l’altro con la possibilità di poter accedere a strumenti tipo sincronizzazione con server di produzione. Il tutto senza “sporcare” il proprio sistema operativo 🙂