Google cloud: Big Data + docker = kubernetes
•Download as PPTX, PDF•
2 likes•971 views
Immaginiamo un modo diverso di concepire la struttura di un pacchetto software che ci consenta di spaziare tra affidabilità e scalabilità. Sulla costruzione ci affidiamo alle risorse infinite di un PublicCloud, di cui monitorare i costi infrastrutturali per evitare di scendere sotto il break even point nel rapporto Costi/Ricavi. Pensare il software come una nuvola di processi staccati che colloquiano tra loro, ci da maggiore flessibilità (la singola ape è sacrificabile e sostituibile nel contesto dello sciame), mentre il concetto di Alveare come concentrazione dei dati raccolti/elaborati, ci permette di semplificare e gestire meglio il problema CONSISTENZA. Avremo così agenti semplici e rimpiazzabili in modo automatico che TRASPORTANO dati dall’acquisizione allo storage (Alveare), in cui, altri moduli manipoleranno e gestiranno il Miele. Abbiamo trasformato il problema da: gestiamo pochi oggetti complessi (VM) in gestiamo tantissimi moduli semplici (Container), come li coordiniamo??? Kubernets è una possibile risposta.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (17)
Similar to Google cloud: Big Data + docker = kubernetes
Similar to Google cloud: Big Data + docker = kubernetes (20)
More from Giuliano Latini
More from Giuliano Latini (18)
Google cloud: Big Data + docker = kubernetes
- 3. WhoAmI Giuliano Latini: • Classe 1969 • Si interessa di I.T. dal 1986 • Lavora presso l’Università Politecnica delle Marche dal 1991 • Inizia ad usare i computer perché s’illudeva di aver trovato qualcuno che lavorerà al suo posto. Internet Avatar latini.giuliano@gmail.com Twitter: @giulianolatini Linkedin: https://www.linkedin.com/pub/giuliano-latini/a/aa6/274 Pagina Feedback: https://it.surveymonkey.com/s/Y8YW537 Pagina Feedback
- 4. Docker Ottimizziamo i nostri ambienti virtuali usando la filosofia di Henry Ford e i mattoncini Lego la modularità Vince Sempre
- 5. Giuanin go to Dopo gli anni passati a macinare scarpe tra lezioni e cacce ai prof. per gli esami, Giuanin ha finalmente la sua occasione, viene chiamato da Google per un colloquio alla sede centrale.
- 6. Progetto interno a Google. Datacenter progettato dalle prime classi (elementari) della scuola aziendale. I componenti base sono: 3 scatole di mattoncini lego; 32 Raspberry Pi B; 2 switch 24 porte, cavi. L’infrastruttura è un private cloud per sostenere i 48 blog Wordpress degli alunni che l’hanno costruita.
- 7. Giuanin dopo il quesito proposto Giuanin ha un’idea meravigliosa, meglio di Cesare Ragazzi. Usare DOCKER
- 10. Cos’è Docker??? • Un collante di Tecnologie e Componenti Infrastrutturali • Un strumento con cui Devs & Ops raggiungono i propri scopi senza litigare • Un modo intelligente di risolvere le sfide del continuous integration
- 11. Il mondo docker
- 12. Il mondo docker Mettiamo ordine nel caos
- 16. Timeline da LXC a Docker
- 17. VM versus Docker Grafici comparativi per operazioni atomiche su: sistema installato (Native) - Docker - VM (KVM) Architettura Storage
- 18. VM versus Docker Grafici comparativi per sistemi DBMS su: sistema installato (Native) - Docker - VM (KVM)
- 19. VMware versus Docker?? Docker-on-VMware. The companies are working together to ensure that the Docker Engine runs as a first-class citizen on developer workstations using VMware Fusion, data center servers with VMware vSphere, and vCloud Air, VMware’s public cloud.
- 20. VMware versus Microsoft Azure??
- 26. Architettura boot2docker Schema di comunicazione tra Internet (l’esterno) e i container che sono running nell’infrastruttura boot2docker
- 27. Container über alles Container: usiamo docker come i mattoncini Lego, per costruire un’infrastruttura slim e modulare.
- 29. docker run -i apriamo una sessione shell per interagire con un’istanza docker
- 31. Conclusioni Critiche Tutto Giusto??? Che succede quando dal mio pc passo al Cloud????
- 32. Una proposta: lo sciame Api: Container Polline: Dati
- 33. Bibliografia • Introduction on Docker - Solomon Hykes • An Updated Performance Comparison of Virtual Machines and Linux Containers - Wes Felter, Alexandre Ferreira, Ram Rajamony, Juan Rubio • Sito - www.docker.com • Sito - www.dotcloud.com • http://blogs.vmware.com/cto/vmware-containers-containers-without- compromise/ • http://blog.docker.com/2014/08/docker-vmware-1-1-3/ • http://azure.microsoft.com/blog/2014/10/15/new-windows-server-containers- and-azure-support-for-docker/ • http://www.slideshare.net/jpetazzo/presentations • http://googlecloudplatform.blogspot.it/2014/11/google-cloud-platform-live- introducing-container-engine-cloud-networking-and-much-more.html
- 34. WhoAmI Giuliano Latini: • Classe 1969 • Si interessa di I.T. dal 1986 • Lavora presso l’Università Politecnica delle Marche dal 1991 • Inizia ad usare i computer perché s’illudeva di aver trovato qualcuno che lavorerà al suo posto. Internet Avatar latini.giuliano@gmail.com Twitter: @giulianolatini Linkedin: https://www.linkedin.com/pub/giuliano-latini/a/aa6/274 Pagina Feedback: https://it.surveymonkey.com/s/Y8YW537 Pagina Feedback
Editor's Notes
- Perché Mobile SUIT Gundam e “la modularità Vince Sempre”: autolesionismo, Gundam lo vedevo alle medie e mi ricorda quanto so’ “veccio”; perché la serie Gundam introduce, sia nel design dei “robottoni” buoni, che nella storia la contrapposizione tra due filosofie, l’all-in-one (arma dal Principato di Zeon) e il Gundam, prototipo robot da combattimento modulare e multifunzione (la cabina del pilota è un caccia, che si trasforma nel tronco del robot, giunzione tra gambe e spalle/testa) che consentirà alla Federazione Terreste di ribaltare le sorti della guerra. Docker ha caratteristiche simili. In buona sostanza sposta il paradigma della virtualizzazione dalla VM (S.O., Framework, Applicazione) alla composizione di tecnologie viste come moduli collegabili fruttando i concetti di resource isolation di LXC (LinuX Container).
- Giuanin è il classico prodotto del sistema universitario italiano: capace, intelligente, testardo, un candidato ideale al gruppo dei “cervelli in fuga”. Dopo aver escluso di rimanere parcheggiato in facoltà con un dottorato da fame, la grande occasione, viene selezionato per un colloquio in Google. Gasato e sognando un futuro lavorativo radioso e finanziariamente esaltante investe i risparmi di 3 anni passati a raccogliere uva, servire pizze, correggere bozze e passare tesine agli studenti danarosi in un biglietto aereo solo andata per Mountain View, CA, Stati Uniti d’America (spera che il viaggio gli basti per smaltire lo shock di un’azienda che ti offre vitto&alloggio, tanto per non far la figura del solito italiano provincialotto).
- Arrivato, dopo essersi rinfrescato nella stanza messagli a disposizione della foresteria aziendale, un gentile impiegato gli mostra la struttura, mentre aspetta il giorno successivo quando dovrà affrontare il test d’ingresso per il lavorare in Google. Costruire un PrivateCloud per realizzare 48 blog in Wordpress, uno per ogni alunno che ha concorso alla realizzazione del progetto.
- Giuanin si sente perso, non sa cosa fare. Come riesce a far funzionare 48 wordpress con 32 schede montate con i mattoncini della Lego??? L’occasione della vita è finita prima di cominciare. Oppure no. Con l’intuito dei momenti di disperazione assoluta, ricorda i discorsi fatti con un suo amico smanettone, mai laureato e ora sepolto nel sottoscala di un datacenter della CariVerona a badare ai server bancari. LXC, LinuX Container, forse è questa la risposta. Rimasto solo difronte al datacenter delle elementari di Google apre il portatile, si collega ad internet ed apre www.docker.io…
- Giuanin, alla fine della giornata di ricerche e studi su www.docker.io, dopo litri di caffè, ciambelline glassate al cioccolato che avrebbero arricchito generazioni di dentisti e abbastanza coca-cola per ruttare fino a fine 2015 può urlare: SI PUO FARE!!! Ora sa che al termine della settimana a disposizione potrà firmare il contratto e iniziare la vita che voleva dalla cima del mondo.
- Ma riveliamo chi è il nostro protagonista, che spero non se ne abbia a male se ne ho sfruttato l’immagine, è il CTO della dotCloud, un’azienda che fornisce, appunto servizi PaaS scalabili per applicazioni web sfruttando come infrastruttura di base Docker.
- boot2docker è la soluzione per i sistemi Windows&OSX. Docker, nativamente, richiede un’architettura LXC per funzionare, Windows e OSX non consentono questo tipo di archiettura, percui il pacchetto prevede l’installazione di una VM minimale che contenga un ubuntu con installato docker.io e le sue dipendenze, unito a questo boot2docker ha la predisposizione per usare la docker-cli direttamente dalla shell del sistema host. boot2docker installa nativamente Virtualbox come hypervisor. Nei sistemi Windows con il ruolo Hyper-V attivo il Virtualbox installato non funziona, la soluzione più funzionale è convertire la VM fornita in un VHD o installare un ubuntu server minimale (l’Hyper-V supporta nativamente ubuntu) aggiungendo il pacchetto docker.io
- Uno dei vantaggi di docker è l’estrema facilità con cui derivare da un servizio una sua variante. Esempio: partendo da un’immagine ubuntu deriviamo tre servizi: node.js, nginx e mongodb. Dall’immagine node.js possiamo generare due immagini con l’applicazione custom per due clienti. Questo si ottiene stratificando elementi singoli, costruendo così la struttura necessaria. Rispetto l’architettura basata su VM il confronto mostra in modo evidente il risparmio di risorse.
- FROM: image da cui parte la build MAINTAINER: riferimenti del builder/maintainer RUN: esegue il comando e fà la commit dell’immagine memorizzando le modifiche prodotte nell’immagine prodotta dalla build EXPOSE: la porta indicata viene “esposta” dal sistema, sarà utilizzata per il dialogo via rete con l’esterno ADD <src> <dst> : copia il contenuto di <src> (dir dell’host, URL, archivio .tar) nel container in <dst>. WORKDIR: imposto la working-directory per i successivi RUN,CMD, ENTRYPOINT. ENTRYPOINT: comando che viene eseguito di default allo start del container. VOLUME: predispongo un punto di mount a cui collegare un volume esterno al run del container CMD: indico il comando da eseguire allo statup del container.
- docker run: -d : modalità detach o daemon, la comunicazione con il il container avviene via rete -i : modalità interattiva -t : alloco una pseudo-tty, necessario per gestire l’I/O in modalità interattiva -rm : al termine della sessione il contenuto del filesystem dell’istanza non è conservato (immagine non persistente) -p : associazione porta host:container, la porta del container viene pubblicata dall’host -v : VolumeShare eseguo il mount di una cartella presente nel filesystem dell’host come volume del container (sintassi estesa -v [“host path”]:[”container path”]:[ro|rw])
- Fico, adesso con boot2docker o direttamente con ubuntu e apt-get installa docker.io ho risolto tutti i problemi. Spedisco i miei container, li cambio real-time senza che l’utenza si accorga di nulla. Mi porto in azienda la realtà del mio cliente e su quella faccio debugging&continuos integretion. Ma se la potenza di fuoco di cui ho bisogno è altra che faccio… butto via tutto e ricomincio da capo??? La flessibilità, la ridondanza, la scalabilità di un ambiente a risorse virtualmente infinite come le implemento efficacemente??
- Immaginiamo un modo diverso di concepire la struttura di un pacchetto software che ci consenta di spaziare tra affidabilità e scalabilità. Sulla costruzione ci affidiamo alle risorse infinite di un PublicCloud, di cui monitorare i costi infrastrutturali per evitare di scendere sotto il break even point (punto di pareggio) nel rapporto Costi/Ricavi. Pensare il software (se il problema da risolvere c’è lo concede) come una nuvola di processi staccati che colloquiano tra loro, ci da maggiore flessibilità (la singola ape è sacrificabile e sostituibile nel contesto dello sciame), mentre il concetto di Alveare come concentrazione dei dati raccolti/elaborati, ci permette di semplificare e gestire meglio il problema CONSISTENZA. Avremo così moduli semplici e rimpiazzatili in modo automatico che TRASPORTANO dati dall’acquisizione allo storage (Alveare), in cui, altri moduli manipoleranno e gestiranno il Miele. Abbiamo trasformato il problema da: gestiamo pochi oggetti complessi (VM) in gestiamo tantissimi moduli semplici (Container), come li coordiniamo??? Kubernets è una possibile risposta.