Docker per lo sviluppo WordPress

Sapere come sviluppare in locale il proprio progetto prima di lavorare sul server di produzione ormai non può essere considerata solo una buona pratica ma anche una comodità incredibile che ci permette di lavorare in maniera più rapida e sicura.

In questo articolo ti introdurrò all’uso di Docker ovvero uno strumento molto giovane che ha però, sin da subito, conquistato i sistemisti e gli sviluppatori di tutto il mondo per il suo modo di affrontare alcuni dei problemi più stressanti legati alle architetture dei progetti software.

Dato che questo sarà un articolo abbastanza lungo non voglio perdermi in lunghe chiacchiere, prima di proseguire voglio farti capire che è importante conoscere Docker anche perché molte aziende di hosting, come DigitalOcean, ti permetteranno di configurare velocemente le tue VPS grazie a questa soluzione. Ecco una piccola introduzione a questa fantastica tecnologia.

Introduzione a Docker

Docker fondamentalmente ti permetterà di tirare su dei Container contenenti tutti i software dello stack sul quale si basa l’applicativo che stai sviluppando e tutto questo indipendentemente dalle versioni degli stessi che ci si trova installati nel nostro sistema operativo.

Ok, sto correndo forse un po’ troppo quindi proverò a farti un esempio banale che potrai però capire al volo in maniera semplice.

Prendiamo ad esempio PHP, che è il linguaggio alla base dello stack LAMP di WordPress. Se vai a controllare la versione attualmente installata nel tuo sistema operativo probabilmente sarà in un range compreso tra 5.2 e 7.

Cosa succedeva prima dell’arrivo di Docker?

Nel migliore dei casi avevi una bella macchina virtuale nella quale testare il tuo codice prima di andare in produzione e quella macchina era configurata per avere la stessa versione presente anche nel server in produzione.

Nella peggiore delle ipotesi ti ritrovavi a pregare che tutto filasse liscio e in caso contrario aggiornare o fare il downgrade della versione di PHP in produzione.

Cos’è un Container Docker e le differenze con una Macchina Virtuale

Si definisce un Container un pacchetto di software che al suo interno abbia già tutto ciò che gli serve per girare indipendentemente, in maniera efficente e minimale.

In pratica un Container deve girare allo stesso modo in una macchina Windows o in una Linux poichè al suo interno ha già tutto il codice, le librerie, gli strumenti di sistema e di runtime di cui necessita. Un’altra caratteristica fondamentale di un Container Docker è il suo isolamento che garantisce al codice di non avere conflitti di dipendenze e ambiente con altri Container ospitati sulla stessa macchina.

Docker, al contrario di Vagrant e VVV, richiede un numero di risorse limitate e ha dei tempi di provisioning molto più bassi perché usa direttamente il nostro OS come host e non richiede la presenza di un hypervisor che gestisca e allochi le risorse fisiche della nostra macchina.

Macchine Virtuali (VMs)

Docker Container

Le Virtual Machine sono un’astrazione del hardware fisico e sono in grado di trasformare una macchina in molte macchine con scopi differenti. Per allocare le risorse di un singolo hardware alle varie astrazioni c’è bisogno di un Hypervisor che dialoghi direttamente con l’infrastruttura fisica.

Ogni Virtual Machine avrà bisogno di un sistema operativo indipendente, delle librerie e ovviamente dello strato applicativo che vogliamo farci girare. Ovviamente per far girare tutto questo dobbiamo anche assicurarci di aver soddisfatto tutte le dipendenze della nostra applicazione.

Una macchina virtuale solitamente pesa alcuni GB e ha tempi di avvio abbastanza lunghi comparabili a quelli di boot di un computer/server, questi tempi tendono a dilatarsi ulteriormente con la presenza contemporanea di altre Virtual Machine sulla stessa macchina ospitante.

Un Container Docker rappresenta invece l’astrazione dello strato applicativo e racchiude il solo codice con le sue dipendenze, permettendo quindi la condivisione del kernel del sistema operativo con gli altri Container che gireranno come processi isolati ognuno nel proprio user space.

In questo modo un Container riesce a pesare solo qualche decina di MB e si avvia in maniera quasi istantanea con tempi che si avvicinano a quelli del lancio di una applicazione all’interno del vostro OS.

Se consideri tutto ciò che ti ho detto fino ad ora capirai da te che avere un Container significa poterlo anche muovere in maniera indipendente da una parte all’altra senza mai avere problemi di compatibilità e configurazioni.

In poche parole, se il tuo hosting supporta il caricamento di immagini Docker potresti addirittura sviluppare tutto in locale e poi trasportare l’intero pacchettone sul tuo server senza dover configurare alcunchè!

Questo per ora però avviene solo in casi specifici e ancora non ho visto nessuno integrarlo in maniera semplice in un workflow che comprendesse WordPress. I motivi sono tanti ma il principale è quello che non ci sono hosting a “costi contenuti” e (sopratutto) managed che offrono Docker come soluzione in produzione.

Non disperare però perchè come già ti ho detto prima in questo articolo io ho già abbandonato Vagrant e VVV per sviluppare in locale.

Sono in grado infatti di caricare i miei lavori direttamente in produzione senza dover avere bisogno di spostare l’intero Container, tutto questo combinando semplicemente Docker con WordMove, un comodissimo strumento di cui abbiamo già parlato qui su SkillsAndMore.

Prima di fiondarci a testa bassa su questo argomento devi avere un altro po’ di pazienza e permettermi di spiegarti come installare, gestire e far comunicare tra loro i tuoi Container in modo da rendere tutto quello che verrà dopo molto più chiaro e semplice.

Usare Docker e docker-compose per gestire i Container

Iniziamo questo viaggio alla scoperta di Docker procedendo all’installazione e per farlo al meglio ti consiglio l’ottima guida ufficiale che ti basterà seguire dal link nella tabella con il nome del tuo sistema operativo sul quale vuoi farlo girare, ovviamente scegli senza problemi la versione Docker CE x86_64 che sta per Community Edition.

Ti faccio notare solo che se sei, come me, un utente Linux probabilmente la tua distro sarà già predisposta con Docker o comunque ne troverai una versione pronta all’installazione nel tuo gestore pacchetti. Sentiti comunque libero di seguire la guida per avere l’ultima versione disponibile, ma ricordati che troverai le distribuzioni Linux sotto la tabella server e non in quella desktop, dove sono riportati solo OSX e Windows.

Se hai installato la versione per Mac o Windows per ora sei apposto e hai tutto ciò che ti serve per proseguire con questo tutorial mentre se sei un pinguino dovrai seguire un passaggio ulteriore e installare anche docker-compose. Anche questo tool dovresti trovarlo facilmente nel tuo package manager di fiducia, ma se così non fosse ricorri pure alla documentazione ufficiale e installalo per conto tuo.

Ora che abbiamo tutto il software necessario facciamo una prova e capiamo se tutto è andato come dovrebbe quindi aprite un terminale e digitate:$ docker --version && docker-compose --version

Se vedi stampate a video le due versioni dei software significa che puoi proseguire, altrimenti accertati di aver effettuato tutti i passaggi necessari all’installazione e ripeti il test.

Comporre e gestire gruppi di Container con docker-compose

Quando parliamo di stack software stiamo parlando di diversi applicativi che combinati insieme ci permettono di costruire sopra di loro il nostro software. La cosa importante è che questi software possano dialogare tra loro e che siano disegnati per operare insieme producendo una solida base per il nostro codice. L’esempio che tutti noi conosciamo è quello dello stack LAMP, ovvero Linux che ospita un server Apache, un database MySQL e un inteprete per il linguaggio PHP, Perl o Python.

Come abbiamo imparato all’inizio di questo articolo un Container per definirsi tale deve essere minimale e isolato, quindi nonostante possiamo trovare ottimi Container con lo stack LAMP difficilmente li troveremo con anche WordPress preinstallato e che oltretutto abbia WordMove.

Per questo tipo di cose c’è già VVV, l’ottima macchina Vagrant per lo sviluppo WordPress che comprende anche altri numerosi tool che soffre però dei problemi sopracitati in termini di performance. La finalità di Docker non è quella di fornirti uno strumento omnicomprensivo bensì di darti tanti piccoli pacchettini isolati e uno strumento per riunirli e farli parlare come meglio credi, qusto strumento è appunto docker-compose.

Grazie a qusto tool saremo in grado di creare il nostro stack e comporlo come meglio crediamo senza stare ad impazzire con configurazioni e impostazioni, semplicemente creando un file docker-compose.yml e lanciandolo dalla cartella dove vogliamo montare il nostro stack.

In questo file inseriremo tutte le configurazioni base richieste da tutti i Container Docker più le impostazioni richieste dalle singole macchine. Senza troppo dilungarci su inutili spiegoni tecnici andiamo a vedere un mio file docker-compose.yml che uso per lo sviluppo WordPress e poi approfondiremo tutto pian piano in modo che tu possa creare file di configurazione indipendentemente dal progetto, dal linguaggio e dagli strumenti.

version: "2"
services:
  mariadb:
    image: mariadb
    ports:
      - "8081:3306"
    restart: on-failure:5
    environment:
      MYSQL_ROOT_PASSWORD: myc00LpsW
  wordpress:
    image: wordpress
    volumes:
      - ./public:/var/www/html
    ports:
      - "8080:80"
    restart: on-failure:5
    links:
      - mariadb:mysql
    environment:
      WORDPRESS_DB_PASSWORD: myc00LpsW
  phpmyadmin:
    image: phpmyadmin/phpmyadmin:latest
    ports:
      - 8082:80
    links:
      - mariadb:mysql
    environment:
      PMA_USER: root
      PMA_PASSWORD: myc00LpsW
      PMA_HOST: mysql
  wordmove:
    tty: true
    depends_on:
      - wordpress
    links:
      - mariadb:mysql
    image: welaika/wordmove:php7
    restart: on-failure:5
    volumes:
      - ./public:/html
      - ~/.ssh:/root/.ssh

Il file inizia con la dichiarazione della compatibilità (version: "2"), questo numero di versione non ha nulla a che vedere con il numero di versione di docker-compose bensì serve a indicare un range di versioni Docker che sono supportate dal nostro stack e segue uno specchietto semplice che troverete sempre aggiornato direttamente nei changelog delle release sul repo git di docker/compose seguendo questo link.

Ad oggi mi sono sempre trovato bene usando la versione 2 in modo da supportare il maggior numero possibile di utenti e versioni di Docker attualmente installate.

Subito dopo la dichiarazione di compatibilità inizia un elenco di services, questi non sono altro che i Container che vogliamo comporre insieme e subito sotto di loro una lista di parametri e configurazioni specifiche.

... 
services: 
  mariadb: 
  ... 
  wordpress: 
  ... 
  phpmyadmin: 
  ... 
  wordmove: 
  ...

In questo caso sullo stesso livello troviamo un Container mariadb a fare da database MySQL, il Container ufficiale wordpress che contiene un server Apache e l’interprete PHP, un Container phpmyadmin per gestire comodomente il database via browser e finalmente il Container wordmove per gestire la sincronizzazione del progetto con il nostro server di produzione.

Facciamo un piccolo passo indietro e cerchiamo di capire come fa Docker a sapere come e dove scaricare le immagini di questi software e soprattutto come fa a conoscerne le configurazioni specifiche.

Come ti ho già detto ci basta dichiarare il solo file docker-compose.yml per tirare su tutta l’archietettura che abbiamo pensato, quindi da qualche parte ci deve essere un repository che verrà consultato per fornirci le immagini contenenti tutto il software necessario. Questo repository è ovviamente online, ha sede nel sito ufficiale di Docker e si chiama Docker Hub.

Tramite questo hub ti sarà possibile esplorare tutte le immagini create fin’ora, consultare le configurazioni particolari di ogni Container e, se ne sarai in grado, anche crearne nuove semplicemente iscrivendoti al portale. Ora che sai dove ho rimediato tutte le informazioni necessarie a scegliere e configurare i miei Container possiamo andare ad analizzare le impostazioni base che troverai in quasi tutti i Container Docker.

Definire il nome del Container e la sua immagine

La primissima istruzione inserita nel file di configurazione docker-compose.yml dei services è sempre il nome del Container. Non sei assolutamente vincolato nei nomi che potrai dare a questi servizi ma ti consiglio di non lavorare troppo di fantasia perchè dovrai essere in grado di capire al volo di cosa si tratta quando elencherai la lista dei Container attivi nella tua macchina, è quindi buona pratica seguire una nomenclatura auto-esplicativa.

Il nome del Container ti servirà anche in altri contesti, ad esempio se vorrai collegare o far dipendere un Container da un altro. In quest’ultimo caso userai il suo nome direttamente all’interno del file docker-compose.yml ma questo aspetto lo affronteremo meglio più avanti, per ora concentrati sul concetto di restare semplici nello schema dei nomi che sceglierai.

La prima delle istruzioni che troverai sempre è image che serve appunto ad istruire Docker sull’immagine che dovrà andare a scaricare e utilizzare, questo valore lo ricaviamo direttamente da Docker Hub ed è il nome che viene fuori facendo una semplice ricerca.

... 
  mariadb: 
    image: mariadb 
    ... 
  wordpress: 
    image: wordpress 
    ... 
  phpmyadmin: 
    image: phpmyadmin/phpmyadmin:latest 
    ... 
  wordmove: 
    ... 
    image: welaika/wordmove:php7
    ...

Ricorda che a volte può essere anche composto dal nome del releaser seguito dal nome del software, come vediamo ad esempio nell’immagine che utilizzo per WordMove.

Quest’ultimo comportamento serve a segnalare che non è una immagine ufficiale di quel software ma semplicemente un Container creato da una persona che ne mantiene l’aggiornamento in maniera indipendente, quindi lo stesso Container non sarà presente sullo store di Docker che si rivolge sopratutto al mondo dell’enterprise.

Mappare porte e volumi dei Container

Se un software ha bisogno di interagire con altri software fuori dal Container stesso dovrai dichiarare il parametro ports e mapparlo con le tue porte locali perchè come già ti ho spiegato i Container sono, ripetiamolo per l’ennesima volta insieme, isolati per natura.

Nel mio file di configurazione puoi vedere ad esempio che la porta standard del database del Container, che per convenzione risiede su 3306, è mappata sulla porta 8081 della macchina locale.

... 
  mariadb: 
    ... 
    ports: 
      - "8081:3306" 
... 
  wordpress: 
    ... 
    ports: 
      - "8080:80" 
... 
  phpmyadmin: 
    ... 
    ports: 
      - 8082:80

Con il parametro portsindichiamo a Docker come mappare le nostre porte locali con quelle del Container che stiamo lanciando seguendo lo schema di dichiarazione - localhost:docker. Una volta che avvieremo i Container potremo utilizzare l’indirizzo localhost:8081 per connettere i nostri software direttamente al DB mentre puntando il browser su localhost:8080 raggiungeremo il server Apache e quindi la nostra installazione WordPress, se vuoi invece raggiungere phpMyAdmin ti basterà puntare localhost:8082.

Un altro parametro che troverai spesso nella tua vita da “dockerista” è quello che definisce la mappatura dei volumi fisici. Con volumes infatti andremo a mappare, in maniera analoga a quanto abbiamo fatto con le porte, i volumi fisici delle macchine in modo da poter agire sul filesystem e sui file ospitati al suo interno.

Prendiamo ad esempio il Container WordPress che al suo interno ospita la cartella pubblica contenente tutti i file del CMS.

In questo caso dobbiamo essere in grado di operare sui file direttamente in locale, senza dover passare dalla shell del Container stesso, quindi non facciamo altro che dichiarare di voler creare una cartella /public nella cartella del nostro progetto mappata con la cartella /var/www/html del server Apache del Container.

... 
  wordpress: 
    image: wordpress 
    volumes: 
      - ./public:/var/www/html 
...

Allo stesso modo ho fatto coincidere la cartella del server Apache del Container di WordMove con la nostra public in locale in modo da poter avere accesso ai file da sincronizzare direttamente in produzione.

... 
  wordmove: 
    tty: true 
    depends_on: 
      - wordpress 
    image: welaika/wordmove:php7 
    restart: on-failure:5 
    volumes: 
      - ./public:/html 
      - ~/.ssh:/root/.ssh

Se noti bene queste istruzioni usano dei percorsi relativi, ovvero sono cartelle relative al posto in cui si lancia il comando (se sei un purista, ti prego, passami il concetto per il beneficio della semplicità), mentre nel dichiarare il volume relativo alle chiavi ssh ho utilizzato il carattere tilde (~) che indica la relatività del percorso in base alla cartella utente. Questo significa che nel caso di bisogno di chiavi ssh invece di salvarle nella cartella del progetto dovrete piazzarle in /home/nomeutente/.ssh, una cartella nascosta e protetta da eventuali push involontari.

Collegare e creare dipendenze tra Container

Come promesso poco più su, vediamo ora in che modo possiamo collegare dei Container tra loro in modo da creare degli stack software efficaci. Se infatti non dichiarassimo i collegamenti tra Container, data la loro natura isolata, non ci sarebbe permesso ad esempio di far dialogare WordPress con il DB e quest’ultimo con phpMyAdmin.

Per collegare due Container possiamo usare sia l’istruzione links che quella depends_on, la differenza tra le due è data dalla natura del collegamento che andremo a creare.

... 
  wordpress: 
    ... 
    links: 
      - mariadb:mysql 
    ... 
  phpmyadmin: 
    ... 
    links: 
      - mariadb:mysql 
    ... 
  wordmove: 
    ... 
    depends_on: 
      - wordpress 
    ...

Usando depends_on infatti andrai a creare un legame molto più forte tra i Container che si avvieranno rispettando l’ordine delle dipendenze consentendoti anche di avviare il Container dipendente con un comando e contestualmente avviare tutti i Container da cui dipende.

Nel mio caso ho deciso di creare questo legame di dipendeza forte solo per WordMove che altrimenti sarebbe inutile senza WordPress, mentre ho collegato con links WordPress al DataBase in modo da poterlo tirare su anche da solo e cambiare magari la base di dati alla quale puntarlo.

La differenza è labile quindi io seguo sempre la regola per la quale se esistono casi, anche limite, per i quali potrei aver bisogno di quel determinato Container senza collegamento allora va preferito sempre il semplice link mentre al contrario va preferita sempre la dipendenza.

Configurazioni d’ambiente nei Container Docker

Ogni software di solito ha delle caratteristiche differenti e deve essere configurato in maniera particolare per funzionare a dovere. Pensa al database che in fase di installazione deve sapere che passoword impostare, o magari pensiamo a WordPress, al quale dobbiamo far conoscere la stessa password del database in modo da ritrovarlo già configurato e pronto per partire all’avvio!

Per operare queste configurazioni specifiche Docker ci viene incontro e ci fornisce l’istruzione environment, con la quale possiamo indicare tutte le configurazioni specifiche dell’ambiente.

... 
  mariadb: 
    ... 
    environment: 
      MYSQL_ROOT_PASSWORD: myc00lp@ssw0rd 
  wordpress: 
    ... 
    environment: 
      WORDPRESS_DB_PASSWORD: myc00lp@ssw0rd 
  phpmyadmin: 
    ... 
    environment: 
      PMA_USER: root 
      PMA_PASSWORD: myc00lp@ssw0rd 
      PMA_HOST: mysql 
  ...

Queste configurazioni non sono comuni a tutti i Container proprio perchè ciascun ambiente ha necessità particolari quindi dobbiamo andarle a ricavare dalla documentazione delle immagini stesse. Non ti preoccupare se ti sembra un gran lavoro perchè molto spesso sono i manutentori delle immagini che ci mettono a disposizione esempi di configurazioni particolari da cui prendere spunto e, soprattutto, se si conosce il software in questione è anche facile capire quali saranno quelle necessarie.

Prendiamo ad esempio il nostro Container phpMyAdmin al quale abbiamo collegato tramite link il Container mariadb.

Dobbiamo ora dire al software quale utente e password utilizzare per gestire il database e specificarne il tipo. In questo caso mi è bastato leggere la documentazione dell’immagine per sapere che esistono le istruzioni PMA_USER, PMA_PASSWORD e PMA_HOST che ho messo in fila sotto all’istruzione environment per creare una configurazione d’ambiente specifica.

L’immagine del Container Docker ufficiale WordPress permette configurazioni d’ambiente molto avanzate e utili allo sviluppo che spaziano dalla versione di PHP fino alla versione di WP-CLI. Ti invito quindi a scoprirle tutte per personalizzare al meglio il tuo ambiente di sviluppo, in fondo questa è la vera potenza di Docker e sta solo a te saperla sfruttare!

I comandi base docker-compose

Ora che abbiamo il nostro file docker-compose.yml pronto all’uso non dobbiamo far altro che dire a Docker di comporre i nostri Container come disposto nelle configurazioni.

Per fare questo dobbiamo navigare con il terminale nella cartella del nostro progetto contenente il file e digitare docker-compose up -d. Il comando up non farà altro che avviare i Container e nel caso in cui non fossero ancora stati creati si preoccuperà di farlo per noi scaricando anche tutto il contenuto necessario da Docker Hub. Questa operazione scaricherà le immagini in una cache locale che ti premetterà di non dover ripetere l’operazione di download ogni volta che deciderai di avviare quelle specifiche immagini in progetti diversi.

Avrai notato che ho usato la flag -d con il comando up, in realtà il comando funziona anche senza, ma questa flag ci permette di avviare i Container in maniera non verbosa e di poter continuare ad usare la riga di comando senza riempirla di output poco interessanti per il nostro fine. Il comando up -d ci tornerà utile anche per avviare novamente i Container che abbiamo deciso di fermare.

Una volta concluso l’avvio dei Container possiamo iniziare a lavorare sul nostro sito locale, ci basterà navigare nella cartella public/ per trovare tutti i file del webserver mentre possiamo navigare nella cartella config/ e piazzarci il Movefile necessario a far funzionare WordMove e mettere sotto controllo versione con Git le cartelle che ci interessano.

Ricorda che in questo modo potrai anche spingere su Git direttamente la cartella public/, facendo però attenzione a non spostare i file con i dati sensibili, quali wp-config.php e .htaccess, escludendoli via gitignore.

Nel caso in cui ti interessi vedere i nomi dei Container avviati, lo stato attuale e la mappatura delle porte ti basterà navigare nella cartella del progetto e digitare docker-compose ps, questo comando è molto comodo per capire bene a fondo l’ordine dei Container e se qualcosa è andato storto nell’avvio. Potete vedere nello screen qui sotto la situazione dei miei Container per lo sviluppo di SkillsAndMore.

Operato ciò che vogliamo fare è arrivato il momento di spegnere tutto e andare a mangiare qualcosa ed è qui che ci viene incontro il comando docker-compose stop che  permette di arrestare i Container e liberare le porte mappate. Il comando stop non distrugge i dati e la persistenza del database ed è il comando che permetterà di fermare i Container e magari utilizzare la stessa mappatura delle porte per un’altro progetto.

Diciamo pure che questo è il comando che “mette in pausa” il tuo lavoro e permette, eventualmente, di passare ad altro senza pedere nessun dato o configurazione.

Nel caso in cui avessi finito di lavorare definitivamente al progetto e volessi distruggere tutto ripulendo quindi la tua macchina da Container in disuso, ti basterà navigare nella root della cartella del progetto e digitare il comando docker-compose down. Il comando si occupa, al contrario di up, di spegnere le macchine ed eliminarne la peristenza.

Resta solo un comando che devi conoscere per sviluppare in locale con questa configurazione e si tratta di docker exec che ti permetterà di eseguire e lanciare comandi all’intero di un Container direttamente dal tuo terminale.

Prendiamo proprio ad esempio WordMove, che necessita di essere pilotato per fare alcune operazioni. Per prendere il possesso del terminale del Container WordMove dobbiamo lanciare il comando docker exec -it nome_container_wordmove /bin/bash dove nome_container_wordmove lo ricaverai dal comando docker-compose ps che ti ho spiegato poco più in alto.

Questo comando ci permetterà di lanciare qualsiasi eseguibile messo a disposizione all’interno del Container. Potete approfondire i significati delle flag che ho utilizzato nella pagina apposita della documentazione.

Sviluppo locale con wp-docker

Se non sei ancora svenuto per la quantità di informazioni che ti ho dato fin qui allora vuol dire che meriti questa scorciatoia che ti sto per regalare. Come avrai capito mi sono innamorato di questo strumento ed ho iniziato ad integrarlo nel mio workflow con WordPress da qualche tempo con successo.

Immagina un programmatore pigro che deve mettersi ogni volta a scrivere il file docker-compose.yml, spesso molto simile, se può starsene a guardare se stesso ripetere operazioni da scimmia. Ecco qui che ho deciso di creare uno script che permette, una volta installato nel sistema, di creare un progetto WordPress in locale con Docker già preconfigurato per avere tutto ciò che serve a lavorare.

Ho creato quindi wp-docker, che potrai scaricare da questo repo GitHub e piazzare nella cartella /usr/local/bin, nella cartella /bin nella home del tuo utente oppure lanciarlo direttamente spostandolo dove meglio credi, l’importante è rendere lo script eseguibile.

Al momento lanciandolo viene chiesto il nome del progetto, una password abbastanza sicura e se si vuole includere o meno phpMyAdmin e WordMove. Specificate queste cose lo script penserà a creare la struttura ideale per il progetto locale, mapperà le porte e avvierà i Container selezionati. Se hai deciso di installare WordMove troverai la cartella config/ con al suo interno un Movefile di base di cui dovrai modificare i dati della scheda production per poterti collegare con il tuo sito online.

Se il tuo sito si connette in SSH utilizzando una password ti sarà necessario installare sshpass, puoi fare questa operazione richiamando il terminale del Container WordMove come ti ho spiegato in precedenza con il comando exec e una volta preso il controllo del terminale lanciare apt-get install sshpass. In caso ti connettessi via SSH avvalendoti di chiavi allora puoi comodamente piazzarle nella cartella nascosta .ssh che si trova nella home del tuo utente.

L’albero delle cartlle che ti troverai nel progetto segue questo schema:

• Cartella progetto
  • public/
  • docker-compose.yml

La mappatura delle porte, una volta avviati i Container, sarà la seguente:

• localhost:8080 o 0.0.0.0:8080 – WordPress (Apache)
• localhost:8081 o 0.0.0.0:8081 – MariaDB (MySQL)
• localhost:8082 o 0.0.0.0:8082 – phpMyAdmin (User root)

Ricordati che una volta avviato un progetto con questo script per ora non potrai avviarne un altro senza prima fermare il precedente perchè altrimenti causeresti un conflitto di porte mappate. Ti basterà utilizzare il comando docker-compose stop per poterti avvalere nuovamente dello script.

Una volta fermato il progetto in questo modo potrai usare docker-compose up -d per avviarlo nuovamente quando ne avrai bisogno.

Se invece vuoi disfarti del progetto usa docker-compose down e alla fine dell’operazione di cancellazione elimina pure la cartella senza rimorsi.

Conclusioni

Siamo giunti alla fine di questo lungo articolo dove ti ho presentato le potenzialità di Docker e uno script che ti permetterà di creare ambienti di sviluppo dedicati a WordPress in un baleno.

Spero che i contenuti ti siano piaciuti e sfrutto l’occasione per invitarti a sperimentare con Docker e a comporre i tuoi stack con docker-compose perchè se cercherai un po’ in rete ti accorgerai del numero sempre crescente di organizzazioni e compagnie che lo stanno adottando nelle loro architetture.

Oltretutto mi interessa molto il tuo parere su questo script e sul modo di lavorare che ormai è diventato il mio workflow quotidiano, quindi fammi sapere tramite i commenti se hai o suggerimenti in merito e se ti viene in mente qualche altro tool vitale da inserire che attualmente manca all’appello.