Agileday2013 pratiche agili applicate all'infrastruttura

811 views

Published on

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.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
811
On SlideShare
0
From Embeds
0
Number of Embeds
169
Actions
Shares
0
Downloads
10
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Agileday2013 pratiche agili applicate all'infrastruttura

  1. 1. Pratiche Agili applicate all'Infrastruttura Marco Trincardi - @trink0 Giuseppe Leone - @joebew42
  2. 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. 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. 4. Il nostro primo progetto • Infrastruttura particolarmente complessa • Necessità di simulare una rete privata con due server
  5. 5. Le componenti in gioco? • Esigenza: • Creare ambiente per lo sviluppo • Replicare questo ambiente dal cliente
  6. 6. Grafo delle dipendenze dell'Infrastruttura
  7. 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. 8. Problemi comuni
  9. 9. Virtualizziamo? • Virtualizzare è stata la prima scelta • Non vogliamo sporcare il nostro computer
  10. 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. 11. Parliamone … !! Vediamo un po' se esistono metodi e tool che possono tornarci utili!
  12. 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. 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. 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. 15. Puppet http://www.puppetlabs.com È un software di automazione che ci consente di descrivere e gestire configurazioni molto dettagliate di infrastrutture.
  16. 16. Le nostre scelte • Perché questi strumenti? • Più vicini al nostro mondo Dev: Vagrant e Puppet sono Ruby!
  17. 17. Vagrant in action! Vagrantfile di esempio
  18. 18. Puppet in action! Puppet per installare e configurare Cube
  19. 19. Vagrant & Puppet in action Le configurazioni Vagrant e Puppet sono codice Ruby!
  20. 20. Vagrant & Puppet in action Le configurazioni Vagrant e Puppet sono codice Ruby! Quindi l'Infrastruttura è codice?
  21. 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. 22. Infrastruttura come codice! Cominciamo a capirci! Se possiamo descrivere una infrastruttura complessa tramite del codice, allora ...
  23. 23. Infrastruttura come codice! Possiamo usare un software per il controllo di versione e sfruttarne tutte le potenzialità.
  24. 24. Infrastruttura come codice! Possiamo seguire uno sviluppo incrementale.
  25. 25. Infrastruttura come codice! Possiamo applicare metodi di sviluppo Agili: Test Driven Development
  26. 26. Testing dell’infrastruttura Come facciamo il Testing dell'Infrastruttura?
  27. 27. Testing dell’infrastruttura Trial & Error
  28. 28. Testing dell’infrastruttura Dry run / No Op
  29. 29. Testing dell’infrastruttura Test automatici
  30. 30. Testing dell’infrastruttura Code standard compliant VS
  31. 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. 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. 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. 34. Ancora ... Fornire codice e NON costanti aggiornamenti di documentazione. spesso la documentazione non è fedele e può lasciare spazio a libere interpretazioni.
  35. 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. 36. Quali altri progetti? • Beancounter • Un grado di complessità più alto
  37. 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. 38. Quali altri progetti? • Hadoop • Test automatici • Code standard compliant
  39. 39. Infrastruttura come codice! Quali tool? • Rspec-Puppet • Come funziona? • Perché? • Multi environment • Regression test
  40. 40. Infrastruttura come codice! Quali tool? Ma se ho i test allora posso fare refactoring!
  41. 41. Infrastruttura come codice! Quali tool? Ma se ho i test allora posso fare refactoring! Vediamo un esempio...
  42. 42. Refactoring dell'Infrastruttura
  43. 43. Refactoring dell'Infrastruttura Ok, test “rossi”, facciamoli diventare verdi! Scriviamo codice!
  44. 44. Refactoring dell'Infrastruttura NODO DI ESEMPIO
  45. 45. Refactoring dell'Infrastruttura
  46. 46. Refactoring dell'Infrastruttura POSSIAMO ESTRARRE QUESTO CODICE!
  47. 47. Refactoring dell'Infrastruttura Abbiamo estratto il codice interessato in una risorsa definita coma “User::Complete”. Test!
  48. 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. 49. Refactoring dell'Infrastruttura
  50. 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. 51. Infrastruttura come codice! Quali tool? • Puppet-lint • Capire se il nostro codice è conforme agli standard • Come funziona?
  52. 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. 53. Finisce qui ... Happy Infrastructure Coding :)
  54. 54. … Extra Time! Extra Time! • Replicare un ambiente per piattaforma Diaspora* • Il progetto completo è su GitHub joebew42 • Demo pratica per chi è interessato!
  55. 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

×