Gestire l’infrastruttura come se fosse codice, ha degli indubbi vantaggi, soprattutto in un team agile che ha più esperienze Dev piuttosto che Ops. In questa sessione vi racconteremo la nostra esperienza, problemi, vantaggi e cosa abbiamo imparato. Lo unified tooling è l’area di interesse DevOps che fonde pratiche di software development a quelle di system administration, con lo scopo di semplificare il processo di deployment di ambienti complessi. In questo talk vengono esposte le esperienze di un team di dev che è riuscito a gestire e replicare ambienti complessi, ricorrendo a strumenti e pratiche delle metodologie agili. Saranno evidenziati i vantaggi ottenuti e le problematiche riscontrate.

1. Pratiche Agili applicate all'Infrastruttura
Marco Trincardi - @trink0
Giuseppe Leone - @joebew42

2. La nostra esperienza ...
• L'adozione di pratiche DevOps nasce
dalla necessità di poter creare, gestire,
condividere e replicare configurazioni di
ambienti complessi
• Circa nove mesi di esperienza su progetti
con diversi gradi di complessità

3. Di cosa parliamo
• Vi raccontiamo una nostra esperienza
• Casi reali
• DevOps: Unified Tooling
• Come ci siamo arrivati
• Conoscenza acquisita sul campo
• Un esempio pratico :)

4. Il nostro primo progetto
• Infrastruttura particolarmente complessa
• Necessità di simulare una rete privata
con due server

5. Le componenti in gioco?
• Esigenza:
• Creare ambiente per lo sviluppo
• Replicare questo ambiente dal cliente

6. Grafo delle dipendenze
dell'Infrastruttura

7. Problemi comuni
• Gestire tutte le dipendenze
• Perdersi in configurazioni complesse
• Sporcare l'ambiente con componenti non
più necessarie
• Non riuscire più a riprodurre fedelmente
l'ambiente
• Figuriamoci per un Dev...

8. Problemi comuni

9. Virtualizziamo?
• Virtualizzare è stata la prima scelta
• Non vogliamo sporcare il nostro
computer

10. Virtualizzare non basta
• Condividiamo le VM tra sviluppatori?
• Mantengo snapshot di VM stabili e poi
continuo a provare nuove configurazioni?
• E se poi vogliamo fare il deploy?
• Troppo meccanico
• Troppo costoso
• Non funziona!

11. Parliamone … !!
Vediamo un po' se esistono metodi e tool
che possono tornarci utili!

12. DevOps
Unified tooling
• Replicabilità, distribuzione e
manutenibilità di ambienti complessi
• Gestione di più ambienti di deploy
• Codice per Documentazione
• Sviluppo incrementale
• Dev e Ops finalmente riescono a capirsi!

13. Quali tool utilizzabili?
• Software Configuration Management
• Git, SVN, Mercurial, etc ...
• Deeply Modeled-System
• Puppet, Chef, Salt Stack, etc ...
• Automation of repetitive tasks
• Vagrant
• Capistrano, Fabric, ...
• Maven

14. Vagrant
http://www.vagrantup.com
È una interfaccia per diversi provider di
Virtual Machine: VirtualBox, Amazon EC2,
digitalOcean e altri.
Vagrant esegue le VM su diversi provider e
fornisce i primi parametri di configurazione.

15. Puppet
http://www.puppetlabs.com
È un software di automazione che ci consente
di descrivere e gestire configurazioni molto
dettagliate di infrastrutture.

16. Le nostre scelte
• Perché questi strumenti?
• Più vicini al nostro mondo Dev:
Vagrant e Puppet sono Ruby!

17. Vagrant in action!
Vagrantfile di esempio

18. Puppet in action!
Puppet per installare e
configurare Cube

19. Vagrant & Puppet in action
Le configurazioni Vagrant e Puppet sono
codice Ruby!

20. Vagrant & Puppet in action
Le configurazioni Vagrant e Puppet sono
codice Ruby!
Quindi l'Infrastruttura è codice?

21. Infrastruttura come
codice?
• Come sviluppatori siamo abituati a
gestire diverse dipendenze tra
componenti software (classi, package e
librerie)
• Ma anche le infrastrutture hanno delle
dipendenze!
• File e Directory
• Utenti
• Software e loro configurazione

22. Infrastruttura come
codice!
Cominciamo a capirci!
Se possiamo descrivere una
infrastruttura complessa tramite del
codice, allora ...

23. Infrastruttura come
codice!
Possiamo usare un software per il
controllo di versione e sfruttarne tutte le
potenzialità.

24. Infrastruttura come
codice!
Possiamo seguire uno sviluppo incrementale.

25. Infrastruttura come
codice!
Possiamo applicare metodi di sviluppo Agili:
Test Driven Development

26. Testing dell’infrastruttura
Come facciamo il Testing dell'Infrastruttura?

27. Testing dell’infrastruttura
Trial & Error

28. Testing dell’infrastruttura
Dry run / No Op

29. Testing dell’infrastruttura
Test automatici

30. Testing dell’infrastruttura
Code standard compliant
VS

31. Ancora poca esperienza
Testing dell'Infrastruttra solo con
“Trial & Error” e “Dry run”
• È come fare test manuali del software:
funziona ma porta via molto tempo.
• Il test copre l'intero setup della
configurazione piuttosto che le singole
componenti.

32. Vantaggi per lo sviluppo
• Possibilità di distruggere e ricreare
l'ambiente quando vogliamo
• A seguito di una prova o di un deploy, ho
compromesso l'ambiente
• Impiego meno tempo a buttar via tutto e
ricaricare da zero l'ambiente, piuttosto
che cercare di risolvere manualmente I
conflitti

33. Risultati ottenuti
• Documentazione della configurazione
dell'ambiente come codice
• Sviluppo incrementale dell'infrastruttura
• Destroy e Reload dell'infrastruttura a
costo zero.
• Alta manutenibilità dell'infrastruttura
• Replicabilità dell'Infrastruttura dal cliente

34. Ancora ...
Fornire codice e NON costanti
aggiornamenti di documentazione.
spesso la documentazione non è fedele e
può lasciare spazio a libere
interpretazioni.

35. Ma il nostro software?
Siamo Agili!
Deploy automatico con Capistrano
• Setup database
• Deploy di applicazioni Rails
• Deploy di servizi e gestione degli stessi
(start, stop, restart)

36. Quali altri progetti?
• Beancounter
• Un grado di complessità più alto

37. Quali altri progetti?
• Qualcosa in più …
• Provision della VM su provider esterni:
• Amazon EC2 (automatico)
• Azure (manuale)
• Gestione di diversi stage
• Sviluppo
• Integration
• Produzione

38. Quali altri progetti?
• Hadoop
• Test automatici
• Code standard compliant

39. Infrastruttura come
codice! Quali tool?
• Rspec-Puppet
• Come funziona?
• Perché?
• Multi environment
• Regression test

40. Infrastruttura come
codice! Quali tool?
Ma se ho i test allora posso fare refactoring!

41. Infrastruttura come
codice! Quali tool?
Ma se ho i test allora posso fare refactoring!
Vediamo un esempio...

42. Refactoring
dell'Infrastruttura

43. Refactoring
dell'Infrastruttura
Ok, test “rossi”, facciamoli diventare verdi!
Scriviamo codice!

44. Refactoring
dell'Infrastruttura
NODO DI
ESEMPIO

45. Refactoring
dell'Infrastruttura

46. Refactoring
dell'Infrastruttura
POSSIAMO
ESTRARRE
QUESTO
CODICE!

47. Refactoring
dell'Infrastruttura
Abbiamo estratto il codice interessato in una
risorsa definita coma “User::Complete”.
Test!

48. Refactoring
dell'Infrastruttura
AGGIUNGIAMO
UN NUOVO TEST
PER IL NODO
EXAMPLE.
DICIAMO CHE
DEVE
CONTENERE UNA
RISORSA DI TIPO
USER::COMPLETE
TUTTI I VECCHI
TEST NON
SERVONO PIÙ!
BUTTIAMOLI VIA.

49. Refactoring
dell'Infrastruttura

50. Refactoring
dell'Infrastruttura
• I test che avete visto non sono corretti
• Non ha senso testare la presenza di risorse
che sono definite in modo espilicito nel
puppet
• È utile ricorrere ai test solo se abbiamo
delle strutture condizionali all'interno dei
puppet
• È utile ricorrere ai test nei casi di regression
test: aggiungiamo nuove feature
• I test che avete visto sono solo degli
esempi!

51. Infrastruttura come
codice! Quali tool?
• Puppet-lint
• Capire se il nostro codice è conforme
agli standard
• Come funziona?

52. Cosa abbiamo capito?
La nostra esperienza termina qui, per ora!
Ma cosa abbiamo capito da quello che
abbiamo fatto?
Siamo riusciti a trattare problematiche del
mondo operational con un metodo a noi
familiare.
Dev e Ops non sono poi così distanti! :)

53. Finisce qui ...
Happy Infrastructure Coding :)

54. … Extra Time!
Extra Time!
• Replicare un ambiente per piattaforma
Diaspora*
• Il progetto completo è su GitHub
joebew42
• Demo pratica per chi è interessato!

55. Grazie...
Sì, abbiamo finito!
• Website www.xpeppers.com
• E-Mail info@xpeppers.com
• Twitter @xpeppers, @trink0, @joebew42
• Sede Via Oss Mazzurana 45,
• Tel 0461 1823400