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 info@xpeppers.com

• Twitter @xpeppers, @trink0, @joebew42

• Sede Via Oss Mazzurana 45,

• Tel 0461 1823400