Università degli Studi di Padova

Dipartimento di Matematica "Tullio Levi-Civita"

Scuola di Scienze

Corso di Laurea in Informatica

Un sistema di continuous building basato suJenkins e tecnologie di containerizzazione

Relatore

Prof. Gilberto FilèLaureando

Federico Silvio Busetto1026925

Anno Accademico 2016-2017

Federico Silvio Busetto: Un sistema di continuous building basato su Jenkins e tecnologie dicontainerizzazione, Tesi di laurea triennale, © 07 Dicembre 2017.

Sommario

Il presente documento descrive il lavoro svolto durante il periodo di stage, della durata dicirca trecento ore, dal laureando Federico Silvio Busetto presso l’azienda IKS s.r.l., sita inPadova.

Lo scopo principale dello stage consisteva nella realizzazione di un sistema di continuousbuilding, in grado di prendere in ingresso il codice sorgente di un’applicazione d’esempio,e�ettuarne la compilazione, e produrre in uscita un artefatto pronto per il deploy.

Era inoltre richiesto che tale sistema prevedesse l’utilizzo di tecnologie di containerizzazione,al �ne di valutare gli e�ettivi vantaggi della loro adozione.

Particolare attenzione è stata posta agli aspetti legati all’esercibilità, quali: monitoraggio,aggiornamento, backup e ripristino della piattaforma.

Gli obiettivi da raggiungere erano molteplici:In primo luogo era richiesta la progettazione e la de�nizione dell’architettura sia di alto livelloche di dettaglio di tale sistema, e la sua implementazione.

In secondo luogo è stato richiesto uno studio di fattibilità sulle modalità di comunicazionetra nodi, approfondendo in particolare le comunicazioni tra nodi container in un ambientedistribuito.

In�ne era richiesto lo sviluppo di un plugin base per Jenkins[9][24][17], da utilizzare comemodello di riferimento per l’eventuale implementazione di nuove funzionalità a livello dipiattaforma.

III

“Una grande illuminazione nasce da un grande dubbio.”

— Proverbio Zen

Ringraziamenti

Voglio esprimere la mia gratitudine al Prof. Gilberto Filè, relatore della mia tesi, per la di-sponibilità, l’aiuto e il sostegno fornitomi durante il periodo di stage e nella stesura di questodocumento. Un grazie sincero anche per l’attenzione che riserva ai suoi studenti, fornendo levideo lezioni del corso di Programmazione.

Un particolare ringraziamento al Prof. Tullio Vardanega, per aver dato una svolta al mio per-corso accademico, insegnandomi a �ssare i miei obiettivi e a piani�care adeguate strategie nelperseguirli.

Desidero ringraziare con a�etto i miei genitori e la mia famiglia per tutto l’amore che mi hannodonato e per aver sempre creduto in me, anche quando io stesso ne dubitavo.

Un ringraziamento speciale va ai miei nonni e a mia zia Dirce, per avermi insegnato a nonmollare mai e ad andare sempre avanti, anche quando sembra tutto sia perduto.

Ho desiderio di ringraziare poi i miei compagni universitari, in particolar modo i ragazzi (e leragazze) del Visions Team per aver reso quest’ultimo anno il migliore. Un grazie doppio ai mieiamici Ettore, Thomas, Elisa, Giuseppe, Marco, Paolo e Beatrice.

In�ne, ma non meno importanti, un ringraziamento ai colleghi di IKS s.r.l., specialmente almio tutor aziendale Massimo Celegato per la pazienza e la disponibilità nei miei confronti eper avermi fatto crescere professionalmente; grazie ad Andrei per avermi accompagnato allascoperta del fantastico mondo dei container e un grazie sentito a Stefano, Daniele e Giulia pertutti i bei momenti trascorsi assieme.

Padova, 07 Dicembre 2017 Federico Silvio Busetto

V

Indice

1 Introduzione 11.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 L’idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Organizzazione del documento . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Lo stage 52.1 Introduzione al progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Motivazioni aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Motivazioni personali . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Vincoli metodologici . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Vincoli temporali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3 Vincoli tecnologici . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Piani�cazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Ambiente di Lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.1 Metodologia di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.2 Gestione di progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.3 Documentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.4 Ambiente di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.5 Infrastruttura di test . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Analisi preventiva dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Tecnologie adottate 153.1 Tecnologie software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 CentOS 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.2 Bash 4.4.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.3 JDK 8 update 151 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.4 Apache Tomcat 9.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.5 Jenkins 2.73.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.6 Docker 17.10 Community Edition . . . . . . . . . . . . . . . . . . . . 173.1.7 Apache Maven 3.5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.8 cadvisor 0.28.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Linguaggi di Programmazione . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.2 Groovy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Realizzazione del sistema 214.1 Descrizione generale dell’architettura individuata . . . . . . . . . . . . . . . 21

4.1.1 Limiti dell’architettura attuale . . . . . . . . . . . . . . . . . . . . . . 214.1.2 Vantaggi della soluzione . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.1 Di�coltà riscontrate e punti di attenzione . . . . . . . . . . . . . . . 25

VII

4.3 Modalità di comunicazione master/slave . . . . . . . . . . . . . . . . . . . . 264.3.1 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3.2 JNLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Esercibilità 295.1 Monitoraggio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.1 Scelta dei plugin per Jenkins . . . . . . . . . . . . . . . . . . . . . . . 305.2 Backup e Ripristino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.3 Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Veri�ca e validazione 336.1 Resoconto attività di Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7 Conclusioni 357.1 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . 357.2 Resoconto dell’analisi dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . 377.3 Possibili Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.3.1 Monitoraggio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.3.2 Repository prodotti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.4 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.5 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Glossario 41

Acronimi 45

Bibliogra�a 47

VIII

Elenco delle �gure

1.1 Logo di IKS s.r.l. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Esempio d’applicazione a microservizi . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Visione d’insieme della metodologia Devops . . . . . . . . . . . . . . . . . . 3

2.1 Devops come punto d’unione tra sviluppo e operations . . . . . . . . . . . . . 5

2.2 I vari processi coinvolti all’interno della metodologia Devops . . . . . . . . . 6

2.3 Integrazione Continua e continuous building . . . . . . . . . . . . . . . . . . 7

2.4 Rappresentazione della metodologia CBSE . . . . . . . . . . . . . . . . . . . 12

2.5 Logo di Visual Studio code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Logo di CentOS 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Logo Bash 4.4.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Logo JDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 Logo Apache Tomcat 9.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.5 Logo Jenkins 2.73.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.6 Logo Docker 17.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.7 Logo Apache Maven 3.5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.8 Struttura di un progetto Maven, così come de�nita da un generico POM . . . 18

3.9 Logo cadvisor 0.28.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.10 Logo Java 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.11 Logo Groovy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 Visione d’alto livello dell’architettura iniziale . . . . . . . . . . . . . . . . . . 22

4.2 Rappresentazione di alto livello della soluzione individuata . . . . . . . . . . 22

4.3 Visione astratta della struttura del sistema . . . . . . . . . . . . . . . . . . . 23

4.4 Esempio di creazione della connessione tramite SSH . . . . . . . . . . . . . . 26

4.5 Diagramma di sequenza della connessione via JNLP . . . . . . . . . . . . . . 27

5.1 Uso della memoria da parte di un container Jenkins master . . . . . . . . . . 29

7.1 Loghi dello stack ELK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

IX

Elenco delle tabelle

2.1 Obiettivi dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Piani�cazione iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 tab-rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 Dimensioni delle immagini . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1 Test Funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.1 Obiettivi Raggiunti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367.2 Obiettivi Raggiunti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367.3 Resoconto dell’analisi dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . 37

X

Capitolo 1

Introduzione

In questo capitolo introdu�ivo viene fornita una panoramica dell’azienda IKS s.r.l., proponentedello stage da me svolto e l’idea alla base del proge�o. Vengono inoltre fissate alcune convenzionitipografiche per agevolare la le�ura del documento e viene presentata la stru�ura dello stesso,secondo una suddivisione per capitoli.

1.1 L’azienda

IKS 1 s.r.l. (Information Knowledge Supply) nasce nel 1999 a Padova, come azienda di consu-lenza e system integration con servizi rivolti ad una variegata tipologia di clienti quali banchee centri servizi, industria e pubblica amministrazione.

L’azienda punta da sempre su temi strategici in capo informatico, quali la sicurezza informa-tica, lo sviluppo di soluzioni software Java Enterprise Edition, l’automazione e l’innovazione.

Questo approccio portò IKS negli anni 2000 ad essere uno dei leader nel settore, nel nord-estitaliano, con sedi a Padova, Milano e Trento e nel 2016 a formare, assieme ad altre tre aziende(Insirio, System Evolution e Kirey) il gruppo Kirey2, con l’obiettivo di:

“ Diventare il principale progetto italiano di integrazione e collaborazionefra imprese del mondo IT e assumere il ruolo di protagonista di riferimento ditutte le aziende che vogliono a�rontare percorsi di innovazione digitale, riunendoeccellenze di settore, competenze verticali e partnership tecnologiche di altolivello.Sito internet Kirey Group ”

Figura 1.1: Logo di IKS s.r.l.

L’azienda è strutturata in business units (BU), cioè divisioni specializzate in particolari compiti.Ad esempio: la BU middleware si occupa della gestione della con�gurazione di applicativi

1https://www.iks.it/2http://kireygroup.com/

1

1.2. L’IDEA Introduzione

dei clienti, andando a fornire opportune impostazioni dell’infrastruttura secondo le richiestepervenute.

1.2 L’idea

Il mercato dello sviluppo software sta cambiando; mentre in passato si assisteva alla nascita dipiccole medie imprese, focalizzate sullo sviluppo di uno o due prodotti, con tempi di rilasciolunghi tra una versione e l’altra, oggi la competizione è serrata.Negli ultimi anni si assiste alla nascita di nuovi paradigmi: il machine-learning, con macchi-ne in grado di eseguire autonomamente alcune operazioni; l’Internet of Things (IoT), condispositivi perennemente connessi alla rete, in grado di misurare l’ambiente che li circonda ecomunicare tra loro; e in�ne un’automazione sempre più spinta in tutti gli ambiti delle nostrevite quotidiane.Da applicazioni monolitiche (un unico prodotto software dalle molte funzionalità, stretta-mente dipendenti e correlate tra loro), si sta passando allo sviluppo di soluzioni �essibili amicroservizi, dove vari moduli con funzionalità univoche e distinte vengono composti conaltri moduli, al �ne di ottenere un’architettura scalabile, snella e robusta.

Figura 1.2: Esempio d’applicazione a microservizi, immagine tratta dahttp://microservices.io/patterns/microservices.html

In quest’ottica, va ripensato l’intero ciclo di sviluppo del software; un’azienda, anche digrandi dimensioni, dovrà mettere in campo dei processi evolutivi per non rischiare di perdereposizioni di mercato.IKS fornisce ai suoi clienti degli appositi servizi di consulenza, accompagnandoli nella transi-zione verso una metodologia di sviluppo Devops; tale metodologia di sviluppo è un’evoluzionedel modello agile, incentrato su un’ampia automazione delle operazioni ripetitive (quali adesempio il testing e il rilascio) e sul principio cardine di collaborazione stretta tra sviluppo,ambito operations (cioè gestione dell’infrastruttura, mantenimento dell’ambiente di lavoro,con�gurazione, ecc...) e garanzia della qualità, in passato visti come mondi separati e bendistinti.

Scopo dello stage è lo studio e la realizzazione di un sistema di continuous building, che inottica Devops, permetta un’automazione dei processi di build, test e rilascio del software conun’attenzione particolare agli aspetti di portabilità del sistema, anche in previsione di unfunzionamento dello stesso in ambienti cloud.

2

Introduzione 1.3. ORGANIZZAZIONE DEL DOCUMENTO

Figura 1.3: Visione d’insieme della metodologia Devops, immagine tratta dahttp://it.wikipedia.org

1.3 Organizzazione del documento

Dopo questo primo capitolo introduttivo, il resto del documento si articola come segue:

Il secondo capitolo descrive in dettaglio il progetto di stage, riportando le motivazioniche hanno spinto l’azienda a proporlo e le mie personali nella scelta, gli obiettivi daraggiungere e la relativa piani�cazione.

Il terzo capitolo approfondisce le tecnologie adottate nella realizzazione del progetto, for-nendo per ciascuna di esse una panoramica generale e contestualizzandone il ruolo nelsistema implementato.

Il quarto capitolo illustra le varie fasi di realizzazione del sistema, dalla progettazioneall’e�ettiva implementazione. Tale capitolo riporta inoltre una panoramica approfonditasui vantaggi e i punti di attenzione dell’architettura individuata.

Il quinto capitolo Illustra le procedure individuate in merito all’esercibilità del sistema,cioè agli aspetti di monitoraggio, upgrade, backup e ripristino della piattaforma.

Il sesto capitolo riporta le strategie di veri�ca e validazione adottate e il risultato dei testcondotti.

Nel settimo capitolo in�ne, si riportano alcune considerazioni circa l’attività di stage e gliobiettivi raggiunti.

Riguardo la stesura del testo, relativamente al documento sono state adottate le seguenticonvenzioni tipogra�che:

∗ gli acronimi, le abbreviazioni e i termini ambigui o di uso non comune menzionativengono de�niti nel glossario, situato alla �ne del presente documento.Alcune de�nizioni dei termini del glossario, possono essere tratte da fonti online, tracui:https://it.wikipedia.org/;

∗ i termini in lingua straniera o facenti parti del gergo tecnico sono evidenziati con ilcarattere corsivo. Fanno eccezione a questa norma, i nomi delle tecnologie.

3

Capitolo 2

Lo stage

In questo capitolo viene illustrato de�agliatamente il proge�o di stage, riportandone la pianifi-cazione iniziale, gli obie�ivi da raggiungere, i vincoli ai quali era so�oposto e le motivazionipersonali nella scelta. Viene inoltre riportata un’analisi preventiva dei possibili rischi e vieneesposto l’ambiente di lavoro.

2.1 Introduzione al progetto

Riprendendo il contesto de�nito nella sezione “1.3 - L’idea”, occorre de�nire in modo piùapprofondito e dettagliato la metodologia di sviluppo Devops[29]; abbiamo visto come talemetodologia di sviluppo si focalizza sul rapido rilascio dei prodotti software e su un automa-zione spinta dei processi ripetibili. In tutto questo non vi è più una divisione netta e separatatra sviluppatori e l’ambito operations ma viene instaurato un clima basato sulla collaborazionee sulla condivisione delle conoscenze.

Figura 2.1: Devops come punto d’unione tra sviluppo e operations, immagine tratta dahttps://intland.com/

I processi di tale metodologia consistono nel:

∗ Piani�care gli obiettivi da raggiungere e progettare le funzionalità da implementarenel prodotto software al �ne che esso consegua tali obiettivi (Plan);

∗ Implementare e�ettivamente tali funzionalità (Code);

∗ Costruire le componenti software e i relativi artefatti (Build);

∗ Assicurarsi che le componenti software costruite siano conformi alle attese e ai bisogni(Test)

∗ Rilasciare il prodotto (Release);

∗ Rendere disponibile il prodotto a determinati usi (Deploy);

5

2.1. INTRODUZIONE AL PROGETTO Lo stage

∗ Far si che il prodotto sia operativo, tramite opportune con�gurazioni (Operate);

∗ Monitorare le performance e lo stato del prodotto (Monitor).

Figura 2.2: I vari processi coinvolti all’interno della metodologia Devops, immagine tratta dahttps://www.01net.it/devops-monitoring/

Nel concreto, tali processi vengono svolti tramite una serie di attività e strumenti, tra cui:

∗ Sviluppo del codice tramite opportuni ambienti di sviluppo integrato (IntegratedDevelopment Environment (IDE)) e versionamento del codice che risiederà in unrepository;

∗ Strumenti di integrazione continua al �ne di automatizzare il processo di build e il loromonitoraggio;

∗ Attività continue e automatizzate di testing al �ne di veri�care le funzionalità delprodotto, e garantire che esso abbia le desiderate proprietà qualitative;

∗ Attività automatizzate di packaging, con un repository per gli artefatti;

∗ Attività di gestione dei cambiamenti, approvazione dei rilasci e automazione deglistessi;

∗ Strumenti di con�gurazione dell’infrastruttura, vista anch’essa come codice (Infrastruc-ture as Code)

∗ Strumenti e metriche di monitoraggio continuo della user experience e delle prestazionidel prodotto software.

Le s�de che tale metodologia si trova ad a�rontare sono molteplici, ad esempio:

∗ Di�coltà nel mantenere e rendere disponibile l’ambiente di produzione. A tal�ne, si fa ampio uso di tecnologie di virtualizzazione e containerizzazione in modo dasimulare gli ambienti, soprattutto durante le fasi di test dei prodotti;

∗ Gestione dell’infrastruttura di�cilmente automatizzabile. Opportuni strumentidi gestione della con�gurazione permettono di gestire in modo proattivo l’infrastruttura,vista come codice, tramite linguaggi di con�gurazione facilmente personalizzabili;

∗ Di�coltà nel diagnosticare mancanze e ricevere feedback sul prodotto. Graziea strumenti dedicati, è possibile un monitoraggio e�cace e continuo delle applicazioni.

Uno dei punti cardine è rappresentato dall’integrazione continua, cioè l’allineamento continuodegli ambienti di lavoro di più sviluppatori.Nello speci�co l’integrazione continua si basa su:

∗ Versionamento del codice;

6

Lo stage 2.1. INTRODUZIONE AL PROGETTO

∗ Automatizzazione delle build e dei test;

∗ Esecuzione dei test eseguiti in un clone dell’ambiente di produzione;

∗ Gestione e recupero degli artefatti;

∗ Automatizzazione dei rilasci.

Il continuous building, facilmente confondibile con l’attività di integrazione continua rappre-senta una parte cospicua ma non il tutto. Non si occupa ad esempio della con�gurazione deirepository per il versionamento del codice sorgente, ma assume che siano già presenti. Cosìcome non si occupa direttamente della gestione dell’infrastruttura cloud.

Figura 2.3: In rosso, la parte di continuous building, all’interno dell’integrazione continua, immaginetratta dahttps://opsani.com/

2.1.1 Motivazioni aziendaliIKS, con il progetto di stage proposto intende principalmente formare personale per l’attivitàdi consulenza al �ne di poter fornire ai propri clienti servizi in ambito Devops, data la richiestadi mercato sempre maggiore. L’azienda inoltre intendeva valutare l’uso di container al �ne diottimizzare l’uso delle risorse dei nodi �sici.

2.1.2 Motivazioni personaliLo stage curricolare rappresenta la tappa �nale del percorso di studi in Informatica pressol’Università degli Studi di Padova. Tale attività costituisce un’interessante opportunità permettere in contatto le realtà aziendali che necessitano di competenze speci�che, con studentiche si trovano ad approcciarsi al mondo del lavoro. A tal proposito ogni anno, tra marzo eaprile l’università, con il patrocinio di Con�ndustria Padova organizza un apposito eventodenominato STAGE-IT, per mettere in comunicazione aziende e studenti.

Durante STAGE-IT 2017 ho avuto modo di sostenere sedici colloqui preliminari con varieaziende; colloqui ai quali successivamente ne sono seguiti altri che mi hanno fornito unavisione più chiara dei progetti proposti al �ne di una scelta �nale. Tra le varie proposte, hostabilito dei criteri così riassunti: personali, professionali, economici e logistici.

2.1.2.1 Motivazioni personali

Le motivazioni personali rappresentano le tematiche di mio interesse, nello speci�co cercavouno stage con le seguenti caratteristiche:

∗ Forte orientamento all’open source. L’uso di tecnologie open source e softwarelibero è in costante crescita tra le aziende informatiche, inoltre avere a disposizione il

7

2.2. VINCOLI Lo stage

codice sorgente delle applicazioni che si andranno ad utilizzare permette da una partedi capire il loro funzionamento e dall’altra di potere adattarle secondo i propri bisogni.

∗ Ambito innovativo. Cercavo uno stage che mi permettesse di rapportarmi con i temicaldi attualmente presenti nel mercato dell’IT, quali ad esempio: machine-learning, IoT,Devops, blockchain o cloud.

∗ Ambito prevalentemente sistemistico. Il nostro corso di studi si focalizza princi-palmente nell’ambito sviluppo, l’ambito sistemistico rappresentava una s�da e un’op-portunità per integrare le mie conoscenze.

2.1.2.2 Motivazioni professionali

∗ Ambito innovativo. Oltre all’interesse personale, approcciare tecnologie innovativepenso permetta di avere più opportunità lavorative e di confrontarsi con s�de semprenuove.

2.1.2.3 Motivazioni economiche e logistiche

Alle motivazioni economiche e logistiche, ho preferito anteporre quelle personali e professio-nali.

∗ Luogo di lavoro. Sicuramente uno stage vicino casa sarebbe stato comodo ma nonmi avrebbe permesso di crescere. La zona industriale di Padova, parecchio lontanasia �sicamente che idealmente alla mia “comfort-zone” mi ha sicuramente aiutato inquesto.

∗ Logistica - Trasporti. Idealmente avrei voluto minimizzare il tempo di trasporto viag-giando in auto, ma questo non è stato possibile. Il dover coordinare diverse tipologie ditrasporto mi ha comunque permesso di migliorare le mie doti organizzative e gestionali.

∗ Rimborsi. Cercavo un’azienda che fornisse un minimo di rimborso spese. IKS inquesto senso ha messo a disposizione dei buoni pasto a parziale copertura delle spesedi ristorazione.

2.2 Vincoli

2.2.1 Vincoli metodologiciAll’inizio del progetto di stage è stato concordato con il tutor aziendale un piano di lavoro dimassima, comprendente la piani�cazione dello stage da svolgersi prevalentemente presso lasede dell’azienda ospitante in Corso Stati Uniti 14 bis a Padova.Regolarmente, (circa una volta la settimana) si sono tenuti incontri diretti con il tutor aziendaleper veri�care lo stato di avanzamento del progetto, ride�nire gli obiettivi, a�nare la ricerca eaggiornare il piano stesso di lavoro; il tutor aziendale ha inoltre richiesto un breve reportgiornaliero delle attività svolte da inviare via mail in modo da essere costantemente aggiornatosul procedere del lavoro e poter tempestivamente chiarire dubbi e fornire chiarimenti.

2.2.2 Vincoli temporaliLo stage curricolare, all’interno del corso di informatica si deve svolgere in un margine di orecompreso tra le 300 e le 320 ore presso l’azienda ospitante. Il progetto che ho svolto pressoIKS ha avuto una durata di 304 ore circa, più alcune ore dedicate da remoto per la stesura didocumentazione tecnica.

La piani�cazione iniziale è stata seguita in linea di massima, ma con l’emergere di altrepriorità come lo studio dei protocolli di comunicazione tra master e slave, inizialmente non

8

Lo stage 2.3. OBIETTIVI

previste dal piano di lavoro ha sottratto tempo ad altre attività come lo sviluppo di un pluginbase da usare come modello di sviluppo.

2.2.3 Vincoli tecnologiciGli unici vincoli tecnologici imposti dall’azienda circa la piattaforma di continuous buildingda implementare riguardavano il sistema operativo da utilizzare, Community enterprise Ope-rating System (CentOS) 7, Jenkins come fulcro centrale del progetto al �ne di automatizzare iprocessi di build e Docker come standard “de-facto” nelle tecnologie di containerizzazione.

2.3 Obiettivi

Vengono qui riportati gli obiettivi iniziali dello stage, in forma tabellare.Ogni obiettivo è descritto da tre attributi:

∗ ID. Un codice identi�cativo univoco, al �ne di tracciare l’obiettivo. Esso è determinatoda una lettera indicante la priorità (O, D o F) seguita da un numero progressivo a duecifre.

∗ Priorità. L’importanza attribuita all’obiettivo. Essa può essere:

– Obbligatorio. Obiettivi vincolanti in quanto esplicitamente indicati come primaridall’azienda proponente;

– Desiderabile. Obiettivi non vincolanti o strettamente necessari, ma dal ricono-scibile valore aggiunto;

– Facoltativo. Obiettivi rappresentanti valore aggiunto non strettamente competi-tivo, giudicati dall’azienda come opzionali.

∗ Descrizione. Una breve descrizione riepilogativa dell’obiettivo.

ID Priorità Descrizione

O01 Obbligatorio Progettazione dell’architettura di un sistema di continuousbuilding

O02 Obbligatorio Implementazione dell’architettura progettata su sistemi IKS

O03 Obbligatorio Stesura manuale di installazione

O04 Obbligatorio Utilizzo della piattaforma implementata per la produzione dicontainer Docker

O051 Obbligatorio Studio di fattibilità sulle modalità di comunicazione master e slave

D01 Desiderabile Containerizzazione della piattaforma implementata

D02 Desiderabile Relazione sui confronti prestazionali tra la piattaforma e la suacontroparte containerizzata

DO3 Desiderabile Individuazione metriche per il monitoraggio della piattaforma

DO4 Desiderabile Individuazione procedure per il monitoraggio, backup, ripristino eupgrade dell’infrastruttura

9

2.4. PIANIFICAZIONE Lo stage

ID Priorità Descrizione

DO5 Desiderabile Breve relazione che documenti metriche e procedure dei puntiDO3-4

F01 Facoltativo Implementazione di un plugin base per JenkinsTabella 2.1: Obiettivi dello stage

In sezione “7.1 - Raggiungimento degli obiettivi” viene fornito un riepilogo in forma tabellaredi tali obiettivi, indicando per ciascuno di essi il grado di soddisfacimento.

2.4 Piani�cazione

In tabella 2.2 viene riportata la piani�cazione delle attività, con la relativa suddivisione oraria.

Durata in ore Descrizione dell’a�ività

38 Formazione sulle tecnologie

38 De�nizione architettura di riferimento e relativa documentazio-ne

12 Analisi del problema e del dominio applicativo

22 Progettazione della piattaforma e relativi test

4 Stesura documentazione relativa ad analisi e progettazione

38 Implementazione di base

24 Implementazione architettura di base

10 Implementazione test funzionali

4 Stesura Manuale di installazione

38 Building di container

28 Implementazione delle funzionalità di containerizzazione

10 Testing delle funzionalità

38 Containerizzazione della piattaforma

25 Containerizzazione della piattaforma

10 Confronti prestazionali

3 Stesura documentazione relativa alle prestazioni

1Tale obiettivo è emerso in seguito, esso è qui riportato solo per completezza.

10

Lo stage 2.4. PIANIFICAZIONE

Durata in ore Descrizione dell’a�ività

38 Monitoraggio / Backup / Upgrade

9 Individuazione metriche per il monitoraggio

15 Sviluppo procedure e modalità per il recupero delle metriche

5 Individuazione procedure di backup e ripristino della piattaforma

5 Individuazione procedure di upgrade

4 Stesura documentazione relativa alle metriche e alle procedure indivi-duate

38 Sviluppo plugin sample per Jenkins

30 Implementazione plugin e relativi test funzionali

4 Testing del plugin sviluppato

4 Stesura documentazione relativa all’uso e manutenzione del plugin

38 Collaudo Finale

30 Collaudo della piattaforma

5 Stesura documentazione �nale

1 Incontro di presentazione della piattaforma con gli stakeholders

2 Live demo di tutto il lavoro di stage

Totale ore 304Tabella 2.2: Piani�cazione iniziale

11

2.5. AMBIENTE DI LAVORO Lo stage

2.5 Ambiente di Lavoro

2.5.1 Metodologia di sviluppo

IKS adotta la metodologia di sviluppo agile, tuttavia, per questo progetto dove la parte disviluppo è poco prevalente, si è scelto di adottare Component Based Software Engineering(CBSE), cioè un processo di sviluppo basato sul riuso di componenti software già esistenti esulla loro integrazione.Visto che le componenti software sono già esistenti, non è detto che esse rispecchino piena-mente le funzionalità necessarie al prodotto �nale; occorrerà quindi una loro attenta selezionein relazione ai requisiti del prodotto �nale e dei bisogni degli stakeholders, con i quali andràinstaurato uno stretto rapporto.

Figura 2.4: Rappresentazione della metodologia CBSE, immagine tratta da http://www.federica.unina.it/ingegneria/ingegneria-software-ii/component-based-software-engineering-sviluppo-cbse/

Il modello a componenti, favorisce la separazione delle responsabilità secondo il SingleResponsibility Principle e permette di ottenere un basso accoppiamento tra le componenti e ilsistema principale.Jenkins, con la sua architettura a plugin ben si presta ad una composizione gerarchica, doveil servizio principale invoca direttamente quelli esposti dai singoli plugin che ne estendono lefunzionalità.

2.5.2 Gestione di progetto

2.5.2.1 Versionamento

Inizialmente da quanto preventivato, per il versionamento del codice sorgente di alcune ap-plicazioni Maven d’esempio[21] non è stato possibile utilizzare git. L’azienda ha però fornitoun repository Concurrent Versions System (CVS)2 che è stato utilizzato principalmente perlo storage e il versionamento di applicazioni Maven e dei Docker�le creati.

CVS è un sistema di versionamento del codice piuttosto vetusto (non presenta nuove versionidal 2008) ma essendo uno tra i primi strumenti di versionamento, tra l’altro costituito dasoftware libero, è ancora parecchio usato.Non avendo mai approfondito in dettaglio tale strumento, mi sono avvalso di un client gra�co,smartCVS3.

2https://savannah.nongnu.org/project/memberlist.php?detailed=1&group=cvs

3https://www.syntevo.com/smartcvs/

12

Lo stage 2.6. ANALISI PREVENTIVA DEI RISCHI

2.5.3 DocumentazioneLa documentazione tecnica è stata redatta utilizzando Libreo�ce 5.4.2, lo strumento, puressendo open source non si è rivelato pienamente adatto allo scopo, in quanto non permetteuna standardizzazione della documentazione (anche se è possibile de�nire dei template) edella formattazione. LATEX probabilmente avrebbe rappresentato un’alternativa migliore, inquanto codice pienamente versionabile ma sarebbe di di�cile adozione all’interno di un team,in quanto tutti dovrebbero conoscere tale linguaggio.

2.5.4 Ambiente di sviluppoPer la piccola parte di sviluppo e personalizzazione di script Groovy si è utilizzato VisualStudio Code.Visual Studio Code4, è un editor open source sviluppato da Microsoft, basato su Electron,un framework javascript che permette lo sviluppo di applicazioni desktop. La caratteristicachiave di Visual Studio Code consiste in un’ampia gamma di plugin ed estensioni, che lorendono un editor versatile e facilmente adattabile a varie esigenze. Esso inoltre risultacon�gurabile in modo preciso e dettagliato tramite Javascript Object Notation (JSON).

Figura 2.5: Logo di Visual Studio code

2.5.5 Infrastruttura di testIKS ha messo a disposizione una macchina virtuale Linux la quale è stata utilizzata comepostazione di laboratorio al �ne di e�ettuare vari test funzionali e prove di con�gurazione.

2.6 Analisi preventiva dei rischi

In tabella “2.2 - Analisi dei rischi” viene riportata l’analisi dei rischi che ho dovuto a�rontarenel corso del progetto. Per ogni rischio viene de�nito:

∗ Un nome;

∗ Una breve descrizione;

∗ La modalità di rilevamento;

∗ La probabilità di occorrenza;

∗ Il grado di pericolosità;

∗ Il piano di contingenza.

4https://code.visualstudio.com/

13

2.6. ANALISI PREVENTIVA DEI RISCHI Lo stage

Nome Descrizione Rilevamento Rischio

Scarsaesperienza

L’ambito innovativo e la scarsaconoscenza pregressa potrebberocomportare ritardi nell’esecuzionedelle attività previste

Occorrerà comunicare altutor aziendale eventualidi�coltà

Occorrenza:Medio-alta

Pericolosità:Alta

Piano dicontingenza:

Occorre segnalare tempestivamente al tutor aziendale eventuali problematiche eapprofondire la formazione

Nome Descrizione Rilevamento Rischio

Disponibilitàtemporali

La disponibilità dei mezzi ditrasporto pubblici ed eventualiimprevisti possono causarel’impossibilità nell’essere in sede

Occorrerà comunicare altutor aziendale eventualiritardi

Occorrenza:Medio-bassa

Pericolosità:Medio-alta

Piano dicontingenza:

Verranno �ssate delle giornate di recupero, se il lavoro riguarda la documentazionepotrà essere svolto da remoto

Nome Descrizione Rilevamento Rischio

Tecnologieda usare

Il tempo di apprendimento per letecnologie potrebbe causareritardi nello svolgimento deilavori

Andranno evidenziateeventuali lacune al tutoraziendale

Occorrenza:Media

Pericolosità:Medio-alta

Piano dicontingenza: Andranno aumentate le ore disponibili in attività di formazione

Nome Descrizione Rilevamento Rischio

Problemihardware

Potrebbero veri�carsi guastihardware i quali comporterebberoperdite di dati e/o di tempo

Andrà segnalato al tutoraziendale ogni eventualemalfunzionamento oguasto

Occorrenza:Medio-bassa

Pericolosità:Bassa

Piano dicontingenza: Il team sistemistico di IKS provvederà al ripristino dell’infrastruttura

Nome Descrizione Rilevamento Rischio

Strumentisoftware

Il progetto prevedel’interoperabilità di componentisoftware che potrebbero rivelarsiincompatibili tra loro

Andrà speci�cata perogni componente laversione, facendoriferimento alladocumentazione u�ciale,se presente.

Occorrenza:Medio-alta

Pericolosità:Bassa

Piano dicontingenza: Andranno scelte componenti che siano compatibili, nel limite del possibile

Tabella 2.3: Tabella descrittiva dell’analisi dei rischi e attualizzazione

In tabella 7.3 è riportato un’attualizzazione dei rischi veri�catisi assieme alle misure adottateper la loro risoluzione.

14

Capitolo 3

Tecnologie adottate

In questo capitolo vengono esposte brevemente le tecnologie, gli strumenti e i linguaggi utilizzatidurante lo svolgimento dello stage. Per ognuno di essi, verrà fornita una panoramica di altolivello, che verrà eventualmente approfondita nei capitoli successivi.

3.1 Tecnologie software

3.1.1 CentOS 7

CentOS 7 1 è la distribuzione (GNU)/Linux di riferimento all’interno di IKS. CentOS è unadistribuzione di tipo aziendale, basata su Red Hat Enterprise Linux e si distingue da quest’ul-tima per la mancanza di supporto tecnico fornito da Red Hat e per il cambio di logo.CentOS fa dell’a�dabilità e della robustezza i suoi punti cardine, rendendola una delle miglioridistribuzioni GNU/Linux attualmente presenti sul mercato in ambito server.

Figura 3.1: Logo di CentOS 7

1https://www.centos.org/

15

3.1. TECNOLOGIE SOFTWARE Tecnologie adottate

3.1.2 Bash 4.4.5

The Burn-Again Shell (Bash) 2 è una shell, cioè un interprete a linea di comando frequente-mente presente all’interno di sistemi Linux. Essa fornisce un semplice linguaggio di scriptingnativo che tramite l’impostazione di variabili, comandi e strutture di controllo del �ussopermette di eseguire compiti complessi, favorendone l’automazione.

Figura 3.2: Logo Bash 4.4.5

3.1.3 JDK 8 update 151

Il Java Development Kit (JDK) è una raccolta di strumenti essenziali per la programmazionein linguaggio Java. Esso fornisce, tra le altre, una componente per la compilazione delcodice sorgente, un interprete per il bytecode generato dal compilatore, uno strumento per lagenerazione automatica di documentazione a partire da particolari commenti presenti nelcodice sorgente, un debugger e molto altro.

Figura 3.3: Logo JDK

3.1.4 Apache Tomcat 9.0.1

Apache Tomcat 3 è un Application Server una piattaforma software per l’esecuzione di appli-cazioni Web sviluppate in linguaggio Java[27]. Esso permette una facile gestione di applica-zioni web, consentendo di de�nire varie politiche di gestione degli utenti e una dettagliatacon�gurazione di porte e altre impostazioni di rete.

Figura 3.4: Logo Apache Tomcat 9.0.1

2https://www.gnu.org/software/bash/3https://tomcat.apache.org/

16

Tecnologie adottate 3.1. TECNOLOGIE SOFTWARE

3.1.5 Jenkins 2.73.3

Jenkins 4 è uno strumento di integrazione continua open source e rappresenta uno dei princi-pali strumenti di automazione di compiti. Esso permette agli utenti, tramite la de�nizionedi project (in passato de�niti jobs) di automatizzare una serie complessa di compiti, qualiad esempio la compilazione di una componente software a partire dal suo codice sorgente,l’esecuzione dei test e la visualizzazione dei loro risultati e il deploy dell’artefatto ottenutoverso un dei prodotti.

Jenkins è facilmente installabile e con�gurabile ed è funzionante “out of the box” senzaparticolari impostazioni; presenta un ricco ecosistema di plugin messi a disposizione dallacomunità ed è estensibile, tramite questi ultimi, qualora le funzionalità desiderate non fosserogià disponibili.

Jenkins si basa su un’architettura master - slave, dove un’istanza principale (il master) coordinai vari compiti tra uno o più slave, i quali rappresentano dei meri esecutori dei lavori a loroassegnati.

Figura 3.5: Logo Jenkins 2.73.3

3.1.6 Docker 17.10 Community Edition

Docker 5 è un progetto open source che consente la creazione, l’istanziazione e l’esecuzionedi processi isolati, de�niti container[28] in un sistema ospite.

L’idea alla base di Docker è la containerizzazione, una particolare forma di virtualizzazioneche basandosi sui cgroups, una funzionalità del kernel Linux che rappresenta dei gruppi dicontrollo in grado di o�rire applicazioni complete viste come risorse isolate, senza che sianecessario istanziare delle macchine virtuali pienamente operative.

Possiamo immaginare un container in ambito informatico, come la sua controparte legataai trasporti �sici di merci. In un container che siamo abituati a vedere trasportato da untreno o stivato in una nave, la merce viene racchiusa al suo interno e spedita in luoghispeci�ci. Il concetto si ritrova in campo informatico, dove in un container è possibile includereun’applicazione software con tutte le sue dipendenze e con le utilità necessarie al suo correttofunzionamento, in modo isolato dal resto del sistema.Questo permette di avere applicazioni portabili indipendentemente dal sistema operativo sulquale andranno in esecuzione, un uso e�ciente delle risorse di sistema, la scalabilità delleapplicazioni e la garanzia che ogni container sarà un processo isolato dagli altri container edal sistema ospite stesso, consentendo quindi ogni volta che viene mandato in esecuzioned’avere un ambiente “pulito”, con le caratteristiche desiderate.

4https://jenkins.io/5https://www.docker.com/

17

3.1. TECNOLOGIE SOFTWARE Tecnologie adottate

Figura 3.6: Logo Docker 17.10

3.1.7 Apache Maven 3.5.2

Apache Maven 6[26, Chapter 1] è uno strumento di automazione delle build[11], usatoprincipalmente per progetti Java. Grazie a Maven, è possibile gestire le dipendenze di undeterminato progetto e de�nirne particolari aspetti, quali ad esempio le politiche di deploy emolto altro.

Figura 3.7: Logo Apache Maven 3.5.2

Concetto fondamentale di Maven è il Project Object Model (POM)7[30, Chapter 9], un parti-colare �le di con�gurazione, basato su eXtensible Markup Language (XML) che descrive ilprogetto, con le sue dipendenze e la sua con�gurazione. Ogni progetto Maven dovrà esseredotato di almeno un POM[12], e rispettare la struttura in esso de�nita.

Figura 3.8: Struttura di un progetto Maven, così come de�nita da un generico POM, im-magine tratta da http://www.murraywilliams.com/2012/04/maven-and-jpa-programming/

6https://maven.apache.org/7https://maven.apache.org/pom.html

18

Tecnologie adottate 3.2. LINGUAGGI DI PROGRAMMAZIONE

3.1.8 cadvisor 0.28.2

cadvisor 8 è uno strumento sviluppato da Google per il monitoraggio e l’analisi in real-timedelle performance e del consumo di risorse di container.Fornisce inoltre supporto nativo ai container Docker.

Figura 3.9: Logo cadvisor 0.28.2

3.2 Linguaggi di Programmazione

3.2.1 JavaJava è un linguaggio orientato agli oggetti, fortemente tipizzato e focalizzato sull’esseremulti-piattaforma. Tale linguaggio grazie alla Java Virtual Machine (JVM) permette unanotevole portabilità del codice sorgente, che verrà compilato sotto forma di bytecode.

Java è inoltre il principale linguaggio col quale vengono sviluppati plugin per Jenkins[jenkins-cookbook],essendo esso stesso scritto prevalentemente in tale linguaggio.

Figura 3.10: Logo Java 8

8https://github.com/google/cadvisor

19

3.2. LINGUAGGI DI PROGRAMMAZIONE Tecnologie adottate

3.2.2 Groovy

Groovy 9 è un linguaggio per la piattaforma Java ma indipendente da esso, pur avendouna sintassi molto simile. È sviluppato dall’Apache Software Foundation con l’intento diessere facile da imparare, semplice da integrare con librerie e componenti scritte in Java, confunzionalità aggiuntive e un ricco ecosistema di framework a supporto. Può inoltre esserevisto come un linguaggio di scripting semplice e maneggevole per la scrittura di test concisi emanutenibili oltre che per l’automazione di vari compiti.

Figura 3.11: Logo Groovy

9http://groovy-lang.org/

20

Capitolo 4

Realizzazione del sistema

In questo capitolo vengono esposte le a�ività relative alla realizzazione del sistema; dalla fasedi analisi e proge�azione, all’e�e�iva implementazione. Viene inoltre riportato una sintesidello studio dei protocolli e dei metodi di comunicazione tra master e slave riferito ad ambienticontainerizzati.

4.1 Descrizione generale dell’architettura individuata

In questa sezione si intende analizzare i limiti dell’architettura attuale e si riportano breve-mente i vantaggi della soluzione implementata.

4.1.1 Limiti dell’architettura attualeTipicamente si ha un’istanza master di Jenkins ospitata su un server �sico o virtuale, la qualecoordina il lavoro e dirige lo svolgimento dello stesso, delegando più compiti a vari nodi slave.Ciascuno slave a sua volta, sarà ospitato da un host �sico o virtuale, il quale dovrà provvederele risorse adeguate in termini di memoria, capacità di elaborazione, disponibilità nell’ese-cuzione dei compiti eccetera. Tale architettura risulta essere poco �essibile e rappresentaun Single Point of Failure; qualora il nodo slave risulti o�ine o irraggiungibile per qualchemotivo, il nodo master non sarà in grado di mandare in esecuzione su di esso alcun project. Inodi slave inoltre andranno preparati in precedenza, con�gurando manualmente la macchinahost, installandovi eventuali dipendenze, quali ad esempio:

∗ Strumenti di automazione delle build come Maven, Gradle o Ant;

∗ Framework speci�ci per le applicazioni sviluppate;

∗ Utilità di compilazione e supporto allo sviluppo come il JDK.

È impensabile dover ripetere manualmente tali operazioni per ogni host; senza contare chepotrebbe essere necessario avere più utilità, anche in con�itto tra loro (come ad esempio di-verse versioni del JDK, al �ne di garantire la retro compatibilità delle applicazioni sviluppate).Tale architettura è di�cilmente manutenibile, troppo rigida e quasi impossibile da adattarealle esigenze; ne consegue che ogni nodo slave una volta con�gurato sarà adatto solo perdeterminati tipi di build.

L’architettura presenta inoltre un uso ine�ciente delle risorse. Se l’intera macchina è dedicataunivocamente a svolgere il ruolo di slave, si troverà ad eseguire i compiti assegnati dal masterper un certo tempo, ma la maggior parte lo trascorrerà in uno stato di inattività.

21

4.1. DESCRIZIONE GENERALE DELL’ARCHITETTURA INDIVIDUATARealizzazione del sistema

In �gura 4.1 è illustrata la con�gurazione iniziale che ho utilizzato presso IKS per l’attività diformazione e di sperimentazione. Tale infrastruttura rispecchia pienamente i limiti appenadescritti, in questo caso il ruolo di master viene assunto da un’istanza di Jenkins presentesu un portatile con Windows 10, mentre il ruolo di slave è ricoperto dalla macchina virtualeLinux remota; in questa con�gurazione, si sono ottenuti come artefatti, sia applicazionigenerate da progetti Maven (in formato “.war”) che immagini Docker. Per raggiungere talirisultati è stato necessario installare e con�gurare nello slave remoto sia Maven che Docker.

Figura 4.1: Visione d’alto livello dell’architettura iniziale

4.1.2 Vantaggi della soluzioneLe tecnologie di containerizzazione fornite da Docker sono risultate essere la scelta opportunaper sopperire i limiti dell’architettura esposti in sezione 4.1.1. I container possono essere messiin esecuzione con un solo comando da terminale e non necessitano di grosse con�gurazioni;forniscono inoltre ogni qualvolta vengano eseguiti, un’ambiente “nuovo” (non contaminatoda installazioni o con�gurazioni precedenti) e isolato dal resto del sistema ospite. Ecco quindiche un nodo host non dovrà più essere dedicato solamente al ruolo di slave, ma quando essoriceverà dei compiti da eseguire dal master potrà allocare uno o più container che svolgano illavoro e de-allocarli una volta che abbiano raggiunto lo scopo, dedicando nel tempo rimanenterisorse ad altre attività.

La �gura 4.2 rappresenta la situazione ideale, con un master centrale ospitato su una macchinadedicata, il quale coordina e dirige vari project su un numero imprecisato di slave allocatisu sua richiesta. Ogni nodo non assumerà più quindi il ruolo di slave ma piuttosto quello difornitore di slave, potendone allocare diversi secondo le risorse a sua disposizione. È stataimplementata, un’architettura ancor più evoluta, dove anche l’istanza master di Jenkins ècontenuta in un container; questo permettere, ad esempio, di poter utilizzare l’intero sistemasu una sola macchina, riducendo al minimo la con�gurazione e le attività di mantenimentodell’infrastruttura.

Figura 4.2: Rappresentazione di alto livello della soluzione individuata

22

Realizzazione del sistema 4.2. IMPLEMENTAZIONE

4.2 Implementazione

In un primo momento ho proceduto con la con�gurazione del sistema, come riportato in�gura 4.1, in modo da comprenderne il funzionamento e studiarne le peculiarità, questo miha permesso di ampliare notevolmente le mie conoscenze nell’ambito di amministrazione disistema utilizzando varie tecnologie proprie del mondo Linux, come ad esempio systemd.Parte consistente dell’implementazione del sistema è stata la progettazione e la costruzionedelle immagini dei container. Gli sviluppatori di Jenkins mettono già a disposizione delleimmagini sia per i master che per gli slave, tuttavia l’azienda ha preferito la creazione dazero in modo da avere delle immagini pienamente adatte alle proprie esigenze. In �gura4.3 è rappresentata la struttura gerarchica delle immagini, così come de�nite all’interno deiDocker�le[7].

Figura 4.3: Visione astratta della struttura del sistema

A partire dall’immagine pre-costruita di CentOS 7, ho de�nito una serie di Docker�le, arri-vando a de�nire tutta l’architettura del sistema. Nel listing 4.1 viene riportato il Docker�ledell’immagine di Java 8 update 151, seguito da un breve commento.

Listing 4.1: Esempio di Docker�le

1 FROM centos:723 MAINTAINER fedsib <fedsib@hotmail.it>45 # Prepare environment6 ENV JAVA_HOME /opt/jdk1.8.0_1517 ENV PATH $PATH:$JAVA_HOME/bin8 ENV JAVA_VERSION 8u1519 ENV JAVA_BUILD 8u151-b12

1011 # Instead of download binaries let’s copy them directly in /opt12 ADD jdk-${JAVA_VERSION}-linux-x64.tar.gz /opt1314 CMD ["echo", "Java up and running"] �

In riga 1 di Listing 4.1, con il comando “FROM”, verrà utilizzata l’immagine u�ciale di CentOS7 come base dalla quale derivare.In riga 3 con il comando “MAINTAINER” viene riportato il creatore dell’immagine ed un suocontatto.Nelle righe 6-9 tramite il comando “ENV” vengono de�nite delle variabili d’ambiente.In riga 12 l’archivio contenente i binari di installazione di Java viene decompresso nelladirectory /opt con il comando “ADD”.In�ne, con il comando “CMD” viene eseguito un comando echo di conferma che l’installazioneè andata a buon �ne. In questo Docker�le sono de�niti otto comandi, quindi l’immagine

23

4.2. IMPLEMENTAZIONE Realizzazione del sistema

risultante avrà otto strati.

Un’immagine consiste in un insieme di strati, ciascuno dei quali porta a delle modi�che del�lesystem del container che andrà in esecuzione, secondo determinati parametri. Le immaginipossono derivare gerarchicamente l’una dall’altra in un modo molto simile all’estensione diclassi in un linguaggio di programmazione orientato agli oggetti.

Per de�nire un’immagine, occorre riassumere l’insieme di comandi[4] in un Docker�le; sem-pli�cando, quando l’immagine verrà costruita con un comando di build, ogni comando delDocker�le diventerà uno strato dell’immagine andando ad aumentarne la dimensione; al �nedi ridurre tali dimensioni[5] esistono delle best practice per la stesura dei Docker�le[2].Durante lo stage è stata data particolare attenzione all’ottimizzazione delle immagini, inparticolare alla riduzione della loro dimensioni, per meglio comprendere quanto la dimensionepossa variare, viene riportato di seguito un confronto tra comandi simili, presi direttamentedal Docker�le dell’immagine di Apache Tomcat 9.0.1.

Listing 4.2: Esempio di comando RUN in un Docker�le

1 ENV CATALINA_HOME /opt/apache-tomcat-9.0.12 ENV TOMCAT_MAJOR 93 ENV TOMCAT_VERSION 9.0.145 RUN wget http://ftp.riken.jp/net/apache/tomcat/tomcat-${TOMCAT_MAJOR

}/v${TOMCAT_VERSION}/bin/apache-tomcat-${TOMCAT_VERSION}.tar.gz&& \

6 tar -xvf apache-tomcat-${TOMCAT_VERSION}.tar.gz && \7 rm apache-tomcat*.tar.gz && \8 mv apache-tomcat* ${CATALINA_HOME} �

Nelle righe 1-3 di Listing 4.2 vengono de�nite tramite il comando “ENV” 3 variabili d’ambientecon i rispettivi valori. Esse rappresentano, in ordine:

∗ il percorso d’installazione di Tomcat;

∗ la major version di Tomcat;

∗ la versione speci�ca di Tomcat.

Successivamente in riga 5 con il comando wget viene recuperato l’archivio d’installazionedi Tomcat dal sito u�ciale; tale archivio viene decompresso con il comando tar e succes-sivamente eliminato ed in�ne la directory con i �le estratti viene trasferita nel percorsod’installazione scelto. Si noti come le quattro operazioni siano incluse in un unico comando“RUN” invece che in quattro; questo serve a ridurre il numero di strati (e quindi la dimensione�nale) dell’immagine.

L’installazione può avvenire anche se disponiamo già dell’archivio senza doverlo scaricaredalla rete (questo può tornare utile in caso la connessione non sia disponibile), nel listing4.3 viene riportato lo stesso processo di installazione facendo uso del comando “COPY”; talecomando andrà a copiare l’archivio all’interno del container.

Listing 4.3: Esempio di installazione o�ine di Tomcat all’interno di un Docker�le

1 COPY apache-tomcat-${TOMCAT_VERSION}.tar.gz23 RUN tar -xvf apache-tomcat-${TOMCAT_VERSION}.tar.gz && \4 rm apache-tomcat*.tar.gz && \5 mv apache-tomcat* ${CATALINA_HOME} �

È possibile fare ancora meglio, utilizzando il comando “ADD”. Tale comando è in grado discompattare direttamente un’archivio “.tar” o “.tar.gz” in un percorso scelto, favorendo la

24

Realizzazione del sistema 4.2. IMPLEMENTAZIONE

leggibilità del Docker�le e minimizzando il numero di strati prodotti a uno. Un esempiod’uso di “ADD” è riportato nel listing 4.4, in una sola riga l’archivio viene decompresso nelladirectory /opt.

Listing 4.4: Uso del comando “ADD” in un Docker�le

1 ADD apache-tomcat-${TOMCAT_VERSION}.tar.gz /opt �Nella tabella 4.1 viene riportato un confronto tra le dimensioni delle varie immagini utilizzandoi diversi tipi di comandi. Il risparmio calcolato in termini di megabyte oscilla tra i 200 e i circa300 megabyte.

Nome dell’immagine MB usando RUN MB usando ADD

java8u151 771 581

tomcat9.0.1 807 608

jenkins-master 926 727

jenkins-ssh-slave 1260 955Tabella 4.1: Dimensioni delle immagini

Una volta create le immagini, ho proceduto alla con�gurazione dei container andando ade�nire un volume1 per poter gestire agevolmente la directory principale di Jenkins, in mododa sempli�care le operazioni legate all’esercibilità, come descritto nel quinto capitolo. Sonoinoltre stati de�niti e adattati degli script Groovy al �ne di automatizzare alcune operazionidi con�gurazione del Jenkins master; in�ne ho provveduto ad una selezione di plugin per lafornitura di container e monitoraggio.

4.2.1 Di�coltà riscontrate e punti di attenzioneLe principali di�coltà riscontrate riguardano:

∗ Documentazione obsoleta o sparsa. La documentazione di Jenkins per molti aspettiè letteralmente un “work in progress” e quindi per buona parte completamente man-cante od obsoleta. Essa non presenta una chiara strutturazione ma è sparsa in piùcollegamenti di di�cile reperimento;

∗ Non univocità nella con�gurazione di un proxy. Per accedere alla rete esterna,spesso è comune l’uso di un proxy in ambito aziendale. La sua con�gurazione è stataun aspetto non banale in quanto è possibile impostarlo in un’unica maniera ma vannoattuate circa sei / sette impostazioni distinte, a livello di sistema operativo, a livello diDocker, delle immagini, dei container;

∗ Con�itti di permessi[3]. Soprattutto nel caso dei backup dei volumi[23] si sono riscon-trati comportamenti curiosi e di�cilmente interpretabili con la gestione dei permessidei �le in Linux.

1https://docs.docker.com/engine/admin/volumes/volumes/

25

4.3. MODALITÀ DI COMUNICAZIONE MASTER/SLAVE Realizzazione del sistema

4.3 Modalità di comunicazione master/slave

Questa sezione riporta una sintesi dello studio di fattibilità inerente le modalità di comunica-zione tra l’istanza master di Jenkins e gli slave container che verranno allocati su richiestadel master[14]. Verranno introdotti brevemente i protocolli utilizzati illustrando il loro fun-zionamento contestualizzato nel dominio applicativo del progetto.

Yet Another Docker Plugin2, il plugin selezionato per la fornitura e la messa in esecuzionedegli slave container, supporta due modalità di comunicazione: Secure Shell (SSH) e JavaNetwork Launching Protocol (JNLP).

4.3.1 SSHIl protocollo SSH permette di stabilire connessioni di rete sicure, tramite uno scambio dichiavi cifrate tra un server e un client, come illustrato in �gura 4.4.

Figura 4.4: Esempio di creazione della connessione tramite SSH, immagine tratta dahttps://www.ssh.com/ssh/protocol/

Questo protocollo di rete è risultato essere la via preferibile e la più semplice per stabilireuna connessione sicura tra master e slave in quanto Jenkins contiene un’implementazionedel client SSH che può essere utilizzata per stabilire connessioni con gli slave in modo semiautomatico.Un generico slave container[8], dovrà contenere nella directory ~/.ssh/authorized_keys lachiave pubblica del master generata in precedenza; per agevolare tale processo l’immaginebase ssh da me de�nita va già a caricare nel container la chiave pubblica, impostando gliopportuni permessi di sicurezza. A questo punto basterà solamente con�gurare in Jenkinsle credenziali, impostando la chiave privata e lo Yet Another Docker Plugin svolgerà tutte leoperazioni in modo completamente automatizzato.

4.3.2 JNLP

“ The Java Network Launch Protocol (JNLP) enables an application to belaunched on a client desktop by using resources that are hosted on a remote webserver..Oracle about JNLP3 ”Il protocollo JNLP, tramite dei descrittori in XML speci�ca le risorse da recuperare e le

modalità di esecuzione di applicazioni Java Web Start (JWS), un particolare framework Javache permette agli utenti di avviare applicazioni dalla rete direttamente tramite un browser.JNLP permette di scaricare localmente tutte le risorse di un’applicazione in modo da eseguirlarapidamente, andando a veri�care periodicamente la presenza di aggiornamenti.Fino a luglio 2017, Yet Another Docker Plugin non forniva pieno supporto a tale protocollo.All’interno dell’architettura implementata JNLP si è rivelato particolarmente di�cile dacon�gurare, a causa dei limiti imposti dal proxy aziendale[10]; per sfruttare appieno questoprotocollo si deve infatti con�gurare opportunamente il proxy in più punti:

2https://plugins.jenkins.io/yet-another-docker-plugin

26

Realizzazione del sistema 4.3. MODALITÀ DI COMUNICAZIONE MASTER/SLAVE

∗ A livello di sistema operativo della macchina host;

∗ Nel demone Docker;

∗ All’interno del container master;

∗ All’interno del container slave;

∗ Nelle opzioni di Java, passate tramite comando tramite la variabile JAVA_OPTS;

∗ Nel �le settings.xml di Maven[22].

Tutte queste impostazioni sono di�cilmente automatizzabili soprattutto confrontandole conil protocollo SSH descritto in sezione 4.3.1.

Figura 4.5: Diagramma di sequenza della connessione via JNLP

In �gura 4.5, tramite un diagramma di sequenza UML viene rappresentata la procedura diconnessione tra master e slave. Il processo è completamente automatizzabile e a carico delYet Another Docker Plugin ma non è detto che questo vada a buon �ne, in quanto il downloaddei “.jar” potrebbe essere bloccato dal proxy, se presente.

27

Capitolo 5

Esercibilità

�esto capitolo ha lo scopo di approfondire gli aspe�i legati all’esercibilità della pia�aformaimplementata. Verranno quindi elencati i plugin scelti per Jenkins e le procedure di monitoraggio,upgrade, backup e ripristino individuate.[19]

5.1 Monitoraggio

Il monitoraggio[1, Chapter 1] costituisce un’attività essenziale nel valutare le performancedel sistema, prevenirne i guasti ed attuare tempestivamente le necessarie misure correttive.Nell’architettura individuata le macro aree da monitorare sono essenzialmente due: i contai-ner e il sistema containerizzato (Jenkins).Per i container in esecuzione è interessante conoscere le risorse utilizzate, quali ad esempio:la quantità di memoria, la percentuale di utilizzo del processore e l’uso della rete e comequesti parametri cambino in base alle attività del sistema containerizzato. Lo strumento cheho reputato più adatto a tale scopo è cadvisor di Google, il quale permette un monitorag-gio, tramite gra�ci e statistiche in real-time di tutti questi aspetti, purtroppo non gestiscedirettamente la persistenza dei log e dei dati raccolti, ma è integrabile con altri strumentidedicati1.

Figura 5.1: Uso della memoria da parte di un container Jenkins master, si noti il decadimento dovutoalla conclusione di un project

Per il monitoraggio di Jenkins esistono già svariate soluzioni tramite plugin o l’adozione distrumenti speci�ci, quali ad esempio Datadog2. Datadog sarebbe stata la mia prima scelta,

1Una panoramica di tali strumenti è reperibile nella documentazione del repository di cadvisor, al link: https://github.com/google/cadvisor/blob/master/docs/storage/README.md

2https://www.datadoghq.com/

29

5.2. BACKUP E RIPRISTINO Esercibilità

vista la completezza dei dati raccolti e l’agevole visualizzazione degli stessi in comode edettagliate dashboard, tuttavia è un software a pagamento (disponibile gratuitamente per unperiodo di prova di soli 14 giorni). Ho quindi ripiegato sulla selezione di plugin per Jenkins.

5.1.1 Scelta dei plugin per JenkinsDopo aver valutato diverse opzioni, la scelta è ricaduta su quattro plugin, nello speci�co:

∗ Metrics Plugin[15]. Espone varie Application Program Interface, tramite JSON inmodo da poterle poi riusare con altri sistemi. Particolarmente signi�cative sono lemetriche sullo stato dei plugin caricati, sul tempo impiegato dai project, sullo statodelle build e sul numero di build eseguite con successo o fallite per project;

∗ Monitoring Plugin[16].Permette di monitorare tramite JavaMelody3 vari aspetti diJenkins tra cui sicurezza, tempo di attività dei nodi, uso della rete e molto altro. Permetteinoltre di generare dei diagrammi inerenti il consumo di risorse (CPU, Memoria usata,tempo d’esecuzione delle build) visualizzandoli in delle dashboard. Tali diagrammi sonoesportabili in formato “.pdf ”;

∗ Disk Usage Plugin[13]. Crea dei diagrammi e dei report sull’uso della memoria dimassa da parte dei singoli project;

∗ Plugin Usage Plugin[18]. Mostra in una tabella l’utilizzo dei vari plugin di Jenkins,da parte dei vari project.

5.2 Backup e Ripristino

Le procedure di backup e ripristino individuate fanno ampio uso del comando docker cp[4].Tale comando permette di copiare �le da un container verso l’host che lo ospita e viceversa.L’uso dei seguenti comandi potrebbe essere integrato in uno script al �ne di automatizzarel’intera attività.

Listing 5.1: Sintassi del comando docker cp per la creazione di un backup

1 # Comando per il backup23 docker cp nome-container:${JENKINS_HOME} /

pathAssoluto_directory_di_salvataggio/jenkins �Nel listing 5.1 è evidenziata la sintassi del comando docker cp per copiare la directory princi-pale di Jenkins dal container in un determinato percorso del sistema ospite.

Nel listing 5.2 è invece riportato un esempio completo di backup, salvato in un archivio. Ilcomando “tar”, con le opzioni zcvf permette di:

∗ -z. Comprimere l’archivio usando gzip (solitamente incluso nelle distribuzioni Linux);

∗ -c. Creare l’archivio;

∗ -v. Mostrare a video i progressi (ed eventuali errori), durante la creazione dell’archivio;

∗ -f. De�nire il nome dell’archivio, in questo caso sarà jenkins-home-AAAAMMDD,dove AAAAMMDD è una nomenclatura rappresentante la data, secondo la seguenteconvenzione:

– AAAA: Quattro cifre per identi�care l’anno;3Libreria per il monitoraggio di applicazioni Java Enterprise Edition https://github.com/

javamelody/javamelody/

30

Esercibilità 5.2. BACKUP E RIPRISTINO

– MM: Due cifre per speci�care il mese;– GG: Due cifre per identi�care il giorno.

Listing 5.2: Esempio completo della creazione di un backup

1 # Esempio backup2 docker cp jenkins-master:/opt/datatools/jenkins/ /home/jenkins/

backup20171110/jenkins/34 # Esempio generazione archivio56 tar -zcvf jenkins-home-AAAAMMDD.tar.gz /

path_directory_di_salvataggio/jenkins &&7 sudo rm -rf /home/jenkins/backup20171110/jenkins/ �

Listing 5.3: Sintassi del comando docker cp per il ripristino

1 # Comando per il ripristino23 docker cp /pathAssoluto_del_backup_decompresso/jenkins/ nome-

container-4 master:/

path_alla_directory_padre_della_directory_principale_di_jenkins �Il procedimento di ripristino seguirà la strada inversa, riportando i dati dal sistema dov’è me-morizzato il backup verso il container, come evidenziato nel listing 5.3 e tramite un esempioconcreto nel listing 5.4 (ipotizzando che la directory principale di Jenkins sia localizzata nelpercorso /opt/datatools/jenkins).

Listing 5.4: Sintassi del comando docker cp per il ripristino

1 # Esempio di ripristino dei dati nel volume del container23 docker cp /home/jenkins/backup20171110/jenkins/ jenkins-master:/opt/

datatools �

31

5.3. UPGRADE Esercibilità

5.3 Upgrade

Jenkins ha due linee di sviluppo con distinte tempistiche di rilascio. La prima prevede dei ciclidi sviluppo con rilasci settimanali, orientati a fornire nuove funzionalità e bug�x rapidi inmodo da permettere alla comunità di essere sempre aggiornata con le ultime novità, mentre laseconda denominata Long Term Support (LTS) è orientata alla stabilità, con cicli di sviluppopiù lunghi e rilascio ogni 12 settimane ed è pensata soprattutto per l’ambito aziendale4.

Il team di sviluppo di Jenkins rilascia il prodotto in vari formati nativi per una variegatatipologia di distribuzioni Linux e per Windows; mette inoltre a disposizione delle immaginiper container già preconfezionate ed in�ne eroga il prodotto anche sotto forma di applicazioneweb, in formato “.war”.

In ambiente containerizzato, la procedura di aggiornamento di Jenkins utilizzando l’archivio“.war” e i volumi di Docker diventa immediata, in dettaglio, basterà associare la directoryprincipale di Jenkins, (da qui in avanti denominata JENKINS_HOME) ad un volume; succes-sivamente basterà sostituire il �le "jenkins.war" precedente, con la nuova versione, nelladirectory dov’è presente il Docker�le del master e ricostruire l’immagine del container.In seguito, avendo a disposizione un backup, si potrà procedere al ripristino dei dati nelvolume.L’aggiornamento dei plugin, avviene nello stesso modo.

4Il ciclo di sviluppo della versione LTS è riportato in dettaglio nel sito u�ciale di Jenkins https://jenkins.io/download/lts/

32

Capitolo 6

Veri�ca e validazione

In questo capitolo vengono riportati i test funzionali eseguiti durante i processi di Verifica eValidazione dell’archite�ura sviluppata.

6.1 Resoconto attività di Testing

In tabella 6.1 vengono riportati i test di veri�ca eseguiti; tali test costituiscono anche unasuite di collaudo del sistema.

Ciascun test è descritto da:

∗ ID. Un codice alfanumerico che identi�ca univocamente il test;

∗ Descrizione. Una breve descrizione del test;

∗ Comportamento atteso. Un breve testo che speci�ca i risultati attesi, in caso diriuscita del test.

∗ Stato. Lo stato d’esecuzione del test, esso può essere:

– Riuscito. Se il test ha avuto esito positivo;– Fallito. Se il test ha avuto esito negativo.

ID Descrizione Comportamento a�eso Stato

TF001 Visualizzazione della pagina prin-cipale di Jenkins

La pagina principale di Jenkinsviene visualizzata

Riuscito

TF002 Autenticazione con l’utente ad-min di default

L’utente admin riesce ad auten-ticarsi correttamente con le suecredenziali

Riuscito

TF003 Caricamento dei project Se il container viene rimosso ene viene creato uno nuovo, conla stessa con�gurazione i projectrimangono

Riuscito

TF004 Caricamento dei plugin Se il container viene rimosso ene viene creato uno nuovo, conla stessa con�gurazione i pluginrimangono

Riuscito

33

6.2. CONCLUSIONI Veri�ca e validazione

ID Descrizione Comportamento a�eso Stato

TF005 build di applicazioni web Ma-ven[30, Chapter 10]

L’applicazione di esempio generaun �le “.war”

Riuscito

TF006 build di immagini Docker L’immagine Docker viene costrui-ta correttamente ed è disponibilenell’host

Riuscito

TF007 Esecuzione di build distribuite[25,Chapter 11][14] con più host

Le build vengono eseguite cor-rettamente su entrambi i nodihost

Riuscito

TF008 Esecuzione di build su slave SSH Le build vengono eseguite cor-rettamente su uno slave SSHcontainer

Riuscito

TF009 Esecuzione di build su slave JNLP Le build vengono eseguite cor-rettamente su uno slave JNLPcontainer

Riuscito

TF010 Recupero degli artefatti daglislave

Gli artefatti vengono copiati cor-rettamente nel working space delnodo master

Riuscito

TF011 Recupero del codice sorgente daun repository CVS remoto

La build riesce a recuperare il co-dice sorgente dell’applicazione dacostruire da un repository CVSremoto

Riuscito

TF012 Aggiornamento dell’istanza ma-ster su container

L’aggiornamento dell’istanza ma-ster avviene correttamente

Riuscito

TF013 Backup dei dati di Jenkins dalvolume del container master

Viene generato un archivio conte-nente i dati della home directorydi Jenkins

Riuscito

TF014 Migrazione dei dati di Jenkins suun altro container

La home directory di Jenkinsviene trasferita su un nuovocontainer correttamente

Riuscito

Tabella 6.1: Test Funzionali

6.2 Conclusioni

Tutti i test preventivati hanno riportato esito positivo anche se si evidenziano di�coltà neitest TF009 e TF010. Tali di�coltà sono dovute principalmente a problemi col proxy aziendale.

34

Capitolo 7

Conclusioni

In questo capitolo vengono tra�e le considerazioni finali circa le conoscenze acquisite e glisviluppi futuri del proge�o, riportando inoltre una valutazione personale del periodo di stagein rapporto al percorso di studi. Vengono inoltre specificati gli obie�ivi raggiunti e i rischipresentatisi.

7.1 Raggiungimento degli obiettivi

Gli obiettivi esposti in sezione 2.3 e riassunti in tabella 2.1 non anno subito grosse variazionirispetto quanto inizialmente preventivato. L’obiettivo O05 relativo allo studio delle modalitàdi comunicazione tra master e slave, all’inizio del progetto non era presente e con la suaintroduzione si è dovuto ridimensionare l’obiettivo facoltativo F01 sullo sviluppo d’un pluginbase. Tale obiettivo facoltativo è stato parzialmente raggiunto anche se non soddisfa piena-mente le aspettative aziendali. Non è stato raggiunto l’obiettivo desiderabile D02 relativo allastesura di una relazione sui confronti prestazionali tra la piattaforma containerizzata e non,in quanto di�cilmente analizzabile in sole otto settimane di stage. Le prestazioni del sistemadipendono da molti parametri (quali ad esempio i limiti imposti ai container e le risorse adisposizione dell’host).Sono stati raggiunti tutti gli obiettivi obbligatori e la quasi totalità di quelli desiderabili. Intabella 7.1 vengono riassunti gli obiettivi, riportando per ciascuno lo stato di avanzamento, ilquale può essere:

∗ Raggiunto. Se l’obiettivo soddisfa pienamente le aspettative aziendali;

∗ Parzialmente Raggiunto. Se l’obiettivo è stato raggiunto ma non è pienamenteconforme alle attese;

∗ Non Raggiunto. Se l’obiettivo non ha prodotto i risultati sperati.

35

7.1. RAGGIUNGIMENTO DEGLI OBIETTIVI Conclusioni

ID Priorità Descrizione Stato

O01 Obbligatorio Progettazione dell’architettura di unsistema di continuous building

Raggiunto

O02 Obbligatorio Implementazione dell’architettura pro-gettata su sistemi IKS

Raggiunto

O03 Obbligatorio Stesura manuale di installazione Raggiunto

O04 Obbligatorio Utilizzo della piattaforma implemen-tata per la produzione di containerDocker

Raggiunto

O05 Obbligatorio Studio di fattibilità sulle modalità dicomunicazione master e slave

Raggiunto

D01 Desiderabile Containerizzazione della piattaformaimplementata

Raggiunto

D02 Desiderabile Relazione sui confronti prestazionalitra la piattaforma e la sua contropartecontainerizzata

Non Raggiunto

DO3 Desiderabile Individuazione metriche per il monito-raggio della piattaforma

Raggiunto

DO4 Desiderabile Individuazione procedure per il moni-toraggio, backup, ripristino e upgradedell’infrastruttura

Raggiunto

DO5 Desiderabile Breve relazione che documenti metri-che e procedure dei punti DO3-4

Raggiunto

F01 Facoltativo Implementazione di un plugin base perJenkins

Parzialmente Raggiunto

Tabella 7.1: Obiettivi Raggiunti

In�ne, in tabella 7.2 viene sintetizzata la percentuale di raggiungimento degli obiettivi in basealla priorità associata, sul totale.

Priorità Percentuale di raggiungimento

Obbligatori 100 %

Desiderabili 80 %

Facoltativi ~100 %Tabella 7.2: Obiettivi Raggiunti

36

Conclusioni 7.2. RESOCONTO DELL’ANALISI DEI RISCHI

7.2 Resoconto dell’analisi dei rischi

In questa sezione si elencano in forma tabellare i rischi precedentemente illustrati in “2.2 -Analisi dei rischi” e veri�catisi durante lo svolgimento del progetto. Vengono inoltre riportatele misure adottate per la loro risoluzione.

Rischio Verificato A�ualizzazione Misure ado�ate

Scarsa esperienza NO L’attività di formazioneè stata su�ciente

Nessuna

Disponibilità temporali SI A causa di esami uni-versitari e piccoli im-previsti alcuni giorninon si è riusciti adessere in sede.

Il tempo non in sede,non ha intaccato il li-mite minimo impostodai vincoli universitariper lo stage curricolare,le attività sono state re-cuperate lavorando sul-la documentazione inremoto.

Tecnologie utilizzate NO Le tecnologie da uti-lizzare non si sono ri-velate particolarmentecomplesse

Nessuna

Problemi hardware SI Si è avuta una tempo-ranea mancanza di con-nessione, il problemanon ha avuto ripercus-sioni signi�cative

Durante la mancanzadi collegamento alla re-te esterna ho lavoratoo�ine sulla documen-tazione

Strumenti software NO Le componenti non sisono rivelate incompa-tibili tra loro ma la scar-sità di documentazio-ne e la cattiva orga-nizzazione della stessahanno comportato lieviritardi.

Oltre alla documenta-zione u�ciale, ho con-sultato blog specializza-ti e testi �sici.

Tabella 7.3: Resoconto dell’analisi dei rischi

37

7.3. POSSIBILI SVILUPPI FUTURI Conclusioni

7.3 Possibili Sviluppi futuri

In questa sezione vengono evidenziati alcuni possibili sviluppi futuri del sistema implementa-to.

7.3.1 MonitoraggioCome visto in sezione 5.1, cadvisor non permette nativamente la persistenza dei dati raccolti;inoltre sono presenti altri �le di log (per esempio i log delle build e i log degli slave container)che sono sparsi e di di�cile lettura.Sarebbe interessante valutare un’integrazione con l’infrastruttura ELK (elasticsearch, Logstashe Kibana) già presente in azienda, soprattutto considerato che cadvisor è integrabile conquesto stack tecnologico.

Figura 7.1: Loghi dello stack ELK

7.3.2 Repository prodottiScopo dello stage era l’implementazione di tutto il sistema di continuous building ma non èmai stato fatto un vero uso degli artefatti prodotti. Un possibile sviluppo sarebbe integrare lasoluzione da me sviluppata con un repository prodotti come Nexus Repository Manager1, giàutilizzato con pro�tto dall’azienda.

Anche per le immagini Docker sarebbe utile approfondire l’integrazione del sistema con unregistry pubblico o privato, cioè con un repository appositamente pensato per la memorizza-zione, la gestione e la distribuzione di immagini Docker.

7.4 Conoscenze acquisite

L’attività di stage mi ha permesso di apprendere nuove tecnologie e rapportarmi con aspettidiversi da quelli a�rontati durante gli anni di studio, soprattutto ho avuto modo di seguire unprogetto dalle sue fasi iniziali a quelle �nali in una realtà aziendale. Nello speci�co, duranteil periodo di stage:

∗ Ho approfondito le mie conoscenze del sistema operativo Linux, della sua strutturae delle sue logiche di funzionamento; soprattutto nella gestione di utenti, gruppi erelativi permessi. Ho compreso come con�gurare servizi tramite systemd in mododa eseguirli, fermarli, abilitarli in automatico con l’avvio del sistema ed in�ne hosviluppato conoscenze sulle architetture distribuite e containerizzate in una rete[6];

∗ Ho ottenuto competenze nelle tecnologie di containerizzazione, in particolare nel crearee gestire immagini Docker, nel con�gurare container e nel redigere i Docker�le;

∗ Ho avuto modo di rapportarmi con metodologie di sviluppo mai a�rontate e da mepoco conosciute;

1https://www.sonatype.com/nexus-repository-sonatype

38

Conclusioni 7.5. VALUTAZIONE PERSONALE

∗ Ho approfondito gli aspetti dell’integrazione continua e dell’automazione di compitiripetibili.

∗ Ho migliorato le mie capacità di problem solving adattando tecnologie open source aibisogni dell’azienda.

7.5 Valutazione personale

Nel complesso, seppur con le molte di�coltà a�rontate a livello logistico e le tempistichemolto ristrette valuto positivamente l’esperienza di stage.Le mie motivazioni personali sono state pienamente soddisfatte e anche se all’inizio avevoconoscenze quasi nulle del dominio applicativo e delle tecnologie da utilizzare, gli insegna-menti forniti e l’ampio bagaglio teorico e metodologico fornito dal corso di studi mi hannopermesso di riuscire comunque a raggiungere gli obiettivi pre�ssati.Dal punto di vista professionale, non è ben chiaro se vi sia possibilità di proseguire conil progetto o in questo ambito lavorativo all’interno dell’azienda ospitante, comunque ilbagaglio di conoscenze acquisite e l’esperienza maturata saranno sicuramente utili anche inaltri contesti lavorativi.

39

Glossario

agile Insieme di metodi di sviluppo del software emersi a partire dai primi anni 2000, fondatisu un insieme di principi comuni, direttamente o indirettamente derivati dai princìpidel Manifesto per lo sviluppo agile del software[20]. 2, 12

API in informatica con il termine Application Programming Interface API (ing. interfaccia diprogrammazione di un’applicazione) si indica ogni insieme di procedure disponibilial programmatore, di solito raggruppate a formare un set di strumenti speci�ci perl’espletamento di un determinato compito all’interno di un certo programma. La �nalitàè ottenere un’astrazione, di solito tra l’hardware e il programmatore o tra software abasso e quello ad alto livello sempli�cando così il lavoro di programmazione. 30

application-server Tipologia di server che fornisce l’infrastruttura e le funzionalità disupporto, sviluppo ed esecuzione di applicazioni nonché altri componenti server in uncontesto distribuito. 16

artefatto Un prodotto immutabile, generato durante una build che verrà opportunamentearchiviato in un repository e reso disponibile a determinati utenti per usi speci�ci (es.rilascio, testing). III, 17

blockchain Base di dati distribuita, introdotta dalla valuta Bitcoin che mantiene in modocontinuo una lista crescente di record, i quali fanno riferimento a record precedentipresenti nella lista stessa in modo da resistere a manomissioni. 8

build La costruzione, osservabile e tangibile di una componente software a partire dal suocodice sorgente.Risultato della singola esecuzione di un project, in Jenkins. 2, 6, 9, 18, 21, 30, 34, 38

bytecode Linguaggio intermedio tra il codice sorgente e il linguaggio macchina. 16, 19

cloud Abbreviazione di cloud computing. Paradigma informatico per l’utilizzo di risorsehardware o software in remoto, tramite la disponibilità on demand di risorse preesistentie con�gurabili.. 2, 7, 8

container Processo isolato dal resto del sistema che rappresenta l’istanza in esecuzione diuna data immagine, secondo opportune con�gurazioni aggiuntive. 7, 9, 17, 19, 22–27,29–32, 34–36

continuous building In ingegneria del software per continuous building, (spesso identi�ca-ta come “Build automation”) si intende il processo di automazione dell’intero ciclo dibuild a partire dalla compilazione del codice sorgente, al garantire che i risultati sianosempre ripetibili e conformi alle attese, all’esecuzione dei test e al rendere disponibilegli artefatti risultanti. Tale processo è una parte consistente dell’integrazione continua.III, IX, 2, 7, 9, 35, 38

debugger Strumento per agevolare l’individuazione e permettere un’agevole rimozione dierrori software, comunemente chiamati bug. 16

41

Glossario Glossario

demone Programma o servizio in esecuzione in modalità non interattiva con l’utente. 27

deploy L’insieme delle attività che permettono ad una componente software di esseredisponibile ad un determinato uso. III, 17, 18

host Nodo connesso alla rete, il quale ospita un’applicazione fornendone le risorse necessariealla sua esecuzione. 21, 22, 27, 30, 34, 35

immagini Base fondante e immutabile utilizzata per la costruzione di container . 24, 32

integrazione-continua Insieme delle attività che permettono un allineamento frequentedegli ambienti di lavoro di più sviluppatori. 6, 7, 17

jar Archivio dati compresso usato per distribuire raccolte di classi Java.. 27

Java EE Insieme di speci�che le cui implementazioni vengono sviluppate in linguaggio diprogrammazione Java con ampio utilizzo nella programmazione Web. 1, 30

JNLP Protocollo, de�nito da uno schema XML, che speci�ca la modalità con cui lanciare leapplicazioni Java Web Start. 34

Linux Famiglia di sistemi operativi di tipo Unix-like, pubblicati sotto varie possibili distri-buzioni, aventi la caratteristica comune di utilizzare come nucleo il kernel Linux. 13,15–17, 22, 23, 25, 30, 32, 38

machine-learning Campo dell’informatica che fornisce alle macchine l’abilità di imparare,nello svolgere determinati compiti, senza essere programmate esplicitamente. 2, 8

master L’unità centrale di coordinazione dei processi che possiede la con�gurazione, caricai plugin e gestisce tutti gli aspetti di esecuzione dei vari projects. IX, 8, 9, 17, 21–23, 25,26, 29, 32, 34, 35

middleware Insieme di programmi informatici che fungono da intermediari tra diverseapplicazioni e componenti software. 1

plugin Componente software che fornisce funzionalità aggiuntive ad estensione di undeterminato prodotto software preesistente ma separatamente da esso. III, 9, 12, 13, 17,19, 25, 26, 29, 30, 32, 33, 35

project Una con�gurazione de�nita da un utente, che descrive un lavoro che Jenkins dovràsvolgere, come ad esempio costruire una componente software, eseguire uno script,ecc... A volte riferito come job. 17, 21, 22, 29, 30, 33

Red Hat Società multinazionale statunitense che si dedica allo sviluppo software e al sup-porto di software libero e open source in ambiente aziendale. 15

repository Base di dati centralizzata nella quale risiedono, individualmente, tutti i Con�gu-ration Item (CI) di ogni baseline nella loro storia completa. 6, 7, 12, 34, 38

srp Principio della programmazione orientata agli oggetti, il quale a�erma che ogni compo-nente deve avere una e una sola responsabilità, cioè causa di cambiamento, in modo dagarantire la coesione. 12

slave Letteralmente, schiavo. In Jenkins rappresenta un nodo sul quale vengono eseguitipiù compiti, de�niti sotto forma di project, secondo la direzione di un master. A voltede�nito come Agent. 8, 9, 17, 21–23, 26, 34, 35, 38

42

Glossario Glossario

SSH Protocollo che permette di stabilire una sessione remota cifrata tramite interfaccia ariga di comando con un altro host di una rete. 34

stakeholders Letteralmente, “portatore di interesse". Insieme delle persone che a variotitolo sono coinvolte nel ciclo di vita del software avendo in�uenza sul prodotto o sulprocesso; fanno parte di questa categoria fornitori, committenti e clienti. 12

system integration Processo che consiste nel collegare assieme di�erenti sistemi e appli-cazioni software, a livello �sico o funzionale in modo che agiscano come un insiemecoordinato e coeso. 1

systemd Suite di utilità di amministrazione progettate con lo scopo di centralizzare lagestione e la con�gurazione dei sistemi operativi Unix-like.. 23, 38

UML In ingegneria del software UML, Uni�ed Modeling Language (ing. linguaggio di mo-dellazione uni�cato) è un linguaggio di modellazione e speci�ca basato sul paradigmaobject-oriented. L’UML svolge un’importantissima funzione di “lingua franca” nellacomunità della progettazione e programmazione a oggetti. Gran parte della letteraturadi settore usa tale linguaggio per descrivere soluzioni analitiche e progettuali in modosintetico e comprensibile a un vasto pubblico. 27

war Formato di archiviazione che raggruppa tutti i �le facenti parte di un’applicazione webin Java. 22, 32, 34

43

Acronimi

Bash The Burn-Again Shell. 16

CBSE Component Based Software Engineering. 12

CentOS Community enterprise Operating System. 9, 15, 23

CVS Concurrent Versions System. 12, 34

GNU GNU is Not Unix. 15

IDE Integrated Development Environment. 6

IoT Internet of Things. 2, 8

JDK Java Development Kit. 16, 21

JNLP Java Network Launching Protocol. 26

JSON Javascript Object Notation. 13, 30

JVM Java Virtual Machine. 19

JWS Java Web Start. 26

LTS Long Term Support. 32

POM Project Object Model. 18

SSH Secure Shell. 26, 27

XML eXtensible Markup Language. 18, 26

45

Bibliogra�a

Riferimenti bibliogra�ci

[1] Alan Mark Berg. Jenkins Continuous Integration Cookbook. Packt Publishing, Ltd., 2008(cit. a p. 29).

[25] John Ferguson Smart. Jenkins The De�nitive Guide. O’Reilly Media, Inc., 2011 (cit. ap. 34).

[26] Srirangan. Apache Maven 3 Cookbook. Packt Publishing, Ltd., 2011 (cit. a p. 18).

[30] J. Casey B. Snyder T. O’Brien E. Redmond J. van Zyl B. Fox. Maven: The De�nitiveGuide. O’Reilly Media, Inc., 2008 (cit. alle pp. 18, 34).

Siti web consultati

[2] Best Practice For Writing Docker�le. url: https : / / docs . docker . com /engine/userguide/eng-image/dockerfile_best-practices/(cit. a p. 24).

[3] Marc Campbell. Understanding permissions in Docker containers - Medium.com. url:https://www.cloudbees.com/blog/what-devops (cit. a p. 25).

[4] Docker Commands.url:https://docs.docker.com/engine/reference/commandline/docker/ (cit. alle pp. 24, 30).

[5] Docker Development Best Practice.url:https://docs.docker.com/develop/dev-best-practices/ (cit. a p. 24).

[6] Docker Networking.url:https://docs.docker.com/engine/userguide/networking/ (cit. a p. 38).

[7] Docker�le Reference.url:https://docs.docker.com/engine/reference/builder/ (cit. a p. 23).

[8] Dockerize a SSH service. url: https : / / docs . docker . com / engine /examples/running_ssh_service/ (cit. a p. 26).

[9] Extend Jenkins. url: https://wiki.jenkins.io/display/JENKINS/Extend+Jenkins (cit. a p. III).

[10] How to troubleshoot JNLP slaves connection issues with Jenkins? url: https://support.cloudbees.com/hc/en-us/articles/218097237 (cit. ap. 26).

[11] Introduction To The Build Lifecycle. url: https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html(cit. a p. 18).

47

SITI WEB CONSULTATI Bibliogra�a

[12] Introduction To The POM. url: https://maven.apache.org/guides/introduction/introduction-to-the-pom.html (cit. a p. 18).

[13] Jenkins Disk Usage Plugin. url: https://plugins.jenkins.io/disk-usage (cit. a p. 30).

[14] Jenkins Distributed Builds. url: https://wiki.jenkins.io/display/JENKINS/Distributed+builds (cit. alle pp. 26, 34).

[15] Jenkins Metrics Plugin. url: https : / / wiki . jenkins . io / display /JENKINS/Metrics+Plugin (cit. a p. 30).

[16] Jenkins Monitoring Plugin. url: https://wiki.jenkins.io/display/JENKINS/Monitoring (cit. a p. 30).

[17] Jenkins Plugin Getting Started. url: https://wiki.jenkins.io/display/JENKINS/Plugin+tutorial (cit. a p. III).

[18] Jenkins Plugin Usage Plugin. url: https://wiki.jenkins.io/pages/viewpage.action?pageId=73532011 (cit. a p. 30).

[19] Jenkins System Administration. url: https://jenkins.io/doc/book/system-administration/ (cit. a p. 29).

[20] Manifesto Agile. url: http://agilemanifesto.org/iso/it/ (cit. a p. 41).

[21] Maven Getting Started Guide. url: https://maven.apache.org/guides/getting-started/index.html (cit. a p. 12).

[22] Maven Settings Reference. url: https://maven.apache.org/settings.html (cit. a p. 27).

[23] Adrian Mouat. Understanding Docker Volumes - Container Solutions. url: https://www.cloudbees.com/blog/what-devops (cit. a p. 25).

[24] Plugin Structure. url: https://wiki.jenkins.io/display/JENKINS/Plugin+Structure (cit. a p. III).

[27] Tomcat - A Minimalistic User’s Guide. url: https://tomcat.apache.org/tomcat-3.2-doc/uguide/tomcat_ug.html (cit. a p. 16).

[28] What is a Container? url: https://www.docker.com/what-container(cit. a p. 17).

[29] What is Devops? url: https://www.cloudbees.com/blog/what-devops (cit. a p. 5).

48