Il Continuous Deployment rappresenta l’apoteosi dell’automazione di processo, ogni nuova Feature integrata nel Master Branch viene automaticamente rilasciata in pro-
duzione, garantendo qualità e continuità del servizio. Il Continuous Deployment mostra le sue maggiori potenzialità in quelle aziende che hanno a che fare con servi-
zi daemon, fortemente real time, con la necessità di offrire costantemente un servizio. Il più comune esempio sono i siti web o le Paas, dove anche un solo minuto offline
provoca un danno economico non trascurabile.
percepire gli effettivi vantaggi di questa best practice, accontentandosi dell’automa- tizzare il deploy mantenendo comunque la scelta manuale.
Per raggiungere il livello di confidenza richiesto dal CD, il team deve aver ab- bracciato con successo le precedenti pratiche e aver costruito passo dopo passo una
pipeline in grado di garantire la massima qualità e la totale fiducia riguardo il ri- lascio del componente in produzione. Infine anche l’ecosistema culturale del team
deve essere ottimale, ognuno deve avere a cuore il prodotto e prendersi carico delle proprie responsabilità in armonia con i colleghi.
In questo progetto il Continuous Deployment è garantito dalla presenza di com-
ponenti software, basati ancora una volta su Ansible, in grado di gestire in maniera sicura il deploy in produzione. La pratica è inoltre supportata da un sistema di Con-
tinuous Monitoring in grado di verificare che il prodotto funzioni anche in ambiente di produzione reale.
7.7.1
Script di Deploy
Il deploy, in quanto parte della pipeline, non può più essere gestito con i tradizionali
metodi basati su script. Il componente che esegue l’aggiornamento non deve solo
assicurarsi che la nuova versione sia collocata nella corretta locazione, deve anche garantire che il componente sia attivo e funzionante. Allo scopo di fornire un con-
trollo ottimale si è preferito gestire in maniera differente il deploy dei componenti Batch rispetto a quelli Real Time.
Deploy Batch
I due componenti Batch proposti hanno metodi di esecuzione differenti: BatchETL
è eseguito on-demand all’inserimento di nuovi movies (o in corrispondenza di un nuovo aggiornamento), MRSpark2 è invece eseguito giornalmente a un orario ben
definito. Eseguire un deploy mentre il processo è in esecuzione porterebbe a numerosi problemi, in ogni caso i due processi sono per la maggior parte del tempo offline,
quindi è sufficiente evitare di eseguire l’aggiornamento nel periodo di attività. I Playbook Ansible che eseguono il Deploy devono quindi preoccuparsi sempli-
cemente di trasferire i file necessari all’esecuzione nella corretta locazione del Edge Node di produzione. Nel Listato C.11 in Appendice C è mostrato il Playbook di
deploy per BatchETL.
La Continuous Deployment Pipeline si occupa di archiviare i package assemblati
nella cartella /opt/deploy/*, differente in base al processo in analisi. Il Playbook non fa altro che prendere il contenuto di tale cartella è trasferirlo nella directo-
ry /opt/devops/* sull’istanza DevOps Worker. Alla prima esecuzione verranno percepite le modifiche apportate.
Deploy Real Time
Discorso differente deve essere fatto per i processi Real Time presentati, entrambi hanno un comportamento da daemon, devono infatti essere sempre attivi e dispo-
nibili in modo da processare i dati in arrivo. Si è scelto di implementare entrambi i processi come dei servizi, accessibili da qualsiasi locazione del DevOps Worker tra-
mite il comando service *name* start/stop/status. La configurazione dei file necessari è parte integrante del processo di Provisioning del DevOps Worker tra-
mite Ansible, dando la possibilità di controllare sia l’aggiornamento che l’effettiva esecuzione del servizio.
RealTimeETL Arrestare questo servizio per il breve tempo di trasferimento di una versione aggiornata non comporta un grosso problema. Grazie al tempo di re-
tain dei topics Kafka, gli eventuali ratings sopraggiunti durante il periodo di do- wn verranno processati al riavvio, nel primo blocco di Discretized Stream. Il Play-
book di deployment deve quindi assicurarsi soltanto di arrestare il daemon prima dell’aggiornamento e successivamente riattivare il servizio.
RealTimeMovieRec La sospensione di questo servizio è, in linea teorica, più de- licata. Per come è stato proposto, l’interazione con il raccomandatore avviene solo tramite interfaccia grafica da parte di utenti interessati all’argomento, non trat-
tando dati personali o comunque importanti il down del servizio comporterebbe semplicemente un maggior tempo di attesa o la visualizzazione di una pagina di
Mantenimento.
In pratica però la webapp è in tutto e per tutto un server REST potenzial-
mente utilizzabile, tramite opportuni endpoint del tipo localhost:10000/raw/see/ :user/:movie/:rating, da altri servizi per accedere al raccomandatore. Mettere offli-
ne il daemon per un aggiornamento potrebbe quindi significare compromettere le funzionalità di altri servizi correlati.
Al momento il deployment è gestito nella stessa maniera del RealTimeETL, in ogni caso sarà necessario implementare come sviluppo futuro una soluzione basata
ad esempio sul Blue/Green Deployment, illustrato nel Capitolo 3. Il Listato C.12 in Appendice C mostra il Playbook di deployment del RealTimeETL.
Il Playbook è suddiviso in tre fasi:
1. Prima di tutto i servizi vengono arrestati;
2. La nuova versione viene trasferita, nello stesso identico modo del Deployment Batch;
3. Infine i servizi vengono riattivati, in questo caso specifico il playbook si assicu- ra anche che il Connettore Kafka sia ancora attivo. Si noti inoltre che i servizi
vengono lanciati con enabled: yes, questo significa che verranno eseguiti au- tomaticamente all’avvio del sistema, nell’ordine specificato dai relativi file di
configurazione.