Prvi korak implementacije u Kubernetesu je smještaj vaše aplikacije u kontejner. U ovoj seriji ćemo razmotriti kako možete stvoriti sliku malog i sigurnog kontejnera.
Zahvaljujući Dockeru, stvaranje slika kontejnera nikad nije bilo lakše. Odredite osnovnu sliku, dodajte svoje izmjene i stvorite kontejner.
Iako je ova metoda izvrsna za početak, korištenje osnovnih slika prema zadanim postavkama 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 iako to osigurava izvrsnu kompatibilnost i jednostavnu prilagodbu (Docker datoteka zahtijeva samo dvije linije koda), osnovne slike mogu dodati stotine megabajta dodatnog opterećenja u vaš kontejner. Na primjer, jednostavna datoteka node.js aplikacije Go "hello-world" zauzima oko 700 megabajta, dok je veličina same vaše aplikacije svega nekoliko megabajta.
Dakle, sve to dodatno opterećenje - prazna je potrošnja digitalnog prostora i izvrstan skriveni prostor za ranjivosti i greške u sigurnosti sustava. Stoga, razmotrimo dva načina smanjenja veličine slike kontejnera.
Prvi je korištenje osnovnih slika male veličine, drugi je korištenje obrazaca dizajna Builder Pattern. Korištenje manjih osnovnih slika vjerojatno je najlakši način smanjenja veličine vašeg kontejnera. Vjerojatno vaš jezik ili tehnologija koju koristite nudi izvornu sliku aplikacije puno manjeg veličine od zadane slike. Pogledajmo naš kontejner node.js.
Prema zadanim postavkama, veličina osnovne slike node:8 u Dockeru iznosi 670 MB, dok veličina node:8-alpine iznosi samo 65 MB, što je 10 puta manje. Koristeći manju osnovnu sliku Alpine, znatno smanjujete veličinu svog kontejnera. Alpine je mali i lagani Linux distribucija koja je vrlo popularna među korisnicima Dockera jer je kompatibilna s mnogim aplikacijama, dok istovremeno održava malu veličinu kontejnera. Za razliku od standardne Docker slike "node", "node:alpine" uklanja mnoge pomoćne datoteke i programe, ostavljajući samo ono što je dovoljno za pokretanje vaše aplikacije.
Da biste prešli na manju osnovnu sliku, jednostavno ažurirajte Docker datoteku kako biste započeli rad s novom osnovnom slikom:
Sada, za razliku od stare slike onbuild, trebate kopirati svoj kod u kontejner i instalirati sve ovisnosti. U novoj Docker datoteci kontejner počinje s slikom node:alpine, zatim kreira katalog za kod, instalira ovisnosti pomoću upravitelja paketa NPM i naposljetku pokreće server.js.
S ovom nadogradnjom dobivate kontejner 10 puta manje veličine. Ako vaš programski jezik ili skup ne podržava smanjenje osnovne slike, koristite Alpine Linux. Također će omogućiti potpunu kontrolu nad sadržajem kontejnera. Korištenje osnovnih slika male veličine izvrstan je način za brzo stvaranje malih kontejnera. No, još veće smanjenje može se postići korištenjem Builder Patterna.
U interpretiranim jezicima, izvorni kod prvo se prosljeđuje interpreteru, a zatim se izravno izvršava. U kompiliranim jezicima, izvorni kod se prethodno pretvara u kompajlirani kod. Pri tome, kompilacija često koristi alate koji zapravo nisu potrebni za pokretanje koda. To znači da te alate možete potpuno ukloniti iz konačnog kontejnera. Za to možete koristiti Builder Pattern.
Kod se stvara u prvom kontejneru i kompajlira. Zatim se kompajlirani kod pakira u konačni kontejner bez kompajlera i alata potrebnih za kompilaciju tog koda. Prođimo kroz ovaj proces s Go aplikacijom. Prvo, prijeći ćemo s slike onbuild na Alpine Linux.
U novoj datoteci Docker kontejner započinje s imidžom golang:alpine. Zatim stvara direktorij za kod, kopira izvorni kod u njega, gradi ovaj izvorni kod i pokreće aplikaciju. Ovaj kontejner je puno manji od onbuild kontejnera, ali još uvijek sadrži kompajler i druge Go alate koji nam zapravo nisu potrebni. Stoga, hajdemo jednostavno izvući kompilirani program i smjestiti ga u naš vlastiti kontejner.
Možda ćete primijetiti nešto neobično u ovoj Docker datoteci: ona sadrži dvije FROM linije. Prvi odjeljak od 4 linije izgleda točno onako kao i prethodna Docker datoteka, osim što koristi ključnu riječ AS kako bi dao ime ovoj fazi. U sljedećem odjeljku postoji nova FROM linija koja omogućava započinjanje novog imidža, pri čemu umjesto imidža golang:alpine kao osnovnog imidža koristimo Raw alpine.
Raw Alpine Linux nema instalirane SSL certifikate, što će uzrokovati neuspjeh većine API poziva putem HTTPS protokola, stoga hajdemo instalirati nekoliko korijenskih CA certifikata.
A sada dolazi najslađi dio: za kopiranje kompileranog koda iz prvog kontejnera u drugi možemo jednostavno koristiti COPY naredbu smještenu u 5. liniji drugog odjeljka. Ona će kopirati samo jednu datoteku aplikacije i neće dirati uslužne alate Go. Nova višestupanjska Docker datoteka sadržavat će imidž kontejnera veličine samo 12 megabajta, dok je izvorni imidž kontejnera imao 700 megabajta, što je velika razlika!
Dakle, korištenje malih osnovnih imidža i Builder Pattern sjajni su načini za izradu kontejnera daleko manjih veličina bez previše posla.
Moguće je da, ovisno o stogu aplikacije, postoje dodatni načini za smanjenje veličine imidža i kontejnera, ali imaju li stvarno mali kontejneri mjere prednosti? Pogledajmo dva aspekta gdje su mali kontejneri izuzetno učinkoviti – to su performanse i sigurnost.
Kako bismo procijenili rast performansi, razmotrit ćemo trajanje procesa stvaranja kontejnera, njegovo umetanje u registry (push) i naknadno preuzimanje iz njega (pull). Možete vidjeti da manji kontejner ima neospornu prednost u odnosu na veći kontejner.
Docker će缓存irati slojeve, tako da će sljedeće kompilacije biti vrlo brze. Međutim, u mnogim CI sustavima koji se koriste za izgradnju i testiranje kontejnera, slojevi se ne кешiraju, stoga ovdje postoji značajna ušteda vremena. Kao što možete vidjeti, vrijeme izgradnje kontejnera velike veličine, ovisno o snazi vašeg računala, iznosi od 34 do 54 sekunde, dok vrijeme za korištenje kontejnera smanjenog pomoću Builder Pattern iznosi od 23 do 28 sekundi. Za operacije ovog tipa, povećanje performansi iznosit će 40-50%. Zbog toga se samo zapitajte koliko često stvarate i testirate svoj kod.
Nakon što je kontejner izgrađen, trebate umetnuti njegovu sliku (push container image) u registry kontejnera kako biste je koristili u svom Kubernetes klasteru. Preporučujem korištenje Google Container Registry.
Korištenjem Google Container Registry (GCR), plaćate samo za "sirovo" skladište i mrežu, a dodatna naknada za upravljanje kontejnerima se ne naplaćuje. Ovo je povjerljivo, sigurno i vrlo brzo. GCR koristi mnoge trikove kako bi ubrzao operaciju pull. Kao što možete vidjeti, umetanje slike kontejnera Docker Container Image prilikom korištenja go:onbuild ovisno o performansama računala trajat će od 15 do 48 sekundi, dok će ista operacija s manjim kontejnerom trajati od 14 do 16 sekundi, pri čemu se za manje performansne strojeve prednost u brzini operacije povećava tri puta. Na velikim strojevima vrijeme je otprilike isto, budući da GCR koristi globalni cache za zajedničku bazu slika, tako da ih uopće ne morate učitati. Na računalima male snage CPU je usko grlo, stoga je prednost korištenja malih kontejnera ovdje mnogo izraženija.
Ako koristite GCR, toplo preporučujem upotrebu Google Container Builder (GCB) kao dijela vašeg sustava izgradnje.
Kao što vidite, njegovo korištenje omogućava postizanje znatno boljih rezultata u smanjenju trajanja Build+Push operacija, čak i od produktivne mašine – u ovom slučaju, proces izgradnje i slanja kontejnera na host se skoro udvostručuje. Dodatno, svaki dan dobivate 120 minuta besplatnog izgradnje, što u većini slučajeva zadovoljava potrebe za izradom kontejnera.
Sljedeća je najvažnija metrika performansi – brzina preuzimanja, ili Pull kontejnera. Ako vas ne brine previše vrijeme potrebno za push operaciju, trajanje pull procesa ozbiljno utječe na cjelokupnu učinkovitost sustava. Pretpostavimo da imate klaster od tri čvora, a jedan od njih doživljava kvar. Ako koristite sustav upravljanja poput Google Kubernetes Engine, automatski će zamijeniti neispravan čvor novim. Međutim, taj novi čvor će biti potpuno prazan, i morat ćete prebaciti sve vaše kontejnera u njega da bi počeo raditi. Ako pull operacija zauzme dovoljno dugo, vaš klaster će cijelo to vrijeme raditi s smanjenom učinkovitošću.
Ima mnogo situacija u kojima se ovako nešto može dogoditi: dodavanje novog čvora u klaster, ažuriranje čvorova ili čak prelazak na novi kontejner za implementaciju. Dakle, minimiziranje vremena preuzimanja postaje ključni faktor. Neosporno je da se mali kontejner preuzima mnogo brže od velikog. Ako koristite više kontejnera u Kubernetes klasteru, ušteda vremena može biti vrlo značajna.
Pogledajte usporedbu: pull operacija dok se radi s malim kontejnerima traje 4-9 puta manje vremena, ovisno o snazi mašine, nego ista operacija s korištenjem go:onbuild. Korištenje zajedničkih osnovnih slika malih kontejnera značajno ubrzava vrijeme i brzinu s kojom se novi Kubernetes čvorovi mogu raspoređivati i povezivati s internetom.
Razmotrimo pitanje sigurnosti. Smatra se da su manji kontejneri puno sigurniji od većih, jer imaju manju površinu napada. Je li to zaista tako? Jedna od najkorisnijih funkcija Google Container Registry je mogućnost automatskog skeniranja vaših kontejnera radi ranjivosti. Prije nekoliko mjeseci napravio sam i onbuild i višekratne kontejner, pa pogledajmo ima li tu kakvih ranjivih mjesta.
Rezultat je impresivan: u malom kontejneru pronađene su samo 3 srednje ranjivosti, dok je u velikom 16 kritičnih i 376 drugih ranjivosti. Kada pogledate sadržaj velikog kontejnera, vidljivo je da većina problema sa sigurnošću nema veze s našom aplikacijom, već je povezana s programima koje čak ne koristimo. Zato kada ljudi govore o velikoj površini za napade, misle na to.
Zaključak je jasan: kreirajte male kontejnera, jer donose stvarne prednosti u performansama i sigurnosti vašeg sustava.
Malo reklame 🙂
Hvala što ostajete s nama. Sviđa li vam se naše članke? Želite li vidjeti više zanimljivih materijala? Podržite nas narudžbom ili preporučite prijateljima, , jedinstveni analog entry-level servera koji smo razvili za vas: (dostupne opcije s RAID1 i RAID10, do 24 jezgre i do 40GB DDR4).
Dell R730xd je 2 puta jeftiniji u data centaru Equinix Tier IV u Amsterdamu? Samo kod nas u Nizozemskoj! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Pročitajte o tome
Izvor: habr.com
