Primul pas al implementării în Kubernetes este plasarea aplicației într-un container. În această serie, vom analiza cum puteți crea o imagine de container mică și sigură.
Datorită Docker, crearea de imagini container nu a fost niciodată mai ușoară. Specificați o imagine de bază, adăugați modificările și creați un container.
Deși această tehnică este excelentă pentru început, utilizarea imaginilor de bază implicite poate duce la lucru nesigur cu imagini mari pline de vulnerabilități.
În plus, majoritatea imaginilor din Docker folosesc Debian sau Ubuntu pentru imaginea de bază și, deși acest lucru oferă o compatibilitate excelentă și o personalizare ușoară (un fișier Docker necesită doar două linii de cod), imaginile de bază pot adăuga sute de megaocteți de încărcare suplimentară containerului dvs. De exemplu, un fișier node.js simplu pentru o aplicație Go „hello-world” are aproximativ 700 de megaocteți, în timp ce aplicația dvs. reală are doar câțiva megaocteți.
Așadar, toată această încărcătură suplimentară este o risipă de spațiu digital și o ascunzătoare grozavă pentru vulnerabilități și erori de securitate. Deci, să ne uităm la două moduri de a reduce dimensiunea unei imagini de container.
Prima este utilizarea imaginilor de bază mici, a doua este utilizarea modelului Builder. Utilizarea imaginilor de bază mai mici este probabil cea mai ușoară modalitate de a reduce dimensiunea recipientului. Cel mai probabil, limba sau stiva pe care o utilizați oferă o imagine originală a aplicației, care este mult mai mică decât imaginea implicită. Să aruncăm o privire la containerul nostru node.js.
În mod implicit, în Docker, dimensiunea imaginii de bază nod:8 este de 670 MB, iar dimensiunea imaginii nod: 8-alpine este de numai 65 MB, adică de 10 ori mai mică. Folosind imaginea de bază Alpine mai mică, veți reduce semnificativ dimensiunea containerului. 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 containerele mici. Spre deosebire de imaginea standard „nod” Docker, „node:alpine” elimină o mulțime de fișiere și programe de serviciu, lăsând doar pe acelea care sunt suficiente pentru a rula aplicația.
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. Într-un nou Dockerfile, containerul începe cu o imagine node:alpină, apoi creează un director pentru cod, instalează dependențe folosind managerul de pachete NPM și în cele din urmă rulează server.js.
Această actualizare are ca rezultat un container care este de 10 ori mai mic ca dimensiune. Dacă limbajul sau stiva dumneavoastră de programare nu are funcționalitate de bază de reducere a imaginii, utilizați Alpine Linux. Acesta va oferi, de asemenea, capacitatea de a gestiona pe deplin conținutul containerului. Utilizarea imaginilor de bază mici este o modalitate excelentă de a crea rapid containere mici. Dar o reducere și mai mare poate fi obținută folosind modelul Builder.
În limbile interpretate, codul sursă este mai întâi transmis interpretului și apoi executat direct. În limbile compilate, codul sursă este mai întâi convertit în cod compilat. Cu toate acestea, compilarea folosește adesea instrumente care nu sunt de fapt necesare pentru a rula codul. Aceasta înseamnă că puteți elimina complet aceste instrumente din containerul final. Puteți utiliza Builder Pattern pentru aceasta.
Codul este creat în primul container și compilat. Codul compilat este apoi împachetat într-un container final fără compilatorii și instrumentele necesare pentru a compila acel cod. Să rulăm o aplicație Go prin acest proces. În primul rând, vom trece de la imaginea onbuild la Alpine Linux.
În noul Dockerfile, containerul începe cu o imagine golang:alpină. Apoi creează un director pentru cod, îl copiază în codul sursă, construiește acel cod sursă și rulează aplicația. Acest container este mult mai mic decât containerul onbuild, dar conține încă compilatorul și alte instrumente Go de care nu avem cu adevărat nevoie. Deci haideți doar să extragem programul compilat și să-l punem în propriul său container.
Este posibil să observați ceva ciudat în acest fișier Docker: conține două linii FROM. Prima secțiune de 4 linii arată exact la fel ca fișierul Dockerfile anterior, cu excepția faptului că folosește cuvântul cheie AS pentru a denumi această etapă. Următoarea secțiune are o nouă linie FROM pentru a începe o nouă imagine, unde în loc de imaginea golang:alpine vom folosi Raw alpine ca imagine de bază.
Raw Alpine Linux nu are niciun certificat SSL instalat, ceea ce va duce la eșecul majorității apelurilor API prin HTTPS, așa că haideți să instalăm câteva certificate CA rădăcină.
Acum vine partea distractivă: pentru a copia codul compilat din primul container în al doilea, puteți utiliza pur și simplu comanda COPY situată pe linia 5 a celei de-a doua secțiuni. Va copia doar un fișier de aplicație și nu va afecta instrumentele utilitare Go. Noul fișier Docker în mai multe etape va conține o imagine a containerului care are o dimensiune de doar 12 megaocteți, în comparație cu imaginea containerului original, care era de 700 de megaocteți, ceea ce este o mare diferență!
Prin urmare, utilizarea imaginilor de bază mici și a modelului Builder sunt modalități excelente de a crea containere mult mai mici, fără multă muncă.
Este posibil ca, în funcție de stiva de aplicații, să existe modalități suplimentare de a reduce dimensiunea imaginii și a containerului, dar containerele mici au într-adevăr un beneficiu măsurabil? Să ne uităm la două domenii în care containerele mici sunt extrem de eficiente - performanța și securitatea.
Pentru a evalua creșterea performanței, luați în considerare durata procesului de creare a unui container, inserarea acestuia în registru (push) și apoi preluarea lui de acolo (pull). Puteți vedea că un recipient mai mic are un avantaj distinct față de un recipient mai mare.
Docker va stoca în cache straturile, astfel încât versiunile ulterioare vor fi foarte rapide. Cu toate acestea, multe sisteme CI utilizate pentru construirea și testarea containerelor nu memorează straturi în cache, astfel încât există economii semnificative de timp. După cum puteți vedea, timpul pentru a construi un container mare, în funcție de puterea mașinii dvs., este de la 34 la 54 de secunde, iar atunci când utilizați un container redus folosind modelul Builder - de la 23 la 28 de secunde. Pentru operațiuni de acest fel, creșterea productivității va fi de 40-50%. Așa că gândiți-vă de câte ori construiți și testați codul.
După ce containerul este construit, trebuie să-i împingeți imaginea (push container image) în registrul containerului, astfel încât să îl puteți utiliza apoi în cluster-ul Kubernetes. Recomand să utilizați Google Container Registry.
Cu Google Container Registry (GCR), plătiți doar pentru stocarea brută și conectarea în rețea și nu există taxe suplimentare de gestionare a containerelor. Este privat, sigur și foarte rapid. GCR folosește multe trucuri pentru a accelera operația de tragere. După cum puteți vedea, inserarea unui container Docker Container Image folosind go:onbuild va dura de la 15 la 48 de secunde, în funcție de performanța computerului, iar aceeași operațiune cu un container mai mic va dura de la 14 la 16 secunde și pentru mașinile mai puțin productive. avantajul în viteza de funcționare crește de 3 ori. Pentru mașinile mai mari, timpul este aproximativ același, deoarece GCR utilizează un cache global pentru o bază de date partajată de imagini, ceea ce înseamnă că nu trebuie să le încărcați deloc. Într-un computer cu putere redusă, procesorul este blocajul, astfel încât avantajul utilizării containerelor mici este mult mai mare aici.
Dacă utilizați GCR, vă recomand să utilizați Google Container Builder (GCB) ca parte a sistemului dvs. de compilare.
După cum puteți vedea, utilizarea sa vă permite să obțineți rezultate mult mai bune în reducerea duratei operațiunii Build+Push decât chiar și o mașină productivă - în acest caz, procesul de construire și trimitere a containerelor către gazdă este accelerat de aproape 2 ori . În plus, primiți 120 de minute gratuite de construcție în fiecare zi, ceea ce acoperă nevoile dvs. de construire a containerelor în majoritatea cazurilor.
Urmează cea mai importantă măsură de performanță – viteza de recuperare sau descărcare a containerelor Pull. Și dacă nu vă pasă prea mult de timpul petrecut cu o operație de împingere, atunci durata procesului de tragere are un impact grav asupra performanței generale a sistemului. Să presupunem că aveți un grup de trei noduri și unul dintre ele eșuează. Dacă utilizați un sistem de management precum Google Kubernetes Engine, acesta va înlocui automat nodul mort cu unul nou. Cu toate acestea, acest nou nod va fi complet gol și va trebui să trageți toate containerele în el pentru a începe să funcționeze. Dacă operațiunea de extragere durează suficient de mult, clusterul dvs. va funcționa la performanțe mai scăzute tot timpul.
Există multe cazuri în care acest lucru se poate întâmpla: adăugarea unui nou nod la un cluster, modernizarea nodurilor sau chiar trecerea la un container nou pentru implementare. Astfel, minimizarea timpului de extracție de tragere devine un factor cheie. Este incontestabil că un container mic se descarcă mult mai repede decât unul mare. Dacă rulați mai multe containere într-un cluster Kubernetes, economiile de timp pot fi semnificative.
Uitați-vă la această comparație: o operațiune de tragere pe containere mici durează de 4-9 ori mai puțin timp, în funcție de puterea mașinii, decât aceeași operațiune folosind go:onbuild. Utilizarea imaginilor de bază de containere mici partajate accelerează semnificativ timpul și viteza cu care noile noduri Kubernetes pot fi implementate și pot fi conectate.
Să ne uităm la problema securității. Containerele mai mici sunt considerate mult mai sigure decât cele mai mari, deoarece au o suprafață de atac mai mică. Este într-adevăr? Una dintre cele mai utile caracteristici ale Google Container Registry este capacitatea de a vă scana automat containerele pentru vulnerabilități. Acum câteva luni am creat atât containere onbuild, cât și containere cu mai multe etape, așa că să vedem dacă există vulnerabilități acolo.
Rezultatul este uimitor: doar 3 vulnerabilități medii au fost detectate într-un container mic, iar 16 vulnerabilități critice și alte 376 de vulnerabilități au fost găsite într-un container mare. Dacă ne uităm la conținutul unui container mare, putem observa că majoritatea problemelor de securitate nu au nicio legătură cu aplicația noastră, ci sunt legate de programe pe care nici măcar nu le folosim. Deci, atunci când oamenii vorbesc despre o suprafață mare de atac, la asta se referă.
Concluzia este clară: construiți containere mici, deoarece oferă performanță reală și beneficii de securitate sistemului dumneavoastră.
Câteva reclame 🙂
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, , un analog unic al serverelor entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
Dell R730xd de 2 ori mai ieftin în centrul de date Equinix Tier IV din Amsterdam? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com