Recommended
Recommended
More Related Content
Similar to DevOps Italian Tech Week 26/06/2019
Similar to DevOps Italian Tech Week 26/06/2019 (20)
Recently uploaded
Recently uploaded (20)
DevOps Italian Tech Week 26/06/2019
- 1. DevOps The dark side of the force 26 June 2019
- 2. About Me~$ whois fabio.todaro Italian Tech Week ovalmoney.com
- 3. Italian Tech Week ovalmoney.com ● 3 years R&D interactive technologies B2B ○ Embedded systems (Arduino, OpenCV) ○ 3D Interactive systems (Kinect, Unity3D) ○ Web interactive systems (E-Learning) ● 6 years Web Developer ○ Backend (PHP, NodeJS, Python) ○ Frontend (JS) ● 4 years in IT Operations e DevOps ○ No spoiler :) ● Love cars and working on car engines
- 4. Why and What is DevOps?~$ which DevOps ovalmoney.comItalian Tech Week
- 5. Let’s take a step back ~$ cd .. Italian Tech Week ovalmoney.com
- 6. Italian Tech Week ovalmoney.com ● Waterfall approach ● Bare metal servers or VPS ● Code stored on NAS ● Deploy once in a while IT Operations And Development
- 7. ovalmoney.comovalmoney.com Then AGILE and Cloud were born
- 8. Italian Tech Week ovalmoney.com AGILE Requirements ● Continuous Releases ● Easily Test and Debug Code changes
- 9. Italian Tech Week ovalmoney.com ● Distributed systems ○ High Availability ○ Microservices ○ Scaling Replicable systems Cloud Requirements and Consequences
- 10. DevOps to the rescue~$ systemctl start DevOps Italian Tech Week ovalmoney.com
- 11. Italian Tech Week ovalmoney.com ● Improved deployment frequency ● Faster time to market ● Lower failure rate of new releases ● Shortened lead time between fixes ● Faster MTTR DevOps Goals
- 12. CI/CD Italian Tech Week ovalmoney.com
- 13. GIT Italian Tech Week ovalmoney.com
- 14. Italian Tech Week ovalmoney.com CI/CD
- 16. IaC Italian Tech Week ovalmoney.com
- 18. Italian Tech Week ovalmoney.com Containers Orchestration
- 19. Monitoring and Logging~$ tail -f /var/log/system.log Italian Tech Week ovalmoney.com
- 20. Italian Tech Week ovalmoney.com Logging
- 22. To be continued... ~$ more ./DevOps.txt Italian Tech Week ovalmoney.com
- 23. Questions?~$ yes(y) | no(n) > Italian Tech Week ovalmoney.com
- 24. Italian Tech Week ovalmoney.com
- 25. Thank you~$ sudo shutdown -h now Italian Tech Week ovalmoney.com
Editor's Notes
- Chi sono
- Ho passato professionale abbastanza eterogeneo, ho lavorato come R&D di sistemi interattivi B2B per poi passare al mondo web e avvicinarmi sempre di più alla gestione delle operations IT. Questa esperienza mi ha permesso di capire che c’era molto margine per ottimizzare i processi di sviluppo di un software.
- Penso che uno dei modi migliori per apprendere un concetto o una soluzione sia comprenderne le motivazioni alla base, quindi prima di tutto le domande che dobbiamo porci sono: Perchè è nata la figura del DevOps? E poi Cosa si intende quando si parla di DevOps?
- Per spiegare il perchè sia nata questa figura dobbiamo fare un passo indietro e analizzare come lo sviluppo software sia evoluto nel tempo.
- Semplificando ai fini narrativi possiamo dire che: Un tempo lo sviluppo di un software era principalmente strutturato in waterfall, (sapete cosè waterfall?) un ciclo di sviluppo testing e deploy unico e molto lungo. I server su cui ospitare il software erano Bare metal o VPS spesso configurati a mano. Il codice molte volte salvato su NAS o comunque su supporti senza alcun tipo di versionamento. Il deploy, essendo un evento unico proprio per come funziona l’approccio waterall, veniva spesso gestito manualmente da team congiunti di Dev e Operations.
- Fino alla nascita e l’adozione sempre maggiore di un nuovo approccio allo sviluppo: l’AGILE e di un nuovo paradigma nella gestione dei server: il Cloud. E gli equilibri fino ad allora mantenuti vengono stati stravolti.
- Vengono stravolti perchè: L’introduzione di AGILE essendo basato su rapide iterazioni del ciclo di sviluppo porta i team a dover fare deploy continui del prodotto con tutto ciò che ne consegue. Si crea la necessità di fare test, build e deploy molto più spesso e quindi di poter debuggare in modo rapido il software in sviluppo.
- La nascita del Cloud Computing invece offre grosse opportunità, poichè nonostante sia semplicemente il server di qualcun’altro, segna la svolta grazie ad una serie di piccole ma fondamentali differenze: la possibilità di gestire la fatturazione a livello orario, l’automazione dell’avvio di istanze o il loro scaling orizzontale e verticale con un semplice cambio di configurazione. Questa semplicità nell’avvio di istanze (che altro non sono che server virtuali situati in un cluster) da vita allo sviluppo di sistemi distribuiti che permettono l’implementazione di HA, Microservices, Scaling ma tutto questo richiede a chi gestisce questi sistemi di poter replicare in modo automatizzato l’infrastruttura.
- Tutte queste necessità hanno reso evidente da un lato il gap presente tra i developers e le operations e dall’altro la nascita di un’area che richiede competenze che non spettano ne agli uni ne agli altri. Per sopperire a questa mancanza serviva una figura che fosse l’anello di giunzione tra lo sviluppo e il deploy del software. Una figura che sapesse scrivere codice al fine di automatizzare l’intero workflow e non solo...
- Un DevOps punta a massimizzare la predicibilità, l’efficienza, la sicurezza e la manutenibilità dei processi operativi. Un DevOps è guidato dalla ricerca continua della massima efficienza nel processo produttivo sia essa legata ad esempio ai tempi di rilascio, ai tempi necessari a ripristinare un sistema completamente down o alla sicurezza. Quando un DevOps osserva un qualsiasi processo il suo primo pensiero è come poterlo automatizzare e se già lo fosse allora diventa come poterlo ottimizzare. Esempio della macchinetta del caffè. Quindi fondamentalmente i DevOps non sono altro che degli individui molto pigri con le capacità necessarie a sviluppare sistemi che gli permettano di non lavorare. Passiamo a vedere nel concreto le tecnologie che usiamo in Oval per affrontare queste sfide, mi limiterò a dare una breve descrizione e delle buzzwords affinchè possiate poi approfondire.
- Per iniziare vediamo come si può applicare automazione al processo di test, build e deploy per velocizzare le release e ridurre quindi il time to market. Andiamo vedere in cosa consiste strutturare delle pipeline di CI/CD.
- Git per chi non lo sapesse è un sistema di SCM, permette di versionare il codice, tenere traccia di ogni sua modifica e collaborare in modo efficiente alla stessa code base. Nell’immagine in particolare vediamo un processo definito Git-Flow Possiamo considerarlo alla base di quasi tutti i processi di Continuous Integration
- La Continuous integration consiste nell’eseguire una serie di operazioni automatizzate che permettono di compilare e testare il codice ad ogni modifica della code base. La Continuous Delivery consiste nel evolvere ulteriormente il concetto di CI automatizzando anche la parte di deploy del codice nei vari ambienti.
- Qui abbiamo degli esempi reali di alcune delle nostre pipeline su Gitlab. In basso la nuova pipeline legata al core del backend di oval dove compiliamo l’immagine Docker dell’applicativo, eseguiamo il testing, in caso di esito positivo generiamo la documentazione e facciamo l’upload di queste immagini su uno storage remoto per poi effettuare il deploy sulle macchine nei vari ambienti. In alto invece una delle pipeline legate alla repository dell’applicazione mobile, dove eseguiamo prima unit testing, in seguito compiliamo le due applicazioni (iOS e Android) oltre che ai test end2end per poi successivamente eseguirli.
- Ora vediamo invece come evolve l’infrastruttura e diventa Infrastructure as code.
- Uno degli approcci è la gestione dell’applicativo in modo containerizzato. I container permettono di eseguire la nostra applicazione in un contesto isolato ma a differenza di una virtual machine riutilizzano buona parte delle risorse del sistema operativo sottostante senza generare l’overhead di un intero sistema operativo guest. Questo garantisce riproducibilità e risolve il problema del “it works on my machine” in quanto all’interno del container vengono definite tutte le dipendenze necessarie all’applicativo per funzionare. Questo è un esempio di Dockerfile, il sistema tramite il quale con docker si definiscono le immagini che poi verrano usate per lanciare i nostri container. In questo caso come potete vedere viene copiata l’applicazione e installata in modo che sia pronta da utilizzare all’avvio del container.
- L’introduzione dei container ha sicuramente risolto molti problemi ma ha creato la necessità di gestire l’orchestrazione degli stessi sui server. Esistono diverse tecnologie create a tal scopo, in Oval utilizziamo kubernetes, un orchestratore di container creato da Google e donato alla CNCF (cloud native computing foundation) Anche kubernetes funziona tramite la definizione di configurazioni che in questo caso rappresentano lo stato desiderato del cluster.
- Passiamo ora alla gestione del Logging e del Monitoring su un’architettura distribuita
- In Oval usiamo uno stack chiamato ELK per la gestione del logging. Si basa sull’uso di un daemon sui singoli nodi kubernetes chiamato filebeat che permette di fare la collection di tutti i log dei container docker in esecuzione su quel nodo. I log vengono poi inviati a logstash che si occupa di processarli uniformarli e archiviarli su elastcsearch. Kibana invece è una webapp utile a fare analisi e visualizzazione dei record presenti su elasticsearch.
- Il monitoring invece viene gestito tramite Prometheus un sistema di collection e query delle metriche oltre che di alerting in grado di funzionare con sistemi estremamente eterogenei. La visualizzazione di queste metriche avviene tramite Grafana che permette di visualizzare qualsiasi metrica tramite specifici linguaggi di query.
- Questi sono solo alcuni aspetti del ruolo di un DevOps e dell’evoluzione dell’industria del software quindi vi invito ad essere sempre curiosi e a fare ricerche.