Slide del workshop tenuto in SMAU Napoli il 14 Dicembre Contiene una introduzione operativa a Puppet

1. +
Infrastructure as Code
nuovi strumenti per i DevOps
Ing Pietro Ciotola
Napoli, 14 Dicembre 2017

2. About me
n Ingegnere Informatico, Master MBA ICT
n 25 anni di esperienza in ambito IT
n Trainer ufficiale e Consulente VMware [VCI]
n VMware VCIX6-DCV Implementation Expert
n Founder e CEO di Enjinia [http://enjinia.it]

3. Di cosa parleremo
n Evoluzione dei Datacenter
n La Virtualizzazione
n Il Cloud ed IAAS
n SysAdmin e DevOps
n Infrastructure as Code
n Puppet

4. I datacenter
n Storicamente localizzati in azienda in apposite stanze [CED].
n Strutturati secondo un criterio “fisico” di corrispondenza tra Software ,
Servizi ed Hardware.

5. La virtualizzazione
n La sfida, della virtualizzazione è stata quella
di portare nel mondo x86 concetti e best
practices che fino a poco prima erano proprie
del mondo host/mainframe.
n Grazie ad un sistema operativo (Hypervisor) è
possibile consolidare più sistemi operativi
(Guest) anche di tipo diverso su un solo
hardware.

6. Vantaggi della virtualizzazione
n Ciclo di vita del software non più legato al ciclo di vita hardware.
n Miglior utilizzo delle risorse hardware, la piattaforma condivisa
permette di riciclare la potenza di calcolo non utilizzata.
n Aumento della business continuity.
n Sistemi di controllo centralizzato e di replica in disaster recovery
facilmente realizzabili.

7. Gestire I problemi
n Garantire uno SLA adeguato al business.
n Il sistema Hypervisor va gestito e rappresenta un potenziale point of
fail dell’impianto.
n Massimizzare la consistenza e la disponibilità dei dati e dei serivizi.
n Gestire la scalabilità veloce dei sistemi al fine di adattare la struttura
a richieste improvvise di carico utente.

8. Il Cloud
n La risposta alle problematiche precedenti è l’adozione di sistemi in
CLOUD.
n Facilità estrema nello startup.
n Flessibilità elevata nella generazione di nuove Virtual Machines e
nella scalatura dei servizi in caso di picchi di carico.
n Connettività dei servizi elevatissima.
n SLA garantiti e dati replicati su più siti per massimizzarne la
disponibilità.
n Grazie al CLOUD l’infrastruttura fisica diventa un servizio [IAAS].

9. Infrastructure as a Service
n IAAS – Infrastructure as a Service
n La mia infrastruttura non è più localizzata in azienda ma è acquistata
on demand da un fornitore esterno, che mi garantisce SLA , backup
e consistenza dei dati.
n Non devo più pianificare e prevedere la crescita futura dei miei servizi
ma posso reagire in maniera veloce ai carichi anche random.
n Non ho costi di startup o costi di dismissione, la mia intera
infrastruttura è un servizio che posso far partire e dismettere quando
voglio a fronte di un canone.

10. SysAdmin e DevOps
n DevOps NON è una figura professionale
n E’ un metodo di lavoro che permette di
controllare ed automatizzare l’intero ciclo
produttivo attraverso l’utilizzo di strumenti
come ad esempio:
n Script per il deployment automatico di
nuove VM.
n Sistemi di analisi automatica dei log ed
alert.
n Automatismi per massimizzare la
continuità del servizio e la robustezza e
la compliance dell’impianto.

11. DevOps
DevOps (a clipped compound of
"development" and "operations") is a
software engineering culture and
practice that aims at unifying
software development (Dev) and
software operation (Ops).
“DevOps is a set of practices
intended to reduce the time between
committing a change to a system
and the change being placed into
normal production, while ensuring
high quality” Bass, Weber, and Zhu (2009)
[Fonte Wikipedia]

12. DevOps ToolChain
Alla base della pratica DevOps c’è il concetto di ToolChain: bisogna
costruire la propria “scatola degli attrezzi” in riferimento ai seguenti
ambiti:
Coding
Continuous Integration
Continuous Testing
Package Staging and Deployment
Change management
Configuration [Infrastructure as Code ]
Application Monitoring

13. Infrastructure as Code
n Infrastructure as code (IaC) is the process
of managing and provisioning
computer data centers through machine-
readable definition files, rather than physical
hardware configuration or interactive
configuration tools.
n The IT infrastructure meant by this
comprises both physical equipment such
as bare-metal servers as well as virtual
machines and associated configuration
resources. The definitions may be in
a version control system.

14. Valore aggiunto e vantaggi di IaC
n Ottimizzazione dei costi – IaC permette di eliminare la componente
manuale del deployment, riducendo il numero di persone necessarie al
completamento dei task .
n Maggiore velocità di deploy – IaC permette di effettuare velocemente il
deployment di macchine identiche ad altre già definite in precedenza.
n Riduzione dei rischi – separare la definizione delle best practices e
delle caratterisitiche”fisiche” dalla fase di deployment riduce i rischi
derivanti da errate configurazioni sia per eventuali malfunzionamenti che
per problemi di sicurezza.
n Controllo di consistenza – IaC permette di controllare e nel caso
forzare la compliance della configurazione di una macchina con uno
standard ben definito.

15. Il metodo utilizzato
n I componenti di una struttura IaC sono tre:
n Server di deploy configurazione
n I file di descrizione della configurazione
n Le macchine client da configurare.
n Tra i software presenti sul mercato abbiamo scelto di illustrare:

16. Let’s Start !

17. Puppet
n Puppet is an open-source software configuration management tool. It
runs on many Unix-like systems as well as on Microsoft Windows,
and includes its own declarative language to describe system
configuration.
n Puppet is produced by Puppet, founded by Luke Kanies in 2005. It is
written in C++ & Clojure and released as free software under
the GNU General Public License (GPL) until version 2.7.0 and
the Apache License 2.0 after that.
n Ultima release stabile del 19 Luglio 2017

18. Architettura
n Puppet ha un’architettura client-server:
n Puppet Master – il server su cui verranno agganciati i client, licenziati
gli agent e creati I file di configurazione
n Puppet Client – le macchine configurate e gestite tramite il puppet
server
n Altri concetti chiave che vedremo sono:
n Manifest – file di descrizione della configurazione.In essi ci sono i
riferimenti ai module. [Puppet Server]
n Agent – software installato sui client che permette loro di collegarsi al
server ed accedere ai manifest. [Puppet Client]
n Module – blocchi di codice platform indipendent usati nella creazione
degli automatismi di deployment. [Puppet Server]

19. Il POD utilizzato
n Puppet Master server – Ubuntu Linux 14LTS , nome
puppet.nyc3.example.com
n Client 1 – Ubuntu Linux 14LTS, nome host1.nyc3.example.com, con
agent già installato e certificato approvato. OpenSSH attivo.
n Client 2 – Ubuntu Linux 14LTS, nome host2.nyc3.example.com, ,
con agent già installato e certificato NON approvato. OpenSSH attivo.
n DNS Server – Windows 2003, nome ns01.nyc3.example.com
Tutte le macchine hanno un FQDN risolvibile via DNS (requisito
obbligatorio).

20. Puppet Agent
n Deve essere installato su tutte le macchine da governare.
n Esistono agent per Windows, Linux, MacOS oppure è possibile
compilarli.
n nel nostro scenario Ubuntu, aggiungere i repo puppet ad apt e poi
procedere :
n wget https://apt.puppetlabs.com/puppetlabs-release-pc1-
trusty.deb
n dpkg -i puppetlabs-release-pc1-trusty.deb
n apt-get update
n apt-get install puppet-agent

21. Il Certificato
n Una volta installato l’agent si fa partire col comando seguente:
n /opt/puppetlabs/bin/puppet resource service puppet
ensure=running enable=true
n Il comando assicurerà la ripartenza dell’agent al riavvio della
macchina e resterà in ascolto delle direttive provenienti dal server
n Se è la prima volta che viene eseguito l’agent , verrà generata e
sottomessa al server Puppet Master una Certificate Request per la
gestione dell’autenticazione Client Server

22. Lista Client
n Dal server Puppet Master è possibile visualizzare le richieste di certificato
ed i certificati approvati.
n Ogni certificatoapprovato rappresenta un client da gestire.
n Il comandi da eseguire sono:
n puppet cert list
n Output: la lista dei certificati da approvare
n puppet cert list –all
n Output: la lista anche dei certificati approvati
n puppet cert sign [fqdn host]
n Output: l’approvazione del certificato e l’inizio della gestione
client

23. Esempio di output
n puppet cert list –all
"host2.nyc3.example.com" (SHA256)
4E:0F:96:97:37:52:BD:01:83:5C:47:7E:FD:DA:34:05:5E:9B:93:98:FE:F1:F6:71:F2:B2:64:58:24:F6:59:78
+ "host1.nyc3.example.com" (SHA256)
25:C9:1F:EE:69:D7:B5:F0:33:28:AA:52:31:17:D3:27:44:05:64:91:BF:97:C9:75:7B:1B:94:88:48:C9:5E:83
+ "puppet.nyc3.example.com" (SHA256)
84:29:47:B7:1D:61:4A:02:08:A7:3E:69:71:E1:A5:6C:07:BE:19:3D:E5:96:99:98:F3:D2:02:16:37:34:72:37
(alt names: "DNS:puppet", "DNS:puppet.nyc3.example.com")
n da notare che i certificati approvati hanno un simbolo “+”

24. Facter command
n L’agent in esecuzione non ha solo il compito di contattare il server
Puppet Master, ma osserva continuamente la macchina su cui è in
esecuzione e raccoglie informazioni.
n Per visualizzarle si usa il comando facter seguito da nulla o dal sotto
sistema che si vuole visualizzare.Esempi:
n facter networking
n Output: i paramentri network della macchina
n facter
n Output: tutti I parametri della macchina (si consiglia un |
more).

25. Main Manifest
n I manifest sono i file “descrittori della configurazione”
n Di default i main maifest risiedono nella directory del Puppet Server:
n /etc/puppetlabs/code/environments/production/manifests/
n Il Puppet Agent periodicamente contatta il Puppet Server (ogni 30 minuti
di default)
n Quando raggiunge il Puppet Server gli spedisce i propri “facts” e scarica
dal master il catalogo delle risorsee delle configurazioni presenti nei
Manifest che lo riguardano
n E’ possibile forzare il cliclo eseguendo il seguente comando:
n puppet agent --test

26. Manifest esempio
n I manifest hanno estensione .pp, consideriamo un esempio:
file {'/tmp/example-ip':
ensure => present,
mode => '0644',
content => "Here is my Public IP Address: ${ipaddress_eth0}.n",
}
n In questo esempio sto creando un file chiamato “example-ip” nella tmp dei client.
Mi assicuro della sua essitenza, settoipermessi, e dentro ci scrivo l’ip address del
client prendendolo dalla variabile ipaddress_eth0 che trovo definita come fact
nell’output di facter.

27. Module
n I module i mattoni su cui si fonda Puppet.
n Identificano le classi ed in tipi utilizzabili in Puppet
n Devono esser presenti sul Puppet Server
n Possono essere importati
n Possono essere programmati ex novo
n Vengono richiamati nei manifest

28. Operazioni sui Module
n Per ricercare un module pubblicato in un repository si utilizza il
comando:
n puppet module search [argument]
dove argument è l’argomento da ricercare, ad esempio PHP, Apache
etc.
n Per installare un module si utilizza il seguente comando:
n puppet module install [nome modulo]
n Esempio: puppet module install puppetlabs-apache
n Una volta importato il module si può richiamare nel manifest e si può
procedere a scriverne la configurazione per I client.

29. Esempio
n Validare la certificate request di host2
n Creare un manifest che installi sugli host del nostro laboratorio
Apache2.
n Forzare l’applicazione del manifest dai client
n Verificare l’installazione di apache sui client puppet.

30. Procedimento
n Dal Puppet Server verificare le cert reqs
n puppet cert list
n Validare la req di host2
n puppet cert sign host2.nyc3.example.com
n Scrivere il manifest di installazione Apache2
n Forzare il refresh delle config dai client
n puppet agent --test

31. Manifest di Apache2
node ‘host1’, 'host2' {
class { 'apache': } # importa il modulo installato prima
apache::vhost { 'example.com':
port => '80',
docroot => '/var/www/html'
} #è la config che avrà apache2
}

32. Risorse
n Documentazione ufficiale Puppet
https://puppet.com/docs
n Puppet 5 Beginner's Guide - Third
Edition. ISBN-10: 178847290X
n Sito Enjinia http://enjinia.it
n DevOps group Linkedin

33. Contatti
Pietro Ciotola
e-mail: pietro@enjinia.it
linkedin: https://www.linkedin.com/in/pietrociotola/
twitter: enjinia_na