Primul pas în desfășurarea în Kubernetes este plasarea aplicației dvs. într-un container. În această serie, vom examina cum să creăm o imagine a unui container mic și sigur.
Datorită Docker, crearea imaginilor de containere nu a fost niciodată atât de simplă. Indicați imaginea de bază, adăugați modificările dorite și creați containerul.
Cu toate că această abordare este excelentă pentru început, utilizarea imaginilor de bază implicite poate duce la gestionarea nesigură a imaginilor mari, pline de vulnerabilități.
În plus, majoritatea imaginilor din Docker folosesc ca imagine de bază Debian sau Ubuntu, iar deși acest lucru asigură o compatibilitate excelentă și o adaptare ușoară (fișierul Docker ocupă doar două rânduri de cod), imaginile de bază pot adăuga sute de megabiți de sarcină suplimentară în containerul dvs. De exemplu, un simplu fișier node.js pentru aplicația Go „hello-world” ocupă aproximativ 700 de megabiți, în timp ce dimensiunea propriu-zisă a aplicației dvs. este de doar câțiva megabiți.
Astfel, toată această sarcină suplimentară reprezintă o risipă de spațiu digital și un loc ideal pentru vulnerabilități și erori de securitate. Prin urmare, să luăm în considerare două moduri de a reduce dimensiunea imaginii containerului.
Primul este utilizarea imaginilor de bază de dimensiuni mici, al doilea este utilizarea modelului de proiectare Builder Pattern. Folosirea imaginilor de bază mai mici este probabil cel mai simplu mod de a reduce dimensiunea containerului dvs. Cel mai probabil, limbajul sau stiva pe care o folosiți oferă o imagine originală a aplicației de dimensiuni mult mai mici decât imaginea implicită. Să aruncăm o privire asupra containerului nostru node.js.
Imaginile de bază node:8 în Docker au, în mod implicit, o dimensiune de 670 MB, în timp ce dimensiunea node:8-alpine este de doar 65 MB, adică de 10 ori mai mică. Folosind o imagine de bază Alpine mai mică, veți reduce semnificativ dimensiunea containerului dumneavoastră. Alpine este o distribuție Linux mică și ușoară, care este foarte populară printre utilizatorii Docker, deoarece este compatibilă cu multe aplicații, păstrând în același timp dimensiunea mică a containerelor. Spre deosebire de imaginea de bază standard Docker „node”, „node:alpine” elimină multe fișiere și programe auxiliare, păstrând doar cele necesare pentru a rula aplicația dumneavoastră.
Pentru a trece la o imagine de bază mai mică, actualizați pur și simplu fișierul Docker pentru a începe să lucrați cu noua imagine de bază:
Acum, spre deosebire de vechea imagine onbuild, trebuie să copiați codul în container și să instalați orice dependențe. În noul fișier Docker, containerul începe cu imaginea node:alpine, apoi creează un director pentru cod, instalează dependențele folosind managerul de pachete NPM și, în final, rulează server.js.
Cu această actualizare, obțineți un container de 10 ori mai mic. Dacă limbajul dumneavoastră de programare sau stiva nu are o opțiune de reducere a imaginii de bază, folosiți Alpine Linux. Acesta va oferi, de asemenea, posibilitatea de a gestiona complet conținutul containerului. Utilizarea imaginilor de bază de dimensiuni mici este o modalitate excelentă de a crea rapid containere mici. Însă, se poate obține o reducere și mai mare folosind Modelul Builder.
În limbajele interpretate, codul sursă este mai întâi transmis interpretatorului și apoi este executat direct. În limbajele compilate, codul sursă este mai întâi transformat în cod compilat. În acest proces, compilarea folosește adesea instrumente care nu sunt necesare pentru a rula codul. Acest lucru înseamnă că puteți elimina complet aceste instrumente din containerul final. Pentru aceasta, se poate folosi Modelul Builder.
Codul este creat în primul container și compilat. Apoi, codul compilat este împachetat în containerul final fără compilatoare și instrumente necesare pentru compilarea acestui cod. Să trecem prin acest proces cu aplicația Go. Mai întâi, vom trece de la imaginea onbuild la Alpine Linux.
În fișierul Docker nou, containerul începe cu imaginea golang:alpine. Apoi, creează un catalog pentru cod, îl copiază în codul sursă, creează acel cod sursă și pornește aplicația. Acest container este mult mai mic decât containerul onbuild, dar încă conține compilatorul și alte instrumente Go, de care, de fapt, nu avem nevoie. Așadar, să extragem doar programul compilat și să-l punem în propriul nostru container.
Poți observa ceva ciudat în acest fișier Docker: conține două linii FROM. Prima secțiune din cele 4 linii arată exact ca fișierul Docker anterior, cu excepția faptului că folosește cuvântul cheie AS pentru a da un nume acestei etape. În următoarea secțiune, există o nouă linie FROM, permițându-ne să începem o nouă imagine, folosind Alpine Raw în loc de imaginea golang:alpine ca bază.
Raw Alpine Linux nu are certificate SSL instalate, ceea ce va duce la eșecul majorității apelurilor API prin protocolul HTTPS, așa că să instalăm câteva certificate CA rădăcină.
Iar acum partea interesantă: pentru a copia codul compilat din primul container în al doilea, poți folosi pur și simplu comanda COPY, situată în linia 5 din a doua secțiune. Aceasta va copia doar un singur fișier aplicație și nu va afecta instrumentele Go. Noua fișier Docker multi-etapă va conține o imagine a containerului cu doar 12 megabytes, în timp ce imaginea de bază a containerului era de 700 megabytes, ceea ce face o mare diferență!
Așadar, utilizarea unor imagini de bază mici și a Modelului Builder sunt metode excelente de a crea containere mult mai mici fără un volum mare de muncă.
Este posibil ca, în funcție de stiva aplicației, să existe metode suplimentare pentru a reduce dimensiunea imaginii și a containerului, dar have container small unquestionable measure benefits? Să analizăm două aspecte în care containerele mici sunt extrem de eficiente – performanța și securitatea.
Pentru a evalua creșterea performanței, să analizăm durata procesului de creare a unui container, de încărcare a acestuia în registru (push) și de extragerea ulterioară din acesta (pull). Puteți observa că un container mai mic are un avantaj incontestabil comparativ cu un container mai mare.
Docker va cache-ui straturile, astfel încât construcțiile ulterioare vor fi foarte rapide. Totuși, în multe sisteme CI utilizate pentru construcția și testarea containerelor, straturile nu sunt cache-uite, ceea ce duce la economii semnificative de timp. Așa cum se poate vedea, timpul de construire al unui container mare, în funcție de puterea computerului dvs., variază între 34 și 54 de secunde, iar pentru un container redus cu ajutorul Builder Pattern – între 23 și 28 de secunde. Pentru astfel de operații, creșterea performanței va fi de 40-50%. Așa că gândiți-vă de câte ori creați și testați codul dvs.
După ce containerul este construit, trebuie să încărcați imaginea sa (push container image) în registrul containerelor pentru a o utiliza ulterior în clusterul dvs. Kubernetes. Vă recomand să folosiți registrul de containere Google.
Folosind Google Container Registry (GCR), plătiți doar pentru stocarea „bruta” și pentru rețea, iar taxa suplimentară pentru gestionarea containerelor nu este percepută. Este confidențial, sigur și foarte rapid. GCR folosește multe trucuri pentru a accelera operația pull. Așa cum puteți vedea, încărcarea imaginii containerului Docker Container Image folosind go:onbuild, în funcție de performanța computerului, va dura între 15 și 48 de secunde, iar aceeași operație cu un container mai mic – între 14 și 16 secunde, având în vedere că pentru computerele mai puțin performante, avantajul de viteză al operației crește de 3 ori. Pentru mașini mari, timpul este aproximativ același, deoarece GCR folosește un cache global pentru baza comună de imagini, ceea ce înseamnă că nu trebuie să le descărcați deloc. La computerele cu procesor de mică capacitate, CPU-ul este un punct slab, astfel că avantajul utilizării containerelor mici este mult mai semnificativ aici.
Dacă utilizați GCR, vă recomand cu tărie să aplicați Google Container Builder (GCB) ca parte a sistemului dvs. de construcție.
După cum puteți observa, utilizarea acestuia permite obținerea unor rezultate mult mai bune în reducerea duratei operațiunii Build+Push, comparativ chiar cu o mașină performantă - în acest caz, procesul de construire și trimitere a containerelor către gazdă se accelerează aproape de două ori. În plus, în fiecare zi beneficiați de 120 de minute de construire gratuit, ceea ce în majoritatea cazurilor satisface nevoile de creare a containerelor.
Următoarea este cea mai importantă metrică de performanță - viteza de extragere sau descărcare a containerelor Pull. Și dacă nu vă interesează foarte mult timpul folosit pentru operațiunea push, durata procesului pull afectează semnificativ performanța generală a sistemului. Să presupunem că aveți un cluster din trei noduri și unul dintre ele eșuează. Dacă folosiți un sistem de gestionare, cum ar fi Google Kubernetes Engine, acesta va înlocui automat nodul nefuncțional cu unul nou. Cu toate acestea, acest nou nod va fi complet gol și va trebui să mutați toate containerele dvs. pe el pentru a începe să funcționeze. Dacă operațiunea pull va dura prea mult, atunci pe tot acest timp clusterul dvs. va avea o performanță mai scăzută.
Există multe situații în care acest lucru poate să se întâmple: adăugarea unui nou nod în cluster, actualizarea nodurilor sau chiar trecerea la un nou container pentru desfășurare. Astfel, minimizarea timpului de extragere pull devine un factor cheie. Este evident că un container mic se descarcă mult mai repede decât unul mare. Dacă folosiți mai multe containere într-un cluster Kubernetes, economisirea de timp poate fi foarte semnificativă.
Aruncați o privire asupra comparației prezentate: operațiunea pull când se lucrează cu containere mici durează de 4-9 ori mai puțin timp, în funcție de puterea mașinii, comparativ cu aceeași operațiune folosind go:onbuild. Utilizarea imaginilor de bază ale containerelor de dimensiuni mici accelerează semnificativ timpul și viteza cu care noile noduri Kubernetes pot fi desfășurate și pot ieși în internet.
Să discutăm despre securitate. Se consideră că containerele mai mici sunt mult mai sigure decât cele mari, deoarece au o suprafață de atac mai mică. Este adevărat acest lucru? Una dintre cele mai utile funcții ale Google Container Registry este capacitatea de a scana automat containerele pentru vulnerabilități. Cu câteva luni în urmă, am creat atât containere onbuild, cât și multistadiu, așa că să vedem dacă există vulnerabilități.
Rezultatul este uimitor: într-un container mic au fost descoperite doar 3 vulnerabilități medii, iar în unul mare - 16 critice și 376 de alte vulnerabilități. Dacă examinăm conținutul containerului mare, se observă că cele mai multe probleme de securitate nu au legătură cu aplicația noastră, ci cu programele pe care nici măcar nu le folosim. De aceea, când oamenii vorbesc despre o mare suprafață pentru atacuri, se referă exact la acest lucru.
Concluzia este evidentă: creați containere mici, deoarece acestea oferă avantaje reale în ceea ce privește performanța și securitatea sistemului dumneavoastră.
Puțin publicitate 🙂
Mulțumim că rămâneți cu noi. Vă plac articolele noastre? Doriți să vedeți mai multe materiale interesante? Susțineți-ne, efectuând o comandă sau recomandându-ne prietenilor, , un echivalent unic pentru serverele entry-level, care a fost creat de noi pentru voi: (sunt disponibile opțiuni cu RAID1 și RAID10, până la 24 nuclee și până la 40GB DDR4).
Dell R730xd la jumătate de preț în centrul de date Equinix Tier IV din Amsterdam? Numai la noi în Olanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — de la 99 $! Citiți despre
Sursa: habr.com
