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.
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
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...
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!
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!
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.
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
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)
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
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!
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! :)
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