Prvi korak implementacije na Kubernetes je stavljanje vaše aplikacije u spremnik. U ovoj seriji ćemo pogledati kako možete stvoriti malu, sigurnu sliku spremnika.
Zahvaljujući Dockeru, stvaranje slika spremnika nikada nije bilo lakše. Navedite osnovnu sliku, dodajte svoje promjene i izradite spremnik.
Iako je ova tehnika izvrsna za početak, korištenje zadanih osnovnih slika može dovesti do nesigurnog rada s velikim slikama punim ranjivosti.
Osim toga, većina slika u Dockeru koristi Debian ili Ubuntu kao osnovnu sliku, i dok to pruža izvrsnu kompatibilnost i jednostavnu prilagodbu (Docker datoteka zauzima samo dva retka koda), osnovne slike mogu dodati stotine megabajta dodatnog opterećenja vašem spremniku. Na primjer, jednostavna datoteka node.js za aplikaciju Go "hello-world" ima oko 700 megabajta, dok je vaša stvarna aplikacija samo nekoliko megabajta.
Dakle, sav ovaj dodatni posao je gubitak digitalnog prostora i odlično mjesto za skrivanje sigurnosnih propusta i grešaka. Dakle, pogledajmo dva načina za smanjenje veličine slike spremnika.
Prvi je korištenje malih osnovnih slika, drugi je korištenje Builder Pattern-a. Korištenje manjih osnovnih slika vjerojatno je najlakši način da smanjite veličinu vašeg spremnika. Najvjerojatnije jezik ili hrpa koju koristite pruža izvornu sliku aplikacije koja je mnogo manja od zadane slike. Pogledajmo naš kontejner node.js.
Prema zadanim postavkama u Dockeru, veličina osnovne slike node:8 je 670 MB, a veličina slike node: 8-alpine je samo 65 MB, odnosno 10 puta manja. Korištenjem manje Alpine baze slike, značajno ćete smanjiti veličinu vašeg spremnika. Alpine je mala i lagana distribucija Linuxa koja je vrlo popularna među korisnicima Dockera jer je kompatibilna s mnogim aplikacijama dok su spremnici mali. Za razliku od standardne Docker "node" slike, "node:alpine" uklanja puno servisnih datoteka i programa, ostavljajući samo one koji su dovoljni za pokretanje vaše aplikacije.
Za prelazak na manju osnovnu sliku, jednostavno ažurirajte Dockerfile da počnete raditi s novom osnovnom slikom:
Sada, za razliku od stare onbuild slike, trebate kopirati svoj kod u spremnik i instalirati sve ovisnosti. U novoj Docker datoteci, spremnik počinje slikom node:alpine, zatim stvara direktorij za kod, instalira ovisnosti pomoću NPM upravitelja paketa i na kraju pokreće server.js.
Ova nadogradnja rezultira spremnikom koji je 10 puta manji. Ako vaš programski jezik ili skup nema funkciju smanjenja osnovne slike, koristite Alpine Linux. Također će pružiti mogućnost potpunog upravljanja sadržajem spremnika. Korištenje malih osnovnih slika izvrstan je način za brzo stvaranje malih spremnika. Ali još veće smanjenje može se postići pomoću Builder Pattern-a.
U interpretiranim jezicima, izvorni kod se prvo prosljeđuje tumaču, a zatim se izravno izvršava. U prevedenim jezicima, izvorni kod se prvo pretvara u prevedeni kod. Međutim, kompilacija često koristi alate koji zapravo nisu potrebni za pokretanje koda. To znači da te alate možete potpuno ukloniti iz konačnog spremnika. Za ovo možete koristiti Builder Pattern.
Kod se kreira u prvom spremniku i kompajlira. Prevedeni kod se zatim pakira u konačni spremnik bez kompajlera i alata potrebnih za kompajliranje tog koda. Provedimo Go aplikaciju kroz ovaj proces. Prvo ćemo prijeći s onbuild slike na Alpine Linux.
U novoj Docker datoteci spremnik počinje slikom golang:alpine. Zatim stvara direktorij za kod, kopira ga u izvorni kod, gradi taj izvorni kod i pokreće aplikaciju. Ovaj spremnik je puno manji od onbuild spremnika, ali još uvijek sadrži kompajler i druge Go alate koji nam zapravo nisu potrebni. Dakle, izdvojimo kompajlirani program i stavimo ga u vlastiti spremnik.
Možda ćete primijetiti nešto čudno u ovoj Docker datoteci: sadrži dva FROM reda. Odjeljak od prva 4 retka izgleda potpuno isto kao i prethodni Dockerfile osim što koristi ključnu riječ AS za imenovanje ove faze. Sljedeći odjeljak ima novi red FROM za početak nove slike, gdje ćemo umjesto golang:alpine slike koristiti Raw alpine kao osnovnu sliku.
Raw Alpine Linux nema instaliran nijedan SSL certifikat, što će uzrokovati neuspjeh većine API poziva preko HTTPS-a, pa instalirajmo neke korijenske CA certifikate.
Sada dolazi zabavni dio: za kopiranje kompiliranog koda iz prvog spremnika u drugi, možete jednostavno koristiti naredbu COPY koja se nalazi u retku 5 drugog odjeljka. Kopirat će samo jednu datoteku aplikacije i neće utjecati na alate uslužnog programa Go. Nova višestupanjska Docker datoteka sadržavat će sliku spremnika veličine samo 12 megabajta, u usporedbi s originalnom slikom spremnika koja je imala 700 megabajta, što je velika razlika!
Stoga su korištenje malih osnovnih slika i uzorka za graditelje sjajni načini za stvaranje puno manjih spremnika bez puno rada.
Moguće je da ovisno o hrpi aplikacija postoje dodatni načini za smanjenje veličine slike i spremnika, no imaju li mali spremnici doista mjerljivu korist? Pogledajmo dva područja u kojima su mali spremnici iznimno učinkoviti – performanse i sigurnost.
Za procjenu povećanja performansi, uzmite u obzir trajanje procesa stvaranja spremnika, njegovog umetanja u registar (push) i zatim dohvaćanja od tamo (pull). Možete vidjeti da manji spremnik ima jasnu prednost u odnosu na veći spremnik.
Docker će predmemorirati slojeve tako da će sljedeće izgradnje biti vrlo brze. Međutim, mnogi CI sustavi koji se koriste za izradu i testiranje spremnika ne predmemoriraju slojeve, tako da postoje značajne uštede vremena. Kao što vidite, vrijeme za izgradnju velikog spremnika, ovisno o snazi vašeg stroja, je od 34 do 54 sekunde, a kada se koristi spremnik smanjeno korištenjem Builder Pattern-a - od 23 do 28 sekundi. Za operacije ove vrste, povećanje produktivnosti bit će 40-50%. Zato samo razmislite o tome koliko puta gradite i testirate svoj kod.
Nakon što je spremnik izgrađen, morate gurnuti njegovu sliku (sliku potisnog spremnika) u registar spremnika kako biste je zatim mogli koristiti u svom Kubernetes klasteru. Preporučujem korištenje registra Google spremnika.
S Googleovim registrom spremnika (GCR) plaćate samo neobrađenu pohranu i umrežavanje, a nema dodatnih naknada za upravljanje spremnikom. Privatan je, siguran i vrlo brz. GCR koristi mnoge trikove kako bi ubrzao operaciju povlačenja. Kao što vidite, umetanje spremnika Docker Container Image pomoću go:onbuild-a će trajati od 15 do 48 sekundi, ovisno o performansama računala, a ista operacija s manjim spremnikom će trajati od 14 do 16 sekundi, a za manje produktivne strojeve prednost u brzini rada povećava se za 3 puta. Za veće strojeve, vrijeme je otprilike isto, budući da GCR koristi globalnu predmemoriju za zajedničku bazu podataka slika, što znači da ih uopće ne morate učitavati. U računalu male snage, CPU je usko grlo, tako da je prednost korištenja malih spremnika ovdje mnogo veća.
Ako koristite GCR, toplo preporučujem korištenje Google Container Buildera (GCB) kao dijela vašeg sustava za izgradnju.
Kao što vidite, njegova uporaba omogućuje vam postizanje puno boljih rezultata u smanjenju trajanja operacije Build+Push čak i od produktivnog stroja - u ovom slučaju, proces izgradnje i slanja spremnika hostu ubrzava se gotovo 2 puta . Osim toga, dobivate 120 besplatnih minuta izrade svaki dan, što u većini slučajeva pokriva vaše potrebe izgradnje spremnika.
Slijedi najvažnija metrika izvedbe – brzina dohvaćanja ili preuzimanja Pull spremnika. A ako vam nije bitno vrijeme potrošeno na operaciju guranja, tada duljina procesa vučenja ima ozbiljan utjecaj na ukupnu izvedbu sustava. Recimo da imate klaster od tri čvora i jedan od njih ne uspije. Ako koristite sustav upravljanja kao što je Google Kubernetes Engine, on će automatski zamijeniti mrtvi čvor novim. Međutim, ovaj će novi čvor biti potpuno prazan i morat ćete povući sve svoje spremnike u njega da bi počeo raditi. Ako operacija povlačenja traje dovoljno dugo, vaš će klaster cijelo vrijeme raditi s nižom izvedbom.
Postoje mnogi slučajevi u kojima se to može dogoditi: dodavanje novog čvora u klaster, nadogradnja čvorova ili čak prebacivanje na novi spremnik za implementaciju. Stoga minimiziranje vremena izvlačenja povlačenjem postaje ključni čimbenik. Neosporno je da se mali spremnik preuzima mnogo brže od velikog. Ako pokrećete više spremnika u Kubernetes klasteru, ušteda vremena može biti značajna.
Pogledajte ovu usporedbu: operacija izvlačenja na malim spremnicima traje 4-9 puta manje vremena, ovisno o snazi stroja, od iste operacije pomoću go:onbuild. Korištenje zajedničkih slika baze malih spremnika značajno ubrzava vrijeme i brzinu kojom se novi Kubernetes čvorovi mogu postaviti i postati online.
Pogledajmo pitanje sigurnosti. Manji spremnici smatraju se puno sigurnijima od većih jer imaju manju površinu za napad. Je li stvarno? Jedna od najkorisnijih značajki Google Container Registry je mogućnost automatskog skeniranja vaših spremnika u potrazi za ranjivostima. Prije nekoliko mjeseci stvorio sam i onbuild i multistage spremnike, pa da vidimo ima li tu kakvih ranjivosti.
Rezultat je nevjerojatan: samo 3 srednje ranjivosti otkrivene su u malom spremniku, a 16 kritičnih i 376 drugih ranjivosti pronađeno je u velikom spremniku. Ako pogledamo sadržaj velikog spremnika, možemo vidjeti da većina sigurnosnih problema nema nikakve veze s našom aplikacijom, već se odnosi na programe koje niti ne koristimo. Dakle, kada ljudi govore o velikoj napadnoj površini, to je ono što misle.
Zaključak je jasan: gradite male spremnike jer oni vašem sustavu pružaju stvarne performanse i sigurnosne prednosti.
Neki oglasi 🙂
Hvala što ste ostali s nama. Sviđaju li vam se naši članci? Želite li vidjeti više zanimljivog sadržaja? Podržite nas narudžbom ili preporukom prijateljima, , jedinstveni analog poslužitelja početne razine, koji smo izmislili za vas: (dostupno s RAID1 i RAID10, do 24 jezgre i do 40 GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV podatkovnom centru u Amsterdamu? Samo ovdje u Nizozemskoj! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 USD! Pročitaj o
Izvor: www.habr.com