‫Bine, în această lecție vom vorbi despre straturile de imagine.
‫Deci, acesta este un concept fundamental al modului în care funcționează Docker. Folosește ceva numit sistem de fișiere sindical
‫pentru a prezenta o serie de modificări ale sistemului de fișiere ca sistem de fișiere real.
‫Ne vom arunca cu capul în istorie și vom inspecta comenzile și vom vedea cum le putem folosi pentru
‫a înțelege de ce este de fapt realizată o imagine. Vom învăța un pic despre conceptul de copie despre
‫scrierea modului în care un container rulează ca un strat suplimentar pe o imagine.
‫Ce vreau să spun prin straturile de imagini?
‫Este de fapt transparent pentru dvs. când utilizați Docker, dar când începeți să săturați anumite comenzi, cum
‫ar fi comanda de istorie, inspecția și comiterea, începeți să obțineți un sentiment că
‫o imagine nu este o bucată mare de date care vine și merge într-o bucată mare.
‫Dreapta?
‫Dacă observați când am tras de fapt Docker, în anumite momente ar putea să vedeți cuvinte care
‫indică faptul că există ceva deja pe care îl aveți, cum ar fi deja cache o
‫parte din ea, și că totul se reduce la faptul că imaginile sunt proiectate folosind conceptul de sistem de fișiere unificat de
‫a face straturi despre schimbări.
‫Dacă am putea să ne uităm rapid la ceea ce avem în Docker ... în imaginile Docker de fapt ...
‫Cu ceva timp în urmă, jucam cu etichetele cu Nginx. Dreapta? Ne amintim că ID-ul de
‫imagine Nginx este același și că aveam etichete diferite pentru același nume de imagine.
‫Deci, hai să facem un istoric rapid de andocare pe nginx mai târziu.
‫Ce caut aici?
‫Aceasta nu este o listă a lucrurilor care s-au întâmplat de fapt în container deoarece este vorba despre o imagine.
‫Aceasta este de fapt o istorie a straturilor imaginii.
‫Fiecare imagine începe de la început cu un strat gol cunoscut sub numele de zgârietură.
‫Apoi fiecare set de modificări care se întâmplă după aceea pe sistemul de fișiere, în imagine, este un alt strat.
‫S-ar putea să aveți un strat, ați putea avea zeci de straturi și unele straturi poate să nu se schimbe în ceea
‫ce privește dimensiunea fișierului.
‫Veți observa aici că de fapt avem o schimbare aici, care a fost pur și simplu o schimbare de metadate despre
‫ce comandă vom merge de fapt. Vom acoperi acest lucru într-un pic când vom trece
‫peste Dockerfile.
‫Dar, deocamdată, puteți vedea că acesta a adăugat o cantitate imensă de fișiere de 123 MB.
‫Apoi am făcut o schimbare aici și o schimbare aici și se întâmplă să știu
‫din cauza Dockerfiles că acestea sunt într-adevăr informații despre metadatele Dockerfile.
‫Pe măsură ce mergeți, avem mai multe schimbări de date.
‫Veți vedea că acest lucru este de fapt destul de diferit într-o altă imagine.
‫Deci, dacă mergem la mysql istoricul docker-ului, acesta are un set complet diferit de straturi de imagine.
‫Permiteți-mi să trag un pic pentru tine și poate că asta îți va ajuta.
‫Când începem o imagine, când creăm
‫o nouă imagine, începem cu un singur strat. Fiecare strat își obține propriul SHA unic care ajută sistemul să identifice dacă stratul respectiv
‫este într-adevăr același cu cel al unui alt strat.
‫Să spunem că la începutul uneia dintre dvs., este posibil să aveți Ubuntu chiar în partea de jos.
‫Acesta este primul strat al imaginii tale.
‫Apoi, creați un fișier Docker, care adaugă mai multe fișiere și acesta este un alt strat
‫deasupra acelei imagini. Poate folosim Apt pentru asta.
‫Apoi, în fișierul Docker, faceți o schimbare de variabilă a mediului. Aceasta este imaginea ta.
‫O.K?
‫S-ar putea să aveți o altă imagine care începe de la debian: jessie și apoi pe acea imagine puteți
‫utiliza, de asemenea, Apt pentru
‫a instala unele chestii, să zicem MySQL. S-ar putea să copiați unele fișiere, puteți deschide un port.
‫Deci, fiecare dintre aceste modificări pe care le faceți de obicei în Dockerfile, dar puteți, de asemenea, să
‫faceți cu comanda docker comitetul pe care îl vom verifica într-un minut.
‫Aceasta este și o altă imagine și toate acestea sunt grupate împreună.
‫Ce se întâmplă dacă am o altă imagine care utilizează aceeași versiune a lui jessie?
‫Ei bine, acea imagine poate avea propriile modificări pe partea de sus
‫a aceluiași strat pe care îl am în cache-ul meu. Aici, conceptul fundamental al cache-ului straturilor de imagine ne
‫salvează o grămadă de timp și spațiu. Deoarece nu avem nevoie să descărcăm straturi pe care le
‫avem deja și să ne amintim că folosește un SHA unic pentru fiecare strat, astfel că este garantat că
‫este stratul exact de care are nevoie. Știe cum să le potrivească între Docker Hub și cache-ul nostru local. Pe măsură ce facem
‫schimbări în imaginile noastre, ele creează mai multe straturi.
‫Dacă decidem că dorim ca aceeași imagine să fie imaginea de bază pentru mai multe straturi, atunci numai o
‫singură copie a fiecărui strat este stocată.
‫În acest sistem, unul dintre cele mai mari beneficii este că nu mai stocăm niciodată aceleași date de
‫imagine pe sistemul nostru de fișiere.
‫De asemenea, înseamnă că, atunci când încărcăm și descărcăm, nu trebuie să
‫încărcăm și
‫să descărcăm aceleași straturi pe care le avem deja pe cealaltă parte. Dacă ar trebui să aveți propria imagine și
‫ați fost personalizat să vă faceți și apoi ați adăugat, să spunem, un server Apache pe lângă acesta ca pe un
‫alt nivel din fișierul Docker și apoi să deschideți portul 80. Apoi, chiar la sfârșit, i-ați spus să copiați în codul sursă, dar de fapt ați ajuns
‫să aveți două Dockerfile diferite pentru două site-uri diferite și fiecare linie din Dockerfile a
‫fost aceeași, cu excepția acelui ultim ultim pic în care ați copiat site-ul Web A în imagine și apoi pe
‫site-ul B, ați termina cu două imagini. Vom arăta asta într-un minut. Aceasta reprezintă o singură imagine
‫și aceasta reprezintă o singură imagine, dar singurele fișiere care sunt stocate în realitate sunt acesta,
‫acesta, acest strat și apoi acest strat mic și apoi acest strat mic.
‫Deci, nu mai stocăm întregul set de straturi de imagine mai mult decât o dată dacă sunt într-adevăr aceleași straturi.
‫Cum funcționează acest lucru cu containerele?
‫Dacă aveți imaginea dvs., să presupunem că avem imaginea noastră Apache și ne decidem să rulați un container în
‫afara acestuia, tot ce face Docker este că creează un nou strat de citire / scriere pentru
‫containerul respectiv deasupra acelei imagini Apache. Când percepem sistemul de fișiere și toate aceste lucruri,
‫toate containerele și imaginile arată doar ca un sistem de fișiere obișnuit, dar sub driverul de stocare folosit de
‫Docker este de fapt straturi, cum ar fi o stivă de clătite, toate
‫aceste schimbări una peste alta.
‫Așadar, dacă am fugit simultan două containere de pe aceeași imagine Apache, containerul 1 și containerul 2 ar arăta numai în ceea
‫ce privește spațiul de fișiere, acestea ar fi doar diferența dintre ceea ce sa întâmplat cu
‫acel recipient live care rulează și ce se întâmplă în imaginea de bază, care este numai pentru citire.
‫Când rulați Containere și schimbați fișierele care veneau prin imagine, să presupunem
‫că am început containerul 3 și am intrat și am schimbat un fișier care se afla în această imagine în containerul
‫care rulează ...
‫acest lucru este cunoscut sub numele de copy-on-write.
‫Ceea ce face este sistemul de fișiere va duce acel fișier din imagine și îl va copia în această diferențiere ...
‫Aici sus... și să stocați o copie a acelui fișier în stratul containerului.
‫Deci, acum containerul este doar doar procesul care rulează și acele
‫fișiere care sunt diferite de cele din imaginea Apache.
‫Dacă ne întoarcem la lista noastră de imagini și ne uităm la aceste comenzi din nou, și ne uităm
‫la partea de jos și să vedem cum sunt diferite datele? De fapt, putem vedea că această imagine a fost schimbată în
‫Docker Hub și a fost actualizată în timp, că aceste modificări nu au
‫fost schimbate la nivelul cel mai de jos în patru săptămâni și apoi ultimele schimbări s-au produs în ultimele
‫două săptămâni.
‫Apropo, nu-ți face griji pentru partea lipsă.
‫De fapt, este doar un nume incorect în interiorul interfeței Docker.
‫Nu înseamnă că ceva e în neregulă sau este greșit configurat. Ceea ce inseamna este ca, intr-adevar, aceasta imagine mysql
‫chiar aici este acel ID de imagine.
‫Celelalte straturi din imagine nu sunt de fapt imagini în sine.
‫Ele sunt doar straturi în interiorul acestei imagini,
‫și astfel ei nu ar avea neapărat propriul lor id de imagine acolo.
‫Personal, cred că este puțin înșelătoare în interfață să spunem asta, dar așa au scris ei.
‫Deci, acum că avem un simț al comenzii de istorie pentru a
‫ne arăta ce ar putea fi făcută o imagine, să folosim comanda de inspectare.
‫Ceea ce face acest lucru este acest lucru ne oferă toate detaliile despre imagine.
‫Aceasta este, în principiu, metadatele. Amintiți-vă când am vorbit despre faptul că
‫o imagine este alcătuită din două părți, binarele
‫și dependențele ei, și apoi metadatele despre acea imagine? Inspectați-vă că vă oferă metadatele.
‫Pe lângă informațiile de bază, cum ar fi ID-ul imaginii și etichetele sale, veți obține tot felul de detalii despre modul în care această imagine
‫se așteaptă să fie rulată.
‫De fapt are opțiunea de a expune aceste două porturi în interiorul imaginii, astfel încât să știți când doriți
‫să-l porniți, ce porturi trebuie să se deschidă în interiorul gazdei Docker dacă doriți să acceptați conexiunile.
‫De fapt, puteți vedea că au fost transmise variabilele de mediu,
‫inclusiv versiunea Nginx care rulează și calea. De fapt, puteți vedea comanda pe care o va rula la pornirea imaginii
‫în mod implicit.
‫Din nou, multe dintre aceste lucruri se pot schimba de fapt, așa cum am făcut-o mai devreme cu comanda de rulare
‫a containerului docker.
‫Dar acestea ne arată toate defectele și alte informații interesante cum ar fi autorul, și
‫aici, în partea de jos, că este o arhitectură a AMD64, care este destul de mult ca în prezent
‫toate PC-urile și Mac-urile obișnuite.
‫Nu avem prea multe mașini pe 32 de biți, deci aceasta este doar o arhitectură Intel standard de
‫64 de biți și este concepută pentru a funcționa pe sistemul de operare Linux.
‫Ok, o revizuire rapidă.
‫Așa că am învățat multe despre imagini și despre felul în care sunt realizate
‫și aflăm că nu sunt chiar atât de complexe. Într-adevăr, sunt doar o serie de modificări ale sistemului de fișiere și metadate despre aceste modificări.
‫Ați învățat că fiecare strat are propria sa identitate unică ca SHA.
‫Ele sunt stocate o singură dată pe fiecare sistem, deci pe fiecare daemon Docker, fiecare strat este reprezentat doar o singură dată
‫în sistemul de fișiere.
‫Acest lucru ne oferă o mulțime de economii în spațiu, precum și timpul de transfer în trimiterea imaginilor înainte și înapoi
‫între registre, cum ar fi Docker Hub. Și, într-adevăr, când porniți un
‫container, este doar un singur strat de modificări pe lângă o imagine existentă.
‫Deci, de obicei, este foarte mic. Am aflat despre istorie și inspectăm comenzile și cum ne pot
‫învăța ce se întâmplă în interiorul unei imagini și cum a fost făcută.