‫Bene, ciao?
‫O dovrei dare il benvenuto al futuro della gestione del software con Docker e strumenti per container?
‫Questo video riguarda specificamente Docker.
‫Aveva molti strumenti nel corso degli anni, ma questo video parla delle tre principali innovazioni
‫che hanno avviato l'intera evoluzione del software Docker nel 2013.
‫Si tratta principalmente di tre cose: l'immagine Docker, il registro Docker e quindi il contenitore Docker.
‫La maggior parte di noi, quando pensiamo a Docker, pensiamo al container.
‫Ma queste tre innovazioni vanno insieme come pane e burro e le chiamano Add, Docker, build,
‫ship run.
‫Questi sono i tre passaggi per prendere in precedenza un software ID non container, trasformarlo in un'immagine docker, inserirlo in un registro,
‫portarlo ovunque sia necessario per eseguirlo e quindi creare un container da esso.
‫In effetti, la Ciencia for the Cloud Native Computing Foundation, di cui parleranno molti strumenti in tutti i
‫miei video, questi prodotti, strumenti e flussi di lavoro presuppongono nella maggior parte dei casi che si stia
‫utilizzando un flusso di lavoro di container, una nave di costruzione .
‫Quindi analizziamoli e quali sono esattamente i tre.
‫Innanzitutto, l'immagine del contenitore e mi piace pensarla come un pacchetto di app universale e nel corso degli anni abbiamo avuto
‫molti gestori di pacchetti.
‫In effetti, ho perso il conto e sono stato in giro per un po' di tutti i gestori di pacchetti,
‫ma non c'è mai stato nulla che io possa ricordare che sia stato multipiattaforma multi-sistema operativo e indipendente dal linguaggio delle applicazioni, il che significa
‫che funzionerà ovunque e funziona su qualsiasi cosa purché esegua Linux o Windows.
‫Ora diamo una rapida occhiata a un file Docker, che è la ricetta o il set di istruzioni per creare un'immagine contenitore,
‫un'immagine finestra mobile e un'immagine contenitore sono lo stesso termine per la stessa cosa.
‫In effetti, la specifica dell'immagine Docker era così popolare che ora è uno standard noto come standard dell'immagine
‫OCI.
‫Quindi vedi una serie di istruzioni e ogni file Docker ha bisogno di un da per cominciare.
‫Possiamo partire dall'immagine di qualcun altro.
‫Possiamo avere molte immagini da, molte da.
‫Quindi entreremo in tutta questa complessità più tardi.
‫Ma stiamo iniziando con un pitone qui e procediamo verso il basso.
‫In effetti, iniziamo con questi come livelli.
‫Ciascuno di questi comandi nel file Docker a volte chiamato una stanza con lettere maiuscole, incluso
‫da e poi l'esecuzione e procedendo verso il basso perché li elabora dall'alto verso
‫il basso creerà livelli che vengono spostati sui server come tarball.
‫E all'interno di questi livelli ci sono file, directory e permessi dei file e talvolta metadati di cui parleremo in
‫seguito.
‫Quando inizio a creare questa immagine, inizierà quella prima riga e andrà a trovare l'immagine Python da Docker Hub o
‫ovunque gli ho detto di ottenere l'immagine.
‫E questo include solo Python, i suoi binari e le sue librerie.
‫Non contiene i driver dell'host o il kernel Linux o altro al di fuori di ciò che Python deve eseguire.
‫Se Python ha bisogno di SSL aperto, allora è incluso in quel livello dell'immagine.
‫Quindi possiamo passare alla riga successiva del file Docker.
‫Questo è un comando PIP per un programma di installazione delle dipendenze Python e sta installando flask.
‫In questo modo verrà avviato un nuovo livello che aggiunge flask proprio come faresti con un normale comando di installazione pip.
‫In effetti, ciò che sta accadendo in background è eseguire piccoli contenitori rapidi per ciascuno di questi
‫livelli, eseguire i comandi o fare qualsiasi cosa sia necessario fare all'interno di quei
‫livelli, e quindi archiviarli come posizione distinta sull'host Linux che lo sta costruendo.
‫Quindi stiamo impilando i livelli qui e poi andiamo alla riga successiva, al comando di copia, al lavoro.
‫C'è solo una modifica ai metadati.
‫Cambia solo posizioni nel file system, niente di grave.
‫Il comando copy copia il nostro codice sorgente dall'host su cui stiamo costruendo nel proprio livello impilato sopra
‫gli altri.
‫Questi insieme formano un'immagine usando la build della finestra mobile dei comandi.
‫Questa è una di quelle cose su Docker che è diventato così facile da usare perché avevamo solo bisogno
‫di questo semplice comando di compilazione Docker per prendere un sacco di cose complesse che accadono nel file Docker e trasformarlo in
‫un'unica immagine.
‫Questa è solo la nostra applicazione e solo le dipendenze di cui ha bisogno e nient'altro.
‫Questa è la prima parte della costruzione della nave costruita da Docker.
‫Successivamente, parliamo del registro.
‫Il registro Docker è per la distribuzione dell'applicazione.
‫Ogni sistema di packaging delle applicazioni ha un modo per ottenere quei pacchetti e il registro Docker non è
‫diverso ora.
‫È noto solo come specifica di distribuzione OCI o specifica del registro OCI.
‫Quindi è di nuovo uno standard in tutto il settore per come spostare le immagini dei container.
‫Ed è ovunque.
‫Ogni nuvola ne ha una.
‫L'hub Docker è quello predefinito e probabilmente il più popolare.
‫GitHub ha un Bitbucket GitLab.
‫Hanno tutti i propri registri di immagini e tu puoi eseguirne uno tuo.
‫Probabilmente ci sono almeno una dozzina di progetti di software gratuiti, open source ea pagamento che ti consentono di archiviare
‫le tue immagini Docker al loro interno.
‫Quindi analizziamo come funziona.
‫In primo luogo, abbiamo la nostra immagine che abbiamo appena creato, e quell'immagine ha un hash sha univoco che identifica tutti
‫quei livelli insieme in modo da poter garantire che se osserviamo l'hash su due sistemi diversi, possiamo essere
‫certi che è esattamente gli stessi file, gli stessi identici metadati che abbiamo appena creato.
‫Questi livelli di immagine si uniscono e si distribuiscono.
‫Possiamo usare qualcosa come Docker Push per prendere quei livelli di immagine e spingerli su un registro.
‫Puoi usare uno dei tanti registri, come ho detto, ma una volta che è lì puoi
‫andare su un'altra macchina ed eseguire un pull Docker, che tirerà una copia identica di quell'immagine su quella macchina, proprio come l'avevamo
‫costruita su la prima macchina.
‫E questo è uno dei principi fondamentali di Docker, è che siamo in grado di prendere
‫il software che abbiamo realizzato su una macchina con tutte le sue dipendenze ed eseguirlo esattamente allo stesso modo su un
‫altro sistema che potrebbe essere distribuzioni di Linux completamente diverse o Windows.
‫Se sei su Linux e crei un'immagine Linux che deve essere eseguita su Linux poiché esegue binari Linux.
‫Se lo hai creato su CentOS e lo hai eseguito su Bonita, sarebbe esattamente la stessa applicazione e dipendenze
‫indipendentemente da quella distribuzione.
‫Infine, arriviamo al container Docker stesso.
‫Dopo aver eseguito tutti quei passaggi per creare l'immagine, metterla in una posizione, possiamo accedervi dai
‫nostri server e quindi scaricarla nei nostri server.
‫Possiamo eseguirlo.
‫Immaginiamo di avere un server che esegue Linux.
‫Potrebbe essere in esecuzione Windows, ma in questo caso ci concentreremo solo su Linux.
‫Avrà Docker in esecuzione in background noto come motore Docker.
‫E il motore su questa singola macchina orchestrerà o gestirà tutte le diverse cose
‫che devono accadere per scaricare le immagini, verificare che siano esattamente ciò che doveva essere scaricato
‫e infine eseguirle.
‫Quindi otteniamo l'immagine che abbiamo appena scaricato con un sondaggio Docker e quindi eseguiremo un comando.
‫Non è molto importante che tu impari ancora i comandi, ma è un comando di esecuzione Docker.
‫Questa è la parte di esecuzione di build ship run.
‫E in questo caso, stiamo eseguendo l'app Python nel proprio contenitore.
‫Quel contenitore è noto come spazio dei nomi.
‫Questa è quella funzionalità di Linux che impedisce all'applicazione in esecuzione in questo contenitore di vedere il resto
‫del sistema operativo.
‫Ottiene il proprio file system vuoto e includerà solo i file che erano nell'immagine che abbiamo appena
‫creato.
‫Otterrà il proprio indirizzo IP e il proprio nic virtuale e il proprio elenco di processi e fondamentalmente sembra
‫il proprio sistema lì dentro.
‫Quindi, se eseguiamo nuovamente il comando Docker run con il nostro nome immagine o hash immagine, otteniamo un contenitore
‫identico in esecuzione fianco a fianco.
‫Ora questi due processi sono isolati l'uno dall'altro.
‫Quindi l'app Python, un contenitore non può vedere l'app Python e il contenitore due.
‫E se modifichi un file nel contenitore in un contenitore, non vedrai quel file per impostazione predefinita.
‫Se aggiungessimo un secondo server con una seconda istanza del motore Docker in esecuzione e facessimo la stessa cosa, potremmo avere
‫una configurazione ad alta disponibilità con la nostra applicazione, in esecuzione molte volte per ridondanza o prestazioni migliori o qualunque
‫sia la nostra ragione per eseguire di più di uno di loro.
‫Saranno identici dal punto di vista del file system, dei permessi e dei metadati.
‫Ora, c'è molto di più che possiamo imparare su queste cose, motivo per cui il corso che ho è
‫così lungo ora.
‫Ma queste sono ancora le tre cose che non sono cambiate dopo Docker.
‫Prima li ho concettualizzati.
‫L'idea di costruzione della nave è uno dei principi fondamentali del container e del timone Kubernetes.
‫Dai un nome al progetto nell'ecosistema nativo del cloud e probabilmente presuppone che tu abbia questo tipo di
‫flusso di lavoro tipico per portare le tue app fuori dalle mani dello sviluppatore nei sistemi di test e quindi infine nei
‫server di produzione.
‫Sono questi stessi tre passaggi, quindi si spera che stia iniziando ad affondare solo un po' nel capire perché questi
‫sono i tre componenti chiave.
‫Ancora oggi, molti, molti anni dopo che tutto questo è stato inventato, scopriamo cosa c'è dopo.