Upload
xpeppers
View
464
Download
3
Embed Size (px)
DESCRIPTION
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.
Citation preview
Pratiche Agili applicate all'Infrastruttura
Marco Trincardi - @trink0Giuseppe Leone - @joebew42
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à
Di cosa parliamo
• Vi raccontiamo una nostra esperienza
• Casi reali
• DevOps: Unified Tooling
• Come ci siamo arrivati
• Conoscenza acquisita sul campo
• Un esempio pratico :)
Il nostro primo progetto
• Infrastruttura particolarmente complessa
• Necessità di simulare una rete privata con due server
Le componenti in gioco?
• Esigenza:
• Creare ambiente per lo sviluppo
• Replicare questo ambiente dal cliente
Grafo delle dipendenze dell'Infrastruttura
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...
Problemi comuni
Virtualizziamo?
• Virtualizzare è stata la prima scelta
• Non vogliamo sporcare il nostro computer
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!
Parliamone … !!
Vediamo un po' se esistono metodi e tool che possono tornarci utili!
DevOpsUnified 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!
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
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.
Puppet
http://www.puppetlabs.com
È un software di automazione che ci consente di descrivere e gestire configurazioni molto dettagliate di infrastrutture.
Le nostre scelte
• Perché questi strumenti?
• Più vicini al nostro mondo Dev:Vagrant e Puppet sono Ruby!
Vagrant in action!
Vagrantfile di esempio
Puppet in action!
Puppet per installare econfigurare Cube
Vagrant & Puppet in action
Le configurazioni Vagrant e Puppet sono codice Ruby!
Vagrant & Puppet in action
Le configurazioni Vagrant e Puppet sono codice Ruby!
Quindi l'Infrastruttura è codice?
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
Infrastruttura come codice!
Cominciamo a capirci!
Se possiamo descrivere una infrastruttura complessa tramite del
codice, allora ...
Infrastruttura come codice!
Possiamo usare un software per il controllo di versione e sfruttarne tutte le
potenzialità.
Infrastruttura come codice!
Possiamo seguire uno sviluppo incrementale.
Infrastruttura come codice!
Possiamo applicare metodi di sviluppo Agili:Test Driven Development
Testing dell’infrastruttura
Come facciamo il Testing dell'Infrastruttura?
Testing dell’infrastruttura
Trial & Error
Testing dell’infrastruttura
Dry run / No Op
Testing dell’infrastruttura
Test automatici
Testing dell’infrastruttura
Code standard compliant
VS
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.
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
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
Ancora ...
Fornire codice e NON costanti aggiornamenti di documentazione.
spesso la documentazione non è fedele e può lasciare spazio a libere
interpretazioni.
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)
Quali altri progetti?
• Beancounter
• Un grado di complessità più alto
Quali altri progetti?
• Qualcosa in più …
• Provision della VM su provider esterni:
• Amazon EC2 (automatico)
• Azure (manuale)
• Gestione di diversi stage
• Sviluppo
• Integration
• Produzione
Quali altri progetti?
• Hadoop
• Test automatici
• Code standard compliant
Infrastruttura come codice! Quali tool?
• Rspec-Puppet
• Come funziona?
• Perché?
• Multi environment
• Regression test
Infrastruttura come codice! Quali tool?
Ma se ho i test allora posso fare refactoring!
Infrastruttura come codice! Quali tool?
Ma se ho i test allora posso fare refactoring!
Vediamo un esempio...
Refactoring dell'Infrastruttura
Refactoringdell'Infrastruttura
Ok, test “rossi”, facciamoli diventare verdi! Scriviamo codice!
Refactoring dell'Infrastruttura
NODO DI ESEMPIO
Refactoring dell'Infrastruttura
Refactoring dell'Infrastruttura
POSSIAMO ESTRARRE QUESTOCODICE!
Refactoring dell'Infrastruttura
Abbiamo estratto il codice interessato in una risorsa definita coma “User::Complete”.
Test!
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.
Refactoring dell'Infrastruttura
Refactoringdell'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!
Infrastruttura come codice! Quali tool?
• Puppet-lint
• Capire se il nostro codice è conforme agli standard
• Come funziona?
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! :)
Finisce qui ...
Happy Infrastructure Coding :)
… Extra Time!
Extra Time!
• Replicare un ambiente per piattaforma Diaspora*
• Il progetto completo è su GitHub joebew42
• Demo pratica per chi è interessato!
Grazie...Sì, abbiamo finito!
• Website www.xpeppers.com
• E-Mail [email protected]
• Twitter @xpeppers, @trink0, @joebew42
• Sede Via Oss Mazzurana 45,
• Tel 0461 1823400