Studio e analisi di strumenti di gestione automatica di ... · Scuola Politecnica e delle Scienze...
43
Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Sistemi Operativi Studio e analisi di strumenti di gestione automatica di infrastrutture IT (Chef, Ansible, Puppet ) Anno Accademico 2013/2014 Candidato: Antonio Barbato matr. N46000464
Transcript of Studio e analisi di strumenti di gestione automatica di ... · Scuola Politecnica e delle Scienze...
Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Sistemi Operativi
Studio e analisi di strumenti di gestione automatica di infrastrutture IT (Chef, Ansible, Puppet ) Anno Accademico 2013/2014 Candidato: Antonio Barbato matr. N46000464
Indice Indice .................................................................................................................................................. III Introduzione ......................................................................................................................................... 5 Capitolo 1: WebScaleIT ....................................................................................................................... 7
1.1 Automation ................................................................................................................................ 9 ITIL .................................................................................................................................................... 12 Capitolo 2: Configuration Management (CM)................................................................................... 13
2.1 Change Management................................................................................................................ 14 2.2 Release Management ............................................................................................................... 15
Capitolo 3: Deployment e Provisioning ............................................................................................. 16 3.1 Bare Metal Provisioning .......................................................................................................... 17
Capitolo 4: Continuous Delivery ....................................................................................................... 19 4.1 DevOps..................................................................................................................................... 20
Capitolo 5: Puppet .............................................................................................................................. 22 5.1 Componenti .............................................................................................................................. 23
5.1.1 Puppet Agent ..................................................................................................................... 23 5.1.2 Puppet Master ................................................................................................................... 23 5.1.3 PuppetDB .......................................................................................................................... 24 5.1.4 PE Console ........................................................................................................................ 24 5.1.4.1 Role-based Access Control (RBAC) ............................................................................... 24 5.1.4.3 Live Management ........................................................................................................... 24
5.2 Configuration Management ..................................................................................................... 24 5.2.1 Modules and Manifests ..................................................................................................... 25 5.2.2 Catalog .............................................................................................................................. 25 5.2.3 Resources .......................................................................................................................... 26 5.2.5 Assegnare dati di configurazione ...................................................................................... 27 5.2.6 Attivare il processo di configurazione .............................................................................. 27
5.3 Monitoraggio ............................................................................................................................ 28 5.4 Orchestration ............................................................................................................................ 28
5.4.1 Components ...................................................................................................................... 28 5.4.2 Actions and Plugins .......................................................................................................... 28
5.5 Deployment .............................................................................................................................. 29 Capitolo 6: Chef ................................................................................................................................. 30
6.1 Componenti .............................................................................................................................. 31 6.1.1 Workstation ....................................................................................................................... 31 6.1.2 Chef Server ....................................................................................................................... 31 6.1.3 Client Chef ........................................................................................................................ 32 6.1.4 Chef Analytic .................................................................................................................... 32 6.1.5 Chef DK ............................................................................................................................ 32
6.2 Resource e Recipe .................................................................................................................... 33
6.3 Configuration Management ..................................................................................................... 33 6.4 Cloud Management .................................................................................................................. 34
Capitolo 7: Ansible ............................................................................................................................ 36 7.1 Agentless .................................................................................................................................. 36 7.2 Playbooks ................................................................................................................................. 36
7.2.1 Task list ............................................................................................................................. 37 7.3 Moduli ...................................................................................................................................... 38 7.4 Inventory .................................................................................................................................. 38 7.5 Pattern ...................................................................................................................................... 39
Conclusioni ........................................................................................................................................ 40 Bibliografia ........................................................................................................................................ 42
5
Introduzione "Con il termine Infrastructure IT ci si riferisci all’insieme delle risorse hardware, software
, di rete e i servizi necessari per l’esistenza,il funzionamento e la gestione degli ambienti
IT aziendali . Essa permette ad un’organizzazione di distribuire servizi e soluzioni IT ai
suoi dipendenti , partners e/o ai consumatori essa è solitamente interna all’organizzazione
e distribuita all’interno di strutture di proprietà [...] " (1) , tuttavia è possibile che
un'infrastruttura IT sia a disposizione di più aziende.
L'unità organizzativa che si occupa della gestione e del coordinamento prende il nome di
Data Center o CED (Centro di Elaborazione Dati) , il numero di persone e di attività che si
svolgono sono davvero molte , basti pensare che all’interno possono esserci delle vere e
proprie Server Farm (2).
Tipicamente sono presenti diverse figure professionali dallo studente tirocinante ,
passando per gli sviluppatori fino ad arrivare a sistemisti , tecnici specializzati e
amministratori.
La gestione e il coordinamento di tutte le parti che compongono tale struttura risulta ardua
e onerosa . Una cattiva amministrazione può portare a delle conseguenze sicuramente non
piacevoli . Tipicamente è l’amministratore di sistema che si occupa dell’infrastruttura .I
suoi obiettivi sono quelli di utilizzare le risorse in maniera efficiente cioè cercare di
ottenere alta qualità, nel minor tempo possibile , con il minor spreco di risorse , nel
rispetto delle politiche aziendali e rientrando nei limiti imposti dal budget .
Per tenere elevate prestazioni e qualità spesso è necessario aggiornare le tecnologie
utilizzate sia in termini hardware che software e quindi un buon amministratore di sistema
dovrebbe tenere sempre in considerazione eventuali soluzioni innovative .
Google, Amazon, Rackspace , Netflix e Facebook (3) i così detti Web Innovator , sono
riusciti negli ultimi anni ad ottenere un elevato successo cambiando radicalmente i modelli
di consumo e le aspettative . Oggi i consumatori sono abituati a beni e servizi disponibili
online in qualsiasi momento, in qualsiasi luogo e da qualsiasi tipo di dispositivo , oltre alle
6
aspettative di elevata velocità e affidabilità . Ogni azienda che ha una "digital presence" e
che vuole rimanere competitiva rischia l'obsolescenza se non si adatta alle odierne
richieste di mercato ed è quindi in alcuni casi costretta a trasformare il proprio modo di
fare business.
7
Capitolo 1: WebScaleIT Le metodologie e i criteri innovativi applicati dai Web Innovator per raggiungere un così
elevato livello di qualità e prestazione sono racchiusi all'interamente del concetto di
WebScaleIT .
Questo termine è stato introdotto per la prima volta dalla Gartner ( rinomata società che si
occupa di ricerca e consulenza operante nell'ambito dell'information technology ) per
indicare il modello di sviluppo adottato dai Web Innovators .
Il termine "Scale" (3) si riferisce a numerose dimensioni . Una dimensione è la grandezza
("size") con la quale si misura il numero di server fisici o virtuali distribuiti . la seconda
dimensione è la complessità ( " complexity") con la quale ci si riferisce alla sofisticatezza
dei componenti o servizi utilizzati per fornire una determinata soluzione software, e
all'interdipendenza tra di essi . Un'altra dimensione è il numero di persone necessarie per
mantenere e supportare l'infrastruttura . L'agilità("agility") intesa come l'abilità di
rispondere velocemente ai cambiamenti richiesti e infine l'ultima dimensione è la
velocità("rapidity") definita dal tempo che intercorre tra l'ideazione di un prodotto e la sua
effettiva commercializzazione .
Le caratteristiche del Web Scale IT sono le seguenti :
Utilizzo di software open-source e "commodity hardware" in questo modo è
possibile creare un’infrastruttura che sia completamente controllabile . Inoltre
siccome c'è poca fiducia nei confronti dei fornitori di terze parti si preferisci
raggiungere un elevato uptime (intervallo di tempo in cui un singolo apparato o un
intero sistema informatico è stato ininterrottamente acceso e correttamente
funzionante ) non comprando alimentatori o dischi ridondanti ma utilizzando la
tecnica del fault-tolerant software , cioè progettare l'intero sistema in modo che
sia elastico in presenza di fallimenti hardware facendo si che esso operi
correttamente anche in situazioni spiacevoli.
Costruire applicazioni come un'insieme di servizi elastici ed indipendenti,
8
utilizzando protocolli web e pattern architetturali.
I Web Innovator utilizzano un'architettura dei servizi web-based .
La caratteristica essenziale di questo tipo di approccio è quella di dover pensare ad
un servizio come un componente software capace di svolgere un determinato
compito in modo indipendente dal resto del sistema , per renderlo condiviso e
riutilizzabile .
Questo tipo di approccio permette di massimizzare l'uptime e l'affidabilità . Inoltre
progettando in questo modo si rende possibile agli sviluppatori di creare nuove
applicazioni partendo da servizio gia esistenti.
Eliminazione della divisione tra sviluppo e operazioni IT (DevOps) concetto che si
trova alla base del DevOps di cui parleremo in seguito.
Adottare dei flussi di lavoro che siano agili e veloci (anche questi scopo del
DevOps)
Tutte le pratiche sviluppate dai Web Innovators puntano alla creazione di infrastrutture
che supporti uno sviluppo rapido e che abbiano l'abilità di cambiare (rapidamente ed
efficacemente) in modo elastico in base ai requisiti aziendali.
Il modello di lavoro dei Web Innovator si basa su alcuni approcci fondamentali:
Concentrarsi sulla digital consumer experience.
Collezionare dati, utilizzandoli per capire che cosa sta funzionando e cosa no, ed
eventualmente basarsi su queste informazioni per migliorare.
Investire nelle innovazioni tecnologiche, mettendo a disposizione dei kit di
sviluppo che consentano di realizzare e testare nuove idee di business in modo
facile e veloce.
Effettuare numerose prove. I Web Innovators mirano a un processo di sviluppo
dinamico, ciò significa che non sprecano tempo e denaro nella produzione di
prodotti che ritengono essere perfetti per i consumatori per poi scoprire alla fine
dello sviluppo che non è quello che i consumatori vogliono, ma cominciano con
delle minime implementazioni per poi eventualmente costruire il tutto in modo
incrementale. E’ usuale effettuare dei test denominati A/B testing, questi
consistono nel fornire a dei gruppi di consumatori delle versioni diverse di una
stesso servizio per poi decidere in base ai dati raccolti qual è la versione che è
meglio adottare.
Utilizzare strumenti automatici.
9
1.1 Automation L’automazione sottintende tutti i modelli e le pratiche sviluppate dai web innovators.
Utilizzare una piattaforma automatica è la porta di ingresso per poter aver accesso agli
stessi modelli di successo che sono stati utilizzati da queste grandi aziende . Il concetto
chiave dell’automazione è quello di rappresentare l’intera infrastruttura come codice
(Infrastructure as a code) . Ciò rende l’infrastruttura veloce, scalabile e consistente
(speed, scale and consistency), queste tre caratteristiche dipendono una dall’altra – per
esempio: non è possibile avere elevato scalabilità senza avere velocità nell’aggiungere
server con una configurazione consistente.
Andiamo quindi ora ad analizzare questi tre aspetti:
Speed. Solitamente nella gestione di servizi IT c’è la necessità di effettuare delle
operazioni che coinvolgono molte macchine fisiche e/o virtuali. In assenza di uno
strumento automatico queste attività devono essere svolte manualmente per ogni
macchina, ovviamente questa è un’operazione molto dispendiosa in termini di
tempo quando è necessario eseguirla un elevato di volte numero. Con uno
strumento automatico è possibile scrivere una sola volta (sotto forma di codice) le
operazioni da dover effettuare per poi eseguire automaticamente su ogni macchina.
Scale. È possibile scalare l’infrastruttura rispondendo opportunamente alle
richieste in modo di soddisfare i consumatori anche in momenti in cui la richiesta
è elevata .
Consistency. La piattaforma controlla la conformità con le specifiche politiche di
business. Effettuando le opportune modifiche ai servizi che non sono allineati con
tali politiche, riducendo i rischi e irrobustendo l'infrastruttura. Inoltre sarà possibile
caricare una determinata versione del sistema a fronte di eventuali problemi
riscontrati nella distribuzione di una nuova release .
Iaas inoltre permette di avere un'infrastruttura:
Versionabile (versionable): è possibile realizzarne diverse versioni così da poter
usare quella che si ritiene più adatta.
Testabile (testable): è possibile prevedere dei test automatizzati.
Ripetibile (repeatable): ogni volta che abbiamo necessità di riutilizzarla è possibile
eseguirla su altre macchine, mantenendone inalterata la struttura.
Molte organizzazioni IT fanno affidamento su processi manuali o script per portare a
termine attività ripetitive. Quando però bisogna gestire grandi sistemi questi metodi non
10
possono essere utilizzati poiché difficili da scalare, tracciare e mantenere, utilizzarli può
portare a numerosi errori e/o diminuzioni in termini di prestazioni. Gartner ha annunciato
che circa il 40% dei fallimenti nei servizi IT mission-critical sono stati causati da errori
umano o nei processi, gran parte di questi fallimenti son dovuti alla mancanza di
coordinamento tra i processi di change, release e configuration management .
Utilizzando un Automated Configuration Management è possibile eliminare la maggior
parte del lavoro manuale aumentando l'affidabilità e la predicibilità. Gli altri aspetti
positivi sono: incremento della produttività (avendo la possibilità di gestire molti più
nodi), diminuzione del tempo per distribuire aggiornamenti, eliminare i configuration-drift
e ridurre i fallimenti.
Inoltre è possibile migliorare la sicurezza del sistema, rinforzando l'ambiente operativo.
L’attività di Configuration Management da supporto alla gestione dei server,
permettendo di configurare il sistema operativo e i software generici caricati sulla
macchina target.
Generalmente le attività che permette di svolgere sono:
Application Deployments : distribuire velocemente le applicazione che servono a
supporto di una determinato servizio
Provisioning - Bare Metal Provisioning : configurare correttamente nuovi server
in modo che possano subito dare supporto ai servizi IT dell'infrastruttura
Cloud Management : deve fornire gli strumenti necessari per poter utilizzare i
servizi dei maggiori fornitori operanti nell’ambito dei cloud – Ottenuto con il
supporto di moduli o interfacce tipicamente messe a disposizione dai fornitori del
servizio di cloud
IT Compliance and Validation: Cercare di mantenere la conformità con le
politiche di sicurezza non c'è quelle aziendali.
Una buona piattaforma automatica dovrebbe avere anche le seguenti caratteristiche:
Deve permettere di avere una vista dell’intero stato della rete.
Deve essere scalabile. Le infrastrutture tendono ad aumentare in dimensione e in
complessità, per tale motivo una buona piattaforma automatica deve essere
fortemente distribuita e non può utilizzare un approccio centralizzato perché il
server centrale potrebbe diventare un collo di bottiglia a causa dell’elevato lavoro
cui sarebbe sottoposto.
11
Deve essere fault-tolerant. E’ necessario mettere a disposizione un insieme di
strumenti che permettano di gestire un'eventuale situazione di errore o eventi
spiacevoli tipo mancanza di connettività o necessità di riavviare l’intero sistema.
Deve essere sicura. Assicurare che la comunicazione tra server e i nodi avvenga in
maniera criptata ed effettuare controlli granulari riguardo all’accesso alle risorse
(un esempio potrebbe essere il role-based access.)
Deve riuscire a gestire reti eterogenee e supportare sistemi legacy.
Deve dare la possibilità di gestire ambienti cloud.
Dare supporto all’attività di Continuous Delivery : e quindi alle metodologie di
sviluppo del DevOps per rendere il ciclo di sviluppo agile , veloce ed elastico
12
ITIL La definizione di alcune delle funzionalità sono contenute all'interno di un documento che
prende il nome di ITIL (Information Technology Infrastructure Library) scopo dell’ITIL è
di fornire un insieme di buone abitudini per la gestione dei servizi IT (IT Service
Management) concentrando l’attenzione sulle necessità aziendali.
Esso costituisce non solo un ottimo strumento per l'amministratore di sistema ma
soprattutto per l'azienda perché fornisce supporto per stabilire delle linee guida per una
gestione a lungo termine dei servizi, inoltre tali linee guida possono essere utilizzate per
valutare la conformità del sistema con gli obiettivi prefissati e misurare il livello di
miglioramento ottenuto. ITIL è un documento diviso in cinque volumi ognuno dei quali
compre una diversa fase dell'ITIL lifecycle:
Service Strategy: mira alla comprensione degli obiettivi dell'organizzazione e le
necessità dei consumatori.
Service Design: trasformare le strategie di servizio in un piano per raggiungere gli
obiettivi aziendali.
Service Transition: mira allo sviluppo e al miglioramento delle capacità per
l'introduzione di nuovi servizi.
Service Operation: gestione dei servizi.
Continual Service Improvement: realizzare servizi incrementali e miglioramenti su
larga scala.
Nella trattazione farò riferimento principalmente agli ultimi volumi essendo quelli che
contengono alcune delle definizioni d’interesse e che quindi sono utili per effettuare un
confronto tra ciò che dovrebbe essere fatto e ciò che è realizzato dagli strumenti
automatici che andremo ad analizzare .
13
Capitolo 2: Configuration Management (CM) E' l'attività che permette di tracciare e controllare i cambiamenti del software. Questo è
realizzato mantenendo informazioni riguardo i Configuration Items (CI) all'interno del
Configuration Management Database (4), le fasi che lo caratterizzano sono le seguenti:
Planning: pianificazione delle strategie, definizione di obiettivi, politiche, ruoli e
responsabilità. Definizione di attività e procedure relative al CMDB,
identificazione delle relazioni con altri processi o terze parti.
Configuration Identification: é il processo di selezione, identificazione ed
etichettatura dei CIs, esso include la memorizzazione dei rispettivi attributi e
relazioni tra essi. I CIs dovrebbero essere memorizzati con un determinato livello
di dettaglio giustificato dalle necessità di business.
Configuration Control: assicurare che solo i CI autorizzati e correttamente
identificati siano gestiti dal loro ricevimento allo smaltimento. Assicurarsi che
eventuali aggiunte, modifiche, sostituzioni o rimozioni dei CI siano adeguatamente
documentate.
Configuration status accounting: monitorare ogni CI durante tutto il suo ciclo di
vita , tenendo traccia di eventuali cambiamenti negli attributi attraverso i vari stati
(ordinato , ricevuto , in prova , vivo , in riparazione , ritirato , smaltimento) .
Configuration audits: Verificare l'esistenza fisica dei CIs e controllare che siano
registrati correttamente nella lista delle parti del CMDB ovviamente in presenza di
eventuali modifiche sarà necessario aggiornare la documentazione
Configuration Item (CI) è l'unità strutturale fondamentale del processo di CM, può essere
una risorsa hardware, software o una combinazione di risorse, che è trattata dal processo
stesso come una singola entità. Un CI è caratterizzato da attributi e relazioni che saranno
assegnate dal gestore della configurazione e memorizzate nel Configuration Management
Database (CMDB). Tra gli attributi possiamo trovare: versione, modello, produttore,
dettagli tecnici, numero d’identificazione, e altro ...
14
Com’è stato possibile notare il Configuration Management Database (CMDB) è un
elemento chiave , esso è utilizzato per memorizzare tutte le informazioni necessarie
relative ai CI compresi gli attributi e le relazioni tra essi.
Per implementare correttamente il processo di CM è utile tenere in considerazione i
seguenti consigli:
Cercare di implementare i processi di configuration, change e release management
insieme possibilmente fornendoli di una funzione centralizzata che li gestisca .
Scegliere un adeguato livello di dettaglio.
Il processo di configuration management ci permette di ottenere una vista sempre
completa e aggiornata del sistema basandosi sulle modifiche degli attributi dei
configuration items e memorizzando tali informazioni all'interno del CMDB, questo porta
degli enormi vantaggi dal punto di vista della manutenzione e del controllo del sistema. Il
prodotto software da controllare potrebbe eventualmente anche essere un Sistema
Operativo.
Solitamente il processo di CM è considerato "troppo burocratico" e quindi c'è scarso
interesse nei suoi confronti anche perché i benefici non sono immediatamente tangibili (5).
Essenzialmente esso è un processo di supporto ,non essendo quello che realmente effettua
le modifiche di configurazione , però abbinandolo con quello di change e release
management e fondendo tutto insieme in una piattaforma automatica abbiamo come
risultato uno strumento molto potente.
Nella mia trattazione con il termine Configuration Management mi riferirò a questa
situazione , però prima di andare avanti , è opportuno dare uno sguardo alle definizioni di
change e release management.
2.1 Change Management Lo scopo di quest'attività è di gestire in modo efficiente e rapito i cambiamenti da
apportare sull'infrastruttura, assicurando che essi avvengano secondo un flusso di lavoro
prestabilito, minimizzando eventuali impatti negativi. Solitamente, le fasi che
caratterizzano il processo di Change Management sono le seguenti:
Iniziare il processo di registrazione dei cambiamenti (o Request for Change, RFC).
Valutare l'impatto, costi, benefici e rischi dei cambiamenti proposti.
Sviluppare giustificazioni (dal punto di vista del business) dei cambiamenti
proposti e ottenerne l'approvazione.
15
Gestire e coordinare l'implementazione delle RFC.
Monitorare e fornire report sulle RFC
Fare la review e chiudere le RFC
2.2 Release Management Gli obiettivi sono:
Pianificare il rollout del software
Progettare e implementare procedure per la distribuzione e l'istallazione dei
cambiamenti sul sistema IT.
Comunicare efficacemente e gestire le attese dei consumatori durante la
pianificazione e il rollout della nuova release.
Controllare la distribuzione e apportare i cambiamenti sul sistema IT.
I concetti chiave che devono essere tenuti in considerazioni sono i seguenti: in un processo
in cui si effettuano dei cambiamenti su un determinato software, è necessario che le
informazioni riguardo alla situazione del sistema siano sempre aggiornate, bisogna quindi
tenere traccia di tutte le modifiche che si effettuano, questo permette di ritornare
facilmente a configurazioni del software precedenti. Un’altra cosa che è evidente è la
necessità di valutare preventivamente quali sono le problematiche che si vengono a creare
nell'effettuare determinate modifiche e quando questo è possibile, progettare
preventivamente le dovute attività da eseguire per risolverle oppure eventualmente
decidere di non effettuare più quella determinata modifica .
16
Capitolo 3: Deployment e Provisioning Il termine Deployment indica la messa in uso di un sistema software tipicamente in un
ambiente informatico aziendale, in altre parole, esso si compone di una serie di attività che
possono essere svolte dallato produttore o dal lato consumatore o da entrambi che hanno
come scopo quello di rendere un sistema software disponibile all'uso. Possiamo vedere il
deployment come l'ultima fase dello sviluppo del software che indica la conclusione dello
sviluppo per dar inizio alla fase di manutenzione. Siccome ogni software è unico, non è
possibile elencare precisamente le attività che lo compongono, possiamo però immaginare
che in essa sia contenta una fase in cui vengono soddisfate tutte le eventuali dipendenze
che sono indispensabili per il corretto funzionamento dell'applicazione e quindi presumere
che il concetto d’istallazione sia molto vicino a quello di Deployment .
Spesso il significato di questa parola è confuso con quella della parola “provisioning”, in
realtà tra i due termini ci sono delle differenze essenziali che però si assottigliano
utilizzando le metodologie di sviluppo software DevOps e le piattaforme di Cloud
Computing .
Il termine Provisioning indica il processo di preparazione di uno o più server per renderli
pronti a svolgere le proprie funzioni, generalmente essa comprende in se:
Selezionare un server.
Caricare il software appropriato (sistema operativo, driver di periferica,
middleware e applicazioni).
Personalizzare e configurare il sistema e il software per creare o modificare
un'immagine di avvio per il server.
Scambiare i parametri (l'indirizzo IP, gateway IP) per trovare le risorse di rete per
verificare il sistema.
Come si può vedere il concetto di Deployment è intrinsecamente presente nella fase di
Provisioning, quindi possiamo vederlo come una sua sotto-attività. Il provisioning è legata
al server, mentre il deployment all'applicazione, la seconda è un'attività che è eseguita
17
molto più spesso rispetto alla prima. Con il cloud computing questa distinzione viene
sempre più ad assottigliarsi, i server virtuali saranno soggetti alla fase di provisioning
molto più spesso, a volte anche solo per la durata di un test .
In definitiva possiamo immaginare che il provisioning coinvolga anche delle operazioni
che devono essere svolte da persone fisiche e che non possono essere automatizzate
attraverso il codice, ovviamente anche questa non è una cosa del tutto vera, per dare una
spiegazione a quest’affermazione è necessario soffermarsi su un altro concetto: il Bare
Metal Provisioning.
3.1 Bare Metal Provisioning Nel gergo informatico Bare Metal indica un computer senza sistema operativo.
Attualmente è possibile eseguire l'operazione di provisioning anche su questi sistemi
utilizzando Razor. Il concetto alla base è trattare l'hardware come il software ("treat your
hardware like software" - Jason Stowe) (6) Razor è un'applicazione che può operare sia su
bare metal sia su sistemi virtuali e punta a risolvere la problematica di come poter
raggiungere uno stato in cui sul sistema possa agire il flusso di lavoro di un configuration
management. Affinché Razor possa funzionare, è necessario settare la macchina in modo
che sia abilitato l'avvio tramite Preboot Execution Environment (PXE). Quando è presente
questa funzionalità il bios della macchina da la possibilità all'utente di scegliere di
effettuare il boot da rete, in tal caso il firmware utilizzerà DHCP sia per configurare un
indirizzo IP sulla scheda di rete sia per individuare un server da cui sarà scaricato un file
(NBP- Network Bootstrap Program) che sarà immagazzinato nella ram ed eseguito. NBP
sarà in molti casi un boot loader, ovvero un programma che a sua volta scarica via TFTP
(7) il kernel del sistema operativo.
Il PXE deve essere impostato in modo che il DHCP punti a un server fornito da Razor, il
file che sarà successivamente scaricato (una volta scelto il server) è il Razor Microkernel,
èsso è un piccolo sistema operativo che è caricato sul nodo per effettuare la fase di
discovery nella quale saranno prelevate tutte le informazioni necessarie per scegliere
correttamente quali operazioni eseguire sul nodo stesso. In base alle informazioni ottenute,
al nodo è associato un particolare tag, per ogni tag corrisponderanno una serie di politiche
di gestione, che solitamente hanno come scopo di selezionare il corretto sistema operativo
da istallare sulla macchina. Generalmente la necessità è di portare il sistema in uno stato in
cui una piattaforma automatica possa gestirlo automaticamente, per fare questo Razor
utilizza un Broker plug-in che interagendo con un broker esterno permette di configurare il
nodo opportunamente, in tal caso il tag e le informazioni scoperte precedentemente sono
18
inviate al broker e saranno utili per effettuare le giuste scelte di configurazione.
E' necessario inoltre sottolineare che Razor non è stato ancora ottimizzato, esso è definito
una Teach Preview e non è ancora pronto per essere utilizzato in ambiente di produzione
(Production Environment).
19
Capitolo 4: Continuous Delivery Martin Fowler (ingegnere del software britannico, autore di numero libri e considerato fra
i massimi esperti nei settori della programmazione orientata agli oggetti) definisce il
processo di continuous delivery come una disciplina dello sviluppo software che mira a
realizzare applicazioni in modo che siano pronte per essere inserite in ambienti di
produzione in qualsiasi momento (8) .
Fare Continuous Delivery significa preferire rilasci piccoli e frequenti invece di pochi e
grandi, per ogni modifica è prevista la fase di testing quindi si lavora sempre su un
prodotto software funzionante. Nel caso ci siano dei bug, è facile trovare la radice del
problema, questo permette al processo di sviluppo di aumentare le sue caratteristiche di
predicibilità e la qualità dei rilasci. Solitamente nel Continuous Delivery il team di
sviluppo da priorità a rendere il prodotto distribuibile invece di realizzare nuove
funzionalità, questo permette di poterlo rilasciare in qualsiasi momento del suo ciclo di
vita.
Uno dei rischi nello sviluppo software è di realizzare qualcosa che agli utenti non piace o
che non è utile, utilizzando un approccio Continuous Delivery è possibile evitare questo
rischio, ogni cambiamento che si effettua può essere distribuito agli utenti. In questo modo
si riesce a ricevere un veloce feedback che ci da informazioni sulle esigenze e la tendenza
dei consumatori.
In alcuni casi si preferisce non rilasciare la versione a tutti ma è comunque possibile
ricevere feedback mettendolo a disposizione solo di un gruppo limitato . Far partecipare
gli utenti al processo di sviluppo fa in modo di infondere in loro un senso di comproprietà
e fedeltà che li rende più propensi a chiudere un occhio quando si effettuano degli errori
(9) (10).
Grazie al continuous Delivery è possibile rispondere prontamente all'evoluzione continua
delle esigenze degli utenti, appena si scopre che le condizioni di mercato sono cambiate è
più facile effettuare delle modifiche veloci.
20
I benefici coinvolgono l'intera azienda, infatti, le responsabilità per la distribuzione del
software sono distribuite in modo molto più ampio questo rende "la vita migliore" a tutti
coloro che fanno parte del processo (IT operators, software development, QA).
Spesso il termine Continuous Delivery è confuso con quello di Continuous Deployment, la
differenza tra i due sta nel fatto che nel primo caso se pur si effettuano dei continui
cambiamenti nel software, non è detto che essi siano estesi all'ambiente di produzione,
cosa che avviene nel Continuous Deployment.
Per raggiungere questi obiettivi è necessaria una stretta collaborazione tra tutti coloro che
sono coinvolti nel processo di sviluppo (DevOps è parte integrante dell'attività di
Continuous Delivery) nonché cercare di automatizzare la maggior parte delle attività della
distribuzione. Effettuando dei cambiamenti manuali è possibile commettere degli errori,
inoltre automatizzare significa risparmiare tempo e questo è essenziale in un processo di
sviluppo che mira a essere agile e veloce.
Le operazioni necessarie per realizzare ottimamente un processo di Continuous Delivery
avranno bisogno di:
Monitoring tools : monitoraggio costante
Version control tools : tenere traccia di tutte le versione , le caratteristiche
aggiunte e i cambiamenti al codice
Continuous integration tools: per integrazione continua e generare
automaticamente test
Configuration management tool
Test automatici cui devono essere sottoposti.
Code review tools
4.1 DevOps E' una metodologia di sviluppo software che sollecita la comunicazione e collaborazione
tra:
Sviluppatori software generalmente impegnati con continue modifiche e rilasci
Professionisti dell'information technology che ci concentrata sulla disponibilità e
affidabilità dei servizi.
Quality assurance (QA) impegnati nel soddisfare gli obiettivi di qualità.
In molte organizzazioni tali gruppi si trovano in divisioni differenti. Ciò rallenta il
21
passaggio dallo sviluppo alla gestione del software con il conseguente aumento nei tempi
di produzione .
Le metodologie DevOps cercano di risolvere a questo problema standardizzando gli
ambienti di sviluppo, promuovendo un insieme di processi e metodi indirizzati alla
comunicazione e collaborazione tra le divisioni e incitando l'utilizzo di approcci agili allo
sviluppo software.
La rapidità e l'efficienza che ci sono date dall'utilizzo di DevOps permettono di:
Diminuire i tempi di sviluppo con conseguente aumentando del numero dei
prodotti e servizi software rilasciati.
Minor impatto sui rilasci con conseguente aumentando della predicibilità.
Ottenere elevate garanzie di qualità
22
Capitolo 5: Puppet
Puppet Enterprise (PE) mira a essere una piattaforma completa per la gestione della
configurazione dei sistemi aziendali. PE comprende:
Puppet: Configuration Management Tool permette all’amministratore di sistema di
definire lo stato desiderato dell’infrastruttura e automaticamente decide le
operazioni da effettuare per raggiungere tale stato.
Facter : componente che viene eseguito sul client e si occupa di collezionare i facts
ovvero determinate caratteristiche relative al client (si tratta di informazioni
sull’hardware, impostazioni di rete e sul sistema operativo in uso )
PuppetDB : data warehouse
Hiera: strumento di ricerca, per i dati di configurazione
Una web-based console per l’analisi di eventi , gestione dei sistemi Puppet ,
gestione degli utenti ,,analisi dei report , sfogliare dati di inventario e assegnare le
classi ai nodi. In esso sono compresi Puppet Dashboard e Live Management.
MCollective: orchestration framework permette di effettuare dell’operazione
simultaneamente su numerosi nodi.
Geppetto: un IDE che fornisce un insieme di strumenti per lo sviluppo di moduli e
manifesti (vedremo in seguito cosa sono) Puppet .
Puppet Forge: un repository dove è possibile scaricare i moduli messi a
disposizione dalla Puppet Labs o dalla comunità Puppet.
Razor: un’applicazione che da supporto per il bare metal provisioning
Cloud provisioning tools: creare e configurare nuove istanze di macchine virtuali,
(tra cui tool per VMware, Google Compute Engine, Openstack, and Amazon EC2).
Altri elementi necessari: ActiveMQ, Live Management, Cloud Provisioner, PostgreSQL,
23
Ruby, Augeas, Passenger, Java, OpenSSL.
PE supporta diversi sistemi operativi tra cui: Red Hat Enterprise Linux, CentOS, Ubuntu
LTS, Debian, Oracle Linux, Scientific Linux, SUSE Linux Enterprise Server, Solaris,
Microsoft Windows , AIX, Mac OS X ...
In base alle esigenze è possiamo scegliere di installare più componenti su un singolo nodo
(istallazione Monolithic) o distribuirli (istallazione Split).
In tal caso si riescono a gestire più nodi, massimo 500 per l’istallazione monolitica, 1000 o
più per quella split, però bisognerà avere accortezza nell’ordine in cui essi sono installati,
l’ordine di precedenza dovrà essere:
Puppet Master
PuppetDB and PostgreSQL
Console
Agents
E' possibile anche effettuare un'istallazione con answer file, esso è un documento che
permette di specificare alcuni parametri per la fase d’istallazione stessa.
Per il corretto funzionamento di PE è richiesta l’istallazione di OpenSSL (alcuni OS lo
includono già).
5.1 Componenti
5.1.1 Puppet Agent L’agente Puppet deve essere installato su tutti i nodi della distribuzione.
Quando s’istalla il Puppet master, PuppetDB, o la console, esso sarà installato
automaticamente. Queste macchine possono:
Ricevere e applicare le configurazioni inviate dal Puppet master grazie ad un
Puppet agent daemon.
Ricevere messaggi per le operazioni di orchestrazione e invocare le azioni che
sono richieste.
Inviare i dati al master, solitamente sono informazioni di report che saranno poi
immagazzinate nel PuppetDB.
5.1.2 Puppet Master E’ necessario istallare il master almeno su un nodo (è possibile anche avere più master, ma
ciò richiede ulteriori sforzi di configurazione.)
24
Esso può:
Compilare e inviare informazioni di configurazione (catalog) all’agente presente
sul nodo.
Inviare messaggi di orchestrazione attraverso il server ActiveMQ.
5.1.3 PuppetDB PuppetDB è veloce, scalabile e affidabile esso utilizza un'istanza di PostgreSQL (è un
completo DBMS a oggetti rilasciato con licenza libera), memorizza per ogni nodo i facts e
i catalog e gli event reports più recenti.Inoltre supporta la console per il RBAC e node
classifier .
5.1.4 PE Console Tramite la console possiamo modificare direttamente le risorse suoi nodi, attivare
l’esecuzione di Puppet, associare i nodi a gruppi o classi, visualizzare report e grafici,
visualizzare informazioni d’inventario e invocare azioni di orchestrazione .
5.1.4.1 Role-based Access Control (RBAC) Consente di gestire i privilegi degli utenti, il concetto è: “Is this user allowed to perform
these actions?”.A ogni utente sarà assegnato un ruolo che non sarà altro che un insieme di
permessi, essi sono usati per definire quali azioni possono essere eseguite e su quali nodi. I
ruoli di default sono: Administrators, Operators e Viewers ma è possibile creare dei ruoli
personalizzati.
Node Classifier (NC) : E’ un modo per organizzare e configurare i nodi.
5.1.4.3 Live Management E’ l’interfaccia per il motore di orchestrazione operazioni possibili dal Live Management
sono:
Sfogliare, cercare, ispezionare e confrontare su qualsiasi sottoinsieme di ogni
nodo.
Invocare azioni avanzate sui nodi (per esempio caricare e applicare la
configurazione, disabilitare l’agente, e altro.)
5.2 Configuration Management Puppet divide la gestione della configurazione in quattro principali attività:
L’utente descrive un pezzo riusabile di configurazione creando o scaricando un
Puppet modules.
L’utente assegna una classe per ogni nodo
25
Il nodo carica la configurazione prelevata dal master e la applica , imponendo lo
stato desiderato che è stato definito dall’utente e presentando un rapporto sui
cambiamenti che sono stati eseguiti . Puppet può funzionare sia con un’architettura
pull-model (la configurazione è richiesta ogni trenta minuti) o push-model.
L’utente può vedere report aggregati o individuali per monitorare quali risorse
sono state cambiate da Puppet.
5.2.1 Modules and Manifests Per modellare lo stato desiderato Puppet utilizza un linguaggio omonimo, dichiarativo
basato sulle risorse, è importante notare che
non sono descritte le operazioni da dover
effettuare ma lo stato finale che il nodo deve
assumere. Il linguaggio è quindi utilizzato per
descrivere pezzi di configurazione .
Il codice Puppet è salvato su file chiamati
manifests con estensione .pp, essi a loro volta
sono memorizzati in cartelle strutturate (con
uno specifico layout) chiamate moduli .
I moduli sono una convenzione per
organizzare i manifest in modo che possano
essere automaticamente localizzati e caricati
dal Puppet master, essi possono contenere
anche altro come classi, plug-in o templates.
Generalmente le classi in un dato modulo
sono correlate a esso.
5.2.2 Catalog
L’agente non vede mai i manifesti e i moduli
che compongono la sua configurazione, il
Puppet master compila il manifesto prima di servirlo al nodo, il documento che è inviato
prende il nome di catalog.
Il catalog non contiene tutto ciò che è inserito all’interno del modulo memorizzato sul
server, ma contiene solo le risorse e le relazioni tra esse.
La configurazione è descritta senza logica contingente, quindi si ha la possibilità di
simulare i cambiamenti necessari per applicarli. Se si esegue Puppet in noop mode,
1‐ Processo di applicazione della configurazione
26
l’agente controllerà lo stato corrente e farà un report in base alle modifiche che avrebbe
dovuto apportare senza effettuarne alcuna (è possibile anche comparare gli effetti di
catalog diversi).
Per comporre una configurazione completa per un nodo, dobbiamo generalmente
assegnargli una combinazione di classi , essi sono dei pezzi riusabili di configurazione
memorizzati nei moduli. Alcune classi possono essere configurate per comportarsi in modi
diversi in base alle esigenze. Ci sono molti modi per assegnare e configurare una classe.
Generalmente la definizione di una classe contiene dichiarazioni di risorse.
5.2.3 Resources La risorsa è l’unità fondamentale per modellare la configurazione di sistema. Ogni risorsa
descrive qualche aspetto del sistema come un servizio che deve essere eseguito o un
package che deve essere installato. Il blocco di codice che descrive una risorsa prende il
nome di resource declaration essa può essere presente all’interno di definizioni di tipo o di
classe. Dichiarare una risorsa significa fare presente a Puppet che bisogna includerla nel
catalog e che deve essere gestita sul sistema di destinazione.
# A class with parameters class apache ($version = 'latest') { package {'httpd': ensure => $version, # Using the class parameter from above before => File['/etc/httpd.conf'], } file {'/etc/httpd.conf': ensure => file, owner => 'httpd', content => template('apache/httpd.conf.erb'), # Template from a module } service {'httpd': ensure => running, enable => true, subscribe => File['/etc/httpd.conf'], } }
Ogni risorsa ha un tipo, un titolo e un set di attributi. Gli attributi descrivono lo stato
desiderato di una risorsa, ognuno di essi gestisce un particolare aspetto della risorsa.
type {'title': attribute => value, }
Ci sono diversi modi per assegnare una classe a un nodo (e quindi assegnargli dei
determinati dati di configurazione), non li analizzerò tutti ma mi focalizzerò solo sul
metodo che fa uso del manifest site.pp .
27
5.2.5 Assegnare dati di configurazione I dati di configurazione possono essere presi da diverse sorgenti, site.pp è una sorgente
primaria, tramite esso possiamo:
Assegnare classi
Configurare classi con parametri con variabili top-scope and node-scope.
Convertire dati provenienti da diverse sorgenti in parametri per le classi o variabili.
Dichiarare singole risorse fuori dalle classi.
Site.pp è un normale manifesto scritto nel linguaggio Puppet che è incorporato in ogni
catalog e quindi assegnato a ogni nodo. Per restringere le impostazioni di configurazione a
gruppi o a singoli nodi bisogna inserirle all’interno della definizione di un nodo.
# da aggiungere allafine di /etc/puppetlabs/puppet/manifests/site.pp node 'agent1.localdomain' { . # Qualsiasi risorsa o dichiarazione di una classe va qui dentro include apache #Con il codice seguente dichiarando una classe con un parametro #indicata come resource‐like class declaration class {'ntp': servers => [ "ntp1.example.com dynamic", "ntp2.example.com dynamic", ], } }
Il codice Puppet inserito nel site.pp può accedere a molte altre sorgenti di dati e
trasformale in variabili, parametri o una lista di classi da dichiarare. Se dichiariamo una
classe senza settare i suoi parametri è possibile successivamente assegnarli tramite Hiera.
5.2.6 Attivare il processo di configurazione L’agente sul nodo esegue il servizio pe-puppet che è dormiente in background ed esegue
le configurazioni a intervalli regolari. Solitamente l’intervallo è di trenta minuti.
Modificando il file puppet.conf è possibile cambiare:
La priorità del processo Puppet,
La periodicità con cui l’agente interroga il master per ottenere nuove impostazioni
di configurazione puppet.conf (ogni agente ne ha uno).
La modalità di funzionamento da (pull model a push model) fermando
l’esecuzione del servizio pe-puppet. Questo fa sì che il nodo caricherà la
28
configurazione solo quando essa è esplicitamente richiesta.
5.3 Monitoraggio A seguito dell’esecuzione del catalog e dell’applicazione dei cambiamenti è generato un
report in cui sarà indicato lo stato del nodo, esso potrà assumere uno dei seguenti valori:
Unresponsive, Failed, No-op, Changed, Unchanged, Unreported.
Per gestire la ricezione asincrona dei report Puppet utilizza diversi processi in background.
Il monitoraggio dell’infrastruttura può essere fatto attraverso la console utilizzando:
Il tool Event Inspector è uno strumento di reporting che fornisce i dati per indagare
sullo stato attuale dell’infrastruttura. Esso permette: il monitoraggio delle attività
delle infrastrutture e l’analisi dei dettagli. Ispettore di eventi consente l'analisi da
diverse prospettive (classe, nodi e risorse.)
Puppet Dashboard: permette di visualizzare anche grafici.
5.4 Orchestration
5.4.1 Components Le parti che compongono il motore di orchestrazione sono:
Il servizio pe-activemq in esecuzione sul master che instrada i messaggi.
Il servizio pe-mcollective in esecuzione su ogni nodo, in ascolto dei comandi
autorizzarti esso si occupa anche dell’avvio delle azioni.
Il comando mco e la pagina live management della console che consentono di
inviare le azioni da effettuare a un numero qualsiasi di nodi.
5.4.2 Actions and Plugins Il tool di orchestrazione PE è essenzialmente un sistema con elevato parallelismo basato
sul remote procedure call (RPC). Le azioni sono quelle distribuite dai plug-in per l’agent
Mcollective , sono disponibili molti plug-in ma è possibile aggiungerne degli altri .
E’ possibile selezionare determinati nodi attraverso un filtraggio e sono supportate
esecuzioni in batch.
Le azioni possono essere invocate da due posti:
In the PE console (on the live management page)
On the command line
5.4.3.1 The mco Command MCO è l’eseguibile che tramite il sottocomando rcp permette di richiamare le azioni.
La sintassi è tipicamente:
29
$ mco rpc <AGENT PLUGIN> <ACTION> <INPUT>=<VALUE>
Per ogni plug-in ci sarà una lista diversa di azioni . L’istallazione di default di PE
comprende i seguenti tool:
service: permette di avviare o fermare i servizi del sistema (azioni: restart , start
, status , stop)
puppet: permette di eseguire azioni sull’agente (azioni: disable, enable
, last_run_summary , resource , runonce , status)
package : azioni relative ai packages ( apt_checkupdates , apt_update
, checkupdates , install , purge , status , uninstall , update , yum_checkupdates
, yum_clean )
rpcutil: generiche azioni di supporto ( agent_inventory , collective_info
, daemon_stats , get_config_item , get_data , get_fact , inventory , ping)
puppetral: agisce sulle risorse (azioni: find , search.)
5.5 Deployment Per il deployment è possibile utilizzare sia i meccanismi precedentemente indicati nel
configuration management sia il tool di orchestrazione . Per capire cosa intendo è
necessario sottolineare che è possibile gestire anche risorse del tipo:
exec: per eseguire comandi come apt-get
package: per istallare package tramite apt
service: per essere sicuro che un servizio sia in esecuzione.
file: assicurarsi che un qualche file esista.
Esse si possono utilizzare nel manifesto per stabilire i package da installare e i servizi da
attivare necessari per il deployment. Dopodiché bisognerà applicare la configurazione
utilizzando il comando:
sudo puppet apply –test
O aspettare che i client prelevino automaticamente la configurazione da applicare (pull-
model).
30
Capitolo 6: Chef Chef è un configuration management tool che automatizza la configurazione, la
distribuzione e la gestione delle applicazioni attraverso la rete. Per raggiungere questo
scopo su ogni nodo è istallato un client, essi sono coordinati da un Server centrale, che a
sua volta si avvale del supporto di una Workstation dove l'utente fa la maggior parte del
lavoro .
Per riuscire a capire come Chef funziona, è necessario dare delle definizioni:
Attributi (Attributes): un attributo è un dettaglio specifico che è utilizzato dal
Client per capire lo stato in cui si trova il nodo, può essere definiti dal nodo stesso
o dai cookbook o dai role o dall'ambiente.
Resource: è un qualsiasi pezzo dell’infrastruttura, può essere un file, un modello o
pacchetto da istallare. Si possono utilizzare quelle messe a disposizione da Chef o
crearne delle proprie per gestire configurazioni uniche o sistemi legacy.
DataBag : contenitori di dati critici
Recipe : elemento fondamentale di configurazione , viene scritta utilizzando il
linguaggio Ruby (linguaggio di programmazione progettato per comportarsi in
maniera prevedibile ), è essenzialmente una collezione di risorse definite
utilizzando il pattern : nome della risorsa , coppia chiave-valore e azioni . Una
recipe può dipendere da altre ed è sempre eseguita nello stesso ordine.
Cookbook : definisce uno scenario ( per esempio tutto ciò che è necessario per
istallare e configurare MySql ) e contiene in essa tutti i componenti necessari per
supportarlo ( valore degli attributi da dare al nodo , ricette , file ,librerie , ..) .
Possono essere creati in modo personalizzato (utilizzando il linguaggio Ruby) o
direttamente scaricati da quelli messi a disposizione nello Chef Supermarket.
Policy: sono una serie di elementi che sono utilizzati da Chef per tradurre
opportunamente le esigenze di business, requisiti operativi, i processi e il flusso di
lavoro .
31
Fanno parte delle policy:
Role : è un modo per definire un particolare modello , definiscono il tipo del server
("web server" , "database server" , ...) , può contenere attributi e run-list , inoltre
per ogni nodo possono essere associati più ruoli
Environment: definisce l'ambiente in cui stiamo operando (sviluppo, testing,
produzione), solitamente l'ambiente è legato a una particolare versione da
utilizzare.
6.1 Componenti
6.1.1 Workstation Permette di:
Interagire con lo chef-repo (11) in cui i cookbook sono creati, collaudati e
mantenuti.
Configurare le politiche organizzative: definendo ambienti, ruoli e garantire che i
dati critici siano memorizzati nei data bag.
Permette di caricare gli elementi dallo chef-repo al server Chef.
6.1.1.1 Knife E’ un tool a linea di comando, fa parte della workstation e fornisce un’interfaccia tra lo
chef-repo e il server. Permette di gestire: i nodi, le recipe, i cookbook, i ruoli, l’ambiente,
le risorse cloud, l’istallazione del cliente su nuovi nodi.
knife node è il sottocomando usato per gestire i nodi che sono collegati al server.
Elencherò di seguito alcuni argomenti che possono essere utilizzati con tale sotto
comando:
edit : per modificare i dettagli di un nodo , solitamente i dati di un nodo sono
memorizzati in un file JSON sul server
$ knife node edit NODE_NAME (options)
run_list add : viene utilizzato per aggiungere ruoli o ricette alla run_list del nodo
$ knife node run_list add NODE_NAME RUN_LIST_ITEM (options)
6.1.2 Chef Server E’ il contenitore centrale per tutti i dati di configurazione (cookbooks e policy) che sono
scaricati da un utente dalla workstation. Esso è utilizzato per gestire i data bags, attributi,
run-list, roles, environments e anche per configurare gli accessi (RBAC - Role-Based
access control) per gruppi o utenti. Il server svolge principalmente il ruolo di coordinatore
32
e contenitore d’informazioni, Chef utilizza un approccio distribuito, infatti, la maggior
parte del lavoro di configurazione è svolto sui client. Questo permette di evitare che il
server diventi un "collo di bottiglia" .
6.1.3 Client Chef Può gestire diversi tipi di nodi:
Fisici: qualsiasi dispositivo attivo, collegato a una rete, sul quale è possibile
eseguire un client chef, in grado di inviare, riceve e inoltrare informazioni
attraverso il canale di comunicazione.
Nodi di rete: qualsiasi dispositivo switch, router, ecc che abbia le opportune
caratteristiche per essere gestite da un client Chef.
Virtuali: un’implementazione software che si comporta come una macchina fisica,
può essere, un’istanza cloud o un Container (12) esso è un approccio orientato alla
virtualizzazione a livello di sistema operativo che permette di ospitare "multiple
isolated user space instances" invece di una sola all'interno di un SO (permette a un
singolo sistema operativo di ospitare molteplici configurazioni di lavoro).
6.1.3.1 Ohai Nel client è presente un elemento che prende il nome di Ohai, esso è utilizzato per
individuare gli attributi dei nodi e fornirli al client all'inizio di ogni sua esecuzione. Gli
attributi raccolti includono: dettagli tecnici del nodo, uso della rete, uso della memoria,
CPU data, Kernel Data, nome dell'host, nome di dominio completi e altri dettagli di
configurazione.
Affinché le comunicazioni tra client e server siano sicure ogni volta che il client richiede
l'accesso al server è utilizzata per l'autenticazione una coppia di chiavi pubbliche RSA,
questo permette di essere sicuri che solo un nodo propriamente registrato al server possa
essere gestito e avere accesso ai dati.
6.1.4 Chef Analytic Chef mette anche a disposizione una piattaforma di analisi (Chef Analytic) che fornisce
una vista in tempo reale di cosa sta succedendo permettendo di integrare i dati con sistemi
esterni. Questo permette di inviare alle persone addette o a strumenti automatici i
cambiamenti dei server in modo che si possa reagire in tempo reale. Ovviamente questi
dati vengono anche utilizzati per generare dei report .
6.1.5 Chef DK Kit di sviluppo messo a disposizione da Chef che fornisce gli strumenti per scrivere
cookbook e recipe, mette a disposizione strumenti per effettuare test di unità e
33
d’integrazione e altro.
6.2 Resource e Recipe Una recipe è un file con estensione .rb che contiene al suo interno una serie d’informazioni
di configurazione che sono scritte con il linguaggio Ruby. Generalmente la recipe
contiene un insieme di risorse che servono a descrivere lo stato desiderato di un particolare
item .
Una resource è rappresentata da un blocco con quattro elementi: un tipo, un nome, uno o
più attributi con rispettivi valori e una o più azioni. La sintassi di una risorsa è la seguente:
type "name" do attribute "value" action :type_of_action end
Ogni risorsa ha il proprio set di azioni e attributi. Di seguito elencherò alcuni tipi di risorsa
con alcuni azioni per brevità ho:
apt_package (:install , :upgrade, :reconfig , :remove) usata per gestire i package
directory (:create , :delete) per gestire una directory
file (:create , :delete , :create_if_missing , :touch) per gestire i file
user (:create , :remove, :modify , :manage , :lock , :unlock) per gestire gli
utenti
python (: nothing,:run) per eseguire uno script utilizzando l’interprete Python
service (:disable , :enable , :nothing , :reload , :restart , :start , :stop) per gestire un
servizio
6.3 Configuration Management Periodicamente il client richiede al server l'insieme più aggiornato delle politiche di
configurazione, queste non sono altro che delle recipe da applicare al nodo corrente, il
server determina le recipe secondo diversi fattori tra cui il ruolo ("web server ", "load
balancer",... ) che ricopre il nodo. Le ricette danno luogo a cambiamenti della
configurazione solo quando esso si trova fuori dalle specifiche . (Per esempio: una ricetta
che istalla un particolare servizio sarà eseguita solo se esso non esiste già sul nodo ). Le
informazioni del nodo sono mantenute sul server all’interno di una struttura dati che
prende il nome di Node Object, essa contiene le recipe e gli attributi. Questa struttura è
aggiornata dal client ogni volte che esso termina la sua esecuzione.
34
Chef utilizza un modello di configurazione convergente, in questo tipo di modelli i
cambiamenti sono propagati attraverso i nodi e la rete in modo che il sistema nel suo
complesso converga allo stato desiderato .
Tutte o quasi le informazioni contenute nel Server sono indicizzate per la ricerca, è
possibile quindi fare delle query per ottenere queste informazioni da diverse località per
esempio si possono utilizzare all'interno delle recipe. La combinazione di controlli
periodici di configurazioni con questo tipo di ricerca è uno strumento molto potente, per
capire meglio di cosa stiamo parlando farò un esempio. Ipotizziamo che chef sia istallato
su un load balancer, esso è configurato con un insieme d’indirizzi IP dei nodi su cui il
traffico deve essere bilanciato, possiamo immaginare che nelle recipe del load balancer ci
sarà un’istruzione del tipo: "ricerca tutti i server a cui bisogna inoltrare il carico " nel
momento in cui sarà disponibile un altro server di quella determinata tipologia sarà
aggiunto automaticamente alla configurazione del load balancer e quindi il nuovo server
potrà subito essere utilizzato.
Qualsiasi cosa possa essere eseguita sul nodo può essere gestita da Chef.
6.4 Cloud Management Chef è integrato con i
maggiori fornitori cloud.
Ci sono decine di plug-in
disponibili per tale scopo
. L’istanziazione della
risorsa è iniziata dalla
workstation, utilizzando
appunto il plug-in per
richiamare il servizio
web di acquisizione della
risorsa cloud. Dalla
postazione di lavoro di
un amministratore, si
configura il
provisioning delle
risorse cloud. Quando la nuova istanza è disponibile, si entra in contatto con il server Chef
e che scarica su di esso il client. La nuova istanza esegue le ricette di configurazione che il
Cloud Management ‐ Nel diagramma, l'amministratore ha richiesto una nuova istanza web in Amazon EC2. (39)
35
server gli invia. Per installare il client sul nodo, utilizziamo knife, essa mette a
disposizione il sottocomando bootstrap che ci aiuta in quest’attività, la sintassi da usare è
la seguente:
$ knife bootstrap FQDN_or_IP_ADDRESS (options)
E’ necessario specificare IP address o FQDN del sistema target tra le opzioni possiamo
trovare:
-x username -P password –sudo –Per specificare username e password
-r RUN_LIST, --run-list RUN_LIST –indicare l’elenco dei ruoli e le recipe da
applicare
Dopo che l’operazione di bootstrap è terminata, verificare che il nodo sia stato
riconosciuto dal server. Per questo è possibile utilizzare il comando:
$ knife client show name_of_node
Il server ritornerà qualcosa di simile:
admin: false chef_type: client json_class: Chef::ApiClient name: name_of_node public_key:
36
Capitolo 7: Ansible Tra i tool che abbiamo considerato, Ansible è quello più giovane, esso mira a essere
semplice e minimo in natura .
7.1 Agentless Ansible è una piattaforma agentless nel senso che sul nodo da gestire non è necessario
istallare un client Ansible, quando bisogna far eseguire delle operazioni al nodo, fornisce
al sistema remoto tutti i moduli necessari, il protocollo di comunicazione utilizzato è SSH
considerato come quello attualmente più sicuro. In questo modo si riesce a consumare il
minimo di risorse del nodo e inoltre non è necessario preoccuparsi della gestione di un
ipotetico client.
Affinché tutto possa funzionare sul nodo che bisogna gestire è necessario installare Python
(13) che comprenderà anche il necessario per supportare il protocollo SSH.
E’ possibile utilizzare Ansible per configurare sistemi, distribuire software e fare
operazioni di orchestrazione. Tutto ciò si ottiene grazie all’utilizzo dei moduli e dei
playbook, volendo fare un’analogia possiamo vedere i moduli come se fossero gli attrezzi
dell’officina e i playbook come dei piani di progetto.
7.2 Playbooks
Sono il linguaggio di configurazione, distribuzione e orchestrazione di Ansible. Essi
servono per descrivere le policy e dichiarare la configurazione che si vuole applicare sul
sistema remoto, essi sono utilizzati anche per descrivere le operazioni di orchestrazione.
I playbook si sviluppano in un linguaggio testo di base, sono espressi nel formato YAML
(14). Essi sono pensati per essere human-readable cioè facilmente leggibili, quindi si è
scelto di avere una sintassi minima che volutamente cerca di allontanare il linguaggio da
37
quelli di programmazione o di scripting e di avvicinarlo a un modello di configurazione o
di un processo.
Un playbook è composto di uno o più ‘play'. L’obiettivo di un gioco è di mappare un
gruppo di host a ruoli, che rappresentano le attività che Ansible dovrà eseguire per portare
il nodo nello stato desiderato.
Questo è un esempio di playbook, all’interno un solo play:
‐‐‐ ‐ hosts: webservers vars: http_port: 80 max_clients: 200 remote_user: root tasks: ‐ name: ensure apache is at the latest version yum: pkg=httpd state=latest ‐ name: write the apache config file template: src=/srv/httpd.j2 dest=/etc/httpd.conf notify: ‐ restart apache ‐ name: ensure apache is running service: name=httpd state=started handlers: ‐ name: restart apache service: name=httpd state=restarted
Per ogni play è necessario indicare l’host o il gruppo di host cui è riferito mentre con la
parola “task” si specifica le particolari attività che è necessario svolgere.
7.2.1 Task list Ogni play contiene una lista di attività. Le attività sono eseguite in ordine, su tutte le
macchine che corrispondono al pattern inserito.
Se un’attività fallisce, durante l’applicazione del playbook, il nodo smette di eseguire
l’intero playbook
Ogni attività deve avere un nome, che è inclusa nell’output dall’esecuzione del playbook.
Esso è utilizzato come output da mostrare a video per l’utente, in sua mancanza è usata la
stringa del campo action. In questo modo è possibile avere in output una descrizione
comprensibile delle azioni compiute.
Per applicare un playbook basta chiamare il comando ansible-playbook.
38
Schematizzando:
-Playbook è composto da play
-play è composto da attività
-le attività chiamano i rispettivi moduli
7.3 Moduli
Ansible mette a disposizione una serie di moduli, essi possono eseguire o tramite comandi
ad hoc o tramite i playbook .
Ogni modulo ritorna tecnicamente l’output in un formato JSON, essi possono essere
scritti in un qualsiasi linguaggio (15).
I moduli sono idem potenti questo significa che se si esegue più volte uno stesso modulo,
il risultato sarà sempre lo stesso, al fine di portare il sistema nello stato desiderato. In
questo modo è possibile eseguire più volte lo stesso playbook, con la certezza di non fare
danni .
Elencherò di seguito alcuni moduli, dividendoli secondo le funzionalità che mettono a
disposizione:
package management: yum , apt
remote execution : command ,shell
service management : service
file manager : copy , template
...
7.4 Inventory E’ un file scritto in formato INI-like (16) ed è utilizzato per dichiarare i nodi che vogliamo
gestire e per organizzarli in gruppi. Esso solitamente si trova nella directory / etc / ansible
/ hosts. E’ possibile configurarlo anche dinamicamente prelevando informazioni da altre
fonti. In esso possiamo anche associare delle variabili agli host che eventualmente
possono essere utilizzate nei playbook. Solitamente si preferisce non memorizzare le
variabili e i gruppi direttamente nell’inventory principale ini, ma memorizzarli in singoli
file scritti in formato YAML.
39
mail.example.com [webservers] foo.example.com bar.example.com [dbservers] badwolf.example.com:5309 two.example.com
Questo è un esempio d’inventario, tra parentesi ci sono i nomi dei gruppi, se si hanno host
che girano su porte SSH non standard è possibile inserire il numero della porta dopo il
nome host.
7.5 Pattern È utilizzato per indicare quali host bisogna gestire, solitamente il pattern è riferito a un set
di gruppi (a sua volta set di host) definiti nell’inventario, il pattern può essere utilizzato in
questo modo:
ansible <pattern_goes_here> ‐m <module_name> ‐a <arguments>
All e * indicano che ci si sta facendo riferimento a tutti gli host presenti nell’inventario.
Generalmente Ansible lavora con un’architettura push-model, in tal caso è il server che si
occupa di inviare le richieste di configurazione ai client. Volendo è possibile anche
utilizzare un’architettura pull-model nella quale sono stessi i nodi che fanno richieste di
configurazione a intervalli periodici.
Ansible-pull è un piccolo script che verifica le istruzione di configurazione su un
repository centrale e quindi prende i playbook e li esegue
40
Conclusioni
I tool dispongono di tutte le carte in regolaper essere considerati dei buoni strumenti a
supporto dell’automazione . Come si può notare Puppet e Chef risultano essere più
completi , questa mancanza in Ansible viene colmata però con l’elevato numero di moduli
che esso mette a disposizione . Ansible è il tool più giovane ma si sta velocemente
facendo spazio grazie all’elevata semplicità . Siccome non è possibile decretare "un
vincitore" assoluto ho pensato di elencare alcune caratteristiche dei tool in una tabella che
permette di avere un quadro generale sulle loro caratteristiche .
41
Orchestration Continuous
Delivery DevOps
Bare metal provisioning
Possibilità di incrementare funzionalità
Scalabile Gestire reti eterogenee
Sicura e Gestione Accessi
Principali società
Possibilità di incrementare funzionalità
Puppet
Live Management e
rcp subcommand (23) (18) (24)
X (9) X (25) Razor (26)
Utilizzando il linguaggio Puppet
per costruitre moduli (27) (18)
Achitettura distribuita - supporta sia
un’istallazione monolitica sia split (28) (29)
Supportano tutti molti SO , quello che ne supporta di
meno è Ansible
RBAC (30)
PayPal, Disney, Oracle,
Google (31)
Vmware , Google
Compute Engine , Openstack , and
Amazon EC2 (32) (33)
Chef X X (34) Razor (6) Utilizza il
linguaggio Ruby per aggiungere moduli
Architettura distribuita
Policy , Role
Facebook, Rackspace
(35)
Microsoft Azure , Aws , VMWare
, Google Compute Engine
, gesstione Containers
Ansible X X Clobber (36)
I moduli possono essere scritti in
qualsi linguaggio di programmazione
(15)
Architettura distribuita
NASA , Twitter,
(37)
Docker, AWS VMWare,
OpenStack, Eucalyptus
Cloud , KVM , and CloudStack
Massimo numero di nodi gestibili
con un solo server
Agentless Gui Curca di
apprendimento
Configuration Management , Change Management e Release Management
Configuration Items (CI)
CMDB Monitoraggio CI e
Adeguata documentazione
Sicurezza nella comunicazione
Configuration , change e release
management insieme
Puppet Piu di 2000 (17)
X
(18) Alta Resource PuppetDB
Tool Puppet Dashboard della Console e Event
Inspector (19) (18) SSL X
Chef 10000 (20)
X Alta Resource chefRepo e ChefServer
Chef Analystic coppia di chiavi publiche RSA
X
Ansible
X X
(21) Bassa (14) server Ansible Tower (21) SSH (22) X
42
Bibliografia 1. IT Infrastructure. [Online] http://www.techopedia.com/definition/29199/it-infrastructure. 2. Centro di elaborazione dati. [Online] http://it.wikipedia.org/wiki/Centro_elaborazione_dati. 3. Chef - Automation and Web Scale IT. 4. ITIL v3. [Online] http://www.itil-italia.com/itilv3.htm. 5. Configuration Management. [Online] http://www.itil-italia.com/itilconfigmanagement.htm. 6. Harnessing the Power of Bare Metal with Razor and Chef Server. Nichol, Fletcher. 2013. 7. Lex Parsimoniae : Cloud Provisioning with a Razor. [Online] http://nickapedia.com/2012/05/21/lex-parsimoniae-cloud-provisioning-with-a-razor/. 8. ContinuousDelivery-MartinFowler. [Online] http://martinfowler.com/bliki/ContinuousDelivery.html. 9. Continuous Delivery — What It Is and How to Get Started. Puppet. [Online] http://puppetlabs.com/solutions/continuous-delivery. 10. Puppet. White Paper:The Tools For Continuous Delivery. 11. Workstations. [Online] http://docs.chef.io/workstation.html. 12. Managing Containers with Chef. [Online] https://www.chef.io/solutions/docker/. 13. Installation. [Online] http://docs.ansible.com/intro_installation.html#basics-what-will-be-installed. 14. Playbook. [Online] http://docs.ansible.com/playbooks_intro.html. 15. About Modules. [Online] http://docs.ansible.com/modules.html. 16. Inventory. [Online] http://docs.ansible.com/intro_inventory.html. 17. System Requirements Puppet and Pre-Installation. [Online] https://docs.puppetlabs.com/pe/latest/install_system_requirements.html. 18. Navigating Live Management. [Online] https://docs.puppetlabs.com/pe/latest/console_navigating_live_mgm. 19. Using Event Inspecto. [Online] https://docs.puppetlabs.com/pe/latest/console_event-inspector.html. 20. How Chef works. [Online] https://www.chef.io/chef/. 21. MISSION CONTROL FOR ANSIBLE. [Online] http://www.ansible.com/tower. 22. Getting Started. [Online] http://docs.ansible.com/intro_getting_started.html. 23. Overview of Orchestration Topics. [Online] https://docs.puppetlabs.com/pe/latest/orchestration_overview.html. 24. Subcommands. [Online] https://docs.puppetlabs.com/pe/latest/orchestration_invoke_cli.html#subcommands. 25. From Dev vs. Ops to DevOps. [Online] http://puppetlabs.com/solutions/devops. 26. Next-Generation Provisioning. [Online] http://puppetlabs.com/solutions/next-generation-provisioning. 27. Puppet Modules. [Online] https://docs.puppetlabs.com/pe/latest/puppet_modules_manifests.html#puppet-modules.
43
28. Monolithic. [Online] https://docs.puppetlabs.com/pe/latest/install_pe_mono.html. 29. Split. [Online] https://docs.puppetlabs.com/pe/latest/install_pe_split. 30. Open Source Puppet, Puppet Enterprise and Puppet Apps. [Online] http://puppetlabs.com/puppet/enterprise-and-open-source. 31. Puppet (software). Wikipedia. [Online] http://en.wikipedia.org/wiki/Puppet_%28software%29. 32. Wikipedia. [Online] http://en.wikipedia.org/wiki/Puppet_%28software%29. 33. Cloud Management-Puppet. [Online] http://puppetlabs.com/solutions/cloud-management. 34. DevOps-Chef. [Online] https://www.chef.io/solutions/devops/. 35. Chef (software). Wikipedia. [Online] http://en.wikipedia.org/wiki/Chef_(software). 36. Dynamic Inventory. [Online] http://docs.ansible.com/intro_dynamic_inventory.html#example-the-cobbler-external-inventory-script. 37. New Case Study: NASA and Ansible Tower. [Online] http://www.ansible.com/blog/nasa-automation. 38. An Overview of Puppet. [Online] https://docs.puppetlabs.com/pe/latest/puppet_overview.html. 39. Cloud Management-Chef. [Online] https://www.chef.io/solutions/cloud-management/.
