5 metodi per effettuare il deploy di App PHP

Oggi il nostro focus si sposta su PHP e in particolare sul deploy delle applicazioni create con questo linguaggio. Gli step più comuni che vengono eseguiti per la messa in produzione di un progetto PHP based sono di solito quattro:

1. Test dell'applicazione.
2. Download delle dipendenze (magari con Composer).
3. Compilazione degli assets (Gulp/Webpack/Grunt).
4. Deploy sul server.

Prima di proseguire bisogna però ricordare che è sempre meglio tenere tutto il nostro codice sotto controllo tramite un sistema di version control. Sorgenti, file di configurazione, documentazione, script per la migrazione del database dovrebbero essere inseriti all'interno di un repository, magari tramite Git, cosi da preservarli in caso di problemi.

La seconda regola da tenere a mente è che non si dovrebbero mai caricare dipendenze e applicazioni compilate all'interno del sistema di version control. Questo eviterà noie dovute ai conflitti tra le dipendenze presenti nel repository.

Alcuni developer preferiscono passare tutte le dipendenze e gli altri asset su di un server e realizzare li la propria applicazione. Una volta creata l'applicazione bisogna testarla e se tutto va bene è possibile caricare il codice su di un repository tramite FTP o con rsync. In fine possiamo riscaricare le dipendenze sul server ed eseguire il build finale.

I pro di questo workflow sono:

• il build environment dell'app è identico al running environment;
• le dipendenze vengono scaricate molto velocemente.

I contro invece:

• se non si usa qualche meccanismo per minimizzare i downtime (ad esempio l'atomic deployment), il tempo per il download delle dipendenze e per eseguire il build potrebbe essere davvero lungo.

Altri sviluppatori invece preferiscono realizzare sviluppo, build e test della propria applicazione in locale ed in fine eseguire il deploy vero e proprio su di un server con la versione finale dell'applicazione assieme alle varie dipendenze e agli asset.

I pro sono:

• il server di produzione non è stressato dal processo di build;
• le applicazioni del server di produzione sono uguali a quelle presenti nei server di test;
• non è necessario utilizzare SSH per eseguire degli script ma basta usare un client FTP.

I contro:

• è necessario un sistema uguale al build environment per far avviare l'applicazione;
• visto che si effettua il deploy di ogni elemento (comprese le dipendenze) i tempi di upload possono essere lunghi.

La terza via prevede l'utilizzo di Git, lo sviluppatore segue i medesimi step del primo workflow e l'unica differenza sta nell'installazione di Git sul server di produzione. Il deploy viene dunque effettuato tramite git push al posto delle normali modalità di upload dei file.

I pro di questo workflow sono:

• con Git verranno caricate solo le modifiche effettive e i tempi di upload saranno molto più rapidi;
• non c'è bisogno di usare script ed SSH, perché il webhook verrà invocato in automatico.

I contro:

• il tempo per il build può essere più lungo delle altre opzioni e può impattare sulle performance del server di produzione.

Uno degli aspetti critici dei precedenti workflow è il downtime. Infatti l'applicazione non sarà disponibile durante il processo di deploy. Esiste però una soluzione: bisogna eseguire il deploy e il build dell'applicazione in una directory differente da quella dove attualmente si trova la release in uso. Si deve dunque adottare una configurazione di directory simile a questa:

/current - un symbolic link dell'attuale versione in uso;
/releases - con tutte le versioni caricate sul server
/deploy-cache - usata per il desploy

La nuova versione dell'App viene caricata su /deploy-cache, poi viene copiata in /releases/${revision} e in fine il symbolic link deve essere spostato su /releases/${revision}.

I pro sono:

• downtime ridotto praticamente a zero;
• possibilità di effettuare un rollback istantaneo alla vecchia versione dell'applicazione.

I contro, invece:

• è richiesto molto spazio sul server e questo può far lievitare i costi;
• si devono scrivere diversi script a mano (anche se una volta finito non si dovranno eseguire ulteriori interventi.

L'ultima opzione prevede l'uso di Docker:

FROM php:7
RUN apt-get update -y && apt-get install -y openssl zip unzip git
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
RUN docker-php-ext-install pdo mbstring
WORKDIR /app
COPY . /app
RUN composer install
CMD php artisan serve --host=0.0.0.0 --port=8181
EXPOSE 8181

Questo file può essere utilizzato per creare una Docker image:

docker build -t my-image

Finito il build si potrà avviare un'immagine completamente isolata del nostro ambiente PHP:

$ docker run -p 8081:8081 my-image

In questo ambiente sarà possibile sviluppare, testare, eseguire il build dell'applicazione in un Docker ed in fine pushare l'applicazione sul Docker Registry. Poi si potrà stabilire una connessione SSH al server e passare all'esecuzione.

I pro di questo workflow sono:

• l'applicazione potrà essere avvita in modo completamente autonomo dall'ambiente in cui si trova;
• possibilità di eseguire rollback in modo semplice;
• Build configuration e application environment sono interamente documentati nel Dockerfile all'interno del repository.

I contro invece:

• alcuni sviluppatori ritengono che Docker non sia pronto per la produzione.

Concludendo, esistono vari tipi di workflow e nessuno di questo è perfetto, quindi come accade quasi sempre in ambito informatico è sempre meglio adottare la soluzione che si adatta di più alle proprie esigenze.

Via Buddy Work