‫Ora potresti ancora chiederti, anche dopo aver appreso alcune delle funzionalità chiave di Docker.
‫Perché Docker deve esistere?
‫Ovviamente abbiamo creato pacchetti di software per decenni con tonnellate di altri gestori di pacchetti che distribuiscono software ai
‫server.
‫Quindi parliamone.
‫Questo video si concentrerà su tre cose sul perché Docker e perché ora?
‫E nel momento in cui è stato creato, c'era attrito.
‫C'erano cose che ci impedivano di passare al livello successivo di velocità e facilità d'uso del ciclo di vita del software, in particolare per quanto riguarda il
‫confezionamento, la distribuzione e l'esecuzione di tutto il software che stiamo realizzando.
‫E mi piacciono le liste di tre, suppongo.
‫Quindi questo elenco principale di ambienti di isolamento e velocità.
‫Queste tre aree sono ciò di cui voglio parlare come le tre ragioni generali.
‫Sento che i contenitori stessi devono esistere e perché sono così popolari oggi.
‫Innanzitutto, il problema dell'isolamento.
‫E se torniamo all'inizio della mia carriera negli anni Novanta, possiamo iniziare a parlare di quali
‫erano i server prima di avere i container.
‫Se andiamo ancora più indietro rispetto al solo 2013, prima della creazione di Docker e parliamo dei primi anni 2000
‫negli anni Novanta, quando siamo passati dal mainframe al PC, questo potrebbe essere l'aspetto di un tipico amministratore.
‫Avevo un paio di server per azienda.
‫Sai, non saremmo davvero in grado di gestire 100 server a persona.
‫Di nuovo, questo era tipo, sai, il 2000.
‫E quindi avremmo questi server di grandi dimensioni molto costosi che era raro consumare tutte le loro risorse con una
‫singola app.
‫Quindi finiresti con tutte queste app messe insieme sullo stesso server.
‫E il server è diventato fragile.
‫È diventato difficile da gestire perché potresti dover cambiare una cosa per un'app e quindi un'altra app aveva bisogno di
‫una cosa diversa.
‫E poi dovresti gestire le loro diverse versioni di Python o le tue diverse versioni di
‫Apache su server diversi solo per bilanciare tutto allo stesso tempo, volevi mettere sempre più cose su ciascun
‫server.
‫Ma nulla è stato isolato, quindi tutte queste app condividevano lo stesso file system.
‫Di solito non potrebbero essere più versioni di quell'app senza un sacco di complicati hacking.
‫E quello era un grosso problema.
‫Poi sono arrivate le VM.
‫Quindi, una volta che le VM sono diventate davvero popolari, anche prima del cloud, siamo stati in grado di estrarre
‫tutte le nostre applicazioni e iniziare a inserire meno applicazioni su VM più piccole, scrivendo tutte sullo stesso host di grandi dimensioni.
‫Quindi potrebbe sembrare così e potremmo iniziare con Chef o Puppet come un modo per
‫gestire tutti questi numeri crescenti di server.
‫In effetti, avremmo avuto così tanti server nelle prime 20 decine prima della creazione di Dockers che
‫stava diventando molto difficile gestirli tutti contemporaneamente.
‫Eri un unico amministratore, che forse cercava di gestire dozzine, se non centinaia di server, anche con il cloud che
‫ci aiutava a far girare le macchine più velocemente, abbattendole più velocemente.
‫Era molto.
‫Era così difficile da gestire che è diventato troppo per molti di noi.
‫E il cloud, penso, lo abbia reso migliore, ma anche peggiore perché ha reso molto più facile far girare
‫così tanti altri.
‫Quindi, come può Docker aiutare in questo?
‫In che modo può aiutarci a ridurre la quantità di infrastruttura da gestire garantendo al contempo l'isolamento dei nostri carichi di lavoro in modo
‫che le cose non diventino fragili o difficili da gestire?
‫Bene, se questa fosse la nostra configurazione 20 anni fa, invece di distribuire tutte queste macchine virtuali con un numero non necessario
‫di sistemi operativi.
‫Quello che fanno i container è che ci danno l'isolamento come una macchina virtuale.
‫Non è proprio la stessa cosa, ma per ora sosterremo solo che è un livello di isolamento in cui ottengono il
‫proprio indirizzo IP, ottengono il proprio file system, ottengono il proprio spazio di processo.
‫E quindi sembra quasi una macchina virtuale completa, ma non sono necessari tutti i diversi sistemi operativi in modo da poter
‫ridurre il nostro sistema operativo, contare il conteggio del nostro host fisico.
‫Non è più necessario utilizzare le macchine virtuali come livello di isolamento e potrebbe essere simile a questo.
‫Invece di usare SH, useresti un Docker.
‫Seelye Oppure, se passi a Kubernetes, puoi utilizzare l'intelligenza artificiale del sigillo Kubernetes e le tue applicazioni
‫sono tutte isolate nei loro contenitori.
‫Ciò ti offre molti vantaggi, inclusa l'esecuzione di più versioni della stessa app sullo stesso sistema
‫senza alcun conflitto.
‫Poi, il problema degli ambienti.
‫E ovviamente stavamo facendo girare tonnellate di sistemi operativi come ho detto, ma anche il numero di diversi
‫tipi di ambienti stava aumentando.
‫Hai mai sentito parlare di lavori sulla mia Macchina?
‫È stato reso famoso per scherzo da Jeff Atwood, uno dei fondatori di StackOverflow, e da un famoso
‫post sul blog di un tempo.
‫Ma questo funziona sulla mia macchina L'idea era un po' irriverente, ma lo scherzo era che spesso
‫è compito dello sviluppatore assicurarsi che l'applicazione funzioni correttamente.
‫Ma non hanno tutti gli ambienti necessari per l'esecuzione di questa app.
‫Quindi lo eseguono semplicemente sulla loro macchina, testano sulla loro macchina e poi quando non funziona
‫da qualche altra parte, dicono che funziona sulla mia macchina.
‫È davvero impegnativo quando abbiamo tutti questi diversi sistemi operativi e Docker ha coniato questo The Matrix from
‫Hell, che essenzialmente significa che per ogni parte della tua app, che è sopra di me,
‫e quindi per ogni tipo di ambiente qui da questa parte, hai un configurazione diversa.
‫Forse devi installare le dipendenze in un modo diverso.
‫Forse le dipendenze sono leggermente diverse perché una ha una versione diversa nell'altra.
‫Hai tutti questi diversi tipi di ambienti e probabilmente hai dovuto leggere o scrivere documentazione su come l'app utilizzata dallo
‫sviluppatore su Mac deve essere installata in modo diverso su Windows, che deve essere installato in modo diverso
‫su un server Linux e su e ancora e ancora.
‫Ora l'immagine del contenitore e il contenitore stesso sono diventati un fondamento.
‫Mentale, astratto o un contratto tra dove viene eseguito e ciò che viene eseguito al suo interno, proprio come i contenitori fisici nel
‫mondo reale che ci consentono di spedire merci in tutto il mondo dal design di quasi
‫cento anni fa.
‫L'obiettivo era che le persone che consegnavano i contenitori fisici non dovevano sapere cosa c'era dentro e
‫le persone che mettevano le loro cose all'interno del contenitore non dovevano sapere o preoccuparsi di come il contenitore
‫fosse fisicamente arrivato a destinazione.
‫Quelle erano un'astrazione delle proporzioni ormai epiche di milioni di container in tutto il mondo spediti.
‫E praticamente tutto nella tua casa è stato probabilmente in un contenitore nel corso della sua vita.
‫La stessa cosa ora vale per le immagini nei contenitori Docker.
‫Sono un formato standard coerente noto ora come standard OCI.
‫Questi assicurano che, ovunque si esegue il contenitore, verrà eseguito nello stesso modo coerente con le stesse esatte dipendenze
‫con cui è stato creato.
‫Successivamente, il problema della velocità.
‫Ora, non intendo necessariamente qui la velocità della CPU o la velocità della memoria.
‫Quelle cose diventano naturalmente più veloci nel tempo.
‫Ma sto davvero parlando della velocità degli affari.
‫E quando parliamo di I. T. e software e il ciclo di
‫vita del software, stiamo davvero parlando della capacità delle aziende e delle organizzazioni di realizzare le proprie idee, di fornire le proprie
‫idee software al cliente il più velocemente possibile.
‫E questo fa parte del ciclo di vita del software.
‫Ebbene, si scopre che il settore ha cambiato infrastruttura e architettura dagli
‫albori dell'informatica.
‫Proprio per questo motivo ho realizzato questa piccola grafica carina perché puoi iniziare dall'alto.
‫Negli anni '90, quando ho iniziato e avevamo i mainframe che si spostavano sui PC in un'architettura distribuita
‫che riguardava principalmente la velocità di essere in grado di implementare il cambiamento.
‫Ora potevi installare DOS su una singola macchina senza dover aspettare che il mainframe venisse aggiornato a qualunque
‫fosse la prossima versione di Unix.
‫Non potevamo più muoverci tutti in una volta.
‫Avevamo bisogno che parti diverse della nostra organizzazione si muovessero in direzioni diverse a velocità diverse, da
‫qui l'alba del calcolo distribuito.
‫Poi siamo passati dal bare metal, al virtuale, perché eravamo stanchi di aspettare l'ordinazione dell'hardware e aspettare che
‫venisse implementato in un data center.
‫Volevamo velocizzare le cose e ottenere un migliore utilizzo delle nostre risorse.
‫La virtualizzazione e le macchine virtuali sono diventate estremamente popolari per questi motivi.
‫Quindi il passaggio successivo dal data center al cloud è stato, perché ora dovevamo distribuire le idee ancora più velocemente di quanto il
‫nostro hardware e i nostri data center potessero consentire.
‫Volevamo eseguire server che non avevamo attualmente in pochi minuti, non giorni o settimane, e il cloud
‫ci ha dato accesso a risorse quasi istantanee, che ovviamente è il motivo per cui il cloud è così grande oggi.
‫E infine, siamo sulla prossima tappa di quel viaggio, passando dalla massiccia espansione dell'host che avevamo dove
‫avevamo troppi host, kernel e sistemi operativi.
‫E ora saremo in grado di ridurne il numero perché ora siamo in grado di isolare i carichi di
‫lavoro al loro interno ed eseguirli in sicurezza insieme sullo stesso kernel.
‫A proposito, sto includendo serverless qui, perché se scavi davvero nella maggior parte delle piattaforme serverless,
‫stanno davvero eseguendo contenitori in background.
‫Potrebbe essere un container che hai spedito come immagine o semplicemente un container in cui stanno eseguendo la
‫tua funzione, ma sono ancora in esecuzione in un container.
‫Ed è per questo che mi piace parlare di più veloce, più veloce, più veloce.
‫In sostanza, ciò che Containers e Docker ti offrono è la capacità di sviluppare più velocemente, creare le tue
‫app più velocemente, testarle più velocemente e distribuirle ai tuoi server più velocemente.
‫Ora, sei ancora con me?
‫Ho ancora la tua attenzione.
‫Ricapitoliamo molto velocemente.
‫Quindi, il motivo per cui esistono i container sono tre ragioni principali, a mio avviso, il migliore isolamento all'interno di un singolo sistema operativo che
‫consente di risparmiare tempo e gestione del sistema operativo e delle dipendenze, ma ci fornisce anche l'isolamento di cui abbiamo bisogno
‫per proteggere le nostre applicazioni.
‫Quindi abbiamo ridotto le varianze ambientali.
‫Quindi la differenza tra ogni ambiente che esegue è minima.
‫Ancora una volta, di solito solo le impostazioni di connessione per i database, forse alcuni percorsi URL, cose del
‫genere, porte e poi il resto è tutto esattamente come l'hai costruito e testato.
‫E, infine, aumentare la nostra velocità di cambiamento, non solo per il software stesso, ma per l'azienda
‫che vuole implementare quel software.
‫Ora siamo in grado di sviluppare più velocemente, costruirlo più velocemente, distribuirlo più velocemente sui server e testarlo più
‫velocemente, tutto perché queste immagini del contenitore e i contenitori stessi sono così facili da creare, distribuire, ridistribuire e rieseguire e
‫tutto il resto.
‫Quindi spero che questo abbia senso.
‫Ci vediamo nel prossimo video.