Advertisement
  1. Code
  2. PHP
Code

Fai il Deploy della Tua Applicazione PHP con Rocketeer

by
Length:LongLanguages:

Italian (Italiano) translation by Luca Menozzi (you can also view the original English article)

C'era un tempo in cui gli sviluppatori PHP dovevano utilizzare strumenti per il deployment rivolti ad applicazioni web generiche.  Se ne parla, ad esempio, in un tutorial di Johannes Schickling sul deploying di applicazioni Laravel con Capistrano, ad esempio. E' un tool in Ruby, e c'è bisogno di scrivere codice in questo linguaggio. Questi tool fanno quello che devono fare ma hanno una limitata integrazione con le applicazioni PHP. Il che può generare soluzioni raffazzonate, in alcuni scenari.

Ma al giorno d'oggi abbiamo la fortuna di avere alcuni tool di deployment scritti nel nostro linguaggio che offrono un'integrazione più stretta. Uno di questi tool è Rocketeer, uno strumento che prende ispirazione da Capistrano e dal framework Laravel.

Rocketeer è un tool moderno che propone un ottimo approccio per le tue necessità di deployment: eseguire task e gestire la tua applicazione attraverso differenti ambienti e server. Inoltre, ha anche qualche funzione magica, come installare le dipendenze se trova un file composer.json. Troverai configurazioni di base sensate e automazioni per i task più comuni per un'applicazione PHP moderna. Hai inoltre la possibilità di personalizzare ed estendere qualsiasi cosa.

Puoi vederlo come un task runner SSH eseguito lato client. I comandi vengono eseguiti sui server attraverso una connessione SSH. Se utilizzi un hosting condiviso con il solo accesso FTP purtroppo non c'è nulla da fare. Hai bisogno anche di un repository remoto da cui il tool può andare a scaricare il codice. Di base, c'è il supporto per GIT e SVN. Hai bisogno di supporto per un altro sistema di controllo di versione? Puoi scrivere la tua implementazione partendo dalle interfacce fornite.

Installazione

Puoi installare Rocketeer in due modi. O scaricare il file phar e renderlo eseguibile o installarlo tramite composer. Io prefersico l'ultima. Averlo come dipendenza ti permette di installarlo facilmente quando cloni un repository. Questo è vantaggioso per chiunque cloni il repository che si ritrova con le dipendenze installate e funzionanti.

Installarlo con Composer:

Non ti consiglio di installarlo globalmente. Tenendolo al livello del repository garantisce che chiunque faccia il deploy stia eseguendo la stessa versione. Quello che ti consiglio è di aggiungere vendor/bin al tuo PATH. Così puoi usarlo scrivendo rocketeer dalla root del progetto.

Accensione

Partiamo! Per prima cosa, carica le directory e i file per la configurazione. Fai questo eseguendo rocketeer ignite nella root del tuo progetto.

Con l'accensione dell'applicazione, il tool crea una cartella .rocketeer. Il contenuto della directory dovrebbe essere questo:

Questi sono tutti i file di configurazione di cui hai bisogno per iniziare a settare i tuoi deployment. Ogni volta che parlerò di file di configurazione, d'ora in avanti, li troverai nella directory .rocketeer/ .

Struttura della Cartella Remota

E' importante capire come Rocketeer gestisce la struttura della cartella lato server, perchè è un po' differente rispetto ad un normale setup. Il tool utilizza un po' di directory per gestire alcuni aspetti del deployment, in modo da essere efficace nelle operazioni. Tu specifichi un percorso in cui vuoi effettuare il deploy della tua applicazione sul server, e il tool si prenderà cura di tutto il resto. Quella cartella assomiglierà a questa, se hai /var/www/app come directory dell'applicazione.

Quella più importante è la directory current, che punta alla tua ultima release. Che è dove dovrebbe essere impostata la document root del tuo web server. Quindi cosa succede quando fai il deploy?

  1. Il tool crea una cartella con il timestamp come nome nella directory releases.
  2. Completa tutti i task per creare una release disponibile.
  3. Aggiorna il link simbolico current alla nuova release.

Questo processo rende il tuo deployment trasparente all'utente. Lo switch tra le release è praticamente istantaneo, a cui, solitamente, ci si riferisce con il termine atomic deployments.

Alcuni dati dovrebbero rimanere persistenti tra i deployment. Ad esempio, potrebbero esserci upload, sessioni e log. Questi file o cartelle devono essere inseriti nella cartella shared. Il tool crea i link simbolici dentro ciascuna release per quelli che hai configurato.

Eventi

Gli eventi guidano il tool, e tutte le strategies e i tasks lanciano un evento before e uno after quando vengono eseguiti. Forniscono anche uno speciale evento halt quando un task fallisce. Potrebbero essere, ad esempio, dependencies.halt o deploy.halt per interruzioni di carattere generale. Questo ci consente di avere agganci col processo di deployment dovunque ne abbiamo bisogno.

Gli eventi che normalmente si verificano durante un deployment sono:

  • deploy.before: prima che succeda qualsiasi cosa;
  • create-release.before: prima che crei una nuova directory release;
  • create-release.after: dopo aver creato una nuova directory release;
  • dependencies.before: prima di installare o aggiornare le dipendenze;
  • dependencies.after: dopo aver installato o aggiornato le dipendenze. Assicurati che i binari nella cartella vendor siano eseguibili;
  • test.before: prima di lanciare i test;
  • test.after: dopo aver eseguito i test;
  • migrate.before: prima di lanciare le migrazioni del database. Forse vuoi un backup del database?
  • migrate.after: dopo aver eseguito le migrazioni del database;
  • deploy.before-symlink: prima di creare il link simbolico alla release corrente;
  • deploy.after: completato. Puoi notificare alle persone che tutto è andato liscio come l'olio o che qualcosa è andato storto.

Possiamo anche creare eventi personalizzati che possiamo lanciare e rimanerne in ascolto. Per ora, rimaniamo con gli eventi già disponibili. Sono sufficienti per noi, al momento.

Tasks

Nel cuore di Rocketeer, troviamo un concetto chiamato tasks. Molto di quello che succede all'interno sono core tasks. La definizione di task può essere "un insieme di istruzioni da portare a termine come step in un deployment". Se guardiamo alcune delle classi che fornisce il tool, possiamo farci un'idea di cosa sono i tasks: classi come Deploy, Setup, Migrate, Rollback e Dependencies. Quando fai il deploy, il comando deploy stesso è un task con sottotasks.

Tipi di Tasks

Qui inizi a vedere come il tool è integrato con PHP, dato che andrai a scrivere tasks in questo linguaggio. Puoi crearli in tre modi differenti:

Comandi del terminale arbitrari. Sono comandi di una riga da eseguire sul server. Possono essere utili per molte ragioni, come, ad esempio, lanciare gulp build --production.

Closures. Se hai bisogno di un po' più di flessibilità, o complessità, puoi scrivere i tasks come closures ( funzioni anonime ). Diciamo che hai bisogno di generare la documentazione per una API durante un deployment.

Classi. Per tasks più complessi, dovresti usare l'opzione per creare classi per tasks. Crea una classe ed estendi Rocketeer\Abstracts\AbstractTask. Quindi, fornisci almeno una descrizione e un metodo execute(). Qui di seguito trovi un esempio completamente privo di utilità, ma che mostra la struttura di una classe task:

Tieni presente che devi registrare tu stesso la classe task. Puoi farlo o attraverso il file hooks.php e aggiungerla nell'array custom...

... oppure attraverso la facade:

Una volta registrato, puoi eseguirlo:

Definizione dei Tasks

Abbiamo parlato degli eventi in precedenza perché ci agganciamo ai tasks dove ne abbiamo bisogno durante il processo. Questo può essere fatto in diversi modi. Scegli quello che preferisci e che soddisfa i requisiti del tuo livello di complessità.

Il modo più semplice per definire i tuoi task è nel file hooks.php. Mette a disposizione due array, per questo scopo, in cui specificare l'esecuzione del task prima o dopo l'accadimento di determinati eventi.

Strategies

Potresti pensare che i task a disposizione siano piuttosto generici. Prendi, ad esempio, Dependencies. Di che tipo di dipendenze stiamo parlando e di quale package manager?

E' qui che le strategies entrano in gioco. Una strategy è una specifica implementazione di un task, come l'esecuzione dei test con Behat o l'utilizzo di Gulp per la costruzione del front-end. I tasks hanno una strategy di default con l'opzione per eseguire altre strategies attraverso la CLI. Possiamo elencare le strategies disponibili in questo modo:

Creare le Tue Strategies

Mettiamo che tu stia sviluppando la tua applicazione con il BDD con Behat piuttosto che con il TDD. E che quindi tu voglia eseguire i tuoi test con Behat invece che con PHPUnit. Dato che si tratta di esecuzione di test, esiste già uno strategy namespace per questo, ma manca l'implementazione. Crea la directory .rocketeer/strategies/ e crea il tuo BehatStrategy.php in questa cartella.

Ora puoi sostituire il tuo strategy test con la nuova implementazione in strategies.php.

Connections & Stages

Non importa se hai un'infrastruttura reale o una da realizzare. Non importa se la tua applicazione fa il deploy in molti ambienti su diversi server. Rocketeer sarà al tuo fianco. Puoi anche avere molte posizioni diverse sullo stesso server. Qui è dove entrano in gioco i termini connections e stages.

Una connection è un server su cui fai il deploy della tua applicazione. Ci si riferisce di solito ad esso come ambiente, come, ad esempio, produzione e staging. Configurare queste connessioni nel tool è davvero un gioco da ragazzi. Sia che tu lo faccia tramite un array nidificato, sia che tu tenga i file separati per ogni connessione. Ogni connessione può anche avere molteplici server in essa.

Gli stages sono un po' come connections dentro le connections, una sorta di "connectionception". Puoi configurare un ambiente di staging e uno di produzione in un singolo server tramite gli stages. Così, invece di avere due connections separate,  ne hai una con due stages all'interno.

Plugins

Un'ottima caratteristica è che possiamo estendere il nostro processo tramite i plugins. Ce ne sono alcuni ufficiali per l'integrazione con Laravel, Slack, HipChat e Campfire. E ce ne sono altre, ma non così tante, su Packagist. Installare i plugin è un'azione facile attraverso la CLI:

Nonostante ci sia un limitato numero di plugins, c'è spazio per svilupparne in futuro. Ci suggerisce una buona filosofia. Perché non svilupparne uno per conto nostro?

Configurare il Tuo Deployment

Hai bisogno di qualche configurazione di base per far sì che la tua applicazione decolli. Hai bisogno di dire a Rocketeer dove trovarla e dove deve fare il deploy. Partiamo impostando un nome per l'applicazione e inserendo un server di produzione in config.php.

Ora hai un nome per l'applicazione e un server su cui fare il deploy. Questa configurazione utilizza la chiave di autenticazione SSH, ma puoi connetterti  anche con username e password. Per far sì che vengano richieste username e password, imposta 'key' => ''. Il tool memorizza le credenziali sulla tua macchina locale e le usa ogni volta in seguito. Ti consiglio di non inserire username e password nel file di configurazione, perché così eviti di committare le credenziali nel repository.

Quello che dovresti fare ora è cambiare la connection di default su cui fai il deploy. Avere impostato il server di produzione su default non è il massimo. Vogliamo evitare di fare il deploy in produzione per errore. Per cui, nello stesso file, cerca la chiave default a cambiala con staging.

Non è importante il nome in sé che dai all'applicazione. Ma se non specifichi una cartella in cui fare il deploy, verrà usato questo nome per la cartella nella directory root. Di default, la root è impostata a /home/www. Con questo nome per l'applicazione, il deploy verrà fatto su /home/www/my-deployable-app. Se vuoi modificare la directory root, puoi farlo in remote.php.

Nello stesso file, hai la possibilità di sovrascrivere il nome dell'applicazione e specificare una directory.

Ora hai un punto di ricezione del deployment, ma hai bisogno anche di configurare da dove può essere preso il tuo codice. Puoi farlo inserendo il repository remoto in scm.php. Di default viene usato Git, ma c'è il supporto anche per SVN. Basta dirgli l'indirizzo del repository e fornire le credenziali, se richieste. Suggerisco di usare la chiave di autenticazione SSH anche qui, e lasciare vuoti username e password.

Dato che hai aggiunto una connection al server di produzione, vorrai fare il deploy del branch master.

Configurazione Specifica per Connection & Stages

In molte situazioni, vuoi differenziare la configurazione per le diverse connections o stages. Diciamo, per esempio, che tu voglia fare il deploy di un altro branch per l'ambiente di staging. Rocketeer permette di sovrascrivere i valori di configurazione per le connections e per gli stages nel file config.php. Per fare il deploy di un branch denominato staging, nella connection staging, devi fare questo:

Viene usato un array nidificato per sovrascrivere i valori della configurazione. Sotto la chiave staging, cerca la chiave che vuoi modificare nel file corrispondente. Nel nostro caso è branch in scm.php.

Deploy, Decollo!

A questo punto hai configurato tutto il necessario per fare un deployment che vada a buon fine. Non hai soddisfatto i requisiti per un deployment completo, ma quello che hai fatto è sufficiente per avere l'applicazione clonata sul server e fruibile dagli utenti finali. Per prima cosa, puoi eseguire la strategy check per verificare che il server soddisfi i requisiti.

Se tutto va bene, puoi lanciare il deploy tramite:

Dato che questo è il tuo primo deployment, Rocketeer si assicura che venga creato tutto il necessario. Il tool crea le directory di cui ha bisogno nelle quali verrà sistemata l'applicazione. Se tutto fila liscio, dovresti ritrovarti con una build completa della tua applicazione sul server.

Se hai modificato la connection di default in staging, nella sezione precedente, farà sempre il deploy su staging. Il che è corretto, a meno che tu non dica di fare il deploy altrove. Quando vuoi fare il deploy su una connection differente, o su più di una, usa l'opzione --on.

Vuoi dare un'occhiata a cosa succede sul server una volta che clicchi il pulsante? Usa il flag --pretend per far sì che il tool ti dica cosa sta eseguendo sul server.

Houston, Abbiamo un Problema. Abbiamo Bisogno di un Rollback.

Sfortunatamente dobbiamo preoccuparci dei deployment che interrompono una funzionalità o creano problemi all'infrastruttura. Devi perciò fare un veloce rollback alla tua ultima release. Per fortuna è un'operazione semplice—esegui il comando:

Dato che salva diverse build, effettuare un rollback è veloce. Cambia il link simbolico current alla release precedente.

Directory Condivise

Configurare le directory condivise è semplice—aggiungile nell'array shared che trovi in remote.php. Rocketeer le creerà e le collegherà per te durante il deployment successivamente. I percorsi specificati devono essere relativi alla tua cartella root.

Directory Scrivibili

La maggior parte delle directory condivise hanno anche bisogno di essere scrivibili dal web server. Scrivere log, sessioni o uploads è un task spesso svolto da qualsiasi applicazione. Puoi aggiungere queste directory nell'array permissions.files in remote.php.

Installare o Aggiornare le Dipendenze

Hai bisogno di installare o aggiornare le dipendenze se l'applicazione si basa su qualsiasi tipo di dipendenza. Il tool viene fornito con il supporto per i package manager più popolari. Non c'è bisogno di configurare nulla se con loro usi le configurazioni di default. Il tool rileva e installa, o aggiorna, le dipendenze per Composer, Npm, Bower e Bundler. La strategia di default per dependencies è impostata su Polyglot. Questo è il modo con cui il tool rileva e installa le dipendenze per i diversi package manager.

Ma mettiamo che tu voglia installare tutte le dipendenze su staging e il tool utilizza il flag --no-dev di default. Magari vuoi installare PHPUnit per eseguire dei test, una dipendenza da ambiente di sviluppo. In strategies.php puoi cercare la chiave composer, che indica al tool come eseguire Composer. Puoi quindi sovrascriverlo in config.php:

Migrazioni del Database

La migrazione dei database è, di solito, qualcosa che vuoi fare quando hai una release completa, appena prima di impostare il link simbolico a current. Qualsiasi tool tu utilizzi, puoi dire di eseguirlo prima di deploy.before-symlink. Questo hook non è uno di quelli regolari, ma uno interno. È quindi necessario registrarlo da qualsiasi altra parte tranne che in hooks.php. Puoi farlo in events.php, che puoi creare, se già non esiste.

Eseguire i Test

Eseguire i test in un processo di deployment è un ottimo modo di assicurarsi che non ci siano bug. Di default, il tool usa PHPUnit e puoi far eseguire i test dopo che le dipendenze sono state installate o aggiornate.

Dovremmo vedere, a questo punto, che PHPUnit viene eseguito per ciascun deployment e, nel caso i test falliscano, si interrompe. Assicurati di vedere del testo in output, altrimenti potrebbe esserci un problema nel trovare il binario di PHPUnit nella tua suite di test.

Strumenti di Build Front-End

Spesso le tue applicazioni non sono solo composte da un back end, a meno che non siano API REST, ad esempio. Eseguire gli strumenti di build per il front end è una procedura comune con tool quali Grunt, Gulp o Webpack. Realizzare questo passaggio del tuo processo di deployment è semplice come utilizzare un hook per eseguire comandi, come:

Anche il front end spesso ha dipendenze, per cui esegui i tool dopo averle installate o aggiornate.

Tips & Tricks

Eseguire gli Updates

Se non vuoi creare una nuova release quando fai il deploy, hai la possibilità di lanciare un update. Sii prudente quando lo fai perché non potrai fare il rollback alla precedente versione, solo alla precedente release. Ma è un modo semplice e veloce per aggiornare la tua applicazione con le ultime modifiche, tramite:

Task Locali

Ogni tanto può essere utile eseguire task nel tuo ambiente locale. Diciamo che tu voglia eseguire una verifica con PHPCS, o creare i tuoi asset statici e caricarli sul server, eliminando la necessità di alcuni binari sul server. Se crei una classe task, puoi impostare la variabile protetta $local a true.

Conclusioni

Il processo di deployment è una parte importante di un ciclo di vita di un'applicazione. I tool come Rocketeer ti permettono di rendere questo processo una compito semplice. E' particolarmente vero quando lo usi per un'applicazione PHP, dato che si integra davvero bene con essa.

Scrivere un tutorial introduttivo su Rocketeer si è rivelato essere un compito difficile. Lo strumento è così flessibile che non è facile sapere dove fermarsi. Spero di aver reso le potenzialità di questo tool e di come possa essere utile a te e alla tua applicazione. Se vuoi scavare più a fondo, ti suggerisco di leggere l'intera documentazione. C'è molto di più nel tool di quanto abbia trattato io in questo articolo.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.